Preview

Start a free Courses trial
to watch this video

Sign up for Treehouse

Turning On Spring Security with Java Config

24:11 with Chris Ramacciotti

In this video, we'll switch on security by adding a @Configuration class that specifies the details of which Spring Security features we'd like to use.

Teacher's Notes
Video Transcript
Downloads

Spring Security Filter Chain

For more information on the filter chain, check out the Spring docs: http://docs.spring.io/spring-security/site/docs/current/guides/html5/form.html

I've demonstrated the use of session attributes to handle login failure messages, as opposed to using the standard in examples you might see around the web. Examples typically show the use of a query string parameter in the URL, such as

/login?error=true

I don't like this approach because care must be taken so that one cannot visit that URL directly to reproduce the flash message. Instead, I prefer to keep the URL clean, and rely on a session attribute to save the flash message. Session attributes are server-stored values, and can even include rich objects. When session attributes are used, you'll notice that a session cookie (usually called JSESSIONID) is set in the browser and passed with every request, so that the server can pair the browsing session with the server-stored session data.

If you choose this approach, be sure to clear the session attribute when it makes sense to do so. In our case, it makes sense as soon as we add the flash message to the model map for display in the rendered template.

Session IDs and Cookies

When working with session data in web applications using Java or any other server-side language, it is best to understand how your data might be compromised. Many applications match server-stored session data with browsing sessions using some sort of session cookie. This value is stored in the browser, and when your application receives a request that entails using that session ID for authentication or other session data, the application assumes the request originated from the same place.

But, what if your session ID cookie becomes compromised, whether through a browser vulnerability, or a non-HTTPS (read: plaintext) request intercepted by an attacker? Remember, HTTP requests are sent as plaintext, and if they're intercepted, they are directly readable by the attacker. Adding SSL encrypts all requests and responses in a way that protects all data (including cookies) in a way that doesn't make it more difficult for an attacker to intercept your requests or responses, but rather renders them unreadable since they're encrypted.

In any case, check the Teacher's Notes of later videos for common web app vulnerabilities.

Git Command to Sync Your Code to the Start of this Video

git checkout -f v5

Using Github With This Course

You can complete this course entirely using code created by you on your local machine. However, if you choose to use the code I've made available to you, you have two options:

Use the project files linked at the bottom of this page, or
Use the Github repository I've made available (recommended)

If you choose the recommended option of using the Github repository, it can be found at

https://github.com/treehouse/todotoday

To utilize Github with this course, you can download the Github desktop client for your system or use the command line interface provided with Git.

Clone this repository to your machine using the Github desktop client, or using the following command:

git clone git@github.com:treehouse/todotoday.git

To update your local repository to match a video's starting point, you can use the git checkout command in combination with the stage and video number. For example, to update your local repository to match the starting point of Video 4, you'd use the following:

git checkout -f v4

Notice the use of the -f option. This forces Git to override all local changes, so be aware: this will cause any changes you made to be lost.

To flip the switch for 0:00

enabling springs security we need to add some configuration to our application 0:01

as with anything in spring this could be done with XML or Java based configuration. 0:06

Now we'll stay consistent by sticking with the Java config approach. 0:11

To keep things nicely organized I'm going to put all security configuration settings 0:15

into a configuration class of its own. 0:19

So in this config package I'll create a class name security config. 0:21

SecurityConfig. 0:29

Great to utilize the java configure approach will need to add 0:32

some annotations to the class. 0:35

The first one is the configuration annotation so 0:37

that the spring framework picks this up as a class containing configuration settings. 0:40

And the second one is the enable web security annotation. 0:45

Now this class will also extend web security configure adapters so 0:51

let's do that now. 0:56

Extends web security configure adapter there it is right there. 0:57

Now this is a standard way in spring to use what's called the spring security 1:04

filter chain. 1:08

This chain allows us to filter certain requests so 1:10

that a user doesn't have to be authenticated. 1:12

For example for CSS and JavaScript or require that authenticated users 1:15

have the appropriate level of permissions using rule filtering. 1:20

We'll use this in just a bit. 1:24

Next we'll need to configure an authentication approach. 1:26

Since we've written a user details service we can leverage that work here 1:29

we'll start by auto wiring that service. 1:32

There's that auto wired annotation in private 1:37

