Keycloak with HTTPS & mutual TLS / X.509 authentication | Niko Köbler (@dasniko)

hey friends of keiklok nice to see you again nasniko's back and in this video i will talk about securing key cloak with https on the transport layer with tls certificates and doing mutual tls on authenticating users with x 509 client certificates so let's do it [Music] in an up-to-date environment you should encrypt every http um communication through tls and using https so encrypt everything no matter if it is local or private or public encrypt everything um a few years ago wenner vogels the cto of aws and emerson sat on one of the keynotes of the aws reinvent encrypt everything and encrypt no dance like no one is watching and encrypt like everything's watching we've not taken encryption serious enough this is a quote i like to use yeah first of all no one really wants to see me dancing so that is good anyway yeah but you should encrypt like everyone is encryption is the only tool you have to be absolutely sure that you are the only one who controls access to your data so encrypt everything and um that's what we should do also when using key cloak so first of all we need a few certificates for usage and i prepared them already i have a root certificate i have a certificate for localhost usage which is signed with the root certificate everything is self-signed and for the second part when it comes to user authentication i have a client certificate for fred flintstone our demo user for today but first of all let's focus on the root certificate and the localhost certificate for securing key cloak with https the communication layer channel and if you wonder how to create these certificates i put a link in the video description to a gist and where i explain how to create some certificates some self-signed certificates for uh development usage so um we have this um localhost certificate and the localhost key and if we go to our key cloak configuration as always i'm using docker for key cloak demos and the key clock docker image comes with a convenient script so you only have to put your certificate and key file to certain directories and name it properly and the script will pick it up automatically and create everything uh what is needed i will show you later on uh the script where you can find it and if you have to implement it to yourself so you can um use this as um as a blueprint perhaps so um i'm using key cloak version 14 it's working with with pre all key clock versions and the interesting part is the volumes part where i map the the local host certificate in the localhost key file into the the container to a directory named etc x509 https and naming the certificate file tls cert and the same with the key file put it also to etc x509 https and name it tls.key you have to use these both file names tls cert and tls key that the convenience script can pick these information up and use them when uh starting the server so when we now start the server with the docker compose up and then we can see that one of the first things the container will do is creating the https keystore that's here creating https keystore we are openshift service that's the convenience script i talked about and https keystore successfully created at and the script creates all proper um configuration entries in the standalone xml for the eletron subsystem which is handling all the security and the https handling in the wildfly server so then we can start up the server and switch to the browser where we can call key cloak localhost of course it's also running on port 8080 and that's the regular http part so here it is and we can access the the console of course in regular way admin admin or admin user and that's fine but we can also um access it through https just have to switch the url and the port to the 8443 default https port and then we can access key clock again of course we're accessing key clock through another host name and part so we have to authenticate again and you see it's secured connection secure and we can see it's verified by does nico and that's because we um i um imported the root certificate before to have the verification um that's in firefox view certificates and if i go to des nico i have a root certificate from n minus k dot de that's my domain and i can view it and that's my self-signed root certificate and the local host certificate is signed with this root certificate so the browser knows this certificate authority and can use the the tls certificate so everything is fine everything is secured by tls that's all you have to do that's not pretty much just provide a tls a tls certificate in tls key file for your container and then the magic script does everything for you so the magic script i'm talking about the convenience script is part of the key cloud containers uh repository and you can see that the github repository key cloud keycard containers and go to keyclass server tools h x509.sh this is the file where everything of this magic happens so you don't have to worry about what's going on here if you need to use it in your own environment which is not docker based you can use this script as a good uh starting point and to adjust it to your needs so peak load on tls on https works cool so let's move on to client authentication so for client authentication with tls certificates using mutual tls of course we need a client certificate and in this video i will use some user authentication as an example for client authentication and i created a fred flintstone certificate as already mentioned and signed it with the previously also used root certificate so we have a self-signed fred flintstone certificate also key file and everything we need and it's signed with our own root certificate and to use this client authentication um with certificates signed by our own root certificate we have to provide this root certificate to the docker container we can use them here for two entries in in our config the first thing i have to map also the root certificate search file um to our docker container for convenience i put it to the same directory as the tls and uh certification key file um you don't have to do a i don't have to use the same directory just for convenience i'm using the same directory but i'm using my own name there's no previously declared file name you have to use just map it somewhere into the container and then set the environment and variable variable called x 509 ca bundle and tell where your root certificate is located um you can specify multiple root certificates or certificate authorities with this environment variable you just have to append them using a space and then put some other file path in here so when setting the x500 ca bundle environment file the same script which previously set up the https tls usage will build up the internal trust store so that key cloak is able to trust the client certificate which which the the client or the browser will provide to a key cloak so that's all you have to do again if you're using the docker image the container you don't have to do that much and in case you don't use the docker container you can also use this script the x 509 script for uh starting point and it's the second part in the script where um the thrust source buildup so um good let's start the container in the background docker compose up and again the first thing the container will do is creating the https keystore in here that's what we also saw at the first example and after the keystore is set up successfully the truster will be set up and this takes some time and you see creating key clock trust store trusts are successfully created and importing certificates from systems javascript ca certificate bundle into key cloud cluster and using the own um ca our self-signed ca and we have the trustworth jks and now we can wait until key clock is started go to our browser here again and say localhost 8080 so keep clock service ready and we can again login admin admin or test administrator we're still on the http port not https but uh we're creating now a realm called x509 and uh resetting um this realm for ssl or tls communication only all requests require ssl and we have to do some authentication configuration because the standard flow doesn't use x 509 certificates and we now have to provide an own authentication flow we just do a copy of the regular browser flow call it x 509 browser and delete everything we don't need for now we don't need cameras we don't need identity providers and that's regular browser forms or better overview i didn't i'm deleting the otp because we don't need the otp now and we need the cookie still for a single sign on otherwise the singleton will would not work of course and now we add a new execution execution at the top level and as a provider we're selecting the x 509 validate username form click save and put it up to as the second entry so newly entry newly created entries will be at the bottom of the list so you have to push it up with the arrows here to have it on the second second position and click on alternative so it's one of the alternatives to authenticate a user additionally we have to um config configure this um validator so let's call it x509 config and our user identity source where from where in the secure in the certificate we get the information or which user this is we're using the subject's email because we're using we have specified the email address and we're identifying the user with its email so let's say a subject's email you can do a lot of other configuration also using regular expressions to get it from the subject distinguished name using a lot of other things um for this demo easiest way is to use the email address because we provide the email in the certificate and um the user mapping method it's also important uh how we recognize the internal user in key cloak it's a username or email so above using the email from the certificate and identifying the internal key cloak user by the username or email you can also identify the user through a custom attribute and you can specify the attribute from attribute name from the user so that the the attribute from the certificate and the attribute in your user has to be the same but we're using username or email so we don't need the name of the attribute because when you don't use the attribute we can check the validity of the certificate and we can also turn on checking the certificate against a certification revocation list if we have one um i have now none of them and um so yeah that's it what we have to configure for this little demo click save it's been saved created okay and then to use this x 500 and browser flow in the browser flow of course we have to select it here and save the bindings and of course we have to create a user there's no user available we add a user named fred flintstone so the fret email address will be fred flinstone example.com so the certificate is created with this email address forever in stone at example.com and the first name of course is fred and the last name is flintstone user is enabled click save and uh yeah we're done we don't need to give credentials because we don't [Music] authenticate the user via password or otp or whatever so but only the client certificate and that's put to the client's browser so that's what we um have to do then we can start in a new private window with our localhost but now we have to use the https port okay so now we get asked which certificate we want to use because we configured key cloak to request a certificate with our x 509 browser flow and this is um in this demo this is just a one step too early but because we don't authenticate ourselves yet in the account application but we're accessing key cloak so key clock requests the certificate in a real world example if your application runs on another domain of course this request this certificate request will only appear when you access the key cloak host and doing the authentication and we can select the fred flintstone certificate in here which we previously imported in in firefox so if we have a look to our settings in firefox and have the certificates the client certificates we have the flintstone um certificate which is also located under uh does nico and we can see um organization there's nico and common name is n minus k.e and we signed it with the root certificate of n minus k dot d e so our browser now knows this certificate and now we can use this certificate clicking ok and yeah connection is timed out nice try again so nothing happened because the account console um does not need to do an authentication but if we now click on sign in we are presented a confirmation that the browser or key clock recognized the x 509 certificate from flat fred flintstone of our browser which we selected before and the email address is fred flinstone example.com and you will be logged in as fred flintstone so um if you remember we created the user with the username fred.flinstone and set the email address to fred flinstone at example.com that's um in here and that's the key clock user the fred flintstone in here you will be logged in as this user we can continue and now we're logged in as fred flintstone we see it in the upper right corner fred flintstone and if we click on personal information we see our flat fred and flintstone names so we can sign out again and close this window like this go to our eclog here we see fred flintstone that's a username and yeah if we do it again opening new window you can select the certificate in here also you can see the email address flat flintstone issued by our own root certificate which we put to the key clock server and the script build up a trust source or the key clock server can trust this certificate and if we sign in it can be used here and we can just continue to to sign in and one more option i want to show you if you go to the authentication uh the configuration of our x 509 config and switch the at the bottom the bypass information identity confirmation that's the prompt we saw when we log in and just do it again if we now click on sign in we just directly signed in we don't need to um confirm anything um key cloak just mapped it automatically and we're logged in we don't need to confirm anything we just fred flintstone at this point so as you could see securing your key cloak server with http and https and doing mutual tls and authentication with x 509 client certificate it's not that complicated and not that complex just need some um certificates and key files in case you have uh self-signed certificates and put it to the container again here the https tls3 and the tls key file with the naming conventions for https communication securing the transport layer and putting your root certificate authority to the container or to the key clock server to build up the uh internal truss store to trust external certificates and specifying the x 509 ca bundle environment variable where your certificate authority is located and if you don't use the key cloak container the docker container if you have a manual or a legacy insulation you can use this x 509 script which is used in the container as a good blueprint a starting point to create your own uh script with what everything you what you need in this case um yeah and again if you want to know how to create all these um certificates i put a link in the video description uh to your guest of my github repository where i explain or have a short description how to create those self-signed certificates for yeah mostly development usage or internal usage in your company or wherever okay thanks uh for watching and don't forget to subscribe to the channel so that you don't miss any of my other recordings if you like this video give me some thumbs up and share it tell it to other people and yeah if you've made any experience with the tls and https and key cloak put it down in the comments i would appreciate it and yeah see you next time thanks bye [Music] you

Channel: Niko Köbler (@dasniko)

Views: 2,554

Keywords:

Id: yq1hzNs1JQU

Length: 25min 12sec (1512 seconds)

Published: Wed Jul 21 2021