Getting Started with Spring Security 3.1

good afternoon my name is Rob Lynch and I'm the spring security lead at SpringSource VMware today we're going to be talking about getting started with spring security 3-1 starting off a little bit about myself I'm the spring security lead at SpringSource VMware as I mentioned before I have over 15 years of web experience and over 10 years of Java experience I've been employed at a number of other places prior to SpringSource and probably the most relevant for this presentation is did over seven years of healthcare security at Cerner corporation so today's agenda we'll start off by talking about what spring security is and how it can benefit you and then we'll discuss how to set up a basic spring security application and after we set it up we'll walk through how spring security is working behind the scenes so afterwards you should have a pretty good understanding of how all the pieces fit together then we'll do some very basic customizations including a custom login page and a login controller and we'll wrap up with global methods security and if we have time maybe a little surprise at the end so oh and also QA so a little bit about spring security before we get into all the details is is formerly known as the CG security so if you see one CS cg security know that they're one in the same but also know that a seizure security is no longer actively maintained so it's important to realize that you want to start with the spring security code base or migrate to the spring security code base if you are starting a new project and spring security is divided into two main concepts authentication and authorization authentication describes the who or who's trying to access a particular resource and you can identify that in the number of different ways for example username and password and you can store that username password in a number of different ways like a database or LDAP spring security provides support for both of these out-of-the-box and if you're storing those credentials you want to make sure that they're secured you've probably seen that a number websites have been compromised had their passwords exposed for their users spring security provides a password encoder interface to ensure that your passwords are hashed and salted to ensure if your data store is compromised your users passwords are not it also offers a number of single sign-on solutions like CAS and Open ID CAS is a standard single sign-on protocol for basically anyone to use but a lot of the academic world uses it because it's free and it supports a lot of features like single logout open ID is another standard single sign-on protocol some of the giants like Google and Yahoo use it so if you're integrate interested in integrating with them that's one way of doing so and spring security also provides a pre authentication module or support and the pre authentication support is basically if you don't want to authenticate with spring security you can still use it so say you are using something like site minder which injects a header into your application to determine what your current user is spring security can still be used you might ask well if I'm already authenticated why would I use spring security and that's the next aspect authorization given I know who is trying to access a particular resource are they allowed to access the resource and in a web-based application this is often times done by URL based security and in spring security among other web applications it's implemented using filters and so filters play a primary role in securing your web application with spring security but URL based security is not necessarily enough and that's because URLs can be manipulated and you can have things like relative pass and it can actually be very tricky to restrict access to domain level objects with just URL based security and therefore it's best to have also method based security and here spring security leverages Springs AOP support to add aspects to your service tier to secure your service tier for you and so you can't invoke the method unless you are granted access to invoke that method and finally spring security has a number of extensions and these extensions demonstrate that while spring security is simple it's also powerful it wasn't initially designed for things like Kerberos or Roth not specifically in mind but there are extensions for OAuth Kerberos and sam'l that exists that are built on top of spring security and this should give you some confidence because in the corporate world or any application that you build you're going to have custom requirements and so it's nice to know that the framework can support those custom requirements but still give you a lot of benefit to get up and running quickly so before we get too involved we're going to do a very quick servlet filter review and I'm sure that most of you understand filters very well but there's all there's two misconceptions or misunderstandings that really make it difficult to understand spring security that we're going to clear up and we'll go through this pretty quick so just bear with me if you understand everything but we'll get started on the rest of content very shortly so here we have a very basic web XML there's nothing fancy about it we map filter one to every URL so now we have the code for filter one and filter one does nothing fancy either it basically prints out a statement before it invokes the rest of our application and we'll notate the greater than sign as before request URL and we'll trace through some requests in just a second and then we run the rest of the application and then after that we print out after request URL so the less than sign we notate is after request URL all right let's see what happens when we make a request to our application here you see we make a HP get to our home URL the first thing that happens is the servlet container recognizes that the filter one is intercepting every request there's nothing surprising here but the one thing that I do want to point out is there's nothing magic about filter one do filter being invoked it's just a method call so here the containers just invoking this method and these interfaces and that exists are just interfaces so we could implement the servlet request ourself it's just an interface we could implement servlet response or self just an interface same thing with filter chain and in fact spring security does a lot of these things and replaces it with the replaces the current applications implementation within a Apted version and so we'll get into that a little bit later but just realize this is just a method call and so the very first thing that would happen when you invoke that is you'd print out before home and that's nothing surprising again and then the next thing that happens is the filter will invoke the filter chain and this this demonstrates aspects in a web based application filters are essentially a way of doing aspect oriented programming in a web based application and it does this in a framework agnostic way since it's built into the container so while the filter doesn't know what the rest application is doing its able to invoke the rest application here we decide that the rest application is going to do a forward to home JSP so home dot JSP is invoked and it writes out a response and afterwards it returns back up to the filter chain and that means that our filter chain new filter is now completed and we get after home one of the things that you might notice is that we've had two URLs involved our slash home and the home dot JSP URL however our filter only printed out one of those URLs and this is one of the first things that people get confused with with spring security is well why isn't it intercepting my forwards or includes or or something like that and that's because filters by default will only intercept HTP requests so if you're interested in intercepting other types of requests you need to update your dispatcher elements in your web XML so here we've explicitly listed the request and the forward dispatcher you have to explicitly list requests as soon as you add any dispatcher elements other than leaving it blank so now we're intercepting requests and forwards so let's see how our request is impacted by this we get home just as we did before and filter one is outputting before home just as before now it invokes the filter chain and it does a forward to home JSP and this time filter one all actually intercepts the home JSP and it outputs before home home JSP writes out to the response and then it returns back up to the second invocation of filter it outputs after home JSP and then it propagates back up to the first invocation of filter one and outputs after home so here you can see that the filter can intercept other URLs but you need to make sure you can figure it correctly in your web XML so spring security as web support is based upon filters so it's very important to have a understanding of how they work behind the scenes and it's rare to use spring security with other dispatcher types but if you're looking for that support it is there you just need to be aware of it and how to configure it and some of the other dispatcher types include requests include forward and error all right so moving on to our second thing and this is just basically to clear up some confusion around the filter chain a lot of people feel like the filter chain is just kind of magic it invoked it does some things with the container and then everything continues but really it's just an interface in that interface it you can view it as invoking the rest of my application so here we have an even more basic filter and it basically invokes the filter chain and I want you to read it as run the rest of my application because if there's another filter in your web XML all it's really doing is invoking security filter if it were a security filter dot do filter and so you can think of it as an indirect way of invoking the rest of your application it's just an abstraction over it and in fact if there was no other filters and it was just a servlet it would be a servlet dot service exact same thing so whenever you see filter chain think of it as running the rest your application and this is important because in spring security we use filters as building blocks so that you get the best usability reusability out of spring security as possible so one filter might try to run the rest application and then you might have another filter say a security filter and that filter might say does the current user have access to this URL if not it will throw a security exception and here you can see we can catch that security exception and then we can handle it by sending a user to a login page for example if they're already logged in you might give them an access to I'd page and this is fundamentally how spring securities web-based support is composed is small discrete units that are very reusable in a web application so enough with our servlet filter review we're going to go ahead and demonstrate our web application and I like to use this application because it's very simple and we can focus on what we're trying to learn it's a messages application and all we do is we can list out an application maybe we can make it a little bigger for you not too much bigger we can list out a list them out and we can create a new message we can display that message list out our messages and view the details of the message nothing fancy at all I'm sure you guys are impressed by my coding skills but all right so now that we've seen our application we realized that there's no security and we want to require people to log in in order to access it so let's see how we can update it to add spring security to it so the basic steps for setting up spring security are adding spring security dependencies pretty common sense update your web XML and create the spring security configuration the very first step is updating our dependencies if you're using maven it looks something like this and so you have spring security core web and config core is just that the core spring security if you're using spring security all you're going to need this jar spring security web is required in any web based application using spring security and so you might not be using spring security with a web based application but if you are you will need this jar and then spring security config if you guys are familiar at all with Springs namespace support this directly maps to that functionality and if you're not familiar with it we'll cover it in more detail but in summary it's a declarative way of setting up your spring security configuration another thing that's important to note is transitive dependencies these are bringing in transitive dependencies and most of you are probably familiar with maven but one of the things to know to string Security's minimum dependency version is three spring 300x if you're trying to use it with spring 3 1x and I say X is a variable then you need to make sure that all your dependency versions match so basically what you want to do is when you open it up you can open up your palm XML and hopefully you can see this probably not but you can type in type in spring and then you can see all the dependencies and here you can see that we're getting collisions in our application so we get spring AOP 3:07 and spring ASM three one two and if you get collisions like that you're going to get problems so make sure you use excludes dependency management or explicitly list the spring versions that you want make sure anything that starts with has a group ID or spring framework that security has the same version anything that's org spring framework has the same version one of the biggest problems with transitive dependency management is trying to resolve those sorts of problems all right so now that we've declared our dependencies with maven if you guys are up-to-date with some of the newer technologies Gradle is another way we won't go over this in detail but if you haven't checked out Gradle do because it's a pretty nice framework but this is how you would declare your dependencies with Gradle the next step is to update your web XML and if you're familiar with spring at all with web-based applications you're probably familiar with the context loader listener you add it to your web application and then you specify the context config location and what's happening behind the scenes is the context loader listener is loading the context config location and it's not specific to spring security at all as I mentioned you've probably already used this if you've done a spring MVC application and what it does is it provides the application context which is basically Springs factory it provides application context so that the rest the application can use that to look up your spring beans and it's rare to interact with application context directly but it's it's also good if you're wanting to know what's HAP behind-the-scenes how things work so let's take a look at some pseudocode of context loader listener because I think as engineers pseudocode is probably the easiest way to describe something so whenever the web application starts up it initializes application context in our context loader listener and it looks something similar to this and you'll notice that the context config location is specified WebM Pring starred xml that corresponds to our context config location in our web XML that we already specified so this is where all our spring configuration must be present you can add multiple lines if you want but it is important to make sure that all your XML configuration or if you're using Java configuration corresponds to this location next the rest your application can now use application context to lookup beans so it's essentially a factory behind the scenes but as I mentioned earlier you will typically not interact with application context directly because you want to use dependency injection so and springs provides support for you to be able to do this and we'll cover that in just one moment so the next step is to update your web XML with the spring security filter chain and for now know that the filter name is very important because this this is a basically a keyword within spring in order to get things set up correctly and we'll go over that in more detail on the next slide but for now know that that's important and the delegating filter proxy is the implementation of it again it's nothing magical and will actually reveal what's happening behind the scenes with it but the delegating filter proxy is just another class like you might implement for a filter and then you would map that to every URL and typically when you map it to every URL you also want to make sure that the filter mapping is a very first entry in your web XML and the reason for this is because filter mappings are order dependent so if you place it after another filter mapping the filter that's before it will not be secured there are exceptions to this rule but do realize that the filter mapping order matters because otherwise spring security will not protect it with URL based security here we have the pseudocode for delegating filter proxy and basically what happens initially is it takes application context from the context loader listener and it's not really important how it obtains that application context because it's unlikely that you'll ever need to obtain it yourself and in fact there's other ways to go about doing it in in many instances but here it gets the application context and it uses it like a factory to get a delegate filter and the delegate filter is what will do all the work so you see here it's looking up a bean by the ID of spring security filter chain where does that come from that comes from our filter name that we declared in our web XML so it's important that because we are using the filter name spring security filter chain that later we define a spring bean by the same name so this is how we tie basically the container which understands nothing about spring for example Tomcat knows nothing about spring to our wet to our spring configuration so it's important that matches up and then whenever do filter is invoked all delegating filter proxy does is it delegates all the work to the bean that it looked up in spring configuration so if that's confusing at all you can think of it as mapping something in your web XML to a filter in your spring being configuration that's what delegating filter proxy does and by default it'll do it by the filter name that you have specified so the next step is we need to create our spring security configuration and as we mentioned earlier it needs to correspond to our context config location so we're going to place it at WebM spring security XML and one of the common problems is making sure your namespace gets set up correctly so we're just going to demonstrate hopefully you guys can see it fairly well we're going to demonstrate how you could do with this this was spring tool suite real quickly if you've already used it it's it's not that exciting but if you've had trouble getting your remembering your namespaces it can be fairly exciting so we're just going to put in a dummy that XML instead because we've already created our type because we've already created our security XML file but basically you do the next and then you can check any of the namespace support that you'll need so here I'll click Next select the security and you can see here it adds all the namespaces that I need and if I forgot one or need to add one later I can use a namespace tag to check the boxes that I might want so again if you've used spring tool suite nothing all that exciting but perhaps a nice feature of it that you might not know so now that we've created our XML file we'll go ahead and move on to this is just a summary of what we did we'll go on to what we're adding to our configuration and what it's doing behind the scenes so here we have an HTTP element security HTTP and what this is doing is this is what's creating our bean by the name of spring security filter chain and so whenever you look it up in the delegating filter proxy this configuration is what's creating it and the very first thing that it does is it says that if any URL matches slash star star I'm going to require the role user so the current user must be have role user and slash star star matches everything so basically every request will require a role user if the user is not logged in then it's going to require the user to login and form login is a way of specifying that that means that if the user is not logged in I will require them to login using a HTML form and in this instance we don't specify the URL for it so spring security will actually generate the login page for us and then when you submit that form form login will validate the username and password and how does it do that it actually asks the authentication manager that you see at the bottom and here we're using an in-memory implementation of that authentication manager with the user of user password a password and roles of role user and it's very easy to swap this out if you're wanting to use JD see or LDAP or something else like that but for demo purposes it helps us get up and running much faster so we'll use the in-memory implementation so now let's see what happens when we use our basic spring security setup the first thing I'm going to have to do is enable the filter mapping I have all all the other configuration we went over setup but this was just so we could see that see what the application looked like prior to spring security and we're using an in-memory database so all our objects will be gone since we restarted and here you can see that when I tried to access a URL within my application it sends me to this login page and again it's not very pretty but we didn't have to do anything to generate it well demonstrate how we can customize this in a little bit and right now it's using admin but we don't really have an admin user and so we'll use our regular user I just logged in and now I can do the same operations that I was able to do before again nothing nothing mad exciting after we've logged in but it was very easy for us to add user username and password based authentication to our application and and if you wanted you could easily swap out to a database or LDAP just by updating your Spring security configuration so how is this working behind the scenes we said that the HTTP element is creating our spring security filter chain but what is it doing behind the scenes behind the scenes it's creating an object called filter chain proxy and what that does is it's very similar to our delegating filter proxy except it's a little fancier instead of being a single delegate filter it is actually looking up the delt the filters plural that it will invoke for this particular request so we'll look up all the delegates and then I'll iterate over each of them invoking filter the filters do filter method each and turn and so this is how we are able to create multiple filters in our Spring security configuration and only have a single filter in our web XML and it'll continue iterating over those as long as the filter chain that do filter method is invoked and afterwards it will continue with the original filter chain and so if this is confusing at all think of it as I one-to-many mapping you have one filter in your web XML and it maps to many filters in your spring security configuration and the filters that are being invoked are dynamic based upon the URL that is being requested it's a little bit it may be a little bit too much to swallow but we'll go over the in more detail and we'll see how it works with a few diagrams shortly and by shortly I mean now so we're going to do a HTTP GET to messages and our delegating filter proxy will delegate all the work to the filter chain proxy and remember our filter chain proxy is the spring security filter chain it is what has multiple filters and so multiple filters will see the request and they aren't really that interesting right now because well so we'll skim over them for right now the exception translation filter will see the request and it will try to invoke the rest application remember that's how we want to word that try to invoke the filter chain or invoke the rest of our application and I'll catch any access denied exceptions and then it will continue down to the security filter interceptor and here it will look at our spring security configuration and it will ask the slash match slash star star and slash is essentially the URL that was passed in - the context root so that's where that's coming from and when earlier we said slash star star matches every URL so the answer is yes the current user must have rural user because that is the access that is required for that intercept URL and we're not logged in so we'll throw an access denied exception so it throws an access denied exception the exception translation filter catches that exception and what it does is at first it'll save the current request in an interface called request cache and this is just a httpservletrequest object that's saved in in that request cache interface and that will come into play later but just remember that we made a request for a particular URL after you log in you want to use the URL that you requested originally this is how we replay that so we'll get into more about that later but just now know that we're saving HP servlet request object then we're going to send the user to the login page and we do that using spring Security's authentication entry point and you can customize that behavior if you want to write your own implementation of authentication entry point so it sends us to the login page and using a redirect and you might say well you said slash star star matches any URL well why is that we're using ant patterns behind the scenes if you guys aren't familiar with ant patterns we're actually just going to go over the patterns real quick but there's a couple other things to keep in mind so when spring security matches on the URLs query parameters are not included in the match and you can do this but it's not really encouraged and therefore not enabled by default the reason for this is because oftentimes query parameters can be easy ways to bypass security constraints so if you say if the query parameter exists at the very beginning of the query string it's difficult once you get three or four of them to say that they exist and it doesn't matter where they're at and it doesn't matter what the values are it gets very complicated very quickly now there's an interface that you can implement that can you could do whatever you want in order to determine if the request matches but by default query parameters are not used in the match and the context path is also not included in the match and the reason for this is if you deploy your application again with a different context route you don't want to have to reconfigure spring security so the basic rules for ant patterns are question mark matches one character star matches zero more characters but not a directory delimiter so not a slash and star star matches zero more directories in a path so you might be thinking huh or you might be thinking I've used ant this is boring so we'll go over a couple examples real quick for those that are still scratching their heads so slash star star matches any URL and that's pretty self-explanatory so we won't have any examples for that one slash star matches anything in the root folder so if your full path is slash messages slash one then the path that we're trying to match on a slash one because again we aren't interested in the context root we ignore that and so that's in the root folder so that will match slash messages slash to with the query parameter a equals B that will be the path to match that will try to match on as /to because again context root we ignore query parameters we ignore so it's going to try to match on - and it does because it's in the root folder / 1 / it's not in the root folder so it will not match an example with the double star so if we have / 1 / star star it matches anything that starts with / 1 some of you might think well don't you mean / 1 / no it's a little bit confusing it's actually anything that starts with / so our examples are if it starts with / 1 it'll match add some query parameters again we'll ignore them if it's / 1 / that matches also and / 1 / view will match things that won't match our / other / + / 2 / view so one of the things that we mentioned earlier is URL based security can be kind of fragile and so it's very important to be careful and understand what patterns you're matching on and what patterns you have mapped your resources to so let's take a look at this pattern / star star / star dot CSS this matches anything that ends with that CSS so Styles main dot CSS it matches and this would be good because you know we might want to allow access to all our CSS resources to anyone grant access to anyone makes sense / one that doesn't match so that means that our message if we're viewing a detailed message that's secure so we don't have to worry about anyone seeing that but if someone tried to invoke slash one dot CSS it would be public and you might say well what why is that a problem if you're viewing our message well if you're still logged in it timed out if you're viewing our application you can see that spring MVC ignores the dot CSS extension by default because the best match is a slash one and it's trying to do content negotiation and there's no additional information in our mappings and so someone could actually request one CSS and bypass our constraints if we were doing that so the moral here is the less restrictive our URL mappings are the easier they are to bypass so it's important to be careful how you're mapping your aunt patterns and to test them very thoroughly and to understand how your application maps to your URLs and there's a the other thing is that spring MVC will treat treat the one dot CSS the same as one unless you otherwise configure it so it's important to be aware of these things and there's other ways to bass bypass URL based security for example if you had a URL and you're trying to let anything that started with public be public say public CSS or whatever someone could request the URL slash public slash dot dot slash admin and it's a relative pass so it looks like it starts with public but if it's supporting relative pass all of a sudden they've got into the admin portion of your application now spring security has a lot of things in in place to protect you against these things relative pass will be denied by the HTTP firewall built into spring security so there's a lot of things built into it but the the reality is is that URL based security can be rather fragile and so it's best to combine URL based security with methods security and this is what is known in the security industry as providing defense and depth if one tier gets passed you get passed one tier you want to get secured in another tier so now that we've gone over ant patterns and some of the complications that come up with using them let's see what happens when we request our login page so now the URL is redirecting our app is redirecting to the login page and we're about to render it so the delegating filter proxy sees the URL again and it delegates all the work to filter chain proxy and it skips over a number of filters that aren't very interesting for this request and the default login page generating filter sees it and it sees that it the URL is spring security log in and it's interested in that URL because it renders a login page for us for any URL that matches that so it writes out the login page and that's where you see that white login Paige coming from is that default login page generating filter and now the user fills out the username password and they submit it and it will typically be a post to J's spring security check and these are names J underscore user and J underscore password for the HTP parameters and it comes in and much of the same things happen but this time the security context persistence filter sees it and it it sees that the HP session has no authentication in it and so it's not really interested at this point in the request but it will be shortly username password authentication filter it sees the request and it knows that it wants to process anything matching J Spring security check and so what it does is it validates the username password using the authentication manager that we have setup in our spring configuration and basically what it does is pass in the username and password the authentication manager will then return a valid authentication object and the username password authentication filter will place it in the security context holder and the ARS kind of hidden due to our screen resolution but on the security context holder but you'll see that the user is placed in the security context holder and this is where Springs security sees the currently logged in user at any point in time so if there is a valid authentication on the security context holder it doesn't care how it got there it realizes that's the current user and that's what it will treat as the current user so the most fundamental thing for authenticating a user is setting the security context holder and that's why we can have different ways of authenticating a user and then use the same authorization logic or determining who has access rights to a particular resource without updating our code so then the user name password authentication filter is going to redirect to that saved request remember earlier we placed it in the request cache it's going to redirect to that saved request and it does that by redirecting to that URL that it was originally requested but it can't encode all that information into the URL because there's headers that were in there there might have been cookies etc there's all sorts of things that might have been in that request that can't be included in a redirect so we'll get into how it deals with that in just a moment but just now know that it redirects to the URL and the security context persistence filter now notices that the security context was updated and so it's going to save it in httpsession so anytime you save to update the security context holder the security context persistence filter is in charge of updating httpsession and in fact you don't have to store to httpsession that's implemented using an interface and implementation but that's the default mechanism and so it updates it in a chippy session and it clears out the security context holder and this is because in web applications threads are pooled and so security context holder being a thread local it needs to be cleared out otherwise you'll have a memory leak so now we have our HTTP session populated and the user is authenticated and we're requesting our originally requested URL so the saved request comes in and our delegating filter proxy sees it delegates all the work to the filter chain proxy and the security context persistence filter sees the request realizes that there is a user in session and so what it does is it populates the security context holder now the rest of spring security can see that security context and the request cache aware filter this sees that there's a saved request in our request cache and what it does is instead of invoking filter chain do filter with a original request which I would have notated as just request it looks up the httpservletrequest in the request cache and passes that to the filter chain and again we add just as we said before these are just interfaces so we can implement it if we want any way we want and so basically we've stored that request and now we're invoking the original request that was sent to the application through the filter chain and so now everything that was on the original request is in the request for this saved request now the security filter interceptor sees the request and it sees that the current user has role user so I'll grant acts and let the rest application process is normal and I'll write out some sort of response security context persistence filter is returned to and it sees that nothing has changed so it doesn't have to update the session but because we're using a thread local and threads are pulled we do need to clear the security context folder out so that we don't have a memory leak and so here we're just reiterating and demonstrating all the discreet tasks that spring security has each filter has a discrete task in a specific function and that allows you to reuse each of the filters as building blocks and one of the things that you can think of as is that a filter is actually acting as a controller and so if you're having to customize some of these behaviors some people are inclined to place it in a filter this is fine if that's what you want but some people get confused by this or they lose functionality of their model-view-controller framework like spring MVC and so you can actually implement that logic in your controller if you want nothing stopping you so say you were doing your username/password and you wanted to use JSON instead of HP parameter you could use your standard JSON library convert the user name/password to strings pass it into the authentication manager and then you would be authenticated as soon as you set it on the security context holder so just realize that because it's implemented in filters doesn't mean that you have to do it that way spring security does this a because it's an a way of doing it in an aspect oriented way that's built into the container and B because well I guess it kind of ties into the first one it doesn't want you to require you to use any specific MVC framework so that's why it's using filters it doesn't know what URLs you want it to process so it needs to be able to arbitrarily determine at runtime which URLs to process and it doesn't want you to require any particular MVC framework so now that we've gotten through that let's take a look and see what a custom login page would look like so here you can see that we have our form login element and we've added an additional attribute to it the additional attribute is the login page attribute and that login page tribute says that once you are accessing a URL that and you're not authenticated then and it requires authentication then it should redirect to that URL it also states that if you if you specify that attribute that you are in charge of rendering that URL so no longer will spring security create a login form for you and you probably don't want that anyways because let's face it it's kind of ugly but you are now in charge of rendering that URL and you can also specify additional attributes we only specified one other one here but the authentication failure URL is where it'll go if you fail to authenticate type in an invalid username or password so there's additional attributes you can customize the HTTP parameters that it looks for etc but you can refer to the documentation for that so let's see what happens if that's the only update to our application that we make if we make an HTTP GET to messages it will eventually get to our exception translation filter it'll do our try catch on the rest of our application and then the security filter interceptor will determine if we have access so does slash match slash star star yes so the current user must have role user not logged in so we'll throw access denied exception catches access denied exception now we're redirected to slash login so the URL has changed the other thing is is now we're requesting the login page in we're requesting the slash login URL and the exception translation filter sees it and it tries and catches it can anyone guess what's going to happen does anyone know what's going to happen yes very good it's going to do a loop so security filter interceptor will say does slash login match slash star star yes it does so the user must have roll user and the users not logged no one's logged in so we're throwing an access denied exception and we repeat so you'll say well that kind of sucks spring security actually gives you a warning stating that this is the case but but that you basically probably have a bag configuration but the way that you fix this actually I think I have it in the slides the way that you fix this is by adding another intercept URL pattern it's important to realize that these intercept patterns are considered in order so if we had the slash star star first it would match every URL I'd never get to the slash login so you want to place that first and so we say that if it's a match of slash login then we will grant access to that URL so now how do we create our login JSP and the login JSP only has a few rules and in fact it doesn't have to be a JSP we just chose to use JSP so if you're wanting to learn other templating technologies a little plug for my next presentation in the next session is templating with modern templating languages with spring MVC so if you don't want to use jsps you could use whatever you wanted but there are some rules to how this request must be formulated first of all you'll want to submit to the URL J spring security check this can be customized but by default that's the URL you need to post to because that's what our username password authentication filter is listening to you also must do a post this can be customized as well but it's not a good idea because you always want to send sensitive data over HTTP POST so once you've done that then you need to ensure that you have the username and password and the username password should be J underscore username and J underscore password parameters again these can be customized but by default those are the HTTP parameters that the filter is looking for and you'll also notice in here that I have premier not equal null and if so display failed to log in this is how I'm displaying the air for logging in to our users and I can get the details of how they failed to log in using the spring security last exception and so we've done all these so let's take a look and see what will happen in our application if we update it and I tried to get most of this typed out so we could move along and not see me type too long so now we can access our URL and you see that I get a much nicer well maybe some would argue it's not much nicer but it's relatively nicer login screen and I'm able to login with it just as I was before but one of the things that you'll still notice is that when I try to log in and I have an invalid username password I do get this failed to login but it's not actually repopulating my username in fact Chrome is Chrome is what's populating the admin again as opposed to the other one because it was blank so basically in summary if Chrome was not Auto filling in admin for me it would be blank so you might wonder well I want to integrate with the MVC a framework of my choice and of course you guys are at spring one so we all know your MVC framework of choice is spring MVC so we'll see how we can do that real quickly I'm just going to update our mapping real quick before I forget and so all this is doing is its mapping our /login URL to a different view that we have and here what we're doing is we have our login JSP and there's nothing fancy about it again you don't have to use jsps if you don't want to but now we're submitting to slash login and we're submitting to slash login because we are going to process that URL in spring MVC and I'll show you how to do that in just a moment so we're submitting a post to slash login and we're going to be in charge of rendering it everything else should look very familiar we're able to reuse the JSP form heirs tag so we can display our errors without using spring securities a last exception as we did before and our username and password are being are using the form JSP tags as well so they'll be automatically repopulated so let's see this in action real quick you won't see much of a difference in terms of UI other than the fact that now when I type in user and so now you'll see that the password is required so we're also getting form validation on here as well and it also gives the bad username password so these are all populated using spring MVC standard support and this goes back to what I was saying earlier we can do this logic with spring MVC or whatever you want you don't have to use filters so let's see how we're doing this in our controller think I went to the wrong method so this is the method that we're actually using right now and you can see that we've mapped it to slash login in a post and it's probably a little difficult to see we'll try to add a new line a couple new lines for you and so it should look pretty much like what you would expect a spring MVC application to look like there's a little bit of stuff in there that we probably don't really like like we have the HP servlet request being passed in normally you want to abstract that out but you'll see why we're doing that in just a moment so we have a form login at our login form and the login form is pretty much just a standard form with spring MVC we added not empty to the username and password and again we're using J underscore username Jan or score password it's just to make things easy you could use whatever parameters you want it's functioning just as spring MVC would you don't have to update any spring security configuration to change those and so what you do is you get those username and password and then you can validate it any way you want right now we're validating it using does the username equal the password and we're also validating it because we earlier we said that we also wanted to check to see if they were non empty so that was an honor that's because of our at validate notation and the not empty annotations on the form so you could very easily authenticate in any way you want and so how that's happening is once you validate it in any way that you want you could just do nothing if you wanted you can then authenticate the user and it's a little difficult to see probably make some new lines here for us so what you can do is you can create a new authentication in that authentication you might be a username password authentication token and you can specify the roles that you want for that user right now we aren't using the authentication manager so we're just going to hard-code role user for right now and then you set the authentication on the security context holder and this goes back to what I said earlier it doesn't matter how this security context gets populated as long as it's populated the rest of spring security well behave just as it normally does so for example say you have a user trying to sign up for your application and you want them to log in immediately after they have signed up you don't want them to have to log in again manually so you could create the user just as you would normally in your domain and then you can create a new authentication and set it on the security context and they'll be authenticated and again the reason why this gets added to spring security long term is because our security context persistence filter that we discussed earlier so once you've done that one of the things that people ask is well then how do I replay the original request remember earlier we talked about the request cache and we thought well you know we want to replay the original request before they logged in so how do we do that well you can auto wire an authentication success handler to your controller and this is what spring security is using behind the scenes in order to redirect the user in the username password authentication filter so you can just use the same interface which accepts the HP servlet request and response and that's why you see that and so you can you can do this you can do this as well so you might ask well I don't want to validate these or myself I want to use authentication manager well that's also an option I was just showing you is you know if you wanted you don't have to use the authentication manager it's just there to help you if you view it as a way to help so another way you could do it so you could do the exact same thing we saw earlier and instead you could create an authentication token using the authentication manager so what we do is we pass in a token that's not authenticated so there's just a username password passed into it and then we pass that into the authentication manager and remember earlier in our diagram we said the authentication manager will then return a validated authentication object so it returns that object and then we set it on our security context holder again nothing magical about it just set it and then we can use our success handler to send us to the success page now if there's an error logging in without Kayson manager the contract is is I'll throw an authentication exception so what we can do is we can in spring NBC we can just reject reject that air with an air and specify the message on that exception because spring Security's exceptions are already internationalized and then it sends us back to the login view so again you could do all the logic in the filters in your spring MVC controllers or whatever framework you want but it's important to be aware of how it's working and how things are put together so that you can make these things as easy on yourself as possible so we've talked about a single HTTP element but spring security introduced multiple HP elements support in spring security 31 and so you don't need a single HCP element this can be useful if you're using rest services and HTML based web application in the same application and you want to secure them differently and we're only going to give a very basic demonstration of how it works but it but we want to demonstrate how the flow is traced in our application so here you can see that we're requesting main dot CSS and again delegating filter proxy sees it delegates all the work to filter chain proxy so now we've updated our security XML file and what it's really doing behind the scenes is that the delegating filter proxy is delegating to the filter chain proxy but earlier we alluded to the fact that the number of filters in the filter chain proxy that it delegates to changes based upon the request URL so here you can see that I've added another HTTP element so the filters for the first HTTP element will be different than the filters for the second HTTP element go over that in a little bit more detail so what happens is that if you look at this HTTP element it also has a pattern element on it similar to the intercept URL but this pattern is determining which HTTP element we select so right now the yellow arrow indicates we're seeing if it matches that so does main.css match the resources star star yes it does so we select that HTP element and security is disabled because if you look at it we specified security equals none so what that is doing is rather than saying we're granting access to everything it's actually saying that the filter chain isn't going through any of the security filters so remember earlier we notated it with lots of small little boxes and saying we weren't interested in it well it actually skips over all those boxes because they aren't even added and we write out the response our application writes out the response as it normally would let's see what happens when we request URL other than resources so here we're requesting slash messages slash so does slash match slash resources star star no it doesn't so now we're going to go to the next HTTP element does slash match slash star star and this slash star star is on the HTTP element itself it's not the intercept URL it's the HP element itself and the reason why it's slash star star is the default pattern for HTTP element is slash star star so again the just like the intercept URLs are considered in order so are the HTTP elements so you don't want to place the slash star star one first because otherwise you'll never get to the second one and spring security will actually give you an error if you do this incorrectly so it does match less star star so we're selecting this HTTP element now we're going inside the HTTP element and we'll determine if the pattern matches the current URL and slash does match match slash star star and so we require the role user let's see what happens when we do a slightly different CSS request with a little different configuration than we saw earlier so now we have two HTTP elements and we introduced another intercept URL so we aren't saying actually that that's incorrect the security equals none should not be on there I apologize for that but the HTTP element basically it basically gets to intercept URL and the pattern on the HP element and says does main.css match resources slash star star and yes it does so it's selecting this HP element now our pattern is resources admin dot CSS so does main CSS match admin CSS no it does not it does not match it and there's no more patterns for this HP element so we're going to grant access now be a little might be a little bit confusing because you see another HTTP element right below that and another intercept URL pattern that says match everything but the key is is once it matches on an HTTP element it's already decided all the filters that are being used for it and all the security patterns and everything so once it gets into that HTTP element it's isolated to that HTTP element it will not go to another one so that's why we're granting access let's see how we can add logout to our application now logout is pretty easy all you need to do is add the security logout element and I'll try to get that a little bit higher so you can see it hopefully the logout element which is right here the logout element basically has a logout success URL similar to how the authentication failure URL exists and and all we need to do in order to leverage that is update our application to point to the URL that's listening to so very similarly to the URL that we send the username password to there's a default URL for a logout and that default URL is J spring security check and I'm going to just pull this out because we're going to do another thing in just a moment but we want to illustrate a point first and I want you to be able to see that so all we need to do is create a link with J spring security logout and you can customize that URL as we mentioned earlier so now that we've created that we'll go into our application and we'll see that we have a logout link and we aren't logged in so that's kind of weird but we'll get to that in a moment so now I'm logged in and I have a logout link and I can log out nothing spectacular you'll notice the URL after we're done being logged out has a query parameter logout on it and that's why we're able to see this logout success message now in our JSP we're checking for that query parameter and always displaying it but if you wanted you could also use spring MVC to intercept that URL and add a Flash attribute and display things as you would normally in spring MVC so we didn't do that but it should be pretty self-explanatory on how to do that at this point but one thing you'll notice is that we pointed out earlier is the logout link is still displayed and we're logged out spring security provides a JSP library that allows us to hide things in our JSP s based upon the current user so here you'll see that I have a not the security tag and the security tag we should probably the security tag has a namespace just as any other tag does and then we declare the authorized tag and we say access grant is equals authenticated and this access attribute is very similar to the one we saw in our spring and spring security configuration earlier this is just a keyword that says if the user is authenticated I will grant access so we get into this authorized statement and then we're able to say welcome to the current user how does this work behind the scenes well there's an authentication tag and it does all the work enough said not quite so the authentication tag is using our security context holder just like the rest of spring security so let's look at our security context folder of course the source is not attached see if another one there we go so we have a get context on there and this is where the context comes from and then when we get that the tag is getting this authentication object off of there so it calls get authentication and then authentication extends principle which has a name property might not be able to see but at the very bottom it says get name and so the way this is working is authentication in our JSP it's getting the authentication and then it gets the name property off of that and that's how it's that's how it's working if you had your own custom authentication object you could add like a first and last name to it if you wanted you could add you know an organization whatever you wanted so this tag can access any property on the authentication object and and then we have our logout link also and that's between the authorized tags so you shouldn't see it anymore unless you're logged in or unless I have an error what's funny is I've practiced this a number of times and that always happens all right so now we're logged out and we don't have the logout link displayed up there but we can login with our if I type in the right password if I login with admin I see welcome admin in the upper right if I log out I can log in with user and I took the wrong password sorry about that and I'm now logged in as user so you can see that it's relatively easy to add this sort of customization to your web application and this is some of the stuff that we've already covered we won't go over it again so now we talked about method level security and you must do it so if you must do it then we must cover it as well so let's take a look and see revisit that issue that we saw earlier so if we create a message actually I need to update our configuration I apologize so we need to simulate the situation that we saw earlier so in order to do that let's grant access to any URL that ends in CSS and we realize this is a vulnerability and already but we want to demonstrate how we can catch these are you know if if we miss something like this how spring security method level security can help us so now we've granted access to any URL that ends and dot CSS so as we discussed earlier that means that if we access one of our messages with the dot CSS suffix we'll have access to it so let's create a new message and we'll create the new message hello world and now we have that message and I'm going to copy that URL and I'll log out so if I paste the message I get a login screen this is exactly what we were hoping for but if we know what we're doing we can type in one dot CSS and we see that spring MVC is mapping that to our message resource and this is not what we want at all so how are we going to get around that or how are we going to prevent malicious users from getting around that might be a better way of phrasing it so the easiest way is to add method level security and I'll go over how this works in the slides because it'll be a little easier to see then the IDE but I'm just updating the code here real quick so the first thing you do is you update your security XML to have global methods security in it and then depending on the annotations that you want to process you enable those as well here we're going to use pre and post annotations then you need to add some sort of annotation to your message repository and we didn't really go over this but the message repository is basically our data access to your service tier and this is where we can add these sort of security constraints and we'll go over that in more detail when we update our app because I still need to update that and what's happening here is we have an application context that's represented by the green or depending on how good the quality of the monitor is maybe that's yellow I'm not really sure what it looks like to you guys but the application context is that big big box and it has a number of objects inside of it and one of them is the message repository and what happens is spring security will register a beam post processor inside that application context and what it does is it looks over all your beans in your spring configuration and this is nice because it can actually modify them before it injects them into your objects so it iterates over each of them and it says should I secure this object and in fact message repository it should secure it because it sees one of the security annotations on it so it turns it into a new object secure message repository and this is just a name I gave it it's it's actually a auto-generated proxy object using Springs AOP support but fundamentally this is what it's doing behind the scenes it creates this new implementation and what it does is it replaces the methods with those annotations with checks so earlier we said in a filter we can do a something before and something after we can do the same thing with method level security so we could say before we invoke the delegate which is the original message repository that we had before we invoke it do some sort of check and if that passes then we'll go ahead and invoke the original method and then afterwards we could do some other sort of check and so let's see how we can do that in our application so we've already enabled this in our in our spring security configuration and I'm not going to use this this annotation just yet we're going to require the role user for this method to be invoked and hopefully I type everything correctly so in order to invoke this method now that the user must be logged in and they must have the role user so let's see what happens when we try to bypass security now first we'll go ahead and create our message just so we we demonstrate that we're not cheating somehow we'll create our message and we'll copy the URL and so we'll log out now if we type in the original URL without the dot CSS we get the login page just as we did before but now if we type in with that CSS we get the login page again and what's happening is we met as we mentioned before it's creating a proxy object and it's doing the access control check just as our filters were earlier so now we have two layers of security so we get past one we have another layer of defense and this is what we want so you might say okay well role user is kind of cool but what else can I do a spring Security's annotation based security spring Security's annotation based security also supports spring expression language and if you guys aren't familiar with spring expression language it's very similar to something like jst L there's a number of other similar things but here you'll see that we have a post authorized and the pre-authorize is before the method is invoked so the post authorizes after it's invoked so remember our original object we said that we could do something before and after pre maps too before post maps too after self explainatory but why would I want to do something after well what if something on the object could be used to determine if the user has access so if you remember our message object has a summary property so the return object specifies what we're returning it's just a keyword within Springs expression language support so the return object if that summary equals the current user's name then I'll grant access and like I said if there's a property on that object you have to look up anyways you might as well just look it up and just not let the user see it if they aren't allowed to access it so let's see how this works so now I'm logged in as the admin and I'm going to create a new message and I'll create one with the summary of admin so I'm able to see this just fine if I create another message with the summary of user I get an access denied exception and this shows that if you try to bypass it it's going to give you an error and we can also log out and log in as our user now if I view the admin one I get access tonight and if I view the user one I'm able to view it so it's something that you can use to relate the properties on your current your returned objects to your user and there's actually other abstractions that you can use in order to make this even better so spring security has a CL support so you can map a particular don't domain object to a set of roles or users and grant access that way and we won't have time to get into all that stuff today but you can read about it more in the documentation and I think that was actually all that's in the slides but we are going to have time for our bonus so give me one second to set that up so what I'm doing now is I have another branch of my project this other branch is set up to use what I have started as spring security Java config so one of the things that people have been asking for a while now is how can I configure spring security with Java configuration and this has been something that's been fairly challenging if you've paid attention to the spring source blog Luke Taylor the previous spring security lead had worked on something with Scala support and that worked very well because Scala allows us to have multiple different essentially it allows you to inherit multiple times we won't get into the details of exactly what I mean by that but you can have multiple inheritance and this makes sense because if you look at it the configuration has something you might want to say with login form or you might want to say with open ID or with logout and you can't have multiple types of inheritance and the configurations get very complicated basically so Scala allowed us to do this aspects would also allow us to but it's been something that's been challenging for some of the more complicated projects so first we'll demonstrate that things are not working that really wasn't my intent things are just not working oh my class I don't think I'm going to be able to get that - I'm betting this is not going to work so I don't have any Wi-Fi and I had to clear out all the dependencies but we'll give it a shot basically I need CG live on my class path and when I cleared them out I was on the other branch that didn't have CG lib on the classpath so I have it here we'll see if it finds it otherwise we'll just go over the code and you can try it on your own when there's an internet connection I think it's trying to download it which well maybe no build successful it claims no it's getting in here yeah I can't find that dependency so I apologize I I kind of botched that but we can show you what it looks like and we can see how that works here we might be able to after we go over the configuration try to get the wireless set up I can't remember what the username password is but maybe someone can remind me but we'll go over this first because I think this is probably more pertinent to than seeing the demonstration because you won't you won't really see anything different in the in the applications behavior so the java configuration support is more than super beta this is actually something i put together in probably a couple days time it's not actually as a separate module it's just built into this application but this is probably where the java configuration is going to be going for spring security and the way that it's going to work at least tentatively is using builders so instead of xml will be able to specify something like this so here's our authentication manager builder and you can see that we can add users to our in-memory user details service just as we saw in our xml configuration and so it should it should look nothing it shouldn't look all that surprising but one of the things that you'll notice is one one thing i'm going to try to make sure is that things are as concise as possible so if you use the roles method to add the granted authorities you don't have to say role user role admin you're just going to say that roles and it'll automatically add those prefixes for you and another example might be the intercept URLs earlier you had to have multiple intercept URL definitions if you had multiple URLs that map to the same pattern so here this is kind of hard to see so let me excuse the indentation but otherwise you won't see this so here we add an intercept URL with the ant matchers of resources sign up log in log out and we're granting access to all those previously we had to say permit all permit all permit all permit all so now we're able to do this much more flexibly in addition you'll have all the objects available to you just as you would with the standard spring MVC spring configuration with Java config another thing that we'll try to do is that will provide try to provide some more reasonable defaults for you so for example if you're adding a login form and you specify the URL as a slash login you won't get the infinite redirect loop you won't have to reconfigure that URL as a URL that is public it will automatically realize that because you are configuring a form login now you'll have to invoke a method because URLs aren't the only thing that are used to determine a request so in security you want to be safe than sorry rather be safe than sorry but you'll just invoke a method in any objects any URLs that that's configuring it will automatically make a public so this is the basic configuration of how things would be laid out and this will be available on the web but one of the things that's interesting about this is we're using this builder object and the Builder objects creating multiple multiple things that we need to expose to our spring MVC configure or our spring configuration so we just as the other objects have an enable annotation so two spring security so these are some of the things that uragan was talking about in our in the speech last night and what we've done is we're importing the web security configuration and what this does is it's auto wiring our filter chain proxy builder which is the Builder object that we were talking about earlier and then it exposes multiple objects on that builder to as beans in our spring configuration and so that's how we're getting around some of the limitations that we've had trouble with in the past and again this is super beta but I wanted to show it to you guys in case anyone in here already was familiar with spring security and sat through the whole introduction they had something to go home with that might be a little bit exciting so anyways that concludes my presentation I apologize for not getting the demo working here but I assure you it's it'll run just pretty much the exact same as the app that we saw with the XML configuration and if you have an internet connection it should work just fine so with that said I believe we have a little bit of time for questions do you have any sure so the question is let's say you have two users one's an admin and you have another one that's a user and you want the user roles to be impacted immediately so earlier we mentioned that the security context persistence filter uses an interface in order to discover and map the current user so one option you could have is you could actually put that in something that's distributed so for example you might put in a distributed cache and in that event when the administrator looks up that user you'd have an API that could look up the user in the distributed cache update the roles and then the next time the user invoked their invoke the request they would retrieve it from the distributed cache so that's one option for doing that there are other options you could use mbeans but then you know the mbeans are then being exposed to you're basically adding a lot of things to memory because essentially that's what mbeans are so I mean it kind of depends on the scale of your application but probably the best approach would be updating the security context repository interface to point something to something that could load that's shared across all your cluster I assume you're in a clustered environment so good question yes so if you the question is if if you want to unit test methods that are using the method level security could you unit test it without setting up the users and the answer is yes the only reason those annotations are processed is the XML that we saw the global security global method security element so remember when we added that to our security XML file if you don't have that anywhere in your spring configuration for your tests then the annotations aren't processed so it'll just be a regular object does that make sense um right over here so request type being the content type or the method method yeah in the intercept URLs you can specify the method and so another thing that's important to realize too is the intercept URLs using these ant patterns is the default is a default mechanism for spring security it's actually backed by an interface called request matcher that will allow you to pass in an HTTP servlet request object and it'll return true or false so you can implement that interface any way you see fit if it's not meeting your needs now hopefully we'll be getting some better support for that now that we if we have the Java configuration we'll probably be able to customize that a little easier so we might have you know you might see some better support for other types of requests matchers creep in to spring security when that comes up but again this is super beta I've only been on officially for about four months and my first task was to get us get our bugs down to a minimum and and we've done that now so now we're starting to add new features so good question though um I think she's been raising her hand for a while yeah I'm sorry can you speak up it's hard to hear ntlm huh ntlm support is kind of deprecated in favor of the Kerberos support yep yeah it actually you're correct Kerberos support has not been actively maintained for a while and hopefully some of these extension projects will basically if you're not familiar with the extension projects the extension projects are kind of maintained and contributed by outside contributors but hopefully I will be able to have some time to start helping contribute to those but it will be a matter of working with the those leads because you know it's it's not very community friendly if I go behind their back so to speak so I'm sure that they'll be welcome to it but it'll it'll involve a little bit of politics as well but that is the plan is to start picking up some of the support for some of the extensions and I'm going to try to add that to some of the things that I helped actively maintain so I don't know if that answers your question but that's about the best I have for you anyone else yes sir uh-huh yep and that actually all vary depending upon depending on your solution so actually let me repeat the question real quick the question was if I have a client that's written in JavaScript and I'm calling restful services how do I store the credentials for the client and so the answer is is that will depend based upon your application so for example if you're using a web-based application you can just use the HTTP session and I know a lot of you may say well HTTP session that's state I hate state because I'm restful and it to an extent that's true but you must realize that the important thing to realize is that HP session is just another way of caching something so if the users not logged in anymore it fails over you can either set up a distributed HP session failover stuff like that but if all that fails then essentially all that happens is the users requested to login and so you can think of the session ID is no different than a person identifier or a user identifier or if you're storing medicine medicine identifier and it's looking that up and it might be looking up and distributed cache or it might be session session is temp technically if it's a distributed session technically a distributed cache now with all that said if you don't like that answer which some of you are probably not liking that answer you have other options I mean you can use something like ooofff you could use like the OAuth extension and you could you could store that but I mean the reality is is you're going to have to store it somewhere and your app and whenever you're leaving State for the server you're pushing it to the client and if you push it to a client that anyone can see you want it to be very short-lived because otherwise you're having a security vulnerability so that's a good thing about state is if it gets compromised you can destroy it there's no state there's nothing to destroy and you've been compromised so that's that's something to keep in mind does that help at all I don't know if you still had a question I saw you had your okay okay in the back oh so you're asking if you only want to encrypt part of your application okay so I'm going to answer this and this is probably not going to be the answer you're looking for but I'm going to stick with it so basically it's not good practice to do that and I'll tell you why because anyone here heard of Firesheep raise your hand Firesheep so basically what happens is as soon as you enter that username password what is protecting your users it's the HP session the HP session is going across the wire and plaintext now and anyone can intercept it so if you are not familiar with what I'm talking about Google Firesheep but basically what it amounts to is only protecting the user name/password will only get you so far and it's it's really not the right approach and a lot of people say well SSL that's expensive we can't afford SSL for the load that we have try it before you actually say that there's a lot of people that have said that and they've actually tried it and they they were surprised I mean I know I use this example and you're like well we're not that company but Google uses SSL for everything as well and now yeah you're not Google you probably don't have the resources maybe you are Google I don't know but you you don't have the resources that they have but you probably don't have the load that they have you probably have resources relative to the load that you have and in all honesty the other thing is all the data that you're transferring over over the wire that's not encrypted either so even if you protected that the session ID say I'm in a medical application and I'm searching for medications and the medication implied that I had AIDS all of a sudden they know that I have AIDS and so you or my bank information my bank account is being transferred across the wire so most likely if you're authenticating to the application you're wanting to secure the data any so in summary use SSO I think that's about all the time we have for questions today if you have any others feel free to get me later thank you

Channel: SpringDeveloper

Views: 112,276

Rating: 4.8694158 out of 5

Keywords: spring, springsource, Java (programming Language), Java (software Platform), acegi, spring security, servlet, liveacademy, Spring Framework, eng1, s-lms, sec-web-gs

Id: k32KqrckLEE

Length: 91min 20sec (5480 seconds)

Published: Tue Apr 02 2013

Reddit Comments

[u/tweakerbee]

The current stable version is 3.2.5, so you may want to watch Getting started with Spring Security 3.2 instead.