 Well hello and welcome to another Dev Nation Live. We've had some technical challenges this morning. Our lead presenter is over in Norway and he's having power fluctuations so we might have some excitement. And as always on the chat you can feel free to find me there and ask questions on the chat and we'll try to get those over to our presenter as we can. And you can help each other by basically saying refresh your browser. That's always the trick to this right if you can't hear can't see kind of thing. So let's go and jump right over to Steen who's going to basically show us key cloak and a deep dive demo that he wants to show us to really get this content started and will hopefully his power stays up long enough to see this demonstration. Steen ready to go? Yeah I am. I'll stop by sharing my screen so we can see on my slide. So today we're going to take a little deep dive into key cloak. Last time around for about a month ago we had a presentation on how you can secure your applications and services with key cloak. If you missed that one and you're interested in key cloak then that's worth watching. Today we're not going to focus on how you can secure actually applications and services but we're going to rather be focusing on key cloak and the service itself and a few features that key cloak provides. So recapping for those that are new that didn't join the last session. What is key cloak? Well key cloak is an open source identity and active management solution. It's been designed for modern applications, APIs and services and I think key cloak differentiates itself a bit from the rest of the IM space by the fact that we have developed key cloak to be nice and easy to use for application developers. That is our target audience for key cloak. A quick overview before we start looking at some features. Key cloak provides openly connected and SAML to both and those provide standard ways of securing your applications and services. Key cloak can read users from a number of different sources including you can store users internally in key cloak's own database or you can federate users from a external user store such as open held up, active directory or any custom user store that you may have. We also have support for what we call identity brokering which allows you to delegate authentication to external identity providers. This provides both support for openly connect and SAML to the talk and we also have a Kerberos break so that you can have seamless login between your workstation and your web application. Through the identity brokering feature we also have support built in for a number of social networks. So today I wanted to instead of just having a lot of slides and talking about the features that key cloak provides I wanted to actually show most of the features so primarily today we're going to be going through a demo. The first thing I'm going to do is I'm going to open a key cloak admin console. Through the key cloak admin console I can configure most aspects of key cloak and I can set up my clients, my users and I can configure my realm in general. A realm in key cloak is a space for all your applications and your users so that you can sandbox each from other types of scenarios. So the first thing I'm going to do is I'm going to create the new realm for the demo today. I'm just going to call that demo and I'm also going to give it a nice friendly name for humans. And the next thing I need to do is I need to configure SMTP server for my realm today because I have a few flows where key cloak needs to be able to send emails. So I'm using the Google's SMTP service today which lets me send a few emails each day. But it's obviously not ready for production use because you won't be able to send too many. So you'll need another SMTP server for key cloak for these type of flows. Although now configured that, then I can test that connection by sending a test email to my admin user. And I can go to my mailbox just to make sure that I actually got this message and here you go. We got the message from key cloak so we know that everything is up and running. The next thing I need to do is I need to register clients. I've got an example client I'll be showing in a second and I need to register this in key cloak. So the key cloak knows that this particular client is allowed to authenticate the key cloak. I basically just create the new client. I tell it where the client sits and I give it a name. And this will then set up some a lot of sensible defaults for the client. In which case it's setting up a public client since this is a JavaScript place, it can't authenticate itself directly with key cloak. So relies on these valid redirect URLs to limit who can use this client configuration. Once I've done that, then I can go and I can try my example application. My sample application requires authentication. I immediately redirected the key cloak to log in. And at this point, I can't actually log in because I don't have any users in my realm at this point. I could go to the admin console and I could create the user through the admin console. But in this case, what I want to do is I want to enable use of self registration in key cloak. And I can do that by simply going into my round contact and just enable this feature. I also want self registered users to verify their email address. So I'll enable this feature as well. And now if I refresh my login screen, I can now see that I have an option to register users. So I'm going to quickly register my user. And then keep looking at asking me to verify my email, set this up in the realm itself. I'll go to my inbox. And I've got an email from people to verify my email address. When I click that, I'll be taken to keep up first people then mark my email that valid and then I will be redirected to the application and I will be logged in. And now the application knows some details about me. And the application knows this because it has access to this ID token. And this ID token is a signed token issued by people that gives the application some details about me, including my name. Now, I want to add a little bit extra to this token. I want to add an avatar to this token so that the application knows a little bit more about me and can display a nice little image about me when I log in. To do that, I need to go to my user. And I'll add a new attribute for my user. I'll call it avatar URL. And then I'll need an image. I'm just going to use this one, which is the key code logo. At this point, key code knows about this attribute, but the application is not able to see this attribute yet. I need to map this attribute into the actual token in the sense of the type. And I'll do that by creating a client scope. A client scope allows you to add a reusable scope that can be used along many kinds to be able to add different pieces to the token. So I'll give it a little name, drive-friendly name as well. At this point, I have an empty scope. It doesn't do much at all. So I need to add a few mappers into this scope. This lets me map various different things from key code into the actual token. I'm going to use the user attribute method. I'm going to use call it avatar. And I'm going to use this user attribute. And I'm going to add it into the token with the same name. I can choose here if I want to add it to the ID token and the access token and also the user input endpoint. This lets me decide where I want to issue the token to. So the ID token is aimed at the front-end applications to be able to authenticate the user. While the access token is aimed at the front-end applications to be able to then send to back-end applications or services so that they can then verify the user. Right, so now if I now refresh my token, I don't have to re-log in. Then the user, the token should have contained up. I forgot one little step there. I've created the client scope, but I have to actually give the client access to the client scope. So let's go to the client again and look at the client scope. And here we go. There's an available scope that I need to then add to the client. But this time around, if I refresh my page, so there you go. Now the application has my avatar as well. And I can look in the ID token and I can see that this claim is now available inside the ID token. A few other things I can do through the admin console is I can require that the application needs the user's consent to be able to access the user's account. And that's just a configuration option away. I need to just enable the consent. So now if I log in, I can see that Kikok is now asking me to grant access to this application. So I'll go ahead and give that application that access. Kikok also has the proper roles. We have the proper simple roles and we have the proper composite roles. Composite roles can be nice to use if you want to be able to add a composite role to a group of users, but then be able to manage which particularly roles that belongs to as well in the future. In this case, I'm just going to add a simple role. I'm going to call this user. And I'm going to go to my user and I'm going to add this role to the user. And now if I go to my application again and refresh my token and I'll take a look at the access token, I can see that I now have a few roles in here. And there's a couple of more than just that role that I wanted to add. And the reason for that is that to make it slightly simple for you to set up Kikok, we have this thing called full scope allows that gives the application all access to all the roles that you have. This is not what you really want to use in production. In production, you want to limit down on each individual client to make sure that they only have access to what they need to have. So in case that application is compromised that it can't access other things. So once I've changed this scope now, if I refresh my token again, then we can see that now I only have this particular role that I wanted. Kikok also has support for groups. And basically, you can just create a simple group. And then a group can be used as its own. You can map the group name into the token, and then your application can make decisions based on the group name. You can also decide to add attributes to a group. So in this case, I can add a user type attribute. And I'll call that consumers. And that means that any user in this group will also get this attribute as well. And then you can map that into the token as well. You can also add roles to groups. So as I said before, we are able to read users from other external stores as well. So let's go ahead and try to read some users from an LDAP server I have running locally. All I need to do there is to create a new user federation provider. I'll select the LDAP option. And then I have to configure it a little bit. So firstly, I'm going to select the edit mode writable. That means that you can make changes to the Kiko account management console, which allows users to manage their own account. And these will be written back to LDAP. Or you can make it read only. And you can also use the special mode for on sync, which means that any changes will be kept internally in Kiko and not written back to LDAP. And then I'll choose the vendor order, because that gives me the best initial setup for the particular LDAP server that I'm using. I'm going to tell Kiko where it's fit. I'm going to check the Kiko fit for next, then it can. And then I need to write to tell Kiko where in my directory the users reside. And hopefully I'll do this correct. And then I need to give it credentials to authenticate as the admin. And then I'll check authentication. That was just fine. So I'll go off and save my provider. So now I have a new provider added to Kiko. And I can now choose to synchronize all users from the LDAP server. And I can see here that I have two new imported users from LDAP. So if I'm not quickly go to my users, I can have see that I have three users in my realm. I have the user that self registered. And I have the two users that are imported from LDAP. And we can see if we go into the details for the user, we can see that it links this particular LDAP provider. Okay, so the next thing we're going to try is that we're going to try the indentity brokering feature. I can choose to use any SAML or open ID connect identity providers, your corporate identity providers, or I can use a social identity provider. So in this case, I'm going to use GitHub. And then I'm going to go to GitHub. That's the slash new. And here I can create a new or application. And I need to basically I need to register Kiko inside GitHub for Kiko to be allowed to log in. And I need to tell GitHub, just like I had to tell Kiko to redirect your eyes of my application, I have to tell Kiko to redirect your eyes of Kiko. And once I do that, I get this client ID, and this client secret that Kiko needs to know so that it can authenticate with GitHub. I will also, since I enabled this verify email option in my realm, I'm going to trust that GitHub actually verified emails. I know that when you register with GitHub, GitHub makes you verify your email address. So I'm just going to trust that. And then I also want to call in this avatar from GitHub as well. So I can add a map onto my GitHub provider that allows me to pull out different pieces from the token issued by GitHub and put that into the user in Kiko. And they have the same attribute, the avatar underscore URL attribute. So now if I go to my application again, and I log out, now I have this option to log in by GitHub. And I need to grant access to Kiko in GitHub. And then I forgot to disable the granting of access to the JS console to have the grant again. And here we go. I'm now logged into the JS console. And you can see my avatar from GitHub and also my name from GitHub. And if I go back to my realm, I can now see that I have this user here, which is my GitHub user. I can look at my identity provider link and I can see that I'm linked to a particular GitHub user. So now if we log out again, we can take a little look at this login screen and see that it's got the key to theme. But perhaps we want this to match our corporate theme or our application theme. I can do this by creating a custom theme and deploy it to Kiko. And then through the admin console, I can now choose my custom theme as a theme for this realm. So if I refresh the login page, I can see the nice and beautiful new theme that I have here. I'm going to switch that back because I find that theme a little bit distracting. There you go. Now let's log it back into the application. And then we're going to take a look at this ID token in its encoded form. So it's a pretty long gibberish type of string. It's encoded in the basic before URL encoding to allow it to be very web friendly. It's got three parts. The first part is the header of the token, the middle part is all your claims. And the last part is your signature. And I also deployed alongside my custom theme, I also deployed this custom extension to Kiko, but let's me verify token. So if I paste in this basic before encoded token, I can now get some details about this. It's actually verifying the token for me, making sure it's signed with the active key. And it's giving me the header of the JSON format and the payload as well as the JSON form. What we're interested in this point is this particular claim here. It says that this token is signed with the RS256, which is an RSA-based signature. What I want to show is that we can actually change the way that the tokens are signed and it won't even affect our current logged in session. So I could change the signing algorithm for the whole round for all kinds, but perhaps I'm trying to understand a new algorithm that I'm going to choose. So I'm going to do it just for this particular application. So I'm going to use ES256, which is a typically curved-based signature. These have very much the same security properties as RSA, but they are less CPU expensive. So if I now go to my application again, I can refresh my tokens so that I get new tokens issued. I don't have to re-log in. And now I get this new ID token. And if I go back in here and then look at the algorithm, I can see that now I've seamlessly changed tokens to use a different signing algorithm. In a similar way to being able to change these signing algorithms, I can also rotate my keys that are used for signing. So in this case, I'm going to create some new keys that I'm going to be using for the signing key pair. I'm going to set a high priority to make sure that these are picked up before the currently active key pair. So if I now go back to my application, I fresh and get some new tokens again, I can then look at the key IP here, which is showing me what the ticker key pair is being used here. And we can see that that starts with LZN. And if I then submit my new token, I can see that that is now using a different key pair. And the reason why this works is that the application has a refresh token. And I can use that refresh token and keep up with Verify against the old keys that are still being used for verifying signatures, but not being used to create new signatures. And then KeyCoke will now issue all new keys that are now signed with this new key pair. So we can take a little look at sessions in KeyCoke. KeyCoke has the concept of having a session, an SSO session. So all your keys, all your tokens are issued a link to this particular session. It makes it very easy for you to invalidate all tokens that were issued for a particular session. So I can see here that my user, DNST is logged into this particular application. If I go to my user, I look at the sessions for the user, I can actually also log out the user session through the admin console. The user himself can also go to sessions in the account management console and can log out from there. So I'm going to go ahead and I'm going to log me out from the admin console. If I go back to my application and I now try to refresh my keys, I'll be redirected to the login screen instead of getting new keys, not because the session is no longer active. So let's also take a little look at the event system that KeyCoke has. So pretty much most events that occur in the system generates an event that we can save them a system in audit, or we can implement a custom event listener that can listen for these events and handle them however you want. And as all other custom things, you can hot deploy these things to KeyCoke for these. So we can also choose to save events in a KeyCoke database, which lets us then see a history of events in the admin console. So if I now, for instance, I go off and I create a new client, then I can go and look at the events that were generated. I can see here that someone created a client, and I can see the idea of the client. I can get some detail about who it was, how they tend to get it. And I can also get the JSON representation for how that client is great. And same if someone tries to log in, and provides an invalid username or password, then I get a login error event happening as well. You can filter and you can decide what events that you want to listen to. Okay, so the last thing I want to show is how customizable KeyCoke is. What we're going to do now is we're going to create the whole custom authentication flow. And in this custom authentication flow, we're also going to use a custom authenticator. And this particular authenticator is something that lets you verify or log in with just providing your email. And you'll get a special link in your email to verify that you are who you say you are. So what I'm going to do, I'm going to make a copy of the current flow that's used for browser-based login. I'm going to get rid of this username and password form. And then I'm going to add a new replacement for it, which I cleverly call the magic link. And then I'm going to mark this as required. And now if I go back to my application, oh, I forgot one thing. I need to actually also, this new flow that I created, I need to select that this is the flow that's going to be used for browser login. So let's give that a go. And here we go. So now instead of being asked for the username and password, I'm now only being asked for my email address. And I can now provide this, and I log in, and I'll be asked to go to my email. I'll do this. And in this email, there's a special link that contains a token that allows Kiko to verify that I should be authenticated, and then I'll be redirected to the application and I'll be logged in. And this is fully custom code that I've deployed separately to Kiko without making any changes to Kiko for having to change the Kiko source code itself. Similarly, I can also make some configuration changes to existing built-in authenticated. So for instance, we have the OTP form here, which is a moment is optional. That means that it's only required if the user has configured it. But let's make it required. And if I now try to log in again, so I'll have to do it through the email, then we can see that my customer authenticator initiated first and I logged in via email. And now the OTP authenticator sticking in and is asking me to set up OTP. And that's because I haven't registered it with this user yet. Once I've registered OTP, then the next time around, I'll be asked to provide a one-time code. So that's it for the slides for today. A few features that might be worth highlighting that we didn't have time to demo today is we're leveraging a project called Infinisban that provides us with high quality clustering capabilities and a caching layer as well. And we also have support for clustering across multiple data centers. We have the account management console, which allows users to manage their own account. They can link to additional social networks, they can set their passwords, they can change their profile, and they can also manage their own sessions, and they can view events associated with their own account. We have something called the authorization services, which hopefully sometime in the future we'll have a definition live session dedicating purely on this. The authorization services allows you to define policies and permissions centrally in Kiko so that you don't have to do that in your applications themselves. Kiko, as I've shown, is highly customizable through a number of SPIs. We have about 100 SPIs that you can develop custom for others for. We have support for X5 or 9 authentication, support for users and for clients. We have everything that you can do through the admin console, you can do through an admin REST API as well. And there's also an accompanying admin CLI tool. We have a client registration service that allows you to create clients through something like Ansible or another provisioning tool, or applications can even register themselves automatically in Kiko. There's also an accompanying CLI for this. And then we, of course, have built-in brute force password protection, we have built-in password policies, and there's tons and tons of more features that you can discover in Kiko. So that's the end of my today's session. If you want to learn more about Kiko, then hit the link to our website, and hit the link to our source code on Kiko as well. If you want to actually try out the demo that I've shown today, there's a link there to the demo. A little note here, I've got a few features that require Kiko 4.5, which will be released next week. If you want to give it a go beforehand, you can, but you have to then build Kiko from source yourself, which is pretty simple if you're familiar with Maven and you have Java and so. If you need some help, or if you have some general questions, you can touch with us on our community mailing list. We're not very active in Stack Overflow, but if you ask us on the mailing list, we're more than happy to help. Also, you can get in touch with us on Twitter. Okay, that is it. Thank you. So, Burr, do we have any questions? Oh, you have a lot of questions. As you always do, we're not going to get through all of these, but you just answered one of them. One question was, is this 4.4? And you just said it's 4.5, so that's an important point, so people who want to replicate this demonstration need to wait for 4.5. The other big question was, when can I get the recording? And I provide the link to the playlist. Just monitor that playlist. You'll see all the donations showing up there as I get, I'll update the playlist as I get the recording as well. And then there's a bunch of other questions that are getting pretty detailed. Here's a great one. Question about read-only LDAP. And read-only LDAP connection. Is it planned to make password change possible even with read-only LDAP? In some cases it would make sense to be able to use the key cloak workflow to change and reset the passwords even if the user data is managed outside of key cloak. I think that's a great question. What do you think about that one? Yeah, I think you can somehow achieve it today. You can choose what individual attributes are actually written back to LDAP, but I'm not sure if that... I'm not sure if you can achieve exactly what the person is asking, but LDAP is not my expertise area. So that question is sent to the user mailing list and we'll be able to answer it properly. Very good. And I think I did provide the links to your deep dive demo as well as keycloak.org. There was a question around, well, how do I run this on OpenShift? I found your blog from May 31st on how to run key cloak on OpenShift, which includes the template and the Docker Hub image. That was a bunch of questions that we already answered. At least we had the chat. Hopefully we got that. And here's another great question. Just like today's demo, the last time around, I ran everything on OpenShift. So the whole demo there is running on OpenShift and that's available on GitHub as well. Okay. Fantastic. And then some question about performance numbers. What kind of benchmarks have you guys done to show that this thing scales and what kind of scalability attributes there are? We are still working on that. We basically don't have big enough labs, but we have knowledge about people that are using keycloak with tens of millions of users with hundreds of thousands of open sessions. So it definitely scales. Okay. Are there any plans to support CAS, CAS, with identity brokering? No. We have decided that we're going to focus on OpenID Connect and SAML. However, there are CAS extensions in the community. There is also a WS Fed extension in community. So if anyone is interesting to do a CAS identity provider support and maintain that in community, awesome. Okay. How about SSO with Windows ADFS and IDP? ADFS, I think, can be done through LDAP, SAML or OpenID Connect if I'm not mistaken there. So yes. Okay. And as you said, a lot of these questions probably require more drill down on, in which case the email list is going to be better to go back and forth for these kinds of things. But there's a couple of quick questions here about multi-tenancy that I think could be pretty interesting. So in addition to the Realm Masters, a possible have a Realm that can see and manage other Realms. So my intention is to have supervisors for some Realms. Think of that as submasters. Yeah, no. That's not possible. Directly. However, what you can do is you can use the Identity Brooklyn capabilities to allow users from different Realms to authenticate in a Realm to then manage it. Okay. And then, and we're not going to get through all of these questions. I apologize for you guys who've been hanging out here with us, but we do have to kind of get off this call. We have a kind of a 30-minute limit. Do bring them up on the email list, but we're also going to get these questions out of the platform. Get them over to our teams so we can try to respond to them via email ourselves as well. Okay. Because you guys do have tons of great questions. And actually your demo was awesome, by the way. I really enjoyed it myself. You know, having the key cloaked around a little bit. I loved the way you presented that. That was just great stuff overall. I'm pleased I didn't lose power today. So that's good. I know that was and funny enough for the people here on the call. He lost power right before this thing started and all we had was the phone. That's why we're talking to you via the phone instead of the webcam because we know the phone would work. Okay. Well, I think that's good enough for today. Again, we're going to try to get these questions and stuff back offline, if you will. Look for an email from us. Monitor that playlist we mentioned earlier. So you guys can see the recording and do join that key cloak email list we mentioned just because that's the way to kind of really interact with the team, get your thoughts heard, get your questions answered and debate how architectural you would integrate integrate key cloak into your otherwise enterprise systems that you have. Thank you guys so much. But thank you.