 Hello. Thanks for coming to our lightning talk. My name is Elvin. I'm a software developer for IBM. I work on the Bluemix private cloud team. And here's Nithya. Hey, I'm Nithya. And I work with Elvin in the same Bluemix private cloud team. Today, we'll talk about Kiesel and Kiesel in Federation. We'll compare it to the other types of identity federation. The use case, how it works. We'll briefly talk about how to set it up in a high-level overview, how to use it. And then I'll demo the small blueprint I worked on to enable Kiesel and Kiesel in Federation on Horizon. So here we go. OK, so let's first compare Kiesel and Kiesel with the other two federations we worked in at IBM. So we worked with OpenID Connect and SAML. And for that, we used a third-party provider for identity management. So you bring your cloud and you want to federate with some other identity provider. But in the case of Keystone to Keystone, usually it's you have two OpenStack clouds, but you want to use one Keystone as your identity provider and another one as your service provider. So that's the difference. You don't bring a third-party identity provider into it. And also, the first two use WebSSO. But Keystone to Keystone uses SAML ECP in the back end, which Elvin will touch upon in a few minutes. So yeah, like I said, you have two OpenStack clouds, one Keystone A is your identity provider and Keystone B is your service provider. So identity providers where all your users will be stored, all the information will be stored. And the second OpenStack cloud will authenticate using the first Keystone. And it uses the same horizon. So it's just switching between them with a dropdown box. So now Elvin is going to explain how it works. So we have multiple Keystones. We designate one as the identity provider. That's where your users live. And the other Keystones as service providers, and we establish trust. And the way we authenticate these federated users is through the Keystone off-plugin. It uses SAML ECP in the background. So what the plugin does is it uses the users already, validated token, and gives it to the identity provider. And then that identity provider Keystone will give back in a SAML assertion. And then the off-plugin will then give that SAML assertion, which contains the attributes about that user, which contains the OpenStack attributes, and provide it to the service provider Keystone. And the service provider Keystone will look at these attributes since there's trust built up between the identity provider service provider. The service provider Keystone will trust that these attributes are correct because they're from the identity provider, and then authenticate the user based on that assertion. Now I'll talk about how it works on Horizon. So if you wanted to look up the blueprint, there it is. So it's not the same as Web SSO. You don't get redirected. The browser doesn't get redirected. What happens is in the back end, there's an off-plugin that Horizon uses, which uses SAML ECP. That's Enhanced Client or Proxy. So when you log in, Horizon initially connects to any provider Keystone, which is the normal authentication flow. But now we get a dropdown where we can switch between the Keystone providers. And so here's a little flow I made. So the user logs in the Horizon normal flow. Horizon goes to Keystone and gets the user info object. And in this user info object, we also get a list of service providers. And then we also get an unscope token. And this unscope token is kept in the user session. And so if there's a list of registered service providers that Keystone knows, what the user will see once authenticated is that user will be logged in and you'll see dropdowns. So that's what it looks like, that dropdown. And then once you click and try to switch the service providers, so Horizon will talk to Keystone, get that SAML assertion, provide that unscope token that we kept in the session, and then Keystone will give back that SAML assertion, give it to the service provider, and then based on what mapping we did on the service provider, we can be logged in in the service provider with a particular user. Well, we'll talk about the mappings later. And then the user is basically logged into Keystone B and can access whatever resources that Keystone B protects. All right. So I'll briefly talk about how we set this up. So I made, if someone wants to set up a vagrant leak, I made this GitHub little project. What it does is it sets up two dev stacks and sets up Keystone and Keystone Federation automatically. And then I'll talk about the basic steps. There's three basic steps. You set up Keystone A as an identity provider. Step two is set up Keystone B as a service provider. Step three is create mappings. So I'll go over it at a high level over here. So when you make Keystone a identity provider, you edit the identity provider variables in Keystone.conf, then you generate a metadata file, and then you set Keystone.conf to look at this metadata file. And then this metadata file contains metadata information about Keystone being a identity provider, which will be used by the service provider later on. And then you need to register a list of service providers using this command, Keystone. Step two is we set up Keystone B as a service provider. And with that, we use the help of Shibboleth. So we set up Shibboleth. It helps us do the SAML, help reduce SAML assertions. And then we configure Keystone. We set up a federated authentication method. We set up the remote ID. And then we tell Apache to protect that Keystone endpoint so that when a request, a SAML request, goes to the endpoint, it first goes to Shibboleth. Shibboleth understands the SAML assertion and then passes it to Keystone. And after that, we register the identity provider and with that command. No, I'll pass it to you first. So after we create the identity provider, you can create the groups and the projects like we usually do in Keystone. And then we have to create a mapping to know what permissions this user has and stuff like that. So we'll talk about how the mapping rules are created in a bit. But after you create the mapping, you have to create a protocol that ties all of this together. So the identity provider you created before, then you specify the protocol name and the mapping you just created. So to create a mapping, the SAML assertion will contain the attributes on the right. So the OpenStack user, the roles, project, user domain, and project domain. And mapping is similar to how we do it in other federations as well. But over here, since everything is stored in the first Keystone, the identity provider Keystone, usually it's stored as the username at vagrant service provider to differentiate them. So when you use the remote attribute OpenStack user, you'll have to use the username as this so then it can verify. And also there is no remote attributes for group, so that's something we should work on later. But yeah, this is how the mapping is created. OK, and then to use it, you can use a Keystone off plugin. There's a sample on the next page. Or you can use Horizon for Horizon. As long as you register the service providers on the Keystone, Horizon should dynamically get it back and you should see it. So there shouldn't be anything really you need to do for Horizon. And you can also use a CLI. I haven't confirmed it. I didn't confirm if there's a CLI used, but I think there is because there's a SAML ECP plugin for the OpenStack CLI. So this is the example code for the Keystone off plugin that I took from the documentation up there. So you pass it, a already authenticated plugin, and then you get an authenticated session. OK, so quick demo, quick demo, this big again. So this is the service provider. I'm just showing you the mapping. Here we have a user called another demo user. And then I'm going to switch to any provider and show you how it works by using this user. Here. So here I'm logging in as another demo user. Hold on, what's the password? And up here, here's the list of Keystone providers. The local Keystone, that's the identity provider Keystone. And Vagan Service Provider is the service provider Keystone. And then so I just click on it, and OK, there it works. And then as you can see in the mapping, now the user is another demo user. And this is that Vagan Service Writer, which we put in the mapping in here. So if the user doesn't have access based on the mapping, then it'll just say you can't log in failed. And that's the demo. Does anyone have any questions? But I think we're done. But we'll be in the back if you need questions. Thank you very much.