UserService userService. 1:41

Next we'll configure spring to use this service for authentication by including 1:46

an auto wired method that sets our service as the one to use for authentication. 1:51

So the way that looks is as followed auto wired public void figureGlobal. 1:56

And this will accept an authentication manager builder object. 2:08

There it is right there. 2:16

I'll call that off and in here I'll say auth.userDetailsService and 2:19

I'll pass it the user service that we auto wired into this class. 2:26

And because this user detail service method potentially throws 2:33

a standard exception, 2:37

I'm going to declare this method as throws Exception to take care of that. 2:39

Now that we've configured spring to use that userDetailsService that 2:47

we implemented in a previous video We need to configure the logon 2:51

process more specifically. 2:56

And we need to selectively allow access to various URLs in our application based on 2:58

users and roles stored in the database. 3:02

This is where we use that spring security filter chain. 3:05

Now I warn you, there is a lot you can do here. 3:08

And so much room for customization. 3:11

My goal in this workshop though is to demonstrate the basics and drop 3:14

some resources into the teacher's note so be sure to check out those teachers notes. 3:18

In order to start configuring the spring security filter change 3:24

will override the configure method that accepts a web security parameter. 3:27

Be careful there are a couple configure methods that you can override so 3:31

I will choose to override a method and 3:36

it's the configure method that contains a web security parameter here. 3:38

Let's override that one. 3:43

And inside this method, will tell spring to bypass security checks for our static 3:46

resources to do this we'll call that web security objects ignoring method. 3:51

And what is it that we want to ignore. 3:58

Well we wanted to ignore any path that matches this pattern. 4:00

/assets/anything. 4:06

In doing this, we'll have spring ignore requests to anything in that assets 4:10

directory, which is where I've put all the static assets referenced. 4:14

Let me show you. 4:18

That's under resources, static. 4:19

And then there's that assets directory. 4:23

There's nothing in the static directory apart from the assets directory. 4:25

That's why intelliJ says static data assets And 4:27

then here are all the static assets. 4:31

CSS, images and some JavaScript in there. 4:33

Cool. 4:37

Next, we'll configure security for 4:38

the requests that will actually require authentication and authorization. 4:40

And we'll do that by overwriting another configure method. 4:45

And this is the configure method that accepts an HTTP security parameter. 4:48

So i will override that method. 4:52

We'll override the method that accepts the configure method that accepts that. 4:54

HTTP. 4:59

security parameter. 5:00

There it is right there. 5:01

In this method will configure security for authorizing our users requests to their 5:04

to do list configure the logon page and configure the log out process. 5:08

Let's take those steps one at a time. 5:13

First is restricting access to all resources to only those 5:16

users that are authorized to do so for us that means a user must have the user role. 5:21

So we'll start with that http parameter here and I'm gonna format. 5:26

All of this code nicely as you often see on tutorials about spring security online. 5:31

Okay. 5:37

So http.uthorizeRequests. 5:38

This will ensure that all requests must be authorized at this point. 5:43

So here I'll say any request must have the role USER. 5:49

So again I start by calling the authorizedRequest method so 5:59

that anything that follows is assumed to be handled by authorisation. 6:03

And it's implied that authentication has already happened at this point. 6:07

Also notice that I didn't use roll underscore user here. 6:12

I instead use just User. 6:16

And that's because this has a role method will prepared 6:19

a role_ before checking the role. 6:23

So at this point every request other than ones to our static assets is restricted. 6:28

This will completely lock down our application because we have no way for 6:33

users to authenticate In fact, if you were to run this app, and 6:36

navigate to the app route in a browser, you'd see a 403 response code. 6:40

Which means that access is forbidden. 6:44

Let me show you. 6:47

So I'm going to run that boot run task right there. 6:48

And I'll let the application compile. 6:51

And then I will let this spring application boot. 6:55

Looks like it is booted successfully. 7:02

Now let's go to chrome and I’ll close this user details service tab. 7:05

And I’m going to refresh this page here. 7:10

There's that four o three status code access For bitten. 7:14

We've successfully implemented spring security. 7:20

And now let's go back to our application and let some users in. 7:23

So back in this method after requiring that. 7:28

Any request be authorized with the user role? 7:33

Let's configure the login form. 7:35

