 All right, so Welcome everybody's thanks for being here My name is Alex Stelbach. I work in The open telecom cloud team at two systems as an architect. Oh Good afternoon. My name is Yue Fengpan. I'm senior cloud solutions architect at Huawei Okay, today we're gonna talk about Keystone and and and some L and how we put that all together and adapted and changed it to fulfill some requirements that Are not there a native keystone for some use cases that we have in the open telecom cloud first of all That talk should have been given by my colleague Stefan Eisenblatter who was unfortunately not able to join us here So I'm just standing in for him be able with me if I'm not 100% fit in everything, but I will try to to give as much insight as possible So first of all, we want to have a quick look at what some L is what keystone is That's just a very short recap everyone everyone should know then I'm going to talk about the use cases and challenges we see in the open telecom cloud and after that I will hand over to you Feng for the Implementation part. So first of all keystone and some Summer is just a security assertion markup language currently in version two to zero It's a standard to exchange authorization and authentication information between different security domains and The main point it provides is just it allows that a service provider can rely on authorities or on identities that are issued by a different Let's say authority which is which is called the identity provider So it's commonly used for web-based single sign-on scenarios and it's pretty easy to to administer So what happens with summer is the the user just tries to log in at the service provider, which is Keystone in the open telecom cloud in in our example The service provider then just gives back a redirection to the to the real identity provider So that the request is so to say forward the dare The external identity providers then doing the validation and locks the user on and returns an assertion tag That assertion tag is then again passed to the to the service provider again Which is keystone in our in our example and keystone then just grants you access Regarding your your rights that that you have in the in the environment so native keystone is well able to to Support some as a protocol But you can only configure a single identity provider per domain So it's not possible to To mix them up to use different ones and it needs to be configured by an administrator Which is sometimes not what you want to have in multi-tenant use cases and there's no API for all that federated token management configuring the identity provider as it has to be configured by the by the admin So we need an extension to support the requirements that we have which More than one identity provider and the ability to configure them on a on a tenant level That brings me right to the use cases that we have in an open telecom cloud basically we have to the first one is Rather easy It's just that we have Several customers which are all bound in there in their own keystone domain and every customer needs his own identity provider Which is pretty common for business customers. They want to integrate their cloud offering somewhere in their existing identity management That is something that could be configured with native keystone on an on the on the administrator level But for every new customer as a as a public cloud provider You would have to do that configuration manually, which is which is probably not what you want to do when you're trying to operate at scale and The second use case is even more complex It's where you have a customer with his own domain and inside of that domain. He uses different identity providers This is Simply not possible with with native keystone, so that's why we why we needed to do some extensions to keystone and to the API So once again that the challenges we see is first of all We do not want to have the administrator which is our operations team To do keystone configurations for every new identity provider that needs to be added because we get a new customer But we wanted to be configured through an API if on on on a tenant level second is That if you have Several regions in in in your open stack, which you will probably have if you if you scale it up to a certain level Then you still have only one single keystone service that might become a bottleneck And that is something we worked around by by introduction of a caching proxy for for keystone And of course as I mentioned we needed the ability to support more than one identity provider per keystone domain And that was just done by by patching and extending keystone So that's all for the introduction part and for the implementation part. I just hand over to you think Here you go Okay Thanks, Alex Now I will introduce our identity and the management access management service on open telecom cloud Okay First of all I will introduce our Service between the federated the keystone. Okay, this is the native keystone We just use horizon a patch server and the ship list or melon for several federal Identity Federation, but what we have done on open telecom cloud is that We used front-end We called I am front-end and we also use the cache proxy instead of ship list and all melon and We have a call service called Used the native keystone and we have some patch to the keystones so that we can Support more than one I taps for each tenant. Okay Okay, this is architecture of our service There are three models the first is Front-end front-end is provides Management authentication and account management at UIs and There are three compounds one I am console deployed at is deployed at Deliberated as delimited zooms and also eyes at the trust zooms so that it will be secreted and Second is a cached proxy cached proxy Just for roots and locally accessories the keystone call service which means that We will deploy one cached proxy for each regions and so that it will be accelerate quick case a keystone call service and The third one is our course call service. It includes also includes the keystone and Also a deep keystone database and also our Keystone patch and We also have an extension database Choose to store as to keep the additional information for the identity provider Okay From now on I will talk about what we have done with keystone and Samo. Okay. This is our call service and The native keystone also Is a with application and database here we use my circle as a back end database and deployed in active stand-by mode So usually If if user at the identity provider the information will be stored in the tables such as identity provider protocol mapping and so on so So what do we have done is that we? write a keystone patch and also create new tables for the additional information that Identity provider more identity provider will need so We create new tables such as extension Identity provider and so on and do not list all of the tables so that Take taking the advantage of the keystone extension support open telecom cloud will support up to 10 Identity providers For each tenant Okay, then next This is a workflow of how to create what we have done to create a new identity provider for a tenant First you just an adept Give the name you can yeah give the name as your wish And the second reduced and brought protocol currently we spot Samo protocol So this is a default Samo protocol here and The third step is to create mapping. Yeah mapping rules is which describes The permissions the groups and the permissions of open telecom cloud according to the user attributes from the identity provider, so If if you if you Configure the identity provider through the console we provide a default mapping rules here You can see remote a wide cloud and the name ID and For local we have a Virtual user We called Federation user it's a virtual the default virtual user with no other access but logging and the logout so It is helpful if you We start to Federated with open telecom cloud so with the default Mapping rule it will be convenience and easy to To trust each other, okay And the fourth step and this is our extension import metadata file Okay, I met you the file is Interface file that In the format of Support Samo protocol which contains public key binding end point and algorithm so The identity provider and the service provider keeps their private keys for corruption and They put the public key in the metadata file for the each other to yes to check the signature and so on so Here when in this interface when You use the interface although you the portal we will check the Format of the metadata file so that if it is not if it is Invalid and they will be an error so for easy troubleshooting so that It will be helpful for the customers then Okay, a new identity provider for tenants is created so Here we provide a login link For the users who want to do not a Different way to log into the open telecom cloud here you can see different from the if you use horizon and maybe and You use a job list at the login page and job list and select the the other identity provider and import your username password and Authenticate but here we provide a login link so that It is a different way and This end point information with Identity provider name protocol type and service Service URL so that it if you want to Visit the for example for Elastic server or elastic volume or you can add here and for the customers for the users it will be easy to access the Resources Okay, oh Okay, this is a process of federation authentication first the user attempts attempts to Access So several protect resources and so here our service I am service as a service provider Then we were here. We will try to find out as you know We support more than one identity providers for each tenant. So It is very important that we will try to find out Which identity provider and the metadata file is fit for this Access So here We do something as the keystone patch. We do the things to try to find out the correct right identity provider so that and and we will find out the binding and the point and reflect to the Okay, of course the binding and the point is is point to the identity provider Okay, then Then okay, we'd like to use the identity provider so Identity provider will validate the same request so if there is a node trust have built before this This request and the identity provider may be an error So we should build the chest Before we have do this visit so if the if the identity provider Validate the same request and it is success it will present Logging login form to the user so the user can import the user name passwords and or something else to Ostecate Choose the identity provider so and then the identity provider will validate the credentials and If this cassettes and it generate generate is a similar response Okay, then the user post the Samo response to the service provider here comes to Open telecom cloud Service so here Here we have to do something with the same old response Firstly, we should find out the Firstly we validate the same assertion first We have what we have done is that We just validate to the same old assertion once if the same if the same Samo assertion comes twice or more than twice and three or four times we will reject it so it is It is more secure than the already and then the original demo Okay, and we also will validate If it is because every same old assertion with a Samo response with a timestamp. We also will check if it is expired so if it is So if it is expired, we will we will also reject the same assertion so if the check if the Same assertion is valid then Of course, we go to the We try to we will try to use to a public key and to verify the signature and then comes up to the mapping rules and the mapping rules we will try to Mapping the attributes from the identity provider to our local groups and users Okay, and then Unscoped unscoped token and the project list will return and all user can with use the unscoped token and and the project name and to get a Sculpt token and also and if we use a console Then We will return will return to the protect resource to the user here a session is created for the users and and with the permissions with the right permissions here so that the user can operate and Visit and our console for the open stack resources so here This is the overall workflow of our Federation of authentications here with what we have done For the hardening is that the identity provide identity to provide a Discovery and also the same assertion check checking Of course what we have done to choose the workflow Okay, next Yeah, I'm sure how we delete identity provider for a tenant so and compared compared to the before to the To the before steps it will be simple just delete a mapping and delete the Protocol and delete to the ID IDP and this force these three steps use the native keystone APIs and the third one and delete the metadata file and this we have Write extension APIs to for the keystones of course then Okay, I I Want identity provider will be deleted from from this for for this tenant Okay, okay, yeah, as you have seen we have some We have some extension we have some extension APIs to keystones here one one for One for import a metadata file of the Add of a tenant and the one for or coring the content of the metadata file import imported by an Identity provider and the one for getting metadata content of our service so that It will be Convenient and easy for the users to create identity provider. So Here this is all about our I am called service so next I will talk about our Cached proxy so our cash proxy is just for use for roots and Accelerates Keystone services so The Cached proxy will deploy One cached proxy for one region and of course it includes several applications and Use the load balance and a database and we call the t-cache So that we can with help of the t-cache so we can help cash The essential credentials here and at the region so that they cannot they do not need to go to the cost a keystone service to get the information But there are some considerations that we have to we have to do first is that Secure cached Credential so which means that if we catch catch the the data so we should make sure that The catch the data will be secure. So here we make sure that Each region has its own certificate different which is different from the other regions and We also make sure that The data cached the data cached is also Under it corrupt she of course so that it will be secure and then Limited limit scope so So as our Open telecom cloud has many regions and available zones so that We just catch or we just catch the local regions so means that if the region one and also a region one Catch the proxy in region one, so it's only catch the info for just a region one not know for the other regions and Also, no sensitive data will be kept in the proxies Okay, and third it expiration so Which means that each catch catch the data with a time stamp and If it reaches the expiration as the data will be deleted automatically and also We have effective and reliable mechanism to make sure that the data Between the cached proxy and the code and the core keystone service is consistent so We have we have a mechanism that We will detect the dirty data so that if this appears we will delete delete the dirty dates and And so on so This will be helpful Here next I'm sure it's a sample of how how our Cached proxy works of course when Try to visit visit a resource for example then the API goes through the API gateway and to the cached Cached proxy so if it is fine that the data as a credential maybe something has cached here and It will be returned without going to the keystone core service. So and it's a well more efficient and On the hot on the other hand in region two If the user I try to access. Yeah first time to access the resources then Also goes through goes through the API gateway and Okay, also go to the cached proxy, but the cache proxy and find that oh no not nothing cached so it will go directly to the core service to the course service or of course keystone and get the credentials or the information they need and Returned so meanwhile If the data is not is not sensitive and of course the data is this region and The data will will kept will kept in our cache cached proxy so that next time the same way it it will be Like the left that left picture so This is how the cached proxy works and then This is all about our cached proxy Next I will talk about our front end our console so currently we support two ways to config to add or delete or config Fed identity provider one is through console and The other way is through API's So if you want to use API's you should use enhanced client or proxy which called EZP But it is convenient we if we use Portals so on our Websites or on our console we can create delete edit query and identity provider and also Download upload the metadata file and Also, we can do Create delete edit query the mapping rules Okay, okay here We can see our Console so here we can if you click create an identity provider So a new identity provider will will generate so here With the with the help we take advantage of the our keystone Extensions here we can support 10 identity providers for each tenant In the future tenants Can apply for more quotas on demand so but perhaps they have to pay more Okay, and Here Of course our portal we can see the The end point we have mentioned so that Users can use the login link and just log into our open telecom cloud and then and we also have a Button that we can upload or download the metadata file cause and we also Can yeah create and or edit the mapping rules Of course and what we have done to the mapping rules is that We have a visible console and to help the users If you know the mapping rules that it will it is complicated it's very Complicated for the beginners so here We provide Visible consoles that helps the users to create To edit out to create the mapping rules. So here we can see okay. Okay. We have a job list to that I'm sorry Of course job list for the user group you have created and then The edge builds the edge builds the also a job list for for the ideal For the ideal specifications or the also usually also the or RG specifications and also we can Select the Conditions here and there's a visual then if we click okay create then it Will transfer into the JSON format so here It is Easy for the users to use our console to generate the mapping rules here the user so the remote user with edge builds about ideal person principle name and With a visual of CC CC then match to look our local Group CC test. So and with a display name of this This name. Okay Okay, this is all About our front end and next we will talk about our security for identity federation so So We have to first we have to prevent some risks and then Forex if the then for the for links, of course So I will lead I will list some what we have done, but not all of this just for security, of course just Some what we have done also about Samo assertion harmony I have mentioned that of course way the summer assertion almost Just validate once if the if the same assertion come to twice Oh and oh more than three times it will be rejected and also with the time step to Check the expiration and we also have the Enterprise and enterprise level security management, which means we have Permissions and access security From different use groups and users Also, and Of course, we have a cloud service called the cloud chase cloud chase this service will Record all the will record all the information which Such as federated the user log in log out and Any actions they have done to our cloud services. So Anything that the federated users It down will be recorded at this service. So the administrator Can check also audit Actions so federated users have to have done Okay Okay, then next I will show you a live demo for Federated other do it. I'm sorry The German German research network, okay, perfect Federated with open telecom cloud Dfm Okay Okay, I'm I'm prepared something So we seem to be not as lucky with the demo gods as the keynotes have been but that had that had to happen sometime Okay, okay, it's still not on the screen. Oh Yeah, okay, okay. Okay. This is our portal of course open telecom cloud so here we select the projects and of course our services and There are another a lot of services we have provided and Identity and access management service Also, first we create a user group for the identity Federation here we call Here we call the siblings at the main. So this is a project here and we just Have the rights of IMS and I'm the server and the main street so that and then we create Here we have You can see we have went one tenant for 10 identity providers so D4 for the Dfm we have created here and We can see This is a login link for the Dfm and The metadata file and also This is Yeah, edit This is a mapping rules. We can see we here. We use a wild card here and the match to our local group Sheblist show list and the main and the user of course use the user ID and At Dfm so So I'm sure if we use this login link try to Direct, okay here, okay, it will Delay delact to the Dfm portal here. This is a German research network. So here we can Import our username of course just a test Okay, and username Well password sort of okay success. I then you can see that The user from the Dfm have logged in here. Oh This is a long ID very long so This is the name the federated username and I think I have sure that This is ID and at Dfm. So We have gave the right to the project here at your D. I think we're running out of time. So Maybe we have just One or two minutes for questions. So if you have a question, please step up to the microphone So that it's also on the recording You said that you had to add additional Verification of the SAML assertion Beyond what's currently in Keystone? Why was that necessary and what are you additionally validating? So So you means that our summer so what do we have done to the summer assertion? We So we use So we do not use as we have shown we do not use the ship list or melon for the same assertion so we have right a Model so that we can Do everything we can so sorry So we have a right a model so that we can process Several assertions as we wish so So we can We can decide how the thermos assertion will be accepted just for once or twice or and then so on I'm afraid. I'm not sure if it's Nice work. The question I have is you did some extension enhancements to Keystone. Did you Feed them back into the community Keystone version so that the broader community can actually look at this and benefit from your from your great work Currently we have not okay puts the put the Keystone Keystone patch to the community because It is We have first of all we have a lot we have more works to do for the patch and also This is our Difference from the community version. This is our Community version is for this is our Advantage special advantage, of course for open telecom cloud My name is Rodrigo Hi, it's on core and one of the stuff that I work at upstream is Federation and I Have a doubt why you would need multiple IDP spare domain and When you act as a public cloud provider one possible use case might be a reseller one where you just Resell part of your capacity to a sub provider that then again needs to have Maybe multiple IDPs in that single domain that he is responsible for Okay, so this is probably something that that is that is really special for a foreign open stack based public cloud okay, so You are welcome to give it back to the community. I'll be really interested in in talk to you and maybe raise your use cases to the team so Okay This is actually interesting because you are not the first person that complains about this one-on-one Mapping between IDPs and domains. So I'll bring this up. Thank you. Yeah, okay Great. So if there are no further questions, then thanks for having us enjoy the rest of the summit Have a nice day. Okay. Thank you