 Welcome to Keycloak, the open source identity and access management for modern applications. My name is Alexander Schwartz and I've been an IT consultant for who's been advocating for Keycloak for like eight years, I would say. In 2015 I did my first pull request for the Keycloak project was accepted and last year I joined the Keycloak team and Red Hat full-time in January 2022. So this is a 10-minute adventure of what Keycloak can do for you and your project. And what can it do for you? It can authenticate and authorize your users for your applications. You can configure it interactively via web UI or fully automated. It can be a bridge to existing security infrastructures so that you have a modern front-end with OpenID Connect and maybe a back-end with SAML or LDAP, Active Directory, whatever, and hide all that daunting stuff from your new applications. You can extend and customize it as needed. We will see then in a second how we can do this. And you can run it both in the cloud or on non-cloud environments. So what does Keycloak do? So it's all about tokens in the end for Keycloak. So you have your user that then using a mobile device, using a standard computer, and they want to log into some services in the cloud. They send the first request there and then they get usually a redirect because the user is not authenticated yet. Redirect it to Keycloak and Keycloak presents, for example, a logging stream. People put in the username and password and they receive a token and then with that token they can access the services in the cloud. And with that token, the services in the cloud can then ask Keycloak, well, who is that user? What are they allowed to do? Roles, groups, permissions, whatever. That's then all provided with that token, the application sent to the service. So what's the thing that the user usually sees from Keycloak? Well, it's a logging screen, right? A very standard logging screen. You have a username and a password. And behind that, Keycloak could use that username and password and verify it using its own database where we store all the hashed secrets then. That's one thing to operate it. But if you're then in a real enterprise environment, you usually have a brownfield project, you have an existing infrastructure, maybe you have an LDAP, maybe you have an active directory, maybe you have a legacy application that stores user credentials and user details. You can connect Keycloak to that and Keycloak will hide that from your application. It will be seamlessly integrated. We have standard integrations for LDAP and active directory. If you have a very custom legacy database for your users, then you would need to do some Java programming to integrate it with that user store. And it can do a lot more than just a logging screen. You go into the configuration and say, well, let's add maybe a forgot password button to that logging screen. And Keycloak comes with a pre-configured flow that once you click on that button, you're being asked, well, what's your username? What's your email address? We send out the email and you click on that link. And the usual stuff you know that happens all the time when you forget your password. The same is around, you have a new user they want to register. Even that Keycloak can handle that. So as you see, we're getting a very fully user management out of Keycloak here and all these daunting things, your application doesn't need to care about it. Your application will do only the things that are relevant to your business. And you can also integrate with social logins here, like you can log in with GitHub, you can log in with Stack Overflow, you can log in with Google, all these brokerages also in there as well. You can go even further. So this page intentionally left blank, right? You can skip all your login screen. If you're in an enterprise environment, you're already logged in using Kerberos. And then your application redirects to Keycloak. Keycloak sees, OK, this user already has Kerberos set up. And then creates a token and passes the token to the application. So your applications only need to learn Open by Deconnect. And Keycloak will do the translation to Kerberos, whatever you have in your legacy setup. And such a login screen, such a login flow, what can be really powerful what you can do in a login flow? So between that login where you put in username and password, and then when you end up in your application, you can put in there numerous steps saying, you want to have your users, you force them to configure one-time password generator. So Keycloak will make sure that it has one defined. And if it doesn't have one defined, it will ask the user, now it's a good time to set up a one-time password. The same goes for WebOrson. We can also do a screen in there, confirm the terms and conditions. So it can also do that and recall, these terms and conditions have been confirmed. You update the password because maybe your users need to require a password change every now and then. You want to update your profile. You want to have an email that's verified before you then hand over to the application, because the application requires the email to be verified before it wants to send data there. So all these steps, you can put them between the login screen and the application. And there are some building blocks already defined. Some of these are on the list. But you can also build your own required actions here. So this is the web front end that the user usually comes into contact with. All this can be administered using a web UI. So this web UI, for the administrator, you see here toggle buttons, for example, user registration, enabled yes or no. For good password, yes or no. Remember, me functionality enabled yes or no. So everything can be explored using a web UI. But then, as we're cloud native people, well, we don't only want to have a web UI, right? So you want to have a REST API as well. It's there, and it's also a command line interface where you can configure these things as needed in an automated fashion. Well, that's the UI for the users. But then there's also the UI for the admins. Now it's the UI for the users. So the users can manage their passwords there. They can manage their second factor. They can update their user details. All this UI is there and ready to be used as part of this full user management that's there. And well, as we are here with cloud native people, well, you want to have a continuous everything infrastructure. Everything should be scripted, some called GitOps. So we can do that by exporting and importing re-ons. So I've done it lots of times in test environments that you want to spin up in multiple instances. You have a full re-on exported as JSON and imported when you start a new key clock instance in the test environment, and it's fully set up from that export. But you can do it only in a fine-grade way that you have a REST API, that you add another client, add another user, both in REST API and the command line interface. And of course, the configuration files, but also CRDs. For example, to set up a new instance of key clock using the operator, you fill out a CR like this, naming like, OK, this is going to be the host name. This is going to be the database you want to connect to. And then you're ready to set up a new key clock instance in your environment using an operator. I've been talking about customization quite a lot here. So there's a server developer guide that gives you all the details that you need here. So you want to customize the theme, for example, to make it really look and have the same look and feel as your company. You want to configure the login flows. We talked about earlier that, add new required actions. You maybe want to create event listeners. So whenever a new user logs in, you want to have an event file that's then processed asynchronously in the background, the same when a new user registers. Maybe when there's a failed login, all this can be listened to. And you can react on these events in here. Especially if you're in an enterprise environment and have this an LDAP setup. I've seen LDAPs being set up in lots of different ways and flavors. You want to have some methods of that information so they end up in their token or in the user info endpoint of the OpenID Connect things. So the application can really use this information. And you can write your own methods as needed here. And as I said, you can also connect your custom storage if it's a database, if it's a rest service, maybe if it's a host, your choice. You can connect your custom information to Keynote here. And to run it in cloud and non-cloud environments, in a non-cloud environment, you download an archive, right? You unzip it, untar it, add a JDK to it, and you are ready to run Keynote. But of course, if you're in an OpenShift, a Kubernetes environment, you use pre-built containers that we provide to you. You can customize these containers, and we actually encourage you to do so. You can enhance them, put in your own extensions to this, bake in the configuration so that the container starts faster, and then hand this either the original image or the customized image to the Keynote operator. So this was the 10-minute tour of Keynote. So you've shown you how you can authenticate and authorize your users for your applications. You can configure Keynote interactively or fully automated as of your choice. You can have it as a bridge to existing security infrastructures and customize and extend it as needed. And you can run it on scale, both in cloud and non-cloud environments. There are some links, and I assume that these slides will be shared afterwards. And I have some very exclusive postcards for Keynote and stickers, so grab me in the next break and get some from me, and have you see around. Thank you. Thank you.