So i will follow that up with the end method. 7:37

And here's how we are going to allow access to our login form that formLogin, 7:43

.LoginPage and we'll say, that you are right to our LoginPages/login and 7:48

we will permit anyone into the login page. 7:56

Now at this point we'd actually be able to log in but 8:01

let's keep going before testing again. 8:04

So next we can configure success and failure handler methods. 8:07

In other words we can specify methods that we'd like to execute when 8:11

login succeeds or when login fails. 8:15

So let's do that. 8:19

So we have a success handler and we have a failure handler. 8:20

For these all specified two methods that don't yet exist but 8:27

will create those or right after. 8:30

So I'll call this loginSuccessHandler. 8:32

And i will call this a logon failure handler. 8:38

Now let's create those two methods. 8:44

Ok i'll drop my semi-colon here. 8:48

And here's how these methods need to look. 8:50

This login success handler. 8:52

We'll start with that one, has to return an authentication success handler. 8:54

So, loginSuccessHandler is the name of that method. 8:59

I'll just specify it as returning null, for now. 9:04

And we'll do the same for the authentication failure handler. 9:09

Public_AuthenticationFailureHandler there it is right there. 9:13

And logonFailureHandler what I named it up above return null. 9:21

Now let's go back up to the success handler and actually code that. 9:26

Now this method will need to return an object implementing the authentication 9:30

success handler interface. 9:34

This is an interface here and the interface has only one method. 9:35

So I'll use a lambda to do that. 9:39

I'll return a lambda accepting three parameters. 9:43

The HTTP servlet request and HTTP servlet response and an authentication object. 9:46

Here's how that can look. 9:53

So, the three parameters, the request. 9:55

The response and you can use your IDE's auto suggest as you saw mine come up with. 10:00

And the authentication and 10:07

that's going to return response.send, 10:09

redirect to the application route. 10:15

Let me give myself more room to see all of this code right here. 10:19

Okay. 10:24

So this interface right here has one method that again 10:25

accepts an HTTP server let request parameter. 10:29

An HTTP server that response parameter in an authentication object. 10:33

So then, the body of this lambda will simply read direct to the application 10:39

root or that single slash. 10:44

Now certainly, you could do other things here. 10:46

And if you had a more complex set up you could do a multi-line 10:49

body here by surrounding this in curly braces and 10:52

adding more to pull lines here inside these curly braces. 10:55

We don't need that here because this is a single line implementation, or if you had 11:00

an even more complex set up you might want to create a separate class that implements 11:04

the AuthenticationSuccessHandler interface instead of using a lambda all together. 11:08

For the failure method also use a lambda 11:14

though this one will have a multi-line body, so I will need those curly braces. 11:17

So here, we have the same type of thing here. 11:21

We have the request. 11:24

And here I'll use my IDE's auto suggest right here. 11:26

There we go. 11:30

So I will return. 11:31

And I don't need these enclosing parentheses here. 11:32

I will return a multi-line lambda. 11:36

So in the body of this thing we'll redirect in the same way 11:41

a response.sendRedirect. 11:44

If authentication fails though we'll send the user back to the login form, 11:47

which is located at /login that's the URI for a logon form. 11:51

But before doing, so 11:56

let's add a quick flash message saying that authentication failed. 11:57

So I'll do that in the first line of the lambda here. 12:01

And I'll say, request.getSession.setAttribute. 12:04

We will call this flash. 12:10

And the flash attribute in the session will contain A FlashMessage object, 12:14

just like you've seen in previous courses. 12:19

And I'll say, here is something like Incorrect_username_and/or_password. 12:21

You don't want to reveal which one was incorrect. 12:29

Please try again. 12:32

Cool, and then I also need this constructor. 12:34

This flash message constructor requires me to indicate a status. 12:37

So that's flashedmessage.status.failure. 12:41

Kind of like we did in previous courses. 12:44

Cool. 12:48

So I have a flash message stored into session data and then I redirect. 12:49

Now you'll notice I'm not using the typical redirectAttributes 12:54

object that you've seen before with that addFlashAttribute method. 12:57

And that's because we don't have easy access to that 13:01

redirectAttributes object here from this method. 13:04

This will work fine for this one case though. 13:08

Check the teacher's notes for why I prefer this method over using the query 13:11

