Securing apps and services with Keycloak authentication | DevNation Tech Talk

hello and welcome to another definition live we're gonna be having a good time today we're gonna be talking about security everybody loves security right I know you guys are all super-excited talking about security because it is a critical aspect of all applications and api's at this point in our lives every application we create we need to be thinking in terms of how to make it more secure and some and that's a great topic for us to drill down on and we have our expert at Red Hat stay on who's with the key cloak team is going to rock and roll with us today so Stan are you ready you're ready take it away I'll get my slides onto the screen okay so today I'm gonna be talking not too much about the key cog server itself and all the capabilities and features it has on the other hand I'm gonna talk about a little bit about how you can secure your applications and services we keep so basically what is Kiko for those of you doesn't don't know it's an open source project it's an intensity and access management solution and it's specifically designed for modern applications and api's and services it's a ready to use out of this box service that you spin up separately to your applications to then allow you to secure them easily with little to no code at all needed so why should you be considering key croak well you want to be delegating your security firstly it does provide better security to have a single process and power of your system that deals with users and authenticating users rather than embedding this into all your different applications and also it means that you don't have to deal with storing users and storing passwords you don't have to create login forms and all these things so when you have many many different applications you don't have to repeat yourself many times and you know also provides a huge bunch of cool features capabilities that you may want to provide to your users of your applications such as single sign-on and two-factor authentication and your are as a note you wouldn't really be implementing a database would you so you find a good quality database and you use that to store your data okay so first of all let's look a little bit on the boring stuff so protocols when it comes to delegating authentication and security there's really two main stream protocols out there today one of them is open ID connect it's layered on top of our two and provides on top of the authorization capabilities from earth it also provides authentication capabilities so overnight Connect is JSON based it's a very simple protocol it's easy to understand the flows it's easier than the requests and everything is sent you can easily debug what's going on and it's also even so simple that you could relatively easily implement the client side of it yourself it also has a concept of a bearer token or often filters an access token this is a token that a application can send on to services so that you can then have proper end-to-end authentications of the users throughout all your different bits and pieces of your system sam'l on the other hand is XML based it has a good few more years on it and then openly connect but it's also much more complicated so the XML documents are harder to pass a harder to interpret the flows are also slightly more complicated it also doesn't lend itself as well to modern applications so how do you choose which one to use well if you don't know you should use Open ID Connect it's just simpler to deal with and it it fits their modern needs better if you have single page application or your mobile applications or if your rest services and api's then you want to be using open and ignite sam'l on the other hand works well for monolithic applications it also works really well if your applications are your third-party applications already have some support built-in and there may also be some corner cases where you have some fancy requirements that open early connect just doesn't cover yet okay so how do you actually go about securing your applications well there's a few choices out there depending on what type of framework and language that you're using we have key book adapters that we provide for some languages provide a really good integration and a very good experience with securing with Kiko and then we have what we currently are calling the generic adapter which is coming soon this is a adapter that runs outside of your application in a separate process to then secure your applications and services without you having to modify them in any way and finally since we're providing openly connecting sam'l you can use any standard libraries to do this and as I said before so third-party applications may already have built-in support for these and a lot of frameworks also coming now with built-in support for this okay so Kiko doctors they really do provide in at least in my opinion the simplest and best integration with Kiko we try really strongly into their underlying frameworks and we try to make it as simple as possible to get started with these adapters they can be referred to as kind of a library as well if you want to but what we do try to provide a better experience than what you would typically get from just a library so we have support for JavaScript client-side JavaScript and JavaScript library also has support for Cordova and reason that we also introduced support for single sign-on on mobile applications as well we have support for many Java EE containers with super qualified jetty and Tomcat and for other containers you can use our solace filter it doesn't provide quite the same experience but it will work for for any standard Java EE container we have support for node.js and we also have support for spring boots and spring security now okay so what do you do if we don't provide any adaptors for you well then there we have the generic adapter so the way that that works is that it sits as a separate process on the same host ask your application and your service so we can see here from this diagram that on one host we have the application and it has alongside of it it has two generic adapter process and then we also have on a different host we have the service which again has this separate process for the generic adapter so all incoming requests from the user is sent to the generic adapter which will then deal with all the authentication of the user by basically redirecting it onto Kiko and the generic adapter once the user is authenticated will then forward on the request to an application this can be seen in a way as a proxy we didn't call it the proxy because it is basically just doing this and not other proxy light features and then similarly for the service what it does there is that it checks the authorization headers as included in the requests and make sure that the request should be permitted before it bruises on to the service and one additional cool thing that this thing can do is that it can also intercept the outgoing request from the application to then automatically add this bearer token from open ID connect onto the request so that the application can now securely invoke services without having to modify in any way how it makes the request to the service throughout the session for now I'm primarily focusing on open any connection or what I won't be talking too much about sam'l but a lot of these concepts are directly translatable to assemble this example here shows what happens with a monolithic application where you want to authenticate the user so the user will open the application and the application will then see that there's a need to authenticate to use the application won't show username and a password field or form sorry it will on the other hand it will redirect on to keko keko will display the login forms and will then identikit the user once that's done it will send what called an authorization code to the application this can be seen as a token that the application can then use together with its own application credentials to obtain what's called an ID token an ID token is basically a JSON document that contains what's called claims which is basically just properties or fields in a JSON document about the user so user name first name last name date of birth whatever you want that talking is also signed so that the application can trust that that token is actually issued by Kiko okay so taking this one step further into a single page application so the whole redirect and everything now sits on the current side inside the browser and similarly again we get this authorization code when the client wants to log in but now what we get in addition to this ID token we get what's called an access token so the access token is something that the kind side application can use to then securely invoke services obviously this can be you can use the same concept for monolithic service monolithic application if it wants to also invoke external services so what happens on the service side is that the service so alongside the request we're sending this access token and the service can then pull this access token out and they can use that to verify whether or not the request should be permitted there's basically two different options on how the service can verify this token you can verify it online in which case it will call the key talk server and the key cog server will then check the token and get back to the service and say yes or no or you can verify it offline in which case the service will then at some point retrieve the public key from kiko and in most cases it will cache this so it won't have to reconnect to keep hook every time there's a request and it can use this to verify that the token is valid by basically checking the signature against using the public key there is a bit of a in which approach to choose so the offline has a usually has a bit of a window after the users been disabled or logged out or anything like this until the token expires you know so it doesn't take immediate effect always this is kind of leave eiated a bit by open early connect by the fact that you have a concept of an access token and a refresh token where the access token has a very short expiration time and the application can use the Refresh token to contact people to obtain a new access token whenever it expires so usually we're only talking about the few minutes from the user logs out to all these tokens are then invalid then with the online approach obviously you get a logout from a user or a disabled user takes immediate effect but on the other hand you do have the penalty of an extra request for every request coming in to your service so that can introduce a bit of a higher latency in your request and it will also introduce a higher load on the key server so you may need to beef that up a little bit more so looking at how this works for micro services same as the application invoking one service that service can then invoke another service and so on and so on by basically just sending the same access talking along every time this provides you with a full end-to-end authentication throughout all of your services and all your applications all your bits and pieces that's involved in handling this particular request okay so that takes us to the part where I want to have to show some code and also to show a demo today I prepared a demo it contains basically four components it has the server obviously and it has a five application has a rest service that's implemented in no Jess and I has a PHP service the two services are follow the same API and they're obviously both security cook so they're interchangeable to show that it's very easy to switch between different languages and there's full interoperability of how end-to-end user authentication happens when you use something like so let's start by looking at the age about five application just to see how easy it is to create a to secure something like this wiki so basically this application it it's a PHP application now it's just so that I can inject some configuration into the application I need to tell it what where the service it's and I need to tell it where he talks it and then basically I have three components or three parts of the application I have one part that's shown when the user is not authentic ated and this basically shows a login button I know in this login button all I need to do is to call keylock login when a user clicks that button and that will then deal with all the redirect dances from open and connect and will then attend to get the user similarly when the user is authenticated I have a logout button and then again just calls the javascript adapter and says hey we want to logout and then we have quite a nice feature in key book we have an account management console that lets you users manage all the user details and reset passwords and various different things so that you don't have to implement this in your applications yourself and finally it can invoke the service so it can invoke three different endpoints on the service there's a public endpoint that anyone can invoke there's a secure endpoint that needs a user with a user role and there's an admin endpoint then is a user with an roll to be able to invoke an obviously since this is a JavaScript html5 application there's a bit of JavaScript as well so to use key Koch we have to configure key talk we have to configure the JavaScript adapter all we need to do is to tell it what realm we want to use and we want to tell it the kind ID of the application that we have because the kind has to be registered Mikiko so the key talk is aware that this kind should be allowed to login users and then when the application is initialized we need to initialize the JavaScript adapter and basically that's all we need to do to get this wired up and running so we can see here that when the keycode javascript adapter is loaded it should check if the user is logged in this means that it will check with key o'clock and say hey is this user already logged into the single sign-on realm if it is we just want the user to be authenticated with the application as well and if the user is not logged in we don't want it to show using them and password or login form I'm basically then the application then just displays the different blocks that I showed before depending of the user is authenticated or not and the last piece is that the youth the application also needs to be able to call the services so most of this code is just the actual Ajax request going on and these three lines is all that's needed for the application to add this para token or this access token onto the request so that the service can verify that that should be permitted let's have a quick look at application oh it basically looks like this and I can invoke the public endpoint on the service but I'm not allowed to invoke the secured endpoint or the admin endpoint at this point because I'm not logged in and we can also see that the URL for the application is demo app when I click on login we can now see that we are on Kiko we're not on the demo app anymore so we know now that this this login form is displayed by key o'clock and not the application itself so I log in and provide my username and credential and obviously here this is sent to the key book service so the application will never see the credentials of the user and now I'm logged in untrue the ID token the application can know some details about the user so it knows that the user name is Quito it also knows the first name their last name and date of birth if you set these things for the user inside Quito and now not only can I invoke the public endpoint I can also invoke the secure endpoint because the service is able to see the access token and it pulls out details from the talk and it says hey this is a user has that user role but I can still do the admin endpoint to be able to do this all I need to do is go back to key coke and find that user and I'll grant it the admin role so if I now refresh the page I can now invoke the admin endpoint because now I have an access token that now tells me that this user has both the user role and the admin role so let's take a little look at that no Jess application the first thing it needs to do is to include the key log nodejs adapter and then it needs to initialize this adapter basically needs to tell the adapter where to store bits and pieces and for this particular example all its doors is the public keys from Quito so it caches D so it doesn't have to him fetch these for every request and then we can see that the public endpoint is just a standard end point while the secured endpoint is now wrapped with this method called Kiko protect that just basically says that we need that user role to be able to invoke it and the same again for the admin that's protected with the admin role and the last piece to the puzzle is that we need to configure the adapter in the same way as we did for the JavaScript adapter we need to tell it what route to use and we need to tell it the URL of Kiko and that is pretty much it we can have a look at that so so on the public endpoint it just displays this very simple message and it's the same message that we saw in the application before and if I now try the secured endpoint I will get an access denied obviously because the browser doesn't have this access token it doesn't send this along with the request okay so the last thing I want to show is the PHP service the reason why I have two different services is the fact that I wanted to show how we can should secure different languages and also these are secured in different ways so the node.js service is secured with the nodejs adapter the one that integrates really well with no Jess while the PHP so is is secured with this generic adapter because we don't have one for PHP but this is a very good alternative we can see that I have a very simple PHP application it's been about 15 years since the last I I touch PHP so this was the first time in 15 years that I wrote PHP but anywho we can see here that we have a couple of PHP files that then mimics this rest service so we have the admin endpoint that uses echo message admin we have the public one and we have the secure but there's no security here right so anyone can invoke these that's where the generic adapter comes in and I've chosen today to run this demo on openshift for a few reasons so number one open shift lets me run all these bits and pieces on my machine at the same time very easily it also lets me wire everything together and finally what's really cool about open sharing communities is that you have the concept of pods that can have multiple containers on them or sometimes also referred to as a sidecar proxy what happens here is that you have both the generic adapter and that PHP application deployed to the same host and they can talk together and then you can control how incoming requests to that host happens so you can imagine that I had this already up and running on open shift I had that PHP application and it was already working on OpenShift but it was completely in secured unsecure all I would have to do is that I would have to say to the service that's exposed by by this deployment and OpenShift I would have to change the ports so the PHP application listens from 8080 so I would change that to a different port and then I can see here I have the container this container would have been there before this is my PHP application so we can see he listens on port 8080 I would have just left that just the cities I would not have modified that application anyway and then I would have added this additional container to the pod which is our generic adaptor and I'll give it a few configurations so I say that the public endpoint should be white listed that means that anyone can invoke it and the secure endpoint should be protected with this user role and finally the admin and point should be protected by the admin role and obviously I need to give it the client ID and I also need to tell it where he copies and there's lots and lots of other configuration options here and we can see that this is what's listening on 1990 which is what is going to be commonly incoming requests we can look at this this is the PHP version and it follows the exactly the same API as the other one so it says message public and it gives us a 4-1 error when we don't have this parrot okay I can now show how I can reconfigure this application to now invoke the other service instead of so to invoke the PHP application instead of the node.js application so I just give the URL of the PHP application and change that in the environment configuration for the deployment and I saved that and now open ship will go ahead and we'll redeploy our application I will take a couple of seconds there we go and then I can go back to my application and I've outputted the URL say any application so that you can see that it's now calling that demo service PHP and even though the application was redeployed I'm still logged in and that's because I'm I was remaining logged in with Kiko with a single sign-on realm so I'm automatically lovely and again now after the application is redeployed I can now invoke the public under secured and the admin endpoints on that alternate version where the same means of securing it in the same and user authentication okay so if you want to learn more about key cook join me on September 20 we'll be talking a bit more about what capabilities and features that keep delivers I'm gonna try to touch on as many features and capabilities they can in the 30 minutes available to me it's not gonna be a deep dive but it's gonna be a good opportunity to learn about what Kiko can do I also go to our website you can found documentation and downloads there and obviously it's an open source project so all the source is publicly available on github there is no hidden features or any product only features everything's available in the upstream open source version I also have the demo that I showed today all the code is there available for you to try all you need to do is to have an open shift cluster or used mini shift to run it locally it should also be relatively easy to adapt it to run it on cuban et's or even to run it directly on docker or even if you really want to run it on a single box with different ports and if you want to get in touch with us reach out to us on a community mailing list there's the link there you can also find a link from the website we also have a developer mailing list if you want to be contributing to keep poking in touch to us there and finally you can reach out to me on Twitter or you can contact the key team that's it so thanks bird do we have any questions we we do have some questions a couple a bunch of good ones actually and under some actual chat where people have been answering questions and things of that nature so one on the caz so a cast server so centralized authentication service and then of course what we what looks like is not using the cache protocol but either using oh I DC or sam'l and the answer was if you're using sam'l that's no problem should work fine with you cloak that sound right to you yeah so we've chosen to not support additional protocols so that we can focus on open ID connecting cell because each protocol will basically thin out for what we can work on right it's a generic adapter available now no it should be available the next key quick release and that would be in three weeks failing that I will be available in six weeks in the following release okay all right and then why an interesting question here why you support nineteen eighty into that eighty eighty when you used in the demo it doesn't matter openshift takes the incoming requests and 480 so he just posed to anything and the imagination here was that the PHP application was already listening or 8080 and we didn't want to change that so that's why we introduced that on a different form yeah I could and it because one thing one question that came in I was probably a little bit unclear is how do we get the forgot password option on the login page is that part of the admin console yeah so those things will be part of the next session where I will be showing as many things as possible to enable that all you need to do is to configure your realm and you go in and you click I want to be able to recover passwords and and then now pops up on the login screen and obviously you know you don't have to modify your applications when you want to introduce things like that right right and I think that's an awesome you're awesome capability it's just going to say I want you know I want social sign-on I want forgot password I want registration now there's another question is there an adapter or a plug-in for an open chef router to add simple JWT foundation for it it's the back end I'm not sure I understood that question yeah it's in the Q&A tab from Lars and he was looking for an adapter plug in for notion router so fo ship router of course is based on a cheap proxy yeah so since I'm probably not an adapter for it since I'm not following quite with the question right okay I can't find it OTP feature and key cloak OTP feature and key cloak it's an old time request on form OTP so one-time password so that's a good point how we dig on one-time password and keep plug yeah we we have support for standard OTP or so basically both versions of the counter based one or the time based one and that is easy to implement and as long as you have a mobile phone with the necessary application to generate the code that's it's really no problem to enable it and configure it okay and that's the funny thing about what we're dealing with here right everybody has all their integrations with this technology that technology so like another question is how about Active Directory yes so now we're getting into all the stuff I wanted to talk about in the next session but hey so we have what we call user Federation capability so basically Kiko can then federate users from different user stores and these can be alda or Active Directory okay well we are out of time for today we do try to keep these sessions short we definitely have another deeper dive session coming up so look for another email coming for the next definition live early in September and we're gonna basically come back and hit you guys one more time but more of this technology because there's just a lot to talk about so we're gonna have to get some of your questions later I apologize for that but we had hundreds of you on the line today thank you so much for your interest in the topic and make sure to check us out and oh I'll add to the chat a couple links real quick you saw them in in the presentation deck but make sure to check out these links here are them real quick on to the chat so you guys can see them and then we got to finish up okay there we go I got those links and feel free to check out Twitter you can follow us there and follow the key click project thank you guys all so much Stan thank you so much yeah thank you for having me alright have a great day

Channel: Red Hat Developer

Views: 22,591

Rating: 4.9593906 out of 5

Keywords: devnation live, red hat, keycloak, open source, application development, sso, 2fa, tutorial

Id: mdZauKsMDiI

Length: 31min 41sec (1901 seconds)

Published: Thu Aug 16 2018