Keycloak Deep Dive

okay so the first thing we're going to do is that we're going to login to the admin console and the admin sole console for Kiko allows you to configure all sorts of aspects about your clients and your users and your realm itself where realms allows you to provide a way of encapsulating users and clients into a nice unboxed area so that you can have different realms with different purposes we're going to create a new realm for the demo today I'm gonna call it demo and I'm also gonna give it a little nice friendly name as well for for when users themselves see the realm as part of today's demo I'm going to be using various different flows that requires Kiko to be able to send the email so I need to configure an SMTP server in key cog I'm using Google's smtps over here which allows me to to send a few emails a day which is nice for demo purposes but obviously not sufficient for a production use case right so now that I have that configured I can test that Kiko was able to send an email so let's go to my inbox and make sure that we got this test message from Kiko there you go there's a test message from Kiko so we know that email sending from Kiko is working as expected I have an example application that I'm going to be using draw the demo today and I need to configure this in Kiko and this is an order for this application to be allowed to authenticate liar Kate look so that's all I need to do to configure this client inside k-dog now let's go and have a look at this sample application when I'm opening an example application I'm immediately redirected to Kiko to authenticate I can't actually log in at this point because obviously there was no users in my realm at this point so what we could do we could have gone and we could have added a new user as an admin but in this case what we actually want to do is we want to let users self register to this application so we can do this by basically just enabling the user registration option in the admin console for this realm and we can save this but we also want to make sure that these users verify their emails so that we we know that their email is a valid email okay so now if i refresh the login page i've now got the option to register a user okay so I'm gonna fill in all the details to register a new user and then key coke will prompt me to verify my email addresses I required that for my realm so let's go to my email and this sends me a special link and the link goes to key o'clock and when when key coke sees this link there's a special token in there that that key coke knows that this particular user has now verified their email address and it also will redirect automatically to the application and have the user authenticated so we can see here now that the the application is able to know who I am so it has my name and it has this because it has a special ID token and the ID token contains various different claims about my users it is also signed by Kiko so the application can trust the details inside this token the application also has what's called an access token and that's an another type of token that the application can use when it wants to invoke any REST API so allowing the REST API that then know who the user is and what kind of permission is used half so okay so at the moment what the application knows about me is pretty much my email address and my first name and last name I also want to add a little bit extra to this token so that the user can know some more details about so I can go to my users in key hook I can find the user and I can add an additional attribute about this user I'm going to add is I'm going to add an avatar URL so that the application is able to show a nice avatar for the logged in user I could also have extended the registration screen to add this this to the registration screen or I could add it to the kik account management console let users then fill dense detail into the in in their profile through the account management console but let's just add it here for now because we have a bit limited time today so now at this point key clock is aware about this alpha 2 euro but the client is still not able to see this because we haven't mapped this particular attribute into the token yet we're going to do that by creating a client scope client scopes allow you to create elements that you can add to your token which can then be shared between multiple clients so I'm gonna create a scope I'm just gonna call my scope and I'm gonna give it a little nice and friendly user name is know a little friendly name as well so now I have an empty scope it doesn't do anything other than add a particular scope to to the token but I also wanted to do something else I want to add that avatar to all clients I have this scope so I'm gonna create a mapper the protocol mapper which allows me to that map things into the token I'm going to choose a user attribute mapper and that allows me to map the user attributes avatar URL into the token and I can choose what claim name I want to put it into I'm going to put it into as avatar URL as well and then finally I'll just give this mapper a name so that we can refer to it later if you're looking at here the is we can choose where what tokens does this information be added to we can choose to add it only to the ID token or also to the access token in this case we only want the front-end application so the application that uses the ID token to to see this so once we've saved that now we can go back to our cloud client and we can configure what client scopes available for this particular client and it's a good idea to limit the client scopes that are in in the token for several reasons one is that if you have too many client scopes in the token then then the tokens may become very large and also then you have tokens that contains more permissions and more claims than the application should be able to see so you want to limit this down to basically to harden and to reduce any impact of a compromised client so we're gonna add this my scope as a default client scope that means that it's always added to the token we could have added an optional client scope which means that it's not by default added to the token but the client has to explicitly request this scope for it to be added so if we now go back to our application we don't have to real aughh in to get these additional claims now on the token we can just refresh our token and we will now be able to see these additional claims so we can now see that we have this alberta URL so if we go to the front page of the application we now can see that the application can take that avatar URL out of the token and now display a nice little avatar for the logged in user another thing we can easily do is that we can require consent and that means that the application won't be automatically granted access to all of these claims and all these scopes but rather it will be prompted that the user has to approve the application to have this access so if I now log in again this time around I'm not just automatically forwarded on to the application but rather I'm now prompted to act to grant access to various different privileges to this application and I'll go ahead and give that and again you know now the application has all these details so let's turn that off again so we don't have to grant access again for different users in different clients throughout the demo what we're going to now look at we're going to look at roles sokeep dog has support for simple roles and we also have support for what we call composite rules where composite role can be a composite of other roles a composite role can be useful for instance if you want to have a default role that's added to all self registered users and then still allow you to add and remove roles to this composite role too automatically have it added to all users I'm going to create just a simple role this time around I'm gonna create a user role and then at the moment there is no users in this actual role so let's go and find our user and let's map this role on to the user and now we want to go back to our client and we're gonna have a look at what scope this client is allowed to have so you can see at the moment it has this full scoped allowed which basically means that this client will have access to all the roles that the user has we don't want that we want to limit it down to specific roles so we only want this this particular client to be able to access that user role if we now go back to Kiko we refresh our tokens you look at the ID token there's no knowledge about roles in here as b-girls by default we assume that only the services themselves needs to be able to grant permission to access and that the front-end application is just invoking these back-end services that would then we'll check the permissions if we look at the access token we can now see that there is this brawl user in the actual access token so any service that requires that user role we can now invoke with this token Kiko also has support for groups and groups is slightly different to role so groups allows you to to add attributes on to users part of that group and it also allows you to map roles on to users in this group or you can also use the groups directly if your applications have a concept of groups so we're going to create a new group we're just going to call it my group and at the moment that's just an empty group we can choose to map that group name into the token as well or we can as I said week before we can say that all users that are part of this group will get this user role and we can also say that any users part of this group will have this specific user attribute added to them so we're going to just add this user type consumers attribute and now we want to go to our user and we want to make him part of this group and at the moment key clock is aware that the user is part of this group but we also need to be able to map this information into the token so we need to go to the client scopes again and instead of creating a new client scope we're just going to extend on the my scope that we created before we could have created a new say my group or whatever we wanted scope as well but this we're just going to extend on this one so we're gonna add another protocol number this time we're gonna add a group membership this lets us map the group memberships off the user into the top and again I can choose to add it to the ID token the access token and user and for input and I can add I can choose exactly where it's added well just select all of it for now so now we have in the token so if i refresh my token now I can see now that I have groups so I have this my group group in the token as well but we still don't have that attribute so let's create another map for that we're gonna add of course the user attribute mapper and we're just gonna call it type and we're gonna pull in that user type attribute and again we'll just pull it into everything and then we're gonna now go back to the application we're gonna refresh token and now we can see if we can find it there you go so there's the claim user type consumers okay so now we have a user create the true key code and we have a couple of attributes move extended tokens and so on let's now look at how we can get users in from an external store so we're gonna pull in some users from an LDAP server that I have running here locally first of all I'm gonna choose to use the writable edit mode which allows you to change the user through the Kiko admin console of the account management console and have them written back to Kiko oh sorry back to the LDAP server we can also chose read-only which means that key is not able to make any changes to this user or we can keep them unsynched which means that will maintain the changes but won't write them back to Alda I'm gonna use the other as a vendor because that basically pre-fills a lot of the settings that I need for this particular LDAP server and then I'm gonna pass it in the connection URL I'm gonna check that that works and that's working fine I'm gonna need to tell key o'clock where in the directory to actually find users I also need to tell people how to authenticate with this LDAP server I'm gonna test that the authentication works and I worked fine so I'm gonna go ahead and I'm gonna save this now that I've saved this new user Federation provider in the realm key cogs now able to read users from the LDAP server I can choose how users are loaded I can either have them loaded on demand as key clock as its users are authenticated so key coke will then look for user by this username in the LDAP server and will pull it in on demand or I can choose to synchronize it all in one go I can also choose to synchronize only the change users which will use the change log features available in LDAP servers to only check to only synchronize what changes have occurred since the last time I did this in conversation I can now look at my users in my realm I couldn't see that we have the user the self registered before but we now have these two new users and these have been pulled in from LDAP if we take a look at this user for here we can see that this is actually linked to that how that provider that we created before ok so now that we have users from alda let's also have a look at the identity brokering feature as I said before so we allow you to attend ticket users with an external sam'l to open ID connect forward as well as a number of different social networks in this case I'm gonna choose github the reason why I'm choosing github is that github is very easy to create the necessary configuration on the key clock side now sorry on the github side and I wanted to show you the whole flow that's required to set this up so I have to give it a name I have give it a homepage URL which is basically telling github users where does this application exist and I also need a special redirect URI so the redirect URI is where keylock expects to be redirected back after the authentication has happened or github and this is locking down exactly where this is permitted for this particular client so once I registered that on github I get a client ID and a client secret that allows keylock to authenticate with github so the Kitab knows that it's actually key coke that is trying to initiate this external authentication so once I've saved this I'm now able if I now go to my JavaScript console I log out and now get this option of logging in via ghetto we're not going to do that just yet because we want to do one more thing they actually want to pull in this avatar from github into the internal user and Key Club so that we can get it available for the client we'll do this by creating a mapper which is allowed to so it makes it able to map an attribute from github into our internal user and we're going to call it alberta URL i'm gonna pull in the avatar unit scroll URL from github and i'm gonna pull it into the same user attribute name in quito so now that i've done that there's one last piece that we actually want to do since we are requiring users to verify their email in our realm and guitars already verified the emails for their users we're going to actually trust emails to be verified by github so we're not gonna require them to re-verify the emails so if i now log in we get to i'm not asked to authorize access to key o'clock i'm gonna do that and here you go so now the application so now i've been able to log in via github and the application also has been able to load my avatar directly from github as well as my name okay so looking a little bit at this login screen of course it's styled to match the key o'clock styling you may want to change this to match your you know corporate branding or your application branding and this is pretty easy in key clock so all you need to do is create a custom logon theme which you then can deploy onto the key hook server the theme can consist of style sheets or images and you can also override the actual HTML templates that's behind the actual screens I've already created one and I've deployed it onto the keycode server so I'm gonna change to this new theme we can see here that now that I've changed the theme the the login screen looks completely differently so since this is a little bit distracting with this whole rainbow effect I'm gonna change it back to the key club team for the rest of the demo okay so let's go ahead and look login to the application again because I want to show some features about the actual tokens in key code so we have here we have the JSON based format for the claims in the token but here we have the actual basics before encoded or the encoded version of the token this contains of basically of three different parts so you have the first part which is headers which identifies what signing algorithms and keys and other things about the token and then you have the actual payload or your claims and finally you have the signature part of the token so I've deployed a little extension to key clock which allows me to actually verify or decode these tokens so all I need to do is a paste in this encoded version root token and then submit and now I can see that the token is valid and I can also check that it's been signed with the active key I can also see that various different bits off the tokens I can see the header and I can see the payload what we're interested in now is we want to look at this algorithm here that's the algorithm that's used to create the signature for the token and we can see that it's using RS 256 so RS 256 is our essay based signatures what we want to do is we want actually change this to ecliptic type signatures we could have gone into the realm we can change the default signature for the whole realm tui is 256 which is an ecliptic based signature but that may be a little bit problematic since we may have other clients that are not able to to verify signatures of this type while ers 256 there's a lot more widespread available these days so we're going to leave the realm default and instead we're going to go into this particular client and we're going to choose to use es 256 for any tokens issued to this client I can now go back to my application I don't have to real aughh in to get new tokens I can just refresh my tokens and now I will have a new ID token I can paste that into my verifier and we can see that now then the the token is now signed with a different algorithm similarly to how we can change signatures we can also change the keys used to sign the tokens what I'm gonna do is I'm gonna go in and I'm gonna create a new set of keys for the es 256 signatures and you set a high priority so that this now becomes my new active signing keys I can also go and I can make sure that the old signing keys are no longer active which means that they won't be used to sign any tokens they will only be used to verify tokens so if I now refresh my tokens again I can do that still even though I have tokens my refresh token is using the old signature no signature keys and now I will get new tokens that are signed with the new keys so if I go back to my application I can see that currently of the previous token was signed with these keys here and if I now submit this new token I can see that the actual key is being used have changed and I can also go to the admin console I can look and I can see that that is indeed the actual active Keys okay so the next thing I want to show is session management key coke basically all tokens issued by Tiki Coke associate within an SSL session we have support for both online sessions which means that it's tracking the user that's logged into the browser as well as an offline search session which enables an S session in your application even though the user is now logged out what we're going to do is we're going to take a look at the actual user that's logged in and we're going to look at that uses sessions I believe it's this user here and we can see here that we have a session open I'm gonna go ahead and actually log out this session and I'm gonna now try to refresh my tokens and you can see that the token is no longer valid or the session is no longer valid so I have to then Bri login similarly if I try to now verify the token I can see that the session is no longer active okay so let's take a look at events in key cog we can see here that key o'clock is saving a number of events in the system that allows you to see what's being happening in your system so we can see here if we go back into the story we can see that we updated the realm so and we can see that we created a client we created some execution flows and we created a realm and so we've also see all the login events not only can you not only can you have these events saved into key coke and then be able to see them true through the admin console but you're also able to create your own custom event listeners that can listen to all these events and handle them exactly how you want them to be handled looking a little bit about how extensible keycode is Keiko provides a whole number of different SBI's where you can create your own custom code and deploy to cake look so you can create your own custom protocol mappers you can create your own custom user stores and you can also create your own custom authenticators so what we're going to do here since I've already created a customer 10 together and I've deployed it on the keynote we're gonna configure that into our realm so the first thing we're going to do is we're going to create a crappie off the current flow used for browser-based logins and then we're going to get rid of the username password form because that is what we're going to replace with this custom Authenticator that were created so we're gonna add this thing called a magic link and then we're gonna make it into the required step in this flow we also need to go and change what actual flows are being used by key look for browser-based logins so if I now go back to my application I try to log in I can see that now longer I have I'm being asked for username and password but just my email address so I'm gonna provide that and now it tells me to check my inbox so I'm gonna check my inbox and in my inbox there's a special link that basically proves that I am Who I am it say I am and that's gonna open up on keko keko Gersten gonna verify me as the user and it's gonna then redirect me to the application and I'm gonna be authenticated all without having to provide a password so other things that we can do is for instance if we want to go to the flow and we want to say that actually we want ot P logins to be required if we now go back to application and log in again then when we do that we'll be logged in from that customer indicator but that other built-in Authenticator will now require us to set up OTP and since the the reason why is asking us to set up OTP is because we now require OTPs in the realm but the user doesn't have one set up already so we're now asking the user to to set one up so the user will then set it up and the next time around you will be asked for one time code and we can of course we can change this to two not longer be required and we can make any changes like this if we want

Channel: Stian Thorgersen

Views: 45,389

Rating: 4.9550562 out of 5

Keywords:

Id: XJYy6Aq-PJ8

Length: 27min 2sec (1622 seconds)

Published: Thu Sep 20 2018