string method for a login error page, which will see another online tutorials. 13:16

Now as for the session attribute named flash. 13:21

I've already woven that into the model map for you. 13:24

If you take a look at the login controller let me open that now. 13:27

You can see where i detect that flash attribute. 13:33

I use that HTTP servlet request. 13:38

I get the session data. 13:41

And I look for an attribute named flash. 13:43

Now, what happens here is if this attribute is not found 13:45

an exception is thrown, so I catch that exception and I don't do anything 13:49

because all that means is that there's no attribute in the session named flash. 13:53

But if it is there that is if this line of 13:58

code executes successfully without throwing an exception. 14:01

Then I will add that flash attribute that was retrieved from the session data I add 14:04

that to the model map which will be used by time leave to render the login form. 14:09

Of course, so that this session attribute acts like a true flash attribute. 14:16

If the attribute is found, after I added to the model map, 14:20

I immediately remove it from the sessions so that the subsequent request if they 14:23

refresh the page will not contain That flash message. 14:28

Now another thing I've included for 14:33

you is I have included a flash fragment in the time leave template named layout. 14:34

So if you expand the templates directory and you look at layout.html, 14:40

you will see a fragment named flash. 14:44

It is right here. 14:48

Now that attribute is included in the login template if 14:50

you open the login template you will see this div right here 14:54

is replaced with that flash fragment coming from the layout template. 14:59

Okay, I'll close out of that and 15:06

while I've got the login controller open let's do one more thing. 15:09

Let's add the user entity as an attribute to the model, so 15:14

that in the login form Time Leave, object binding will work as intended. 15:17

So will do that up top here. 15:22

I'll say, model.addAttribute, call that attribute user in the Time Leave template, 15:24

and I'm going to add a new user entity there. 15:30

Make sure you're importing the correct one. 15:35

Cool. 15:37

Okay, with that done I will close that controller and 15:38

we're back in the security config class. 15:41

Let's finish by configuring the log out actions so that spring knows 15:45

which URI to capture, for destroying a user's authentication data, and 15:48

to do this we'll use the log out method in that filter chain. 15:52

So, right here I will add one of those and calls. 15:56

And here's how you configure the logout, you call the logout method. 16:04

We won't require authentication or authorization for this, so permitAll. 16:08

And then finally, I will call the logoutSuccessUrl. 16:14

And I'll say to log out success URL is /logon. 16:22

Now instead of using log out success URL you could have used log out success 16:26

handler as you probably saw in my auto suggest and just like we did for the two 16:30

methods for logging in the login success handler and the login failure handler. 16:34

But, I'm showing you this way for 16:39

logging out just so that you can see both in action. 16:41

Well, hey guess what we should be able to log in and out now. 16:44

Let's fired up and see if that works. 16:48

I'm gonna stop my previous instance and I’m going to run that 16:50

boot run task Looks like we've compiled successfully and 16:55

if all goes well, our application will start successfully, cool. 17:02

Let's flip to chrome and see what happens. 17:06

I'm going to refresh, and there is our logon page. 17:09

Okay, we've got a username and password field here. 17:14

So let's first test invalid credentials. 17:17

I'll type user for the user name and nothing for the password. 17:20

Cool. 17:26

There's our flash message. 17:26

Yeah, it could use a little styling work but it's okay for now. 17:27

Let's make sure though that it acts like a flash message I'll refreshed and 17:31

hey great it's gone. 17:35

Now let's check to make sure authentication succeeds when we 17:37

enter the correct username and password. 17:40

So I'll enter user here and password here and hit enter. 17:43

Okay it looks like providing even the correct username and 17:48

password did not lead to successful authentication. 17:51

Now there are a bunch of reasons why this could happen and 17:55

one of the most common reasons is that usernames and 17:57

or roles aren't getting inserted into the database correctly. 18:00

Let's check our input dot SQL file to make sure. 18:05

That that's the case so I'm wanna scroll down import.SQL and 18:09

looks like I do have my role being inserted as a Role_user 18:13

that's good insert user and okay all this is working nicely. 18:17

One thing I do notice is that insert into role 18:22

It doesn't have a semicolon at the end. 18:25

Let's stick semicolons at the end of our import file, 18:27

at the end of each query in the import file and 18:32

