Securing Microservices with Spring Cloud Security

thanks for coming to my talk services with spring cloud security I'm will Tran and please follow me on Twitter I do not have many followers 510 will a little bit about me I'm spring user and I have been since spring to dotto pretty much my first job after University was re architecting at PHP application in spring and I've been using spring ever attempts and through many strokes of luck I now work for pivotal actually because I've been working with a lot of amazing people throughout my career I'm now working for people I'm currently with the spring cloud services team if you follow the cloud native track you'll see a lot of what's been happening there and formerly I've been with pinnacle single sign-on which is product built on top of Cloud Foundry you aa4 a pitiful Cloud Foundry I've also made a lot of commits to Cloud Foundry you AAA to make it multi-tenant and before that I was working for pivotal Cloud Foundry mobile services this is my second time speaking at spring 1/2 GX you might have seen me last year talking about as horn in spring boot and I'm based in Toronto Canada so I guess I have to go over what microservices are but I'm sure you've heard this repeated many times this quotes from Adrian Cockroft formerly of Netflix and he describes them as a loosely coupled service-oriented architecture with bounded context what he means by loosely coupled is that services can be updated independently and what he means by boundary contacts are is that services are responsible for a well-defined business function and care little about the services that surround it so I read that as do one thing and do it well now in practice micro service architectures are usually taste or they communicate via some other open standard there containerized they are independently deployable and scalable and they are self-sufficient which means that it makes as little assumptions as possible on the external Armin's so when you move to microservices how does that affect security first we'll go over a typical security setup for securing a monolith you've got an HTTP request or HTTP request coming in I hope everything is going over HTTP hits your load balancer now your load balancer may or may not terminate the SSL connection maybe it's starting a new SSL connection with the app servers maybe the connection between the load balancer in your app servers just HTTP but you're inside your your network so that's fine cool so request hits your app server you probably have an authentication layer built into the application the request is authenticated and authorized and then the request gets passed along to various modules in your application and you're probably sharing a single database connection pool with a single set of credentials to access the database that hosts all of the data functionality of your of your components so this is this is easier than securing microservices because you only need to authenticate the request once per request so if you don't have a session you have to log in verify user credentials get the users roles and start the user session if you do have a session then you just have to verify that that session is not expired but that authentication layer takes care of all that for you and and then pass that authentication layer your request in a response the entire user request and response is handled in process so you can trust the method in Vacations that your code is making with each other I hope you can trust it or else you're really paranoid so the pros to this is that you have a limited attack service there's really only one way in and out of your application and that's easy to control and manage but the cons here is that the application has all the credentials it needs to do anything it wants to the database if you can break into that process then you get it all so let's look at microservice architecture a little such as this where you've got your functionality broken up into each its own application each application is accessing a database using credentials that are specific for that function that's kind of good because you can lament the principle of least privilege pretty well with this every component only has access to what it needs to perform its function but this is hard because you have a much larger attack service especially for internal threats so there's a lot of ways if you can get inside that Network there's a lot of ways that you can mess around and also how do you know how do other services know who is accessing them and how can other services trust each other so we'll talk about the this level set up here where you have a request coming in hits your load balancer hits an authentication authorization gateway so you have an application whose only purpose is to authenticate and authorize the request maybe it has a connection to a user store once the request is checked then it'll send a request to whatever service it needs to go to and you can see here that each of these services do not have an authentication layer at all okay so with this sort of setup it's called API gateway or primary parameters security and the public load balancer can't send requests to apps directly let's go back here the network setup only allows this load balancer to stand request the Gateway and then with such a setup each of these apps can trust that ok the request has been authenticated and authorized by the Gateway so they trust all the traffic they received by Assumption pros with this is that network setup can virtually guarantee these assumptions and apps have stay less security its stateless because they're just assuming that everything's secure so there's no other state may there's just one there's just one state well the cons with this is that nothing for internal threats if you can get into the network you can access any application you want so what if you built a security layer into every single app so one one approach with this is that you just use HTTP basic all apps get to do authentication authorization themselves and basic credentials get passed along with every single request the pros here is that it's stateless because you're authenticating the request every single time you don't have to maintain the session and it's easy because it should be basic support is like free out-of-the-box but the cons here is that well how do you store and look up user credentials and how do you manage authorization also you have user credentials being passed around all over the network and fene gets handle on those user financials you can unlock all the functionality that that user can perform forever until the user updates their password any questions so far okay look keep going all right so what if we kept all that same stuff but used a centralized authentication store or maybe it's just a sequel database or something like that so we still have basic auth all the apps get to do authentication authorization themselves credentials are verified against the central DB and this is good because you have a central user store one source of truth and it's still stateless but then a year off DB gets hit every real question that could be a bottleneck and now your look up logic has to be implemented everywhere same deal with user credentials they're being passed around all over the place and it can hold locked all functionality okay so what if we use sessions keep all that same stuff but each app gets to maintain a session with a client device that alleviates the off DB as being a bottleneck because that DB is only hit once per session but it's hard to manage all the sessions you have a separate session with every application you don't get single sign-on you still have dbl look up logic that has to be implemented everywhere and you still have user credentials being passed all over the place okay how about API tokens so forget about all the HTTP basic stuff and instead you have a username and password that gets exchanged for a token at a central authorization server ops can get this token the request and then validate the token by making a call back to the authorization server and the pros here is that the apps never see the user financials the only thing that sees user credentials is the authorization server that gets user credentials and exchanges them for a token but the cons here is that the authorization server becomes the bottleneck because every request results every request that a micro Service receives results in another request to the auth server to validate the token and if you're just rolling your own API token layer you might not be building in an authorization component so tokens provide nothing access sort of the same thing with user credentials okay how about sam'l sam'l is good it's standard in sam'l an identity provider provides sign decisions to apps so what a signed assertion is is that it's basically sets of keys and values but you can but it's signed so you can verify that this information came from a trusted source and apps can trust these assertions and verify them themselves and the pros here is that you have a standard trust model but the cons is that samwell's xml-based xml is big and stinking scary for a lot of developers and it's also difficult for non browser clients to participate in sam'l there is a sam'l to profile called ECP but I don't think it's very well supported so I've brought up a lot of common concerns here there's the bottleneck of a central user store you'll want to have single sign-on of course you want to keep things as stateless as possible especially your your back-end services once you get user credentials game over you'll probably want fine-grained authorization and you want interoperability with non browser clients so enter to an open ID connect what's oauth2 it's a delegated authorization protocol it's a protocol for conveying authorization decisions via token and it's standard means of obtaining a token via the for off to grant types for grant types or authorization code and you'll use this if you have a web application and it's also the most secure grant type which and you'll see why in a little bit we also have the resource owner password grant so you can use this if you have a web application but let's say you want to host your own login page instead of using the login page on the authorization server or let's say you are some non browser clients and you want to participate no off - here's the implicit grant the implicit grant is used if you have a single page JavaScript app so it is browser specific but it's if you have a single page JavaScript app and really no back-end and the client credentials grant is used when a client or a machine is operating by itself so it's not operating on behalf of the user so for back-end processes that might happen asynchronously that's that can be so you have these four grant types that cover pretty much every situation that you could think of and with oauth2 users and clients are separate entities which allows you to say something like I am authorizing this app to form these actions on my behalf but o2 is not authentication it says nothing about how the user is authenticated it does say that in order to obtain a token the user must be authenticated but it also doesn't say how a token is validated nor does it say what a tokens supposed to look like or if it's supposed to contain any information you can read more about this and Olaf net so that in what is open ID Connect well open ID Connect is a delegated authentication protocol built on top of OAuth 2 and in this protocol user identity is conveyed via signs JWT which stands for JSON web token and in short you can just call it jot it provides a standard needs for obtaining an ID token and you can do that over the same for oauth2 grant types and there's also a standard means of verifying ID tokens so that's a little bit of an extra thing that you're getting in the open ID connect specification and it allows you to say things like will is authorizing this app to perform actions on his behalf so these tokens convey both authorization and I did and identity and you can also if an application needs to see this person's email address there's a standard way of conveying claims about one's identity email address phone number mailing address all sorts of stuff like that open ID connect is not ossification though it still doesn't say how users are to be authenticated but this is a good thing because there's a lot of ways to authenticate users you can roll your own internal database you can hook it up to another identity provider over sam'l or LDAP you can do things like multi-factor authentication all of that is possible and open ID Connect but not really specified by the spec do you have any questions so far no ok so I'm going to walk through the authorization codes flow I know there's four different ones but this is the one that you'll probably see the most often it's also the most complicated but it is the most secure so in this little example we've got these four actors user and in both speak it's the resource owner the web app here and a lot to speak is the client the REST API over here is also called the resource server and the authorization server and Oban ID Connect speak is called the Open ID connect provider so you'll see these sort of ladder terms used a lot in documentation and the setup here is that sort of the situation before I begin is that no the user has no session with the authorization server or the web app and the use case that I'm going to demonstrate is the user wants to place an order on the REST API using the web app so step one user accesses the web app and does not have the session with it so the web app says note you're not authenticated and it's going to redirect the user to the authorized endpoint on the auth server the redirect URL contains the scopes open ID and order dot me scopes are like permissions or roles and when these scopes end up in a token that token says this user can do these particular things okay so the auth server gets a request to authorize end point but then redirects the user back to its login page because the users are not logged in so the user logs in and starts a session with the authorization server and now is redirected back to the authorized endpoint the authorization server remember what the user was trying to do in the first place before they had to login so now you see a page and you probably see in this page a lot where you have to authorize the web app to do things on on their behalf so the user sees a page and the page asks easier to permit the web app to access their identity and manage their orders on their behalf so the user says yep that's good and hit submit and the user authorizes access so the authorization server redirects the user back to the web app with a one time code and the query parameters of the redirect the web app receives this one time code and so I'm showing this dotted line here the user is sort of waiting on a response but the web app is doing some stuff in the background the web app receives the one time coach and the query parameters and then goes to hit the authorization server with this one time code in the back and and the officer v validates the code because it just generated it so now the off server returns responds back to the web server it responds with an access token which could look like a random string and an ID token which is assigned JWT and so I'll go over what a JWT look like looks like in the demo so now the web app can verify the ID token consume its contents and start an authenticated session and it saves the access token in session so now the user is authenticated with the auth server users authenticated with the web app webapp now gives control back to the user and responds with an order form and now I'm going to go over now that the users all signed in how this affects the resource server room back here authorization code flow is finished but user still needs to actually do something on this application so the user fills out and submits an order form and the webapp submits the order to the REST API using the access token that was stored in session remember when the authorization server responded the web app starts an authenticated session and saves the access token in that session and that add that access token is present in the request to the REST API in an authorization header so the REST API needs to validate this token it sends the token back to the authorization service token verification endpoint all services yep token is okay and these are the permissions that token grants so the REST API can see that okay this request is authorized to to manage orders but now the REST API before saving the order wants to get more information about the user let's say it needs to get the user's address or phone number and this information is not in the request from the web app so it can make another request to the authorization server using the same token it's making a request to the user info endpoint the user info endpoint is a standard endpoint in open ID Connect and the response is is user information essentially suddenly the off server responds with that information and now the REST API can save the order it's filled it all filled in all the fields and finally control is now given back to the user so that's how a resource server consumes the token now how about single sign-on let's say there's another web app and the user wants use web app to to track their order the users not authenticated with it so this is kind of the same thing the web app redirects the user back to the office servers authorized endpoint but the user is already authenticated with this guy sessions still alive so the user so the authorization server responds to the authorized request with another page that asks if the user permits the web app to access their identity and manage orders on their behalf and the flow continues so that's a lot of hopscotch and that's why we have spring cloud security so with spring cloud security you get single sign-on with OAuth 2 and Open ID Connect servers and you can achieve this with a single annotation and some configuration you can also secure resource servers with tokens also with a single annotation and some config and it also gives you the ability to relay your tokens between single sign-on enabled web apps and resource servers and it gives you this with an auto configure to off to rest template so this whole situation here it lets you do this all very easily there is a caveat though that I mean open ID connect it just became a standard recently and because of that spring cloud security or spring security OAuth 2 actually doesn't consume the Open ID Connect tokens directly what it does support those that it does support the user info endpoint so if your application needs to get identity information get more identity information it can do that through the user info endpoint but it's not going to use the ID token yet however if an access token is JWT containing identity claims then it can consume all that all in one shot but didn't I say access tickets where we'll pick well this is what the ohe spec says access tokens are credentials used to access protected resources and access token is a string representing an authorization issued to the client the string is usually opaque to the client so they're suggesting that the string can just be some random gibberish now the client doesn't understand but it's not saying that the string must in big all caps letters be opaque to the client so really we're free to make that string whatever we want so if access tokens carried information then with scopes in the token you can authorize the request yourselves yourself and with identity claims in the token you can know who the originator of that request is and if that token is signs then you can validate the tokens authentic assent isset e yourself you don't have to pass that off token back to the off server to validate it and get a response you can do it all yourself so your auth server won't become a bottleneck questions cool so how do we get all this enter you AAA what is you AAA you a is the user account and authorization server and it's a core component of Cloud Foundry its Babel tested in production it's the same server if you use run dot pivotal IO or people web services it's it's running there as well it runs with every cloud factory deployment in fact it's Apache 2 license so you can download the war and run it for free you can see all the source code on github.com slash Cloud Foundry slash you AAA it's very actively developed as well it's a lot too compliant and it's almost open ID Connect compliance full compliance I'm sure will be happening very soon I know that they're working on on a couple issues right now but it does support the user info endpoint it's also multi-tenant and spring security off to is actually based on UA UA came first and then allow that code was pulled out and then spring security OAuth 2 was created from that and spring cloud security which is basically spring boot plus spring security OAuth 2 is a great fit with UI a because you a produces a jot containing both scopes at identity in the access token so all of this talk about jaw what is it John stands for JSON web token it was standardized well it became proposed standard May 2015 a jot consists of a header a payload and a signature the header described how that signature hello okay header describes how that signature was generated what algorithm was used and provides a standard way of verifying that signature jots when base64 encoded are very easy to transmit in headers they can encapsulate any claim so you can have scopes identity stuff but all sorts of other information anything that you really you can throw into JSON you can encapsulate in the Jade in the jot payload they have expiry and with all this you can have scalable stateless authentication and authorization clients can verify tokens themselves but there is a trade-off because you lose out on token replication so if you're not making a call back to an authorization server then really you just have to rely on the tokens expiry to know if that user still or that client is still a lot to do whatever they're doing and this should solve the common concerns that I mentioned previously where there's a bottleneck in the central user store don't need it don't have that anymore you can achieve single sign-on resource servers can be stateless you're not passing user credentials around all over the place your tokens can contain fine-grained authorization and it's really easy for non browser clients to enter up with with this okay so let's see it all work if you want you can follow along in these steps on github I'm going to try to display some of the code on this screen but if it's hard to read then you may want to just go on to github and and look at the the repo here and everything's a master okay so the first demo here that I'll show you is single sign-on and so I've set up an app that can see can consume gules open ID connects endpoints and it can also consume UA a with the only difference being configuration so I've deployed an application to PWS and surely what hello okay this this link here is pretty will forward me to a sign-in page and so right now let's open ID Connect provider I'm going to sign in cool now I've already authorized this application to access the credentials or access my genic what you are seeing here is theirs with the access token that Google this token here it's pretty an ID connect provider and I guess didn't track that okay so but can you my audio is cutting in and out isn't it ah man in the back can you hear me alright I'll try to be loud yep okay cool let's yeah let's go back here do this thanks Matt cool okay so yeah access token base64 it's pretty small here's some info and now to switch off the Google support and single sign-on with you eh eh so I know I'm talking about open source you eh eh this or pivotal Cloud Foundry it's pivotal single sign-on so I'm going to bind it to the pivot single sign-on service start the app oh cool sound guy good is this microphone issue gonna get worked up great thank you all right looks like we're live so I'm going to go back to this app again now I see a different login page this login page is hosted on PWS but it's a login page for my my specific tenant of pivotal single sign-on and it'll sign in here maybe it's oh right I forgot to do one thing yeah I'm actually not set up on the internal identity provider which is just database so I'm going to hook this guy up to a sam'l identity provider and you'd like to preview which is a saml environment we offer testing what was my password great and where's my phone so now the cool thing that I'm showing you here is that if you hook up an open ID Connect provider to like a sam'l IDP then that sam'l IDP can enforce the multi-factor authentication that's the thing okay so now we see an authorization page do I allowed this application to access data so this is the user info I got from the user info endpoint using this token but it's jokin and I won't call it okay so you can see here highlighted or jot token and what the header looks like the body and the signature looks like the delimited by its rhythm that was used to generate the signature r56 and this is the payload you've got token ID subject ID so this is unique identifier the client ID that I used to get the token that my username email so there's identity information there as well this is the time that the token was issued and the children will expire and she have audience claims in here as well this odd field here says that this token is intended to be used for the open ID connect endpoint and intended to be used for this application which is the client ID which is this application here so that's a jot token and you're probably wondering okay this is cool how do I set it set it up how do I use Springs out cloud security to do this also on to my next demo okay so my next topic here is called Freddy's barbecue joint the actors are Freddy who's the owner of Freddy's barbecue joint which makes the best ribs in DC we have Frank who is Freddy's most important customer because he's the most powerful man in the world and we have the developer who works for Frank and wants to press him with this side project and the use case here is to give Frank the ability to see the menu online and place orders and to give Freddy the ability to manage the menu and close orders so we are going to build this we have worked late we're going to build two UI applications and two REST API resource servers and these are all the pathways that are going to be followed okay so first let's start with setting up UA a if you want to preview of all this stuff on github and read along I'm going to show you the code let me know what looks better it's more readable on the screen yes so what do you guys with it is or looking at looking at it in this yes these are going to get up yes forget help for us yes I'm saying okay oh I'll stick with STS because it's actually kind of like when I start changing code like I'm going to walk through every single commitments about 30 minutes that I find a groom's very well to show you how to create the pretty funky joint system I kind of like the side-by-side comparison let's go okay so first we've got got a you a configuration file we're going to be running all of this locally so to configure your own local you a a I've got it here in the comments for this commit you can download you a a from even set just search for it or Cloud Foundry identity Cloud Foundry ID any you a once you have it set the environment variable you a config path to the folder that contains this you a amo so it's in the project folder you a and then you can run this war in your favorite container but in this demo run it as localhost 8080 slash you a a once you have that setup commit which I really go over it contains the SSO application that I just MOU let's go to the first commit doing some this commit now establishes the customer UI just okay so we're going to create the customer UI with no security let's look at the application yep it's pretty small we have that spring beauty application this is also a controller so I'm making this class both a controller and in the application because I'm lazy and I always want to show everything and went file um I cannot how do you sue an STS I don't think I could ever do that okay see if that will work sorry oh yeah there we go cool yes so we've got to request mappings we've got a home page I'm using spring MVC with time leaf and it's just going to return the index template just kind of stuff it the valley here throw in the string will or click with the actual authentication later and I'm also stubbing out the response from the menu resource server right here I am going to rich mate I won't really go over the HTML let's look at the domain object here which is out and what are the dependencies here just spring boots starter time leaf and the common project that holds in the common domain model all right let's run it that's a pretty running it is okay I can it's saying hi will but that's a hard-coded value see the menu and this is just some stub debt values so this establishes the basic functions of the customer app right now and we can move on to the next commit yeah basically a four gig JVM though I've heard about visible okay no problem thanks guys it's all good okay so now we're going to add single sign-on to the application inter main application class I've got this annotation unable off to SSO I've also added this dump token endpoint config this is another class that I wrote in the common package so that's just for debugging the token but we don't really need to focus on this this is where all the magic happens when you add it then bring in the request mapping problem okay let's keep going you can pop well object a standard it's part of the Java standard it just means the authentication and instead of hard-coding will I'm going to use the principal cat name to show you that it's really getting a jetty D sign what did we change in our config properties spring to Ottawa to and we need to tell the application where to go to get a token where to redirect the user to y'all John you a a s20 the token this bit of Schottky URI so the two ways you can consume Jah tokens one is to provide a key URI and this URI here is I'm just going to throw this in the browser to show you this spits out an RSA public key and this public key is used for token verification so on application startup it's going to hit send point get that public key and then use that public key for for very after so we set we have to do some setup in ua as well so here i think i went over this this initial stuff but the initial setup with you a a we had to specify the public key which is the same show you on that so kinky end points but signing keep matching our thick private key that's used to Jenna and this is the cub isn't like a secret up pipes strength I am participate token encode grant lock it down and it's actually part of the spec is that different grant types have different levels of security some are more kids more secure than others and over here I'm saying that the clients can only authorize this scope so the client can only authorize access users identity and the authorities field here this says what the client own and in UA a this scope UA a dot resource means that it can access the public key if or no sorry it can access that token key endpoint if that token key endpoint has been secured it can also access the check token endpoint and do things that you a allows resource service to do and finally a redirect URI this is important because this redirect URI locks down how this client can redirect the user back to the application because remember in that opeth authorization code handshake that a one use code gets redirected gets sent back to the browser and that is contained in a redirect so if the browser let's say if you had an open redirect you weren't specifying your redirect URI and in the authorization request you can say Oh redirect me to this bad site if you don't specify a redirect URI that's okay the bad site will end up getting that authorization code and then getting the token instead of the site that the token was meant for so it's really important to specify a redirect URI and what dependencies did we add to make this happen spring cloud starter oauth2 that's that's it just that one thing okay and so let's run it going to restart you AAA because I think I changed some config there now I'm making changes to you AAA using this config file but you can also use the UA a CLI it's called you AAC it is a ruby CLI so if you like ruby then you can just gem install cfd you a AC or there's other ways to install it as well and okay let's rerun the customer portal cool so I try to hit the home page I'm redirected to login screen okay and now I can be the menu I can see my access token good all right on to the next and I'll lose all of my nice commit messages all right so I'm going to go over testing because testing is super important when you're trying to configure security on your application you might think that you're doing things right and you might be thinking that you're following the documentation exactly as it says but you could miss something you could be opening up a big gaping hole in your security so you really have to test your application thoroughly to make sure that you've you've done things properly so I'm going to show you how to do that now if you're using straight spring security there are some great testing tools that have been released somewhat recently that allow you to like mock out and authentication and still do like full integration testing but lock certain things out with spring security oauth2 it's I couldn't find the same so I've added a base test class here security integration test and if you're familiar with testing spring boot applications this is using that at web integration test this means that the entire application is starting up it's starting up in a container that's accessible I'm telling it to start up using some random port and I've added a bunch of methods here which I guess I'll go over briefly which allow you to make things that look like HTTP and HTTPS requests and check the responses on this I could have used could have used rest template to make requests on the server but with rest template I found it difficult to tell it not to follow redirects so what I'm using here to make to do these integration tests is apache httpclient and i'm just disabling cookie management redirects handling so I can use this now to test out a resource server and my customer app okay so over here I'm saying that for this test security dot require SSL equals true when I'm running in production I always want to be running under SSL but if I'm running under SSL I want to make sure that that the redirects are properly follow that the request is being checked if that request is over a secure channel is not over a secure channel I should expect to see a redirect back to the HTTPS URL and these tests fail let's just dig into this this base method a little bit more check requires a GPS no author passing a URI this is calling check HTTP redirect so I'm going to make an HTTP request and on this URI and then look at the response I am going to expect to get a 302 back to HTTPS but that's not happening okay so I expected to be redirected to HBS locals menu but I'm redirected to they should be login that's not right how come let's go the next okay so in this commit I'm going to fix the SSL redirection problem this is what was missing so when you are using enable off to SSO and you want to force SSL which is always a good idea you do need an oauth2 SSO configure adapter this is in the spring cloud security Doc's as a way to specify which requests should be secured with enable oauth2 SSO and if you want to authorize that request if the user supposed to contain any roles that sort of thing you do that all with this configure adapter and so out of the box like the last time I ran the application sure it was asking for authentication but I do need to modify that behavior slightly here and say that over here if require SSL is true in my security properties then I set this up on the HP security configure it's everyone familiar with spring security raise hands awesome also this is a pattern that's pretty pretty common to spring security setup okay so now with that I will rerun tests Green all right let's move on now we get to create a resource server using Springs a data rest and spring data JPA it's going back to our diagram yet we did the single sign-on now we're adding the REST API um so this is plain vanilla and no security okay I've got a manual repository I want to show the IDS on this rest repository and I'm bootstrapping the application with with just an object there and what I added to the menu item class is just some GPA annotations because I'm persisting this and just go over this briefly some more spring data goodness to get this all working you need spring boots started at arrests spring boots started a two JPA and an in-memory database and fig oh that's it just run on 80 83 I'll be running the tests let's run the right thing here okay menu application you oh it's asking for basic off now you're getting get basic auth out of the box if you have spring security running in your application and to turn that off I think I'm doing that in another commit oh yeah here we go security about basic naval D equals false and we want to switch basic security off and off and use OAuth 2 resource server security okay so what changed so to configure resource service security the resource server it this particular one doesn't need to be represented by a client in UAA I mean door the same is true if you're not using UAE for a resource server all the resource server needs to do is check the token and verify the signature so you're letting it do that by specifying the Jockey URI and changes to the application we've added this one annotation here enable oauth2 resource and we need to add a resource server configure adaptor again same sort of deal here we want to say that if require SSL is true then we want to configure that in each to be security configuration and now I'm going to in each subsequent commit write tests for every change in behavior so I'm going to extend security integration test do the same thing here require us a cell to mimic what I want to do in production we're going to check that HTTP GET HTTP redirect when you hit menu items and then when you hit menu items over HTTP with let's say no token you get a 401 and when you do have a token you get a 200 so what's this you a jot token builder it's another class that I wrote to support all of this testing that maybe soon we'll make it into a library that you can easily get ahold of but it's all in github if you want to use it today okay let's run the tests it now you might have seen that the test was not not really adding anything to the token I'm creating a token and it's essentially empty token says nothing doesn't say who the user is doesn't say what the audience of the token is you don't get any of that so this is something that obviously we should check for so to do that I've added this to resource server configure adapter resources resource ID menu this is something that you you get out of the box if you're setting up an application with at enable law to resource and you say and you add this to your configuration where is it yeah you can go spring dotto to resource ID and with no other configuration here you know let's say you don't have let's say you don't have the resource server configure adapter you just added that property then your resource then the audience claim would be checked but I have to do this manually here and through what might be a bug or maybe I'm not setting things up right if you want to specify a resource server configure adapter you have to do it in a bean that has this signature public resource server configure a resource server not too sure why that is happening but that's what I found out through testing that's why testing is so important I thought I was doing the right thing and my test failed and I had to figure out how to make them pass so this test here it expects a 403 if I just build a token that's empty but then if I set the audience claim on the token as menu then it's going to get a 200 feel free to interrupt me at all as well Oh fail oh okay why expression URL authorization figure already built on this table oh I think maybe I'm fixing this another commit this is not something that I expected so maybe I have to do a little more grooving all right let's continue okay and sure menu dot read scope is required to access endpoints so adding some more testing here and some more authorization so now here we're checking for scope and this is where I was running into that that problem with this method signature here being so important I was not able to get this authorized requests work so when you at enable off to resource server or I'm able off to resource you get a security expression you get security expression methods that allow you to check your token for scopes and so the expression here is a lot to have scope menu read so that is saying that any request must have the scope in order to proceed and to test for that so it's not enough just to set the audience claim I have to set menu dot read or menu dot read has to be present in the token scopes and I wonder if my tests will pass now yes okay now I'm using a spring date arrest in spring data JPA which will just expose JPA repository restfully so it lets you get stuff from it and it also allows you to put and post and delete stuff on it and I want to make sure that those methods are secured with a different scope so this is what I'm doing here so see the difference here instead of using any request I'm using ant matters which lets you specify what request method you want to apply an access decision to and so forget we've got menu dot read but for post put and delete we want menu dot right and here you can see our test getting a whole lot longer and we'll go over all that but basically as you add as you keep adding security configuration you need to test thoroughly to make sure that that configuration is doing what you expect it to do alright let's actually see this work I'm going to set up Frank to have menu dot read access and that scope will be requested in the OAuth authorized request UA okay so a couple things to set up on you a a now I don't expect you guys to be using you a you can use your own Olaf to or open ID connect authorization server there's my tour project that also has an open ID connect server but I'm just using ua a here because I'm very familiar with it so we added yes ah yes yep sure so you AAA supports Postgres in my sequel oh oh sure so the question was how do I configure my data sources in UAA and how do I configure identity providers in ua let's say if I want to hook it up to LDAP or sam'l so yes all of that is possible you can hook it up to an external identity provider over LDAP in sam'l multi-tenancy support is only only allows for sam'l at the moment but we will have multi-tenant LDAP soon for the data sources it supports Postgres in my sequel all of this is configurable in you a mo the your yeah Mahalo can get quite large and it is quite large in a Cloud Foundry installation but this is all in documentation as well if you go to github slash Cloud Foundry Sashi UAA all the documentation is there for that you can also hit up the mailing list it's on the captive yes so utilities for registering the application I mean there's a very extensive REST API that you can use to create off clients and make modifications create users create user groups which are like roles I could have and there's also a CLI so you a see that CLI that I mentioned earlier you can use the CLI to do all these things - I'm not using the CLI in this demo because it would just take me too long and I'll probably make mistakes writing it out so I'm just sort of changing the bootstrap configuration restarting the server so that's all in the open source and if you're using pivotal Cloud Foundry then you get a fancy UI well if you're using a multi-tenancy at least show you quickly yeah you've got this UI here that like I could set the the user store that was that this client is configured to use and redirect your eyes and scopes and all that stuff okay does that answer your question great any other questions yeah yeah so the question was is there any way to dynamically change the Scopes that are allowed in a token at runtime of course there is yeah you would do that by let's say let's say this customer portal you wanted to remove the ability for users that are logging into the customer portal to read menus you can do this at runtime just in you a just by calling the oauth clients end point with an ID of customer portal you do a put and you change the Scopes that the client is registered to give out if you do this while the server is running and let's say there are tokens that are out there being used those tokens will still contain that scope but when that token expires then you have to get a new token and that token will no longer contain that scope thanks for the questions it lets me have a little break showing you all this code but and I can't get through I don't think I'll have enough time to get through the entire demo but please if you want to try this out locally just check out the repo and step through every commit and and run it on your own machine it should all work okay so where were we we are yeah so we need to into in order to enable menu dot read scope in the customer app we have to ask for that scope in the authorized request and so that's being done here in application yeah Mille I've added the scope menu dot read to the client configuration and I've registered register that scope in UA a for customer portal and I've added a new user called Frank who will be part of the menu dot read group so I think about user groups in UA a and clients is that you have to go through a client to get a token and the Scopes that your token can contain is the intersection of this value here these scopes and the scopes are and the groups that the user is a part of so Frank could have menu dot right as well but when Frank goes through the customer portal his token is only going to have open ID and magnet Reed okay now with this setup let's run through it oops tore the wrong server and I'm going to restart the customer portal and the menu service okay I'm going to well Guinness Frank oh cool oh no no no this is this is all running in PWS this is not the one I want to use use the local one here that's the finished product okay um I have to authorize this new scope when you don't read so now I can them you the menu and this menu still that hard-coded stuff so I will quickly go through how to access a resource server from the SSO application okay so in this commit I'm going to set up the hideo's consumption and consume it using oauth2 rest template the all to rest template is going to make requests to the resource server it's going to automatically add the users token to that request and that token was stored in session so remember that whole authorization codes dance that that I showed in my slides all of that is already being done for you and it's super easy to set up so I just had to add spring boots started hideous to customer app and here's what changed I needed to do some configuration so that the all to rest template can can consume hideous stuff here not sure if I still have to do that with the latest version okay so now I'm actually making the request for menu items and compare this before this is hard-coded now I'm using all to rest template and all to rest template it's just a rest template but in the background it adds the choke into the request and let's run it oops a round okay nope wrong one there we go the menu great now we can see this is real stuff from that menu resource server just using that bootstrapped information so we finally were able to make a connection yep created Frank and now it's accessing the REST API sorry we're a bit out of time I didn't actually expect to get through everything but in case I was going real quick this is all the stuff every step of the way that happens in order to create value Freddy's barbecue joint again you can follow along a github please send me comments ask me about all the commits that I made and why I did them and we can continue this connection here I see questions but we are done I have to give a shout out to the cloud foundry identity team these guys are awesome to work with majora chrisphillip Robin Shree and thank you all for coming to my talk yeah thanks okay question time we've got a few minutes I'm sorry which side oh yeah yeah for sure yeah write it down cool also feel free to oh yeah yeah sure is that yes yes so as you go through these commits you're going to get to a point where we have all these services and I'm just using all these localhost URLs hard-coded it's a big pain in the butt if you then add Eureka then you're off to rest template we'll know we'll use the ribbon clients and do all that stuff - yes it's great yeah sure so scopes on the resource server let's go to the finished product here okay so this is the menu resource server and we can look at the order application we can't get around to that but and this is a little more simple you just say any one you have to have order order dot admin to access this order's endpoint but you can also use method security so I've added a pre-authorized annotation so you can use method security annotations and putting your expressions that way yep yes the question was if somebody gets a hold of my JWT token that I'm pretty much exposed yes that is true because it is a bearer token which means if you have that token you are what that token says yep so in this particular example how do you protect your token in this example here the token actually never leaves the customer you I the token the stored in session and and then just a session is established between the customer UI and Frank's browser and so you just have a regular session cookie over HTTP and you're good to go if you have to send that token out you can still send it out to the browser but you really need to make sure that it's over HTTPS what you can do is also you can encrypt the token so if that's how it can contain sensitive information that maybe maybe you won't even want Frank to be able to use that jaat decoder and see what his token contains you can use you can encrypt it there's a standard called gwe that was just finalized there's no support for that yet in spring but actually if you go through my commits I show you how to use Zul to encrypt tokens and so you've got this nice little gateway to do that cool umm yeah thanks for coming if you have any more questions just come up to me I'll sir yep yeah so what Zul can do automatically is do the token relay stuff there's documentation and spring cloud security for that but I don't really go into that in my example my example of Howell is used is really just for that token encrypt decrypt you

Channel: SpringDeveloper

Views: 97,270

Keywords: Web Development (Interest), spring, pivotal, Web Application (Industry) Web Application Framework (Software Genre), Java (Programming Language), Spring Framework, Software Developer (Project Role), Java (Software), Weblogic, IBM WebSphere Application Server (Software), IBM WebSphere (Software), WildFly (Software), JBoss (Venture Funded Company), Microservices, Computer Security (Software Genre), Cloud Computing (Industry), Spring boot, OAuth (Internet Protocol)

Id: USMl2GNg2r0

Length: 89min 52sec (5392 seconds)

Published: Mon Oct 19 2015