 If you have any additional messages, you can give feedback to the speakers via this form. The last slash is important. If you like the talk, otherwise it's blocked. So ignore that for non-good reviews. By me. I need to see the results and then I'll tell you whether you can press the submit button or not. Okay, the next speaker is Steven, who works as a developer evangelist with OpenShift. Thanks. Hi, everybody. This is me. I am not Steen Thorgensen, but I leave this up here because if you know, how many of you know Key Cloak or have seen Key Cloak or have seen the page? Just two people. So, good. I am Steen. No. I'm not Steen. One is the lead architect and the lead developer on Key Cloak and I gave this talk with him at Java 1. So I can talk at the high level for the developer experience. How many of you do authentication stuff for your day job? And like, yeah. So you people are not allowed to ask me the deep probing questions because I'll never be able to answer them. So I'm just level setting that for the deep probing, like how does all this ticket stuff go on and are you using this really whatever protocol you're using for your tickets? I'll say talk to Steen. Okay? So I gave that talk with him. I can talk through some of it, but not very deep. This is the slides or Google slides. So if you want to come back to them later, this is the URL for the slides. And I'll have that URL at the end so you can just copy it at the end. You think, oh, now it's kind of worth it. Okay? And this is where you can find me. It's at my Twitter handle, but the Steve Zero because I'm lead like that. That's where I'm everywhere. So the goal is pretty simple. Talk a little bit about microservices. How many of you have heard of microservices? How many of you are actually, keep those hands up because that means those are people who have actually might, you've heard of them. How many of people are actually using them? Keep your hand up if you're still using them. You've written an application that's in a microservices format. That was a quick hands up. Are you not sure that you're really using it or not? Okay, so then it seems like that's a pretty good percentage of the audience. You have permissions, if you get bored during my microservices piece, to check email. Not YouTube, because there's limited bandwidth, but you can check your email. I give you permission. Then we're going to talk a little bit about centralized authentication and then we're going to see it all in action. Okay? Sounds pretty reasonable for 40 minutes. That's more than 10 minutes of goal. So these are microservices. Everybody get the joke, microsushi, microserve. So if you thought that's a bad joke, you should probably leave now. Because it only gets worse from here. The reason I bring, does everybody know what this is? Does anybody want to explain what this is? Yes. That's even more specific than I needed. It's a battle map. A historical recreation of a battle map. You ready? This is where you're, oh, almost. And the reason why I bring this up is because I think a lot of us think microservices is something new. But really, it's really something new only in what we do with computers and how we've architected applications. If you think about what we do in our most normal life, almost everything is microservices like. So in the military, each of these symbols, the different looking symbols, is a different type of military unit. And if you think of football, the real version of football, do we make everybody have the exact same position? No, strikers do not have the same skills as goalies. But for some reason, in the evolution of programming, we have thought that everything has to be linked together and moved together and everybody has the same priority. So basically what ends up happening is, could you imagine if you were playing football, and the goalie, and the striker, and the defenders were all in the same position moving around in the field as a big group. And you couldn't move forward as a group unless the goalie could keep up. That would be foolishness, or you get beat all the time. And it's the same thing in military. So this is not a new concept, it's just actually new to what we do with computer programming. So has anybody seen this image before? This is from Martin Fowler's page. Martin Fowler, the Fowler. Wasn't he one of the GOF, the Gang of Four? I thought he was, maybe not. Anyway, doesn't matter, he's still got a page and he's got this picture up of microservices. For all those that didn't raise their hands for this is what I'm doing, you're not doing microservices now, this is what you're doing now. A monolithic application. And so you'll have all your, how many of you are Java developers? You don't have to be ashamed, this is supposed to be everybody. And it's a red hat, primarily a red hat show and we kind of have a whole middle, and this is the middleware track. Raise them proud. Okay, how many of you are Ruby developers? Yeah, whatever. Okay, and then how many of you are actually Python developers? Okay, my second favorite people. And then Pearl, how many of you are managers? I feel like there's like no hands going up here. So what are the rest of you do? Anyway. So... Bakery? Nice, good. I build Linux boxes, I make RPMs all the time. So this is the monolith, right? And so these are each, let's say we're doing an e-commerce application, because that's what everybody loves to talk about. And each one of these different symbols is a different part of your e-commerce application. So, checkout, shopping cart, browse, I don't remember, other pieces, oh, social media piece of it, right? And in a typical Java enterprise application specifically, and that's what Fowler usually dealt with, these would all be in one large ear or war file, right? And for those of you who are not doing microservices, these would usually ship how many times a year? Two, who said two? Who said one? Who said two? But that's a good guess, because that's actually usually what most big ears, because they're so big and there's so many teams that you're trying to integrate at once, that's how many are actually, that's how often you release, right? And if you miss one of those releases, you've been working on this feature for six months, but you can't get quite finished by the release date. How long do you have to wait until you can actually get your feature in? Another six months, right? So it's incredibly frustrating for people. The other thing is, what's the technology being used in this? What is it? Is it all the same or is it different? Same. And so how much fun is it getting different development teams to agree on a programming language? It's like making everybody use the same IDE, right? Which is like a religious war and you lose two developers because they're dead. So the same thing is happening in this monolith here. What happens with microservices is you take that application and you break each service into its own functional part. And it's running in, it can be its own server, it can be wherever you actually run it, but the key part is that it's not bundled up with the entire monolith, right? So this team, I'm going to make it up again. This is a social networking team, right? So the social networks come up all the time, they do integration with it. What do you think their release cadence is going to be? Fast. Good. Someone's picking up that I'm giving softballs here. So they're going to have a really, that's an American idiom, isn't it? What would that be in football if you're just giving little easy kicks? What's that called? Pass. No. Forget it. That probably doesn't translate. Forget it. I'm giving easy questions. No analogies. So these guys have a very fast cycle and they're probably using what language? Because they're integration with social media. Who, come on, node, right? The hipsters, or maybe Rust. Who's using Rust? Nobody's using Rust? You guys are all old school. Forget it. You guys are behind the times. All right. So this is Rust and it's releasing once every two weeks. This is the actual financial check out. Does the money transaction? What language do you think they're using? Cobalt. Who said cobalt? No. No. What's it going to be? Java. Java, right? And how often do you think they're going to change that? What's their release cycle going to be? Yeah, at best. Because once you get money working, you don't touch that stuff again, right? Like this works and you're not going to touch it. So what happens with microservices is these guys can pick the technology they want and they can have different release cycles. So when I talk to companies about why they're adopting microservices, there's all sorts of advantages, but one of the biggest ones I've heard from some of our customers is autonomy. That teams become responsible for everything about what they're doing. These people are also on call for the beepers. So when it goes down, you can't just point at the ops people and say it worked on our laptop. Then a future problem now. When this goes down, this team gets called. And so they get to choose the technology. They get to choose how their release cycles look, how they're doing everything. And all that happens between teams is you have contracts. This is the API and this is the payload I'm going to give you back. So my therapist taught me this one saying it is clear boundaries, infinite possibilities. So usually when humans fight, it's because they're unclear about whose responsibility it is for this thing. And with this, you have clear boundaries. This team is responsible for everything that happens with social media service. This team doesn't have to concern themselves with that at all. They can be quiet. And what they can do though is the clear boundary is that API contract. And so it gives the teams the freedom. And there's other cost-saving reasons and other things. But here's some of the key points of it. It's distributed services rather than a monolith. The best practice seems to be one functional area per service. So in the beginning of microservices, there was a lot of discussion. Do you guys know the REST API? You know that pattern. And have you ever heard of RESTafarians? So these are people who would be like, if you said, oh, I have a REST API. And they say, well, I studied Fielding's paper. And this is not following this exact protocol. And you're not doing REST. Those are RESTafarians. And so there were some microservice afarians when microservices first started who would say a microservice is one function call. That is a microservice. And most people said that's bullshit. Because there's no way I'm going to decompose everything into one functional call. So usually what seems to have been settled out is it's one functional area. This is a big one. There's no sneaky backdoors. Everything goes through APIs and messaging services. Because that maintains that clear boundary. Nobody gets to say, oh, let's just open a Corbett. We're both Java teams. Open a Corbett interface for me so I can make some remote RMI calls behind the scenes. No. Everybody goes through the same API. And then this is another really big message. There's no specific technology required with microservices. So you'll see talks that are like, you have to be doing Node.js in Mongo if you're doing microservices. Or if you're not doing Acca, you're an idiot for doing microservices. That's not true. That's somebody trying to sell you something and make you feel bad about yourself and it's not true. It's an architectural pattern, not a specific technology. So I have friends who've written microservices in Perl. They use Dancer. There was a couple of Perl hands. Is Dancer like a Perl framework for doing web applications? Thank you for giving a one-word answer. That is awesome. So they use Dancer and then they made microservices and then it was all in Perl and that's fine. So some other architectural patterns. So to show you some patterns. Oops, too far. This is a very basic microservice. So there's three different services. They're each talking to their own database and then they're going through some load balancer to talk to some client. And this is actually particularly a pattern that's used a lot in mobile applications because this connection is actually very expensive in terms of time. So you'll actually make... No, this is not used in mobile. Sorry. The load balancer is just shifting things around between the different services. This is more of a web application. And so sometimes they say you have to have your own DB per service and that's not true either. It's usually the pattern that's used but it's not required. Is this what most people are seeing with their own microservices? That sometimes you have your own DB and sometimes you don't? Okay, half of you raised your hands. At least one person, there's another scarf ready for being thrown, should say yes or no. Is that the pattern you're seeing? Yes. You get a scarf. Thank you. One word. That's like the easiest swag you've ever earned in your life. You didn't even have to talk to me at the booth. Okay. So this is a very simplistic microservice pattern. But it can get to be something like this. Where you have the same service, some as being proxied through one service and another place where you come in directly to the service. Do you understand how that's happening? They took away my big stick. So I can't point. Jorge, come down here. You're very tall. I'd like you to point for me. So the idea is you can mix and match these services, whatever makes sense for your application. Microservices doesn't mean all the services are exposed to the front end. Sometimes you'll have different services calling in with different patterns. Make sense? Okay. I think we're getting close to the end of the microservice part. The fun's not ending yet. So what you used to do is a monolith, especially for Java developers, where would you do all your authentication? What would handle all your authentication? We're going to sit here and wait until someone answers. You guys just didn't write code. You never wrote web apps. That's it? Yeah, that's what it was. Come on. Jorge, where would people do all their authentication in a web app in Java EE? In the application server. Is that so hard? You know, Jorge, I'll give you another here. There you go. So it's in the app server. So if I go back to this picture, which each one of these is an app server? Because they have to be able to be scaled up and down independently. So where am I going to do the authentication now? I can't use the same pattern that I had before. So for those of you who... Okay, if I could say it in check, I promise I would. But for those of you who actually are doing microservices now, is authentication one of the things that you hit up against right away? Like how do you handle authentication? Yes, thank you. It is one of these tricky things that most people don't talk about at the beginning of microservices that comes up and bites you. So I was writing a microservices app just so that I could talk somewhat intelligently about it, and this is why I discovered KeyClook, and this is why I'm going to give the developer experience talk. And then you're probably also using a distributed cache to handle session state. The new way you do it is you have an authentication service just like every other service in your microservice architecture. So just like you have a shopping cart service and just like you have a payment service and a browsing service, you have an authentication service, and it's independent of any other service that's there so you can scale it, everybody can talk to it, and it's shared. It should be distributed and fault-tolerant in the same way that in a microservices architecture you usually don't spin up one endpoint. It usually has multiple in case things fail in the cloud. You do the same thing with your service. It should be able to scale independently, I just said that again, and it should have a standard way to interact because the problem is if that team is writing in Node and another team is writing in Java, you can't use Java authentication with the Node server. You need some open standard that everybody agrees about. So how do I get my hands on this hotness? Have any of you heard of Stormpath? So Stormpath is a centralized authentication server. Another example is Auth0. Have you guys heard of Auth0? Stormpath and PingIdentity are the same, basically. Stormpath and PingIdentity are authentication servers as a service. You sign up, you make an account, and then they have an Auth service running off in the cloud somewhere and you just use it. Auth0, I think you install yourself, if I remember correctly, is that right? Steam is the one who said to use it. And then today what I'm going to show is an installable free and open source project from Red Hat called KeyClok, and it will be running on OpenShift, but OpenShift v2. Any questions so far? As you can tell, I kind of like when people ask me questions, and I promise to be nice. So if you have a question, A, I'm speaking in English, which is probably not your native language for most of you, so I'm assuming I'm going too fast. So if I talk too fast, please stop me, okay? Wait, what do you mean? Where do you live? Are you from Czech? Okay, you need a scarf. It's cold here. Okay, go ahead, give it to someone that you know. Go ahead. So the question was, can I put this authentication in the integration, like on an ESB, like in the integration layer? Is that what you mean? Are you sorry, you prefer? API management at that layer? I think that's kind of the, so you're saying something, like you have a whole bunch of APIs that have some product that manages authentication against the APIs? You can, and I think that's basically what we're going to do today, but the problem is how do you then get the user to authenticate against that on the webpage? Does your product handle the authentication on the webpage or in the client front end? If it does, then that's exactly what we're going to show today. Okay? Any other questions? No? Okay, so Key Cloak. So Key Cloak, you have a client, you authenticate to the, oh, you have a bunch of servers, there's the auth server, which is the Key Cloak server, or hey, I really need your height right now. No? Okay. So they have the auth server, which is the Key Cloak server, and then you have a bunch of services. These services register with the Key Cloak server, and what that means is they get a secrets file from the Key Cloak server. So there's a shared secret between the service and the Key Cloak server, right? And then what happens from there is, the user offs against the auth server, they get back a token, which they can then use against each of these services. That token can then be passed all the way along with any service that's registered with the Key Cloak server, and the roles and everything comes through it. So that's the basic idea about how this works. Everybody get that one? That makes sense? You didn't get it. What part? No, so you can say within Key Cloak, you have this concept of realms and realms are different applications. So everything within a realm can share a token, and then within there you can have a lot of different roles, and people can belong to multiple roles. So you would have to do it that way. You would give a person multiple roles or not have them have multiple roles when they authenticate in. Does that make sense? Yeah? Do you want to, you know what? Are you like, okay, good. It's like beware of Americans bearing scarves. Okay, any, oops, sorry. Any other questions? Yeah, go. Yeah, yeah, yeah, yeah. Very simplified view. You're one of those authentication guys. Shhh. Shhh. If I was Stean, then you could ask Stean all those questions. How many, most of you are developers in here, right? Yes. So I'm talking to my peeps. Let me sing you the song of my people. I don't want to know about tokens. Right? Yeah. Yes. Agreed. But actually all users can't, Key Cloak gives you the pieces to manage users both on the Key Cloak server, I'll talk about this in a bit, or on other authentication servers. Like you can manage them in a database, you can manage them in an active directory server, but it's a whole other area in and of itself. Yeah. But we can handle the authentication. Yeah. Because Key Kerberos is a much more, from a developer's perspective, what I would say is Kerberos is more complicated to use than this would be to use because there's client ends, this is using the OpenID authentication protocol. So it's very easy for you, you can find any OpenID connect provider and use that in your application. No. Next. Yeah. Talk to him afterwards because, but from an application developer's perspective, this is much easier than using Kerberos, especially if you're not into like low level pearl and you don't want to think about all that other stuff that does all that fancy math. That's what I would say. It is true. It is true. I've looked at using Kerberos and it made my head hurt and I ran away in two minutes and this was incredibly simple to me. So from a developer's perspective, this is much easier. So authentication, Key Cloak deals with authentication. It can actually safely store the passwords inside if you want to. It can actually also do two factor authentication out of the box. Do you know what I mean by two factor authentication? Half of you, not every, if you don't shake your heads, then I'm going to talk more. So nobody, not many people shook their heads. What it means is I can check a box and have any of you done that with your phone where you take a picture of a barcode and it starts generating a random number that you have to use. You check a box and Key Cloak and all your users will automatically get a barcode that they have to take a picture of and generate a random number. So I would recommend if you're going to actually handle off, yeah, just like that. If you're going to handle authentication on your machine where you want to store user names and passwords, I would highly recommend that you turn on two factor off. It has saved my Instagram, Facebook, and many other accounts multiple times. Yeah. So when I gave this talk in the fall with Stan, he said they did not support hardware tokens yet. So that's what you're asking, right? Like a hard, yeah, yeah. Last I heard they do not. Yeah. You can do both. I only know the part that is users authenticating and then that being propagated throughout your system. I can't talk much to the other part. Sorry. Any other question? Oh, that's two scarves. They said I could get rid of a lot of these, so I'm going to. Because I like to reward people for interacting. Even though English is your first language, you still get a scarf. Not you. You have an accent like I do. All right. A New York one. So you can also customize the flow of when people log in. Like you know how sometimes when you log into one site, they show you terms and conditions, and then they make you refill out all your information again, and then you're actually a user. You can customize those flows and it's single sign on. So it's one place the user can go in there and manage all their stuff. Protocols, it supports OpenID Connect, which is probably what most of you are going to use, except for some of the Java people, and you're using capital W web services and you have my sympathy, and then you're going to be using SAML. So SAML is for the capital W web services, and it can be a Kerberos SSO bridge. So if you like that kind of pain, have at it. So here, let me throw this to you. And the question was, can I actually... Well, I'm assuming most don't, because I didn't, and I'm not that smart. So I'll talk to people like me. There's a difference between OpenID and OAuth. All... And you can correct me if I get this wrong. So you're my kind of pseudostean. Can you pretend to be Norwegian or Swedish? Can you be Swedish for a bit? Thank you. Good. So Open... OAuth just says, yes, I am this... This user is who this user says they are. It's just I am... They're authenticated. OpenID actually says yes, they're authenticated, but can also pass in information actually about that user that can be passed around. Like, this is their first name. This is their email. This is the roles that they're supposed to have. OpenID... No, OAuth can't do that, right? And so the question was, can you just provide an OpenID provider and then move on to OAuth? Later. I'll show you. Like, turn on Google or Twitter for authentic... This is exactly... So... I need to give you another scarf for that. Do you have... Wait, I know, but do you have a significant other? Do you have a significant other? Like a partner? Do you have children? How about a dog? All right. So the reason I actually... What? I don't know. But back to... This is exactly why I started using key cloak. So you'll see this in a second when I demo, if I... I'm going to probably stop taking questions for a bit, but I wanted to turn on Twitter, Google, and Facebook authentication for my application, and I started looking at how to put all three of those on one page, and I started crying. And so what I... I saw the demo on key cloak, and I'll show you how easy it is to turn that stuff on in your application without having to write any front-end code. Okay? Clustering, it clusters. Screenshots of... Screenshots of the console. I'll show them in real life. So client adapters. So it actually ships with some libraries right out of the box if you want to adapt it. Java EE, Spring, JavaScript, Node.js, and mobile, native mobile, Android and iPhone. So these are the adapters you put into your application or that it knows how to talk to the server. It does all the nice work for you. Again, because it's OpenID Connect, you can actually find any OpenID Connect client library and use it against the server. And everybody here is using Linux, except for the people with the silver boxes. But you're running Fedora on those. Do we have a code of conduct policy here? Just kidding. I'm not going to pick on you. Most of my team uses Max. Most of my team does now. All right, more to come, so there's going to be more to problem. But again, you can use any resource provider that's out of the box. So this is the other really interesting thing about key cloak is the key cloak aimed to be the 80-20 solution out of the box. So 80% of the use cases should just be met by installing it and go. But when we gave this talk at Java One, someone said, I want to do eyeball recognition. I want to do an iris scan, and I want to key cloak handle iris recognition. And the answer is no. But they've done this thing, service provider interfaces, which I like to call in dumb people terms, as a plugin. So a lot of the places in key cloak are pluggable. And so what that means is your authentication is pluggable. So this one person could write an iris scanner, plug that mechanism into here, and whatever that information that's usually passed in from an eye scan can get processed against here, and then the person has been authenticated. So if you want to change any of these pieces and many more, you can actually just write your own interface to that, plug it in and go. Okay? And there's a community of them if you need others. You can theme it, and you'll see this in the demo. And this is the part that you asked about, about open identity brokering, and I'll show this in the demo as well. But it can also do user federation. So this active directory, notice what's interesting about that arrow. It goes both ways, exactly. So most solutions are, I'm going to take this and dump it into here. But I'm never going to go back this way. So if you're administrators, or you're an administrator running the Klee Coke server and you want to be able to do bi-directional work with active directory, you can. Some people will think that is heresy, but if you like that idea, you can. It also can be LDAP, or like Postgres, or any other RDMS. But you can actually send users back, and that whole... Yeah, it's like treating it like an LDAP server. Yeah, yes. I think it's... So, Dian doesn't like to talk about this, just for Java developers, which it's not, but it's written in Java. I don't know if you can write them in any JVM language. You might be able to write them in Jython or JRuby, but I don't know for sure. Any other questions? Because I want to get to the demo. Or do you like hearing me show slides so much that I should just keep going? So demo time. So I'm going to take a microservice with some different patterns, show how easily we add a key cloak, and then the whole microservice. It's very complicated. And it uses everybody's favorite game. I've got 10 minutes. Crap. What's everybody's famous game when you roll dice? No. Are you nerds or not? Dungeons and Dragons. Thank you. Dungeons and Dragons. So this is a... Do you know what Dungeons and Dragons is? Is this like an American thing? I think not. I think all nerds know Dungeons and Dragons. We all sat around in our junior high, being sad, playing Dungeons and Dragons with our friends. They were awesome. Anyway. So there's a player interface. There's an admin interface. They're both in HTML. You cannot log into this until you authenticate against the key cloak server. And then that actually... When you press a button here, it generates a Dungeons and Dragons character. For those people who did like Dungeons and Dragons, this is not following all the official rules, please. So if your wisdom is less than four, you can still be a cleric. And then that actually... Once that's generated, it actually pushes it into a Mongo database. And then the administrator can come in and look in that Mongo database and actually look at all the ones that have signed up. So that's our... So this page authenticates this service and this service do not ever talk to the user. They're just using tokens that are passed along. So go. Make a character. I think... Is it a server or is it a... That's one of the ones where Stean would know. But I didn't think Shibboleth was a server, is it? Okay, so the answer for those on the video, which I think is right there, key cloak is awesome. Shibboleth is tiny and puny. Is that good? Basically, Shibboleth is just for SAML. Thank you, sir. And key cloak has a lot more protocols and it's a lot more robust in what it handles. Is everybody going there to the page? How's it working for you? Can you sign in? I did that for you, Grant. Okay, let's go to the administrator console. So, here's the administrator console. Okay, fine. So I'm in. I'm going to go to key cloak and we're in the dra... Actually, can I make the smaller... Who's my age in the back with bad eyes? You, sir. You're pretty close to my age. Right there. Can you see that? Okay, keep telling me. Can you see it? We're good. Okay. So, this is the administrator console which is actually very easy for me to understand as a developer. We're in the realm of Dragon. So Dragon is just for these suite of applications. And here's the name. It's enabled so it's turned on. Oh, but can users register? No. So sad. Okay, not everybody at once because I need some people to save for like the Google authentication and the Twitter authentication. Okay, so did anybody signed up? Go back to the URL. Now you got excited and now you want to try it? You didn't trust me at first? No, you were just smarter than everybody else. You knew it was a setup. Okay, good. So are some people in now? Yeah. And can you generate a character? Nice. The rest of you can go home. No, so I don't... Thank you for not signing in. So, one of the key things was turning on that kind of authentication. Right? So here we go to identity providers. People on the video, please don't copy down these numbers. Here's the... How many have Twitter? How many of you have a Twitter account? How many of you have tweeted that this is the best talk that the Steve Zero has ever given? Thanks, Jorge. I'm not turning it on then. How many of you are Google users? That's about the same. That's a little bit more. So I'm going to turn on the Google one. So I say here, edit. We put in our client ID, our client secret that you get from the Google when you're defining an app. And I just say enabled. Five minutes. That's sad. It's a conspiracy. Save. It's saved. Go ahead and refresh that page and watch what happens on the right side. It should look something like... Where'd it go? There's now a Google provider. That's how easy it is for a developer to enable Google off. So what I would actually do in my application is I would turn this... I would turn any new user registration off except for this and Twitter. Because I don't want to handle people's passwords. Then I end up on Reddit as being this idiot who's given away everybody's passwords and now they know about their affairs and their love of Dungeons & Dragons. So that's how easy it is to turn on another service. And now, since a bunch of you have signed up, I can actually go in here and look at the users. Right? So who is... Who's Fly Bubic? I don't like you. You are no longer in my application. So that's how easy it is to get rid of somebody in there. The thing that happens with that, though, so he's not in there, if you delete a user, he can just reload the page and reauthentic make a new account again if he wants to. The smarter thing to do is... Now, I'm not going to... I'll have to have something good in my other hand. Who's Good Meric? Who's Good Meric? Is that really your name? Who's A-S-D-F-D-A-F-D? Who is that? Of course it is. Paranoid Security Guy. Okay, so what we can do with him is we can edit and we can say off. And once I save that, he's no longer enabled. So when he tries to come in, that account will be disabled. You have no longer... You can get your characters back. So that's how easy it is for me as a developer to manage users, which I find incredibly easy. There's other features that I could show, but I'm probably down to like two minutes, is that right? Or one minute, or I'm over? Is there a session after this one, or is there a break? That's it? Yeah, okay. Yeah, unfortunately. It is. There's a bunch of users in there. Here's the Federation. So if you wanted to add another provider, you can add LDAP or Kerberos here if you wanted to. This actually screwed my demos once because he added a half-broken LDAP provider and nobody could get in at all. Here's all the sessions. So I can... Here, there's 23 of you who actually have active sessions right now. Right? And who's Harry Potter? The boy who killed... Everybody's scared to tell me now. I shouldn't have done that. Who's Derpy? That's no good. Okay, show more. I need someone to come forward, please. Who's Pepe? This will give me great pleasure. So I can go to your session. Where's your sessions? I can actually... Oh, here's your sessions. Log you out. Right? So there's a bunch of other stuff in here that you could question we get a lot. And I don't know how to answer it all. You're going to have to help me answer part of this. But the part of the way this work is when you authenticate, and this is the last thing I'm going to end on, is back to this diagram. Right? If I go back to this one, the question I usually get a lot is every time I'm actually hitting one of these services, does it actually go back to the Key Cloak server? Right? Is this super, super duper chatty? Because that's what me and my developer had. I'm like, oh, well, I have a token. I have to keep making sure that token's good. If I authenticate, you get your token that says you are who you are. And then you get another token that's a renewal token. And so what that means is you have a token that's good for a certain amount of time. You can keep going. Suddenly, your token is no good anymore. And so what happens is it says, oh, I need a renewal. And then it'll go back to the Key Cloak server, get another token which is good for that amount of time, and you can keep using it. So this is a way, usually, you set your renewal token you set your renewal time to be short so that if somebody's doing something malicious you can kick them, when they go to renew again you can kick them out. But then you set the time that they're allowed to have their entire session open to be long. Right? Like a day or two days or whatever you want to send it to be. So I didn't get to show a lot of other, like there's email integration and all that other stuff and I'm out of time. So any, can I get one more question? One more? You're so nice. Do you need a scarf? New question, sorry. You got scarves. New question. Sorry? So the question, the statement was so I like Kerberos because it's a very similar idea. Yeah, the idea is the same. In my simplistic developer head, it's we're getting tokens and we're passing them around and we're doing stuff with tokens, which was originally built out in Kerberos. I think what's changed over time is this makes it a much easier to use, that pattern that was harder before to make nice libraries for you. Is that a good summary of that? Pretty much. Good enough for a developer. Out of time. Thank you everybody. Oh, and remember to show me your evaluations before you submit them. Just kidding. Are you next? Excellent. I don't have to read the room. You're doing the Archillian one with microservices, right? Good. What? Yeah, I'm still on. Hold on. Hi, hold on one second. You're the guy who offered to give the talk with me. Is that who? No? Okay, hold on. Ladies and gentlemen, please mute your mobile phones. Don't forget to give feedback. And the next presentation is by Aslak who is the