 Okay, so thank you everybody for coming. So my name is Vishakha Garwal, and I'm working as senior member technical staff at NEC. I'm a Keystone contributor. So unfortunately, my co-presenter, Sian and Lance weren't able to travel. So let's get started. So in this session, we'll talk about the basics of federation and identity federation, which helps us for the consumption of resources without managing separate identities. Though the concept of federation isn't new, but people often struggle to understand this. So we'll discuss this in detail. Starting with the overview. So we have what is federation? Why it is referred as federation? Then what are the needs to meet the federation in which we will be discussing the three phase model that a federation supports? Then we can see how we can achieve federation. We'll discuss a single sign-on authentication problem. Also we'll look for some of the terminologies that are mostly used in federation. I also came up with some use cases that company uses. They use this for the federated environment. Then we'll see how federation works with the keystone and the authentication flows in the keystone. And we will have a quick demonstration of federation in keystone. So until now, we can see the cloud ecosystem always consisting of hundreds of clouds, hundreds of independent heterogeneous clouds that are being supported by the private subjects and providing services to the clients. So these types of clouds does not support any type of federation. Nowadays many clouds have started using these services of another cloud. So here the idea is to not to think about the independent private environment, but to consider as a multi-intercloud scenario in which one cloud will be using these services of another cloud. Like the different clouds belonging to different domains can interact with each other and sharing and gaining access of the resources where they will be becoming users and service providers both at the same time. So why we refer this as federation? Like if we'll see in the political world, so if we first think about the federation, the very first thing that comes into our mind is the federated government. So that is a type of government that is also being made by a union of self-governing parties that is sharing the powers and making a central government. So the concept of federation from the political environment to the IT is kind of the same. So we can consider the federation and IT as one as a home cloud, another cloud as the foreign cloud. So home cloud is the cloud where the home cloud which isn't able to instantiate further or create virtual machines due to the saturation of its resources. And we can see the foreign cloud, the foreign cloud which will rent us the infrastructure, the storage or the computing capabilities to the home cloud. So in this diagram we can see that some of the virtual resources that are placed in the foreign cloud environment of the home cloud. So the foreign cloud has rented its resources to the home cloud. So what are the needs of the federation? The cloud environment should be scalable. Scalability means that our home cloud should be able to find out the right foreign cloud with the help of any discovery mechanisms. Or if the home cloud already knew the foreign cloud, then we don't have to use any discovering algorithm or mechanism. Second, we have interoperability. So in interoperability, a cloud should be able to join the federation without changing its security policies since it might be possible that every cloud using different security policies. So in this, a home cloud can also, it also can be said as interoperable if a home cloud is able to authenticate itself once. With every another cloud. Third is user level satisfaction. So this refers to the on-demand user request to have the good quality of service. Now, how we can achieve federation? So in this, we will discuss three phase model that a federated environment do. So first is the discovery. So in this phase, the discovery process lies like we use several discovery mechanisms or discovery algorithms in order to fetch all the clouds that are ready to provide their services. Second, we have matchmaking. So matchmaking involves the foreign cloud whose requirements matches in both terms of the available resources and supported authentication mechanisms. Then the third is authentication. So the authentication process basically involves some of exchanging the metadata in order for the clouds to trust each other. So the authentication phase can lead us to the problem of single sign-on. So if we'll see a distributed environment, we can have hundreds of clouds for which every cloud had to maintain hundreds of other credentials of every other cloud with whom they want to authenticate themselves. So this type of problem, authentication problem is referred as the single sign-on authentication problem where a cloud should be able to authenticate itself with the another cloud only once. So a technical solution to resolve this kind of problem is using a SAML protocol, which involves one cloud to be configured as IDP and another cloud to be configured as SP. In this model, we also exchange the authentication assertion in order for both the clouds to trust each other. So this is the terminology that I just said about the SAML protocol. So SAML protocol involves first the identity provider. So identity provider is the thing, is where our user exists, or we can say our identity exists. So in identity provider, it responds with the user attributes. So identity provider gives information to the service provider about the user attributes. Whatever the service provider we can say is configured, the another cloud is being configured to get the information. Then we have the service provider. So the service provider is the cloud which is providing services to our IDP, to the identity provider. Then we have SAML protocol. So this is the XML-based federation protocol where the authentication assertion, or we can say an XML sum data is being exchanged between our identity provider cloud and the service provider cloud so that they can trust each other. Then next we have one more protocol, OIDC, that is OpenID Connect. And it is a JSON-based federation protocol. So we'll discuss mostly more about the SAML protocol since it's mostly used in the other organizations and also it is a little difficult to tackle. So next we have a terminology that is assertion. So assertion is basically a statement that is being passed from identity provider to the service provider. That contains some information about the user. So the identity provider always sends the assertion that is encrypted and signed. So the Keystone is able to read that encryption and after reading that encryption, it can, it recreates the local users, also known as the shadow users, which we'll discuss further. So now we'll look what is Keystone federation. So identity federation is basically the ability to share identity information across multiple identity management systems. Like this is basically more helpful when an organization already has a primary source of identity and they does not want to create another set of credentials for the users in the cloud. So this is the one advantage. And another is also like Keystone can be used to connect multiple clouds together since we can use the Keystone of another cloud as our identity source. So Keystone supports basically two types of configuration models. First is Keystone as a service provider, where Keystone will be acting as the service provider, will be giving its services to any external identity provider or to any external identity source where the user exists. Then we have Keystone to Keystone. In this type of setup, one Keystone, one cloud with the one Keystone will act as our identity provider and another Keystone will act as the service provider. We can also configure both as service provider as well as the identity provider. So I came up with two use cases. One is the cloud busting scenario and also one use cases of hybrid cloud that is used by Huawei. So first is by the CERN. So CERN is a European organization everybody must be aware of and it's one of the largest and most respected centers for the scientific research. So CERN has basically many laboratories as well as universities. So it has its own user management system and federation identity helps CERNs to maintain such large authentication system easily and it also help the CERN has also bursted their workloads to the public clouds. Then second we have Huawei use case that it supports the federation identity using SAML same like the way we do in OpenStack. And in this ways the users can connect their any local authentication system whether the user exists in Windows, AD or private cloud. They can connect to the Huawei public cloud via federation without any data leakage. So this is a typical hybrid cloud scenario. Okay, so we'll discuss more about SAML profiles. So we have two types of SAML profiles. One is the WebSSO and second is the ECP. So it will talk in terms of Keystone. Keystone for now, Keystone works on the scenario of ECP but still slightly in a different moderated form. We are planning to support WebSSO in future. So WebSSO is basically where the user exists in the web browser and the request is always being initiated or the user existing in the web browser. So the user actually takes the help of web browser to interact with the identity provider as well as service provider. And the request is always initiated at the service provider side. And if we'll talk in terms of ECP. So ECP follows the same flow that WebSSOs see but the user does not have any kind of web browser. It interacts with the service provider and identity provider with the help of any SDK or CLI. And the request is initiated at the service provider side only. We'll see the authentication flow of WebSSO and Keystone using Federation. But as I told that Keystone follows the ECP but in a modified form. So we'll see the authentication flow for the same. So this is the authentication flow for WebSSO where the first user makes the request to the service provider and service provider since user does not exist in the service provider and service provider does not know the user. So service provider will redirect the request to the identity provider. The identity provider is where our user exists. So identity provider will first authenticate the user and it will generate the SAML response. So SAML response is the same encrypted signed containing some information about the user. And it will send the SAML response to the service provider. The service provider will take the SAML response which will make the service provider believe that the user is authenticated. And the service provider will take the SAML response and it will generate and it will then allow the user to use its services. So this is the WebSSO authentication flows. So we are discussing this just to show the comparison of WebSSO with the authentication flow that Keystone follows. Okay. So for Keystone, we have user agent identity provider, service provider and like in Keystone, first the user starts by authenticating with the identity provider. So like for trusting service provider and identity provider, Keystone follows one-sided trust relationship. For identity provider, so here identity provider does not fetch or does not take any requests directly from the service provider. Only the service provider will know our identity provider in such case. Whereas the user will be aware of both where is the service provider and where its identity provider is. So for our service provider to know our identity provider in Keystone, we generally have to do some basic configuration. So to configure a Keystone as an identity provider, we need to make some entries about our identity provider in the Keystone.con file. So we need to generate a column, SAML, whatever the protocol we are using and some parameters like IDP entity ID. So it's a unique ID that a user has to give to the identity provider. It can be a string, a unique string that a user has to provide to our IDP. Then we have IDP SSO endpoint, which is mostly used for web SSO. And since for now it's irrelevant in our case because Keystone does not support web SSO. Then we have certificate file and key file. These are basically the security files, the encryption, the keys that the IDP uses to encrypt the SAML assertion, which it sends to the service provider. The user has to create the metadata for IDP also and need to provide the metadata path of IDP in this parameter, IDP metadata path. So that was the configuration we did, the user did for the IDP. Then we have, then how the service provider will come to know about our identity provider. So here I am using Apache module Shiblet to configure, to use it as a service provider. The Apache module is the mode ship. Since the Apache is already configured with the Keystone configuration, but the mode ship still needs some, still need to look some entries into the Shiblet 2.xml file. So in that file, we need to do the entry for IDP, the remote ID that we just generated, the entity ID we generated in the previous slide. Then we have the entity ID of service provider. So user has to give a unique ID to our service provider also. Then here we need to mention the URL of identity provider then where the service provider will fetch the metadata about the IDP and will trust our identity provider. Okay, so in Keystone to Keystone workflow, the user first sends request to the identity provider. The IDP will authenticate the user and it will give a token to the user agent. And through that token, the user can request the SAML response with the identity provider. The SAML response will be generated and will be returned to the user. Okay, so for now on, so here we need to understand about the two concepts, the shadow users and mapping rules. So in the previous slide, we can see that the user exists only in the IDP. If the user does not exist in anywhere else, so Keystone cannot do anything other than providing it's an unscoped token. So to give the federated user some sort of authentication over the service provider, we first need to, the Keystone needs to recreate the user by reading the SAML assertion. So Keystone makes an entry in its local database about the user and after that, we need to map that user with any of the local group that already exists in the service provider to give some sort of authorization and authentication to that user in the service provider. Mapping rule is the file that we create to remote that federated user with the local user group or any local group or local user roles. So that the remote user can have the same roles to the user that we have mapped. So there is a sample file, mapping file. So we have a remote user and we have mapped that remote user to the group federated users that we have already created in our setup in the service provider. The remote user will have all the roles and authorization and authentication over the service provider that same as the roles of the federated users group. So we need to create this mapping file in order to give some roles to our federated user because this is what Keystone understands. So after this, the SAML response is being sent to the service provider. The service provider will create the shadow user. It will read the mapping file and according to that mapping file, it will give some authorization to the federated user and then it will authenticate it and it will give the user the token to access the services over it. So we can test our setup. So that was the very basic configuration I just shared. We have a lot of more configuration that we need to do which I'll share the link and I'll show the link where we can read more about the federation and the configuration that we need to do. And after the whole lot of configurations, we can see the CLI. So this is the CLI we can use over the identity provider and we can pass the, if the instance we created over the IDP with the name of Keystone SP, we can pass the service provider name and we can issue the token that for this service provider, we need to access the services. So we can have a quick demonstration. So how all of the configuration in Keystone with Horizon will look like. So we created a user on identity provider, giving some roles to the identity provider, giving some roles to the user on the identity provider, logging in the Horizon in the open stack with the user that we just created. So we can see on the right, on the side, okay, so we'll first check that this is our user created and then we can see the service providers listed with our identity provider and the user can successfully switch to the service provider. We can see the same name of the user is being created, that is shadow user and this user can now list down the networks or any services that he's been authorized to, if he can create instances over it. This is just a sample of how instance the federated user is creating over the service provider. So an instance has been created. So this is the URL where we can read more about the Keystone federation, federated identity, the types of the federations and all of the configuration that we need to do to have a federated environment with Keystone. That's it. Anybody with the questions? So a couple years ago I was implementing not the federated but Keystone but OpenID Connect with Keystone and one of the pain points was that we still needed to have the operators' rights to edit the policy to JSON file so that the mappings are properly set up from whatever is coming back from OpenID, XML, whatever, but that was before the policy API was introduced in Keystone. Have you worked with that and did you try to implement and integrate with the federated setup also to set up the actual roles and groups what can come from the IDP? I haven't set up such kind of the environment we just set but maybe we can have a brief over it and I can try that and we can have the solution or the roles you are talking about. Anybody else? Okay, thank you. Thank you all.