Spring Security 5.5 From Taxi to Takeoff

welcome back everybody to spring one i am excited to on this next uh to present you this next talk spring security 5.5 from taxi to takeoff we have three speakers this time out it's josh steven reesberg and marcus dicargio guys take it away welcome everybody thanks for coming to our presentation it's so exciting to be with everybody uh to be with you live if you're catching it with us right now or if you're kitchen recording after the fact we're happy to have you here leveling yourselves up uh on application security specifically with regard to spring security and finding out how it can assist with your authentication authorization and defensive security needs my name is josh cummings and uh the um i've been on the spring security team for three and a half years now this is my fourth spring one on the team and they haven't kicked me out yet so it's a it's real delight to to continue to be here and have this opportunity to be such a to be part of such a special community i'm the father of seven that sounds as crazy as it is it's probably actually just a little bit crazier than you might imagine and i also love frosted mini wheats uh the um that that's my cereal of choice and i had it for breakfast this morning and it was delightful um and uh let's go ahead and let our two newest members of the team introduced themselves i'm i'm so delighted that our team is now six strong if you can believe it we have steve and marcus who recently joined the team and let's take a chance for them to introduce themselves steve would you go first and then we'll let marcus introduce himself absolutely hi everyone my name is steve friesenberg i'm just absolutely thrilled to be here i joined the spring security team just about four months ago and it's been a real pleasure and a blast i've enjoyed working with the community for the last four months and i'm really looking forward to what's next as far as me i just have two little ones and i've joked with josh a couple of times that sometimes it feels like seven but i know it can't be anywhere near as much work so hats off to josh for for that it's just amazing i am also a musician and so when i'm not coding i'm often playing my instrument practicing my instrument or performing so that's just a little bit about me and i think we got marcus marcus are you on coincidentally i am ah there you are we had a little technical difficulty right then uh marcus go ahead all right thanks josh uh and so it's a great pleasure to be here today and you won't believe it my but my house went out of power just now and it's come back now and uh and it's always good when we talk about security right so my name is michael d'accoragio i have joined the spring secret team four months ago and it's been a great experience so far to be working with such great teammates and a passionate community and a little bit from me i'm a burger lover i can eat burger in every meal and also i'm a bonsai beginner so i hope to get to mr miyag's level in the future so this is just a bit from me let's hear from steve now all right and i actually just spoke so i'm going to kick it over to josh all right this thing started great let's do it what we have here is a web application that our our theme today if you can't tell from the title is flights and this web application allows pilots to request permission to take off in an air traffic controller to grant that permission and we thought it'd be fun to do a little bit of a role play here so what we're going to do is steve and marcus are going to be pilots during this role play i'll be an air traffic controller and pilot marcus will request permission to take off and uh then something will happen that will disturb the standard operational procedures see if you can spot it and what happens and then we'll come back and talk about it take it away marcus so eric dave controller josh my flight one or two is ready for takeoff thanks for meeting my permission requests can you consider approving it thanks your request has been received market for flight 102. thank you please continue taxing along the runway you'll be advised when you're ready to take off hey josh sorry to interrupt but can you check your email real quick i just sent you this email for this great meme you just have to see i know it's bad timing but can you check that yeah sure no problem i i love i love i love facebook memes let me check that out oh well you know it's kind of asking me to log in i i'm kind of short on time steve i'll check out later you know what i was i was trying to hack your facebook but you're not logged in so you didn't fall for it good for you okay never mind hey josh thanks for your approval i'm proceeding for takeoff now see you oh pilot marcus no negative negative you may not take off you're not cleared for takeoff there's apparently some kind of problem with the software i'm not sure why it's telling you to take off but please wait for i suppose my manual approval please wait please continue taxing all right so we had a little bit of fun with everybody thanks for listening you can submit your oscar nominations uh at any time uh we um uh what did you see here well obviously this is an unsecured application and there was some kind of interloper that was able to perform what's called a sea surfer attack or cross-site request forgery where a third party made a forged request that seemed real enough for the application to allow for it and somebody else was able to approve uh the flight for takeoff without my intervention and that's one of the many things that we need to be aware of as application developers we're worried about all manner of security or security vulnerabilities as well as doing authentication and authorization appropriately and that's where spring security becomes such a critical component in your software stack because a number of those things are taken care of for you or simplified to help you make the right security choice what we're going to do in this presentation then is we're going to take this unsecured application add spring security to it step by step we have a back end rest api we have a front end single page application and what we'll do is we'll start with marcus he will and add the the beginnings of spring security into the rest api talk about what we're doing and why and slowly we'll move up to the front end and then by the end we'll be doing some extra advanced things on the back end and show you why those are important so uh marcus do you want to take it away yeah sure thank you josh so as josh mentioned the back end application was totally insecure and we are going to go ahead and start fixing it so first let's uh go to the cli and let's take a look how the the the requests are looking like so i can see my flights here and i can see everybody slides and that's working well so let's go now to our build.gradle file and add the spring security dependency and because this is a spring boot application we can make use of the starter dependencies and just add spring boot starter security so i just refresh my gradle project here and restart my application so we are gonna see some difference between the previous requests and the the the newest ones and we are gonna focus on the more important for the purpose of this demo so let's repeat the request and now we can see that my requests are aren't even being completed and more instead it's returning me a status code 401 which means that you have to provide some authentication and the authentication here that it it is expecting is the basic authentication and additionally uh it should happen to every endpoint it doesn't matter if it's a user-generated endpoint or like a springboot generated endpoint like slash error it to behave the same so spring security says that every endpoint requires authentication and this is the first principle called secured by default also there are some other places where spring security implements the secure by the focus poll one of things the default username and password as we as you may know spring secure generates a default username which is user and the default password is randomly generated every time you restart artificial and it's printed to the console and why does being secured do that so it comes against the principle of secure by default so imagine scenario where you have deployed your application to the production environment but you forgot to change the spring profile let's say from there to production and unfortunately on the dev profile you use this the full spring security credentials so if spring security had defined a single default password and malicious user could decide to get the password and get access to our application the production environment so this is one of the reasons why spin sector generates the random default password every time so let's go ahead and take the password printed in the console here all right so we can come back to the terminal and repeat the request and now i'm going to pass the default username and default generated password and we can see that it's working fine now and this is really nice so moving on now we are going to talk about uh another principle which is the principle of list privilege and to exemplify it better let's take place of a malicious user that's trying to find any information about our application and imagine if i come here and i make a request to the index.jsp file and and it returns me a 401 and if i try to request the index.html file and instead of returning a 401 it returned me a 404 i can easily deduce the technology that's being used by the application and it will help me to accept my attack and this is the principle of this privilege in action all right so we have just seen that it's been secured uh by the pho generates a full username and a default password for you but when i'm creating my own application i want to provide my own user star and the way to do that is to expose the user details service to be so let's go ahead and create a security configuration class here and we are going to use the add configuration notation and declare a bin of type user details service here and for this application we are going to have two users which are josh who is the flight controller uh me and steve who are the pilots so let's go ahead and restart my application here and in our demo we are using installing the users in memory but you can connect your user detail service to a spring data repository a jwc that page or any kind of data access object that you want so let's come back to the terminal and now i'm going to use my credentials here this password here is just a plain text password uh crypt encoded so i can just type password here and try to see the flights and it's working so let's just scramble the password just to see if if i provide of wrong conditions it returns me a 401 okay and we can come back to the log here and we can see that the default password isn't being generated anymore because we have overwritten the default security configuration and the way we were able to accomplish this is by using component-based configuration and we have provided a component more specifically a user detail service component as a beam and spring security uses that beam inside its secured configuration all right so moving forward i want to come here now because i have steve credentials and i want to see his flights but instead the applications return my own fights here so i headed over to steve now and who show us how to personalize the api to return the authenticated user slides go ahead steve all right thank you marcus let me share my screen here and so as marcus just shared with us we have not yet personalized our application because up to this point we didn't have spring security we didn't have an authenticated user so we're just hard coding the user id in here as the pilot id but what we could do is we could look to personalize the application using that currently logged in user and one way that we could do that is through something called the security context holder now the security context holder is a thread local and it gives us access to the security context for the application and this is available anywhere on the current thread which is bound in a servlet application to the current request and so if we access the security context we get access to something called the authentication object and so the authentication gives us some of that information about the currently logged in user for example we could see that is authenticated tells us whether or not the user is authenticated we can get things like the authorities which we'll learn about in just a few minutes we could get some details about the user and some other things but in this case we can also get the authentication name and the authentication name is really just the username of the currently logged in user so if we get that we could use that as our pilot id to personalize the application and so that's one way that we could get access to the user name but you can imagine that there's a little bit of a difficulty in testing this code because i'm going to have to mock out that thread local pattern and the security context as well as the authentication and so another way that we could do it is we could use something called method injection and method injection is a feature of spring that allows us to inject certain objects directly into our method and so here spring security collaborates with spring to allow us to inject the authentication object itself directly into this method and it resolves the authentication much the same way as this code that i've shown here it uses the security context holder to get the the authentication for the currently logged in user so we could just access the authentication directly and that would be a similar way and of course this might make it just a little bit easier for us to test the application in unit test because we just have to mock out the authentication that we pass in here and so let's go ahead and restart the application and with that change we should be able to see that i can access my own flights so if i hit the flights endpoint again and i use my own credentials here i can get my own flight so here's my flight but if i change that to marcus now we should see that we can still get flights owned by marcus when he logs in okay so that's working and so we've personalized the application using information about the currently logged in user so i'm going to take a step back for just a moment and we're going to look at this api and i'm noticing one small problem here and that is that the flight's all endpoint is exposed for all users so if i marcus again for example i can go and access all of the flights but in this case as we kind of said at the beginning marcus and i are going to be pilots and josh is going to be an air traffic controller so ideally josh would have access to information about all the flights in the system and marcus and i would just have information about our own flights and so this is something called authorization and so we can actually use spring security to build our own authorization scheme so i'm going to hop over to the security configuration here and just as marcus added a user detail service mean we can add one for our security filter chain now this we'll learn a little bit more about the security filter chain in a few minutes but what i want to show you is that on my screen is very close to the configuration that spring security ships with out of the box the only thing that's different about this is that i'm not using form login and that's because we're not going to be showing that in this talk but otherwise you can see that we have basic authentication enabled and we've expressed in our authorized http request block here our default security posture which is that any request must be authenticated and so that's great but maybe we want to customize that as i just said so let's go over here and i'm going to split the screen so we have the the api on one side and we can begin customizing our own requirements here so i'm going to say for the flights all endpoint that we can add our own custom rule and so maybe we could say has role here and that would be a pretty typical use case but down here all of our users have the role of user so we could change that and we could give these your users different roles in this case i want to show a slightly different mechanism let's use the has authority method and so what we can do with has authority is we can use any kind of generic string that identifies either an authority or a permission or something that the user has been granted that tells us about what they're able to do so i'll just say here for the flights all endpoint that we're going to require the authority has all uh flights all and similarly just to make this consistent let's go down to the flights endpoint and we'll say that for flights we're just going to require an authority of flights read which is a typical permission identifier and then for the other two we have updates here these are both put mappings so let's just say that any other request that doesn't match the first two has authority of flights right and that would be a pretty good start for a custom authorization scheme but i want you to notice one thing and that is that the taxi and the takeoff endpoints are again slightly different and that's because the taxi endpoint is designed for a pilot to request permission to take off so that would be marcus and i but the takeoff endpoint is designed to be used by an air traffic controller that approves those flights so that requires elevated privileges so what i'm going to do is i'm going to come over and add one more rule and i'm going to use star to indicate the flight number then i'm going to say take off and so we're going to say that this requires the authority of flights approved and again this is a special authority that will grant to that user so they can do that but of course our users don't have these authorities so if we were to log in right now no user would be able to do anything so what i'm going to do is come down here and we can go ahead and in our in memory data store we can use some authorities instead of roles so i'm going to say that marcus has the authorities flights read and flights right and similarly i'll have the same ones but then for josh we're going to need all four of these authorities up here so we can say that josh has flights all flights approve flights read and flight's right and so now we have the authorities that we need so let's go ahead and restart the application one more time and this time we'll see a little bit different behavior first i'm going to try as marcus to to use the flights all end point and marcus doesn't have the flights all authority and so because of that marcus is receiving a 403 so this is a forbidden and what this really corresponds to in spring security is an access denied exception and this is telling us that you do not have the right authorities to make this request and so that makes sense if we go back to the flights endpoint then marcus should continue to see his flights because he has the flights read authority so that's great but what about making an update here so let's say for marcus that we wanted to update flight 102 and we're going to use a put request for that now we'd expect this to succeed because marcus has the flight's right authority but what happens hmm we're getting a 403 again and that doesn't make sense so something else must be going on and we need to learn more to find that out so what i'm going to do is turn the time over to marcus now again and he's going to show us how to debug a spring security based application and armed with that knowledge maybe we can figure out what's going on here marcus all right thank you steve so before fixing steve ford we we're gonna learn a little bit more about spring security and how and when it's being secured to participates on the request that comes to our back end so let's come to here to our application yaml file and add the login level place for the spring framework security package and restart our application and starting from version 5.4 office spring security uh we did some exposuring in our logs and the goal was to make to make it very clear of how and when spring security's interception requests and how it's going along the way so i'm just clearing the logs here and just gonna do a valid request so we can see the the logs right so let's come back to the logs here scroll up a little bit and we can see that one of the first places that spring secured uh interceptor uh requests is in the filter chain proxy and the filter chain proxy is the entry point uh for the request to come into spring security and we can see here that the requests have been matched against the request measure and request that means that any request has to come to the security filter chain and after that we can see a list of filters which will which be applied one by one in the order that you can see here and scrolling down a little bit you can see the the filters being invoked one by one and each one of those filters has a single responsibility and and they can continue processing the requests by calling the next filter or terminate the request by interrupting and not calling the next filters and if you you're familiar with it this is the pattern of the design pattern chain of responsibility in action and also this is what we call the security filter chain in spring security additionally remember when steve was talking about the security context holder that had the authentication object with the user details so here in the logs we can see that the basic ultimate spatial filter found my username in the header and it populates the security context holder with my credentials and that's amazing so let's come back here to the terminal and let's see if we have the same error as steve had so he tried to to update my flight here with my credentials so okay we have a forty the same error so let's come back to the logs scrolling to the bottom and scrolling up now a little bit so we can see here let's secure my endpoint that i requested and like we can see now the error in the logs that when it was invoking the cs rf filter or the sister filter it found an invalid token and responded as we saw with a ferocity status code so what does that means uh the back end is asking us to provide a c surf token in order to authorize these requests and this is this is a common mechanism to prevent cross-site request forgery as we have seen in the beginning of our presentation so let's go ahead and provide a c surf token for our front end so if i come back here and i'm going to use the c surf gsl so i just declare the css cserv token repository and that i am telling spring security to read and save the scissor token in a cookie so let's try that so i'm gonna restart my application here instead of testing it via the cli let's do it via our our front end our single page application so let's go ahead here and the request and we can see that here that my flights are aren't even being shown anymore so i'm opening the developer tools in the browser and we can see that there is a cars error and i i'm pretty sure that most of our audience today have faced this error at least once and there are many solutions out there on tutorials on stack overflow for example but but we are going to provide you one elegant solution so let's go ahead and fix it uh we already have our cars dsl here but you have to provide a being of the of the type course configurations first and i have to allow my front-end origin to access my api and also i'm going to allow conditions to be sent the basic credentials so i'm just fixing the imports here and because uh cars is a two-sided agreement between the the origin and destiny i have to change my front-end and i have to tell my front-end that the request contains credentials so i'm just gonna come here and refresh my front end and wait a little bit for that and most of the times adding the allow credentials to two is can be a code smell so stay tuned in our presentation because we're gonna get rid of it in a few minutes so our front end is restarting now i'm gonna go ahead and refresh the back end application so let's come back to the to the single page application refresh and now it's asking us to provide credentials so i'm going to provide my credentials here my flights are here and i can now request takeoff and we didn't receive the 4p errors so let's see why so the preflight request contains the the the course headers here so nice and if you come to the put request we can see here that the request contains xsrf token uh as a cookie and also the c-serve token as a header and this is a common pattern called double submitting cookie all right so we have just learned about the security filter chain and how protects our application from sister of attacks and i will turn it over to josh now and you will continually improve your permission model go ahead josh and you're muted josh button ran away from me i was i was hunting for it great thank you very much marcus it's great to see a working application that has a and sea surf defense as well as as well as authentication and authorization taken care of um let's start to look at a couple more subtle things about authentication authorization uh through for the for the remainder of our presentation the first one i want to point out is a couple of tests that we have here that demonstrate a um an issue that you may have run into before when thinking about authorization you can see here that with this test marcus we're testing to see whether marcus can mark his own flight as ready or as ready for taxiing requesting takeoff and we'd expect that to work we would not expect um something else to work though excuse me it looks like my test didn't run like i thought there we go um the second though is whether or not marcus can mark someone else's flight and can request takeoff for someone else's flight we'd expect this one to fail one pilot probably shouldn't be able to request permission to take off for another pilot but we can see this test fails we don't get the forbidden like we wanted to instead if we take a look um at the bottom here of our output we can see that we get a 200 instead of a 403 it actually passed it allowed marcus to request permission to take off for steve's flight this is a classic web application security vulnerability called insecure direct object reference the problem is that anybody that has flights write permission can hit this put end point supplying any flight number that they wish one way to solve this would be to do some kind of a statement here we could always ask if the pilot id is equal to the currently logged in user this is using the authentication object that steve talked about we could request it as a method parameter and then if this passes then we can go ahead and change the status it fails maybe we can throw an exception like an access denied exception however we'd prefer not to weave our authentication behavior into our business logic we'd prefer to be more declarative with our security steve has already shown some declarative security patterns by using the dsl let me show you some that are method based now this is a great spot for something called for the post authorized annotation that spring security supports both authorize is an annotation that analyzes the return object that comes back from a method and you can run a test that says something like what we just talked about if the pilot id is equal to the id of the currently logged in user then you can allow the method to complete otherwise throw an exception it's the same behavior that we were talking about putting inside this method directly what's nice about doing it here is it's declarative and it relies on a framework to do the business logic for you instead of needing to embed it inside of your method and in conjunction with springs transaction management once this throws an exception any kind of change to the database will be rolled back so that we don't have to worry about that commit occurring either there are other annotations like post authorize there's one called pre-authorized for analyzing method inputs there's also pre-filter and post filter that allows some higher level collection management for method parameters that are collections or re or um excuse me uh or return objects that are that are collections to get spring security to honor those annotations we need to add the appropriate enable annotation this enable annotation tells spring security that we're going to be using spring security's pre and post annotations and anytime it's seen on a method spring security should intercept that and apply its own rules as specified by by those annotations so let's go ahead and try the test again and while this is running i just want to point out so uh ria another member of the spring team gave a great presentation on testing security and doing test-driven uh test-driven security which i strongly recommend you can see that we're following similar patterns here to what she uh evangelized uh especially or specifically one thing that she pointed out in her talk is that we can include sea surf in these which is important since that's what's required as part of the security contract for those requests we can see that we pass now and that's great we've handled in this particular request insecure direct object reference another thing that we can do with authorization in spring security that you can do is we can externalize our authorization marcus showed us how to externalize our authentication by going to a database in order to query the um the users and passwords excuse me um and what i'm going to do is show you how to do the same thing for your authorization model i have a little thing that helps out with some of the boilerplate here it just implements the interface for me you can imagine for example that you might have a spring data repository that holds your authorization rules uh and so we could go ahead and import that but this can represent a number of other things like if you're using open policy agent or if using some other entitlement server to centralize some of your authorization details we can go ahead and call out to that we wouldn't necessarily want to call out on each request though instead we might want to be able to um find out in in some kind of scheduled event uh what the details are so we can cache that instead of taking a long time to authorize by farming that out to a remote service so what i'm going to do here is just do something a little bit simple and representative of of of a more fuller solution that uh that would um find this information out by querying the database simply put we can use the same api that spring security uses to do filter-based security it's the request manager delegating authorization manager which is an appropriately long speed spring component uh that that's how you know it's a real spring component because it has a long name uh we'll go ahead and build that component now with all the rules added and then i just need to declare that delegate up here and use it let's see request manager delegating authorization manager call it a delegate and then we can use it inside of our code once we call this delegate then we'll go ahead and make our authorization decisions based on the thing that we generated programmatically by querying the database for the rules at that point it's a matter of importing that authorization manager and changing our authorization rules to instead of being declared here in memory they're declared in our in our authorization manager that queries the database let's go ahead and restart the application i'll head over to the browser and we'll try it out let's see now it's asking for my username and password as as was done before with uh with marcus and we can see that i can do all of the same things that i did before no change in behavior that's great let's check on the back end and make sure those work as well if i go ahead and hit the end point using marcus oops and i hit the flights all end point we should see that the same rules are given as before let me just see if i can make that look a little prettier we see that we get a forbidden however if i use my own credentials then we can see that it's allowed now we do have just a little bit more time so i want i want to show you one uh i want to turn it over to see to show you one more um one more thing that you can do to make your application even better using spring security using um a different authentication mechanism other than http basic but i want to elaborate on why this might be important to you consider the fact that um like when i time this endpoint it takes you know somewhere around 100 milliseconds and perhaps that's surprising because uh we're not we in this demo we have an in-memory database we're not doing any network calls or anything like that what could possibly be taking 100 milliseconds now i'm not going to give the secret away i'm going to let steve talk about that um but before we go there and i want to try something to see if it's going to help this demo is equipped with um spring native support so i can run a command like this which will take a little bit long on the build if you've ever done this before so i've done it before the demo we'll just we'll just we'll just benefit from the result of running this command but you can run this command too when you uh when you download the demo and try it out it will build a native image for flights api spring security uh integrates the spring native for all of its authentication mechanisms all of its authorization models with the exception of i think there's still a little bit more work for us to do on the saml side um but otherwise it works with oauth it works with http basic form login and uh and everything that that that you might want to use so let's go ahead and try it as a native image i've already built it as an initiative image let's see if we get any performance benefit from doing that oh excuse me i've got to turn off my my other one uh and then let's try it again we can see great we get we get a nice quicker startup time runs in about a quarter of a second which is more than a 10x improvement if you were looking at the startup time uh in in my window earlier uh however if we do this we'll notice that we're still you know we didn't get any benefit on the request site i wonder why um what i'd like to do is i'd like to turn this over to steve to elaborate we're gonna actually change out the authentication mechanism he'll show this and and and other reasons why it's value excuse me why it's valuable for um for you to uh consider the the the recommendations that steve is about to make take it away steve all right thanks josh let me make sure i get the right things shared here okay so hopefully you can see my ide here and so what josh just showed is actually we're making requests to the api and it's taking an amount of time because we're using basic authentication and basic authentication when we're sending the credentials every single time that means that the password needs to be hashed every time and compared to gets against what's in our user store and because we're using bcrypt as the hashing algorithm that means it's going to take a certain amount of time no matter what we we can't really improve that beyond just throwing more processors at it so at this point what i'd like to do is switch over to a different authentication scheme and so we're going to show actually using something called bearer authentication and in fact we're going to use spring security to validate bearer tokens as jots or jwts so in order to do that i'm going to switch over to our build gradle here and instead of just bringing in spring security what we can do is bring in the oauth 2 resource server support and this will bring in spring security as well but in addition it has this resource server module in oauth2 that's going to allow us to perform uh decoding these tokens and using them as our authentication mechanism so let's see how that would work so if we come over to our spring security dsl here we can get rid of basic authentication because we won't be using it anymore and i'm going to actually get rid of c surf as well because we're going to move that in just a moment to another component in our architecture and instead what i can do is i can use the oauth 2 resource server dsl and if we want to support jots then we can use a little shortcut here the oauth 2 resource server configure which will configure us to use jots out of the box and now that's that's it for dsl changes we're ready to actually decode tokens however we need to do one other thing which is we need to contact some kind of authorization server to mint those tokens for us and to give us some secure keys that we can use to verify a signature on them so i'm going to open up our spring security application yaml here and i'm just going to add a couple of properties so we could get by with just the issuer uri here and this is an issuer for an authorization server that i'm running uh already and just a shameless plug here joe and i gave a talk earlier about the spring authorization server and that's actually what boss server i'm running here but in addition i'm going to provide the jwk set uri and this is because we want that that startup time that josh just showed us in our native image to be as fast as possible otherwise we could get by with just the issuer uri so with that we'd be ready to restart our application except for one small problem and that is that we have these rules these authorities stored in in rules in the database and so we need to make sure that when a token is decoded the authorities match and so i'm just going to add one additional bean here and it's this jot authentication converter and i'm not going to describe in detail what this is doing as we're winding down on time but i do want to say that this is going to make sure that our authorities come back and match as they did before and so i'm going to restart the application here okay we're going to come over to our terminal and very quickly we have a little bit of time left so i'm going to run a little script that's going to contact that authorization server i mentioned we're going to log in directly to that server as josh and so i'll use josh's credentials here and i'm going to print out the token so you can see that this is a jot and it's this long crazy thing and we can see what's in it actually there's this sub claim and a claim is really just a field or parameter and in this case this actually corresponds to the user name so much like we had with authentication name we're still logging in as josh and he has scopes instead of authorities and again those are going to get translated into authorities in our system so with that we should be able to make a request and so i'm going to hit the flights endpoint and i'm going to grab the authentication and that is an authorization header and so i'm just using the bear scheme as i mentioned before and we're passing that token value that my script retrieved and so we should be able to see the same result as before we get josh's flights and what i'm going to do is let's actually time this now and so i'm going to actually switch to using curl just so we can run a little bit faster here and so it's running pretty quick actually uh it's not going too bad and so if i just run a bunch of these you can kind of see that we're getting a lot better performance and if i were to hop back to the logs which i won't do now we'll see that the authentication step takes much less time in fact just one to two milliseconds now if we were to run this natively which i'm going to do in just a moment it should be even faster at least the same but what i'd like to do for the last step which we have just a few minutes is kind of jump to the end and i'm going to go ahead and stop these two services here because what we can do is actually switch our entire scheme over to using oauth as the authentication mechanism and we're not going to go into detail about all of the steps that are required to do that because it's just a few steps and it's it's a little bit more advanced than we want to do for this talk but we will have a commit in our repo that shows you exactly how to do that one thing i'll say though is that we've set up a back end for front end using um spring cloud gateway and so that's in here and so that's going to be handling our oauth handshake for us and so instead of actually requiring our single page application on the front end to use access tokens and store them in cookies and do things like that we can just use a traditional authentication mechanism with the session id on the front end and so what i'd like to do is i'm going to jump to that and in fact what i'm going to do is just run all of our applications natively so i've pre-built all of them just to as josh had done and so we can start them up here and so i have an authorization server a resource server and an oauth client which is actually serving up a single page application and i'm going to jump over to my browser here and so what you can see is i've actually been redirected over to that off server to log in and so i'm going to go ahead and do that and once i get past the first authentication step i'm asked to consent and so we see the same authorities as before but now there's scopes that we can consent to to give the client application permission to use these things and so i'm going to give flights read and write access to the application and i'm going to submit and then i get redirected back to the ui and it works as it did before and so that's great and so i'm just going to clear the logs here and let's request takeoff and again all of these are running natively so everything should be fast and there any issues that we've had again you can see that commit in our repo to see how we resolve those things and here it is we've got a request in to to be on the runway and so josh can i go ahead and log in as you and approve this flight is that okay yeah uh uh uh sorry negative negative you you're not allowed to do that i will i will take care of that myself all right i'm going to turn it over to josh now and he's going to wrap us up josh sure thing all right so we talked about a lot of things uh today and to get you started with spring security uh we started by talking about some different principles that undergird the spring security api how we think about what we what we produce and we talked about being secure by default we talked about the principle of least privilege thank you marcus for both of those and and both marcus and steve demonstrated the power of dependency injection from the standpoint of producing beans that spring security can take up and you and and your application reading those beans or components uh by by asking for them via constructor injection or method injection or whatever might be the case we also talked about some of the underlying architecture in spring security it uses uh it uses it it relies on the servlet filter chain model we have our own filter chain called the filter chain proxy and inside of that there are a number of authentication authorization and defensive security filters each one of them participating to help make your request secure and authenticated and we in in in line with that we showed some of the improvements to trace logging that allows you to see what's going on in each filter why you got the 401 why you got the 404 so you could react correctly inside of the way that you're configuring it or the way that uh or the way that that you're using the spring security api and then we proceeded to talk about cores and c-surf where those play a role when we're deploying into a browser when we're a browser-based application we talked about security testing and again i'd advise that folks take a look at rhea stein's presentation test driven security for more information about to dive in on learning how to do testing with spring security talk about declarative security you'll notice that for the most part we kept um we kept authorization and authentication logic out of our application we simply declared the appropriate beans uh used the dsl used annotations in order to configure our security instead of putting it inside of our business logic and then finally we looked a little bit at native support we got to see and that spring security supports spring native for a number of authentication mechanisms and then finally steve wrapped up showing us some of the benefits of using a short term credential not only do we get security benefits because we exchange a long term password for something short term like a jot or jsession id instead in the case of forum login um but we also get performance benefits because we're not having to hash that password on every single request the requests perform much faster so there are a number of great reasons to consider uh consider something uh consider the pattern of exchanging a long-term credit for short-term cred uh there are so many great talks about security at spring one this year i am so excited some of these have already passed i'm getting started with spring authorization server test driven security those have already been presented but you can catch the recordings these others i believe are all on day two so check them out i'm super excited about each one of them and i'm gonna try to try to do my best to to watch those and they're all from great individuals from the security community um and uh thank you very much that's that's it for us you can find us over at our github repo spring project spring security you can also find this um this sample at s john r spring1-2021 find us on stackoverflow you can sometimes find us on gitter as well we're happy to answer questions help you out find ways that we can improve the the the framework you can find us uh on twitter joe marcus decoratio and s john r and we hope to see in the q a thank you very much everybody and uh have a great time at spring one thank you thank you hey josh steve marcus thank you so much for that talk it was spectacular and i was like i wonder if they can get all that into the single talk wow y'all did it so folks um with that you can join uh josh marcus and steve in a zoom breakout and ask feel free to ask them questions and for those folks uh remember at five o'clock we are going to head back to main stage and listen to some pretty interesting uh customer uh conversations as well as some uh announcements so folks look forward to seeing y'all tomorrow at 9 00 a.m eastern standard

Channel: SpringDeveloper

Views: 2,613

Rating: 4.9487181 out of 5

Keywords: Modern Web, Security

Id: 5tlU_Vjv8Ns

Length: 51min 5sec (3065 seconds)

Published: Wed Sep 22 2021