rerun things and see if that helps us at all. 18:36

Okay, let's scroll through the output and 18:46

see if we can verify that users and roles are inserted, 18:49

so I see that we've got insert and user insert end user that's all nice. 18:52

Let's see if we can see the insert statement for roles. 18:57

I see unsuccessful insert into role. 19:04

So here you can check out the output, 19:08

just to make sure that you are getting things inserted correctly. 19:10

And it actually looks like our users were not being inserted correctly even though 19:15

These queries were attempted. 19:19

No worries though we can figure out what happened with the SQL syntax and 19:23

make our changes accordingly. 19:27

Okay, so insert into user 19:28

that is not working it says that the calling count does not match. 19:33

And I see that now. 19:38

I see username, enabled, password. 19:40

But then, I see four values. 19:42

You can probably guess which one I forgot. 19:44

I forgot the role ID column. 19:46

Check this out. 19:49

Role_id, role_ id. 19:50

And with that in place, let's now stop our application and 19:57

reboot and see if we get success. 20:02

Now I want to show you how this looks live, so 20:06

that if you run into similar scenarios, you have experience scrolling through 20:09

this debugging output and finding these things on your own. 20:14

Okay, cool, now I don't see those errors in my output here, 20:19

so it looks like things are getting in okay. 20:23

Let's see if that is the case, I'm gonna refresh this page, that message is gone. 20:27

Let's see if user authentication fails with what we know are invalid credentials. 20:32

Great, that should come up without a password, now user and 20:39

password, there we go. 20:44

We are in. 20:46

Excellent! 20:48

Debugging, successful! 20:48

Now, we'll get to the user specific tasks in a bit, but 20:51

now that we know we can get in, let's test our log out feature. 20:54

And I've got this power icon here at the top right that's an inline form posting 20:58

to the slash log out URI. 21:02

Let's click it and make sure we're logged out. 21:04

Cool, we are logged out. 21:07

Now before we wrap up this video, 21:10

I'd like to show you how Spring saves the fact that a user is authenticated. 21:11

And I'm going to do this by opening the Chrome Developer tools. 21:16

I'll click refresh, just so I can capture all results, because I'm gonna be looking 21:21

at the Network tab, and let me pan up a little bit here. 21:26

I'll size that down to give myself a little more room. 21:30

Okay. If I now click on login, right here, and 21:34

navigate to the Cookies tab, you'll see a cookie named JSESSIONID. 21:38

This is an ID unique to this browsing session, that is, this window in Chrome. 21:44

This cookie is set in the browser, when a request is made to the application. 21:52

And every request, thereafter, from the browser, will include this. 21:57

Here, I'll give you a closer look. 22:01

Let's log in and see what happens, user, password. 22:03

Let me scroll up to the top here and check out that first request, the login request. 22:12

Looking at the headers of this request, we see that the response 22:19

had a 302 Found status code, and a location header, 22:25

if I scroll down here, a location header, going to the root of the application. 22:31

Now looking closer, you'll see that there's a response header from the server, 22:37

instructing the browser to set a cookie named JSESSIONID, 22:41

right here, using the set cookie header in the HTTP response. 22:46

Now, switching to the subsequent request, 22:53

that is the localhost request, we can look at the request headers. 22:56

Let me collapse the response headers. 23:01

We can look at the request headers to see this cookie header being sent. 23:04

This cookie header is sending the JSESSIONID cookie using 23:09

the same value that was set in the browser using the previous response, 23:14

so the response instructs the browser to set a cookie value for the JSESSIONID. 23:19

And then subsequent requests by this browsing session to the same domain, 23:24

will send that cookie value, along with the request, as a cookie header. 23:29

So what's happening here is that upon authentication, 23:35

Spring Security saves your authentication data on the server and 23:37

associates it with that JSESSIONID. 23:41

Then, in the HTTP response, it tells the browser to remember that value name, 23:46

JSESSIONID, on the initial request to the application, so that future requests can 23:50

be lined up with the already saved authentication information. 23:54

That way, your users don't have to provide their usernames and 23:58

passwords on every request. 24:01

Pretty cool? 24:04

Now be sure to check the teacher's notes for 24:05

considerations when working with session IDs and cookies. 24:07

You need to sign up for Treehouse in order to download course files.

Sign up