 Don't know, it's an open source project. It's an identity and access management solution. And it's specifically designed for modern applications and APIs and services. It's 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 Keycork? Well, you want to be delegating your security. Firstly, it does provide better security to have a single process and part 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 Keycork also provides a huge bunch of cool features and capabilities that you may want to provide to your users of your applications, such as single sign-on and two-factor authentication. And 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. OK, 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 mainstream protocols out there today. One of them is OpenID Connect. It's layered on top of OAuth 2 and provides on top of the authorization capabilities from OAuth. It also provides authentication capabilities. So OpenID Connect is JSON-based. It's a very simple protocol. It's easy to understand the flows. It's easy to understand the request and everything ascent. And you can easily debug what's going on. And it's also even so simple that you could relatively easily implement the kind side of it yourself. It also has a concept of a bearer token, or often referred to as 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 identifications of the users throughout all your different bits and pieces of your system. SAML, on the other hand, is XML-based. It has a good few more years on it than OpenID Connect. But it's also much more complicated. So the XML documents are harder to pass, are 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 OpenID Connect. It's just simpler to deal with. And it fits the modern needs better. If you have single-page application, or if you have mobile applications, or if you have REST services and APIs, then you want to be using OpenID Connect. SAML, on the other hand, works well for monolithic applications. It also works really well if your applications or your third-party applications already have SAML support built in. And there may also be some corner cases where you have some fancy requirements that OpenID Connect just doesn't cover yet. OK, 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 Keystroke adapters that we provide for some languages, provide a really good integration and a very good experience with securing with Keystroke. And then we have what we currently are calling the generic adapter, which is coming soon. This is an 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 OpenID Connect and SAML, 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 are also coming now with built-in support for this. OK, so Keystroke adapters, they really do provide, at least in my opinion, the simplest and best integration with Keystroke. We tie really strongly into the underlying frameworks, and we try to make it as simple as possible to get started with these adapters. They can be referred to as a 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 that JavaScript library also has support for Cordova. And the reason that we also introduce support for a single sign-on on mobile applications as well. We have support for many JRE containers. We have support for Wi-Fi, Jetty, and Tomcat. And for other containers, you can use our Solus filter. It doesn't provide quite the same experience, but it will work for any standard JRE container. We have support for Node.js, and we also have support for Spring Boot and Spring Security. Now, OK, so what do you do if we don't provide any adapters 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 as 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 the 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-like features. And then similarly for the service, what it does there is that it checks the authorization headers that's included in the requests and makes sure that the request should be permitted before it boots it onto the service. And one additional cool thing that this thing can do is that it can also intercept the outgoing requests from the application to then automatically add this bearer token from OpenID 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 following now, I'm primarily focusing on OpenID Connect and OAuth. I won't be talking too much about SAML, but a lot of these concepts are directly translatable to SAML. 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 the user. The application won't show a username and a password field or form, sorry. It will, on the other hand, it will redirect onto KeyCock. KeyCock will display the login forms and will then authenticate the user. Once that's done, it will send what's 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 username, first name, last name, date of birth, whatever you want. That token is also signed so that the application can trust that that token is actually issued by KeyCock. Okay, so taking this one step further into a single-page application, so the whole redirect and everything now sits on the client 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 client 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 it can use that to verify whether or not the request should be permitted. There is basically two different options on how the service can verify this token. It can verify it online, in which case it will call the Keynote server, and the Keynote server will then check the token and get back to the server and say yes or nay. Or it can verify it offline, in which case the service will then at some point retrieve the public key from Keynote, and in most cases it will cache this, so it won't have to reconnect to Keynote 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 trade-off in which approach to choose, so the offline usually has a bit of a window after the user's been disabled or logged out or anything like this, until the token expires, so it doesn't take immediate effect always. This is kind of alleviated a bit by OpenID 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 Keynote to obtain a new access token whenever it expires, so usually we're only talking about a 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, it takes immediate effect, but on the other hand, you do have the penalty of an extra request for every request coming into 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 Keynote service, so you may need to beef that up a little bit more. So looking at how this works with microservices, 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 token 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 Keynote service, server obviously, and it has a SMR5 application, it has a REST service that's implemented in Node.js, and it has a PHP service. The two services follow the same API, and they're obviously both secured with Keynote, so they're interchangeable to show that it's very easy to switch between different languages and there's full interoperability on how end-to-end user authentication happens when you use something like Keynote. So let's start by looking at the SMR5 application just to see how easy it is to create, to secure something like this with Keynote. So basically this application, it's a PHP application, not just so that I can inject some configuration into the application. I need to tell it where the service sits and I need to tell it where Keynote sits. 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 authenticated and this basically shows a login button and on this login button, all I need to do is to call Keynote login when the user clicks that button and that will then deal with all the redirect dances from OpenID Connect and will then authenticate the user. And similarly, when the user is authenticated, I have a logout button and that again just calls the JavaScript adapter and says, hey, we wanna logout. And then we have quite a nice feature in Keynote. We have an account management console that lets your users manage all the user details and recent 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 secured endpoint that needs a user with a user role and there's an admin endpoint that needs a user with an admin role to be able to invoke. And obviously, since this is a JavaScript, HTML5 application, there's a bit of JavaScript as well here. So to use Keynote, we have to configure Keynote. 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 with Keynote. So that Keynote is aware that this kind should be allowed to log in 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 Keynote JavaScript adapter is loaded, it should check if the user is logged in. This means that it will check with Keynote and say, hey, is this user already logged in to 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 a username and password or a login form. And basically then the application then just displays the different blocks that I showed before depending of the user's authenticated or not. And the last piece is that 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 bearer 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 the application. So it basically looks like this. And I can invoke the public endpoint on the source 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 Keynote. We're not on the demo app anymore. So we know now that this login form is displayed by Keynote and not the application itself. So I log in and provide my username and credential and obviously here this is sent to the Keynote service so the application will never see the credentials of the user. And now I'm logged in and through the ID token the application can know some details about the user. So it knows that the username is Keynote. It also knows the first name and the last name and date of birth if you set these things for the user inside Keynote. And now not only can I invoke the public endpoint I can also invoke the secured endpoint because the service is able to see the access token and it pulls out details from the token and it sees, hey, this is a user that 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 Keynote and find that user and I'll grant it the admin role. So 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 Node.js application that we wrote or the source. The first thing it needs to do is to include the Keynote Node.js adapter and then it needs to initialize this adapter. It basically needs to tell the adapter where to store bits and pieces. And for this particular example, all it stores is the public keys from Keynote. So it caches these so it doesn't have to fetch these for every request. And then we can see that the public endpoint is just a standard endpoint. While the secured endpoint is now wrapped with this method called KeynoteProtect 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 realm to use and we need to tell it the URL of Keynote. And that is pretty much it. We can have a look at that source. 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 that doesn't send this along with the request. Okay, so the last thing I wanted 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 secure different languages. And also these are secured in different ways. So the Node.js service is secured with the Node.js adapter, the one that integrates really well with Node.js. While the PHP service 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 last I touched PHP. So this was the first time in 15 years that I've wrote PHP, but any who. 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 just says echo message admin. We have the public one, and we have the secured one. 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 in OpenShift for a few reasons. So number one, OpenShift 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 OpenShift and Kubernetes 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 OpenShift. I had that PHP application and it was already working on OpenShift but it was completely insecure. All I would have to do is that I would have to say to the service that's exposed by this deployment on OpenShift, I would have to change the pods. So the PHP application listens on 8080. So I would change that to a different port. And then I can see here that I have the container. This container would have been there before. This is my PHP application. So we can see it listens on port 8080. I would have just left that just as it is. I would not have modified that application anyway. And then I would have added this additional container to the pod, which is our generic adapter. And I give it a few configurations. So I say that the public endpoint should be whitelisted. That means that anyone can invoke it. And the secure endpoint should be protected with this user role. And finally, the admin endpoint 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 KeyClub is. 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 handling incoming requests. We can look at this. This is the PHP version. And it follows exactly the same API as the other one. So it says message public. And it gives us a 401 error when we don't have this bearer token. 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 it the URL of the PHP application and change that in the environment configuration for the deployment. And I save that and now OpenShift will go ahead and will 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, in the 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 was remaining logged in with KeyClock with a single sign on rel. So I'm automatically logged in again now after the application is redeployed. I can now invoke the public and the secured and the admin endpoints on that alternative version with the same means of securing it and the same end-to-end user authentication. Okay, so if you wanna learn more about KeyClock, join me on September 20th, where I'll be talking a bit more about what capabilities and features that KeyClock delivers. I'm gonna try to touch on as many features and capabilities I can in the 30 minutes available to me. So it's not gonna be a deep dive, but it's gonna be a good opportunity to learn about what KeyClock can do. Also go to our website. You can find documentation and downloads there. And obviously it's an open source project. So all the sources 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 use mini shift to run it locally. It should also be relatively easy to adapt it to run it on Kubernetes 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 wanna get in touch with us, reach out to us on the community mailing list. There's a link there. You can also find a link from the website. We also have a developer mailing list. If you wanna be contributing to KeyClock get in touch with us there. And finally you can reach out to me on Twitter or you can contact the KeyClock team on Twitter. That's it. So thanks. Birdie, we have any questions? We do have some questions. A bunch of good ones actually. And there's some actual chat where people have been answering questions and things of that nature. So one on the CAS. So a CAS server, so centralized authentication service. And then of course what looks like is not using the CAS protocol but either using OIDC or SAML. And the answer was if using SAML that's no problem should work fine with KeyClock. Does that sound right to you? Yeah, so we've chosen to not support additional protocols so that we can focus on OpenID Connect and SAML. Because each protocol will basically thin out what we can work on. Right. Is the generic adapter available now? No, it should be available in the next KeyClock release and that would be in three weeks. Failing that it will be available in six weeks in the following release. Okay, all right. And then why, an interesting question here. Why use port 9090 instead of 8080 when you're used in the demo? It doesn't matter. OpenShift takes the incoming request and port 80. So it just goes 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 port. Yeah, because one thing, one question that came in that 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 that now pops up on the login screen. And obviously, 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 feature, awesome capability. It's just going to say, I want social sign on, I want forgot password, I want registration. Now there's another question. Is there an adapter or plugin for an OpenShift router to add simple JWT validation before it hits the backend? 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, plugin for an OpenShift router. So, an OpenShift router, of course, is based on Azure Proxy. Yeah, so since, I'm probably not an adapter for it since I'm not following quite what the question is. Yeah, yeah, I've heard it before. Feel free to ask that one on the user mailing list. Right. Okay. And I can't find the OTP feature in Key Cloak. OTP feature in Key Cloak. It's an old-time request on forum. OTP, so one-time password. So that's against a good point. How are we doing on one-time password in Key Cloak? Yeah, we have support for standard OTP so basically both versions, so the counter-based one or the time-based one. And that is easy to implement as long as you have a mobile phone with the necessary application to generate the code. 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? Yeah, 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 capabilities. So basically Key Cloak can then federate users from different user stores and these can be ALDA for 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 DevNation Live or at least in September. And we're gonna basically come back and hit you guys one more time with 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 of links real quick. You saw them in the presentation deck, but make sure to check out these links here. I'll add them real quick onto the chat so you guys can see them and then we gotta finish up. Okay, there we go. Check out those links and feel free to check out Twitter. You can follow us there and follow the KeyClick project. Thank you guys all so much. Stian, thank you so much. Yeah, thank you for having me. All right, have a great day.