 Hi again, Red Hat developers. This is Jason with the Red Hat Developers Program here at Summit 2017 in the DevZone. Today, we have Thomas Kvarnstrom here from Red Hat. He's going to be showing us how we can secure microservices using JWT and the Red Hat SSO. Thanks, Thomas. So, oh, I was loud. Sorry about that. So we are, like I mentioned, we're going to talk today about how to secure your microservices using JSON web tokens. And so, if you haven't heard about JSON web tokens, you have probably not worked with security for a while. It's the new hot thing regarding security and how we secure different services. But it's actually a JSON-based open standard. And it's very similar to another security standard called SAML. But SAML is XML-based, and this is JSON-based, of course, hence the name, which also makes it less verbose. There's less network traffic having to go to actually secure your services. That's one of the reasons it's being used for big internet or scale type of solutions. But another reason is also because it's very easy to use it, to authenticate APIs and do things like that. So that's what we're going to talk a bit about today. And the other thing we're going to talk about is Key Cloak, which is an open source project, and upstreams project. And we also have a product, downstreams product, from that called Red Hat SSO, which stands for Red Hat Single Sign-On. And Key Cloak is a community project for open source identity and access management. And it supports JWT. So to explain a little bit about what's new with JWT and what we've been doing in the microservice, sorry, in Java development regarding authentication, a typical free tier application might look like this. So we have a web tier. We have a business logic tier. We have a data tier. So when somebody comes in, they authenticate through the web tier. And that will trigger an HTTP session for us. And that's where we'll store all the credentials. And that credentials is then passed through the different layers. But the credentials could check with an external source, like an held-up source, or for user credentials. But it's passed through the different layers, depending to give you whether you're allowed to have access to different certain things. So that was, for example, in the IEB, you could annotate an IEB saying, roles allowed to execute that. So in that case, that's exactly how it worked. But in the microservices world, things are changing. So in the microservices world, it's not as typical anymore to have a web front end. And instead, we could have an HTML5 application, meaning we'll load the application once, and then we talk directly to different services. We could talk through gateways and other things, et cetera. And that means that we all of a sudden, we can't rely on passing security tokens between layers internally in an application server anymore. So in this case, that's why JSON web token became so popular, because JSON web tokens allows us to share tokens between this instead. So I'm going to show a bit on how that looks like. So the auth process, I'm going to simplify it, but basically it looks like this. Somebody will access the first step to securing microservices is to authenticate the user. And it's done by authenticating through the key cloak server. So when the user is authenticated through the key cloak server, they will get a token back. So that token can then be passed on to other services. So we're going to talk more about exactly how that looks like and see a demo in a minute. But just to give you an example here, so one thing that we do provide in Key Cloak is the JavaScript adapter. So you don't really have to care about how that's handling. All you have to do is that if you use the JavaScript library that Key Cloak provides, it will automatically authenticate the user when they log in and provide the credentials. And then it will pass the token when we access other services down the road. So when we secure the services themselves, we then want to have a way to verify the token. So each service will verify the token with the Key Cloak server. That's how SSL works. And what we do here is we have different adapters in Key Cloak. We have one for native Java applications. We have one for Java EE, one for Tomcat, one for Spring Boot, one for Wi-Fi Swarm, one for Node.js. And we have client-side JavaScript, et cetera. The list goes on and on. So we have basically really nice and easy plug-in adapters that you can plug into your services and get the possibility to verify tokens from users. So let's see how this looks like in action. So I'm going to step out. So here I have a very simple REST application within inWi-Fi Swarm. So I started Wi-Fi Swarm here. And what it does is it's basically returning a list of products. So it's a product catalog type of service. So I can use something called Postman here. And I can, using no authentication, there's no headers in here with authentication here. I do have an authentication, but actually, that's delete that one. It's delete all the content in here. So we make sure that we don't have that. It's not checked here. But what happens is that if I hit this service, it's going to give me a product list back. So that's an unsecured execution of a service. So how does it look when we secure this then? Well, the first thing is we have, in Wi-Fi Swarm, we have some called fractions. There's also auto-detection of fractions. It's very simple to do this. Basically, all I've done is I added in the POM file, I added a reference dependency to the Key Cloak project here. The next thing I've done is I've sheeted a bit and I've pre-configured some Wi-Fi Swarm settings here. So basically, what I've done here is I've set in configuring that our catalog var is getting deployed. It's going to have the security constraints that everything that hits API and I get requires role user. And then I have a bit of metadata around how the server can verify the token to the Key Cloak server here. So changing this and saving the files, we can restart our Wi-Fi Swarm. So we're waiting for it to start just. It's not long now. So here we go. Wi-Fi Swarm is ready. So now, let's try to hit this URL. If I do that, you now can now see maybe a bit I'm unauthorized. So I'm not allowed to hit this endpoint anymore. So how do you do that? So I'm going to fake being a JavaScript client or being a client on that. I'm going to do a restful post query to the Key Cloak server and ask for an authentication process. I'm going to pass in a couple of things in here. So let's see if I can. Oh, here we go. So I'm going to pass in what grant type I'm going to use. I'm going to use password, clear text password here, our client ID. And then I have the username and the password. So that's my username and password. So if I hit the server with this, I get a J some web token back. And from here, basically what happens on the client side is that we take the access token here, which is the interesting part. And we put that into, for example, a header. This could be a part of a cookie. It could be part of a post parameter or query parameter. But the easiest one is to use it as a header. And this is how most libraries are using JSON web tokens. And it adds this token in here. So now, if I hit send, hopefully we're going to see our product list again. So we now authenticated against the services. And we can also use this from service to service communication. It's just as easy to take this token and pass it along in a restful service space. So it's very easy to do that. So that's why JSON web token is becoming more and more popular and also becoming more and more de facto standards for microservices security. So to summarize, key cloak and red dot SSO provides open source identity and access management using SAML or OpenID. OpenID is a broader standard than just JSON web token. But underneath it's using JSON web token. And using key cloak or red dot SSO, it's very easy to secure your services. There's multiple adapters for different programming languages. And it's very easy to pass this token around. Either you use a library for that or you do it yourself. So that's all for me. And I want to thank you for attending.