 Hello, I'm Christy Nicola. I'm a software engineer with a mass open cloud at Boston University I'm also the Keystone PTL for the Victoria and Wallaby cycles This presentation is about improvements to federated identity in Keystone We'll talk about what identity federation is the specific the Keystone specific implementation approaches to authorization and limitations of each of these approaches improvements that we have done in the past few cycles Future work that we are targeting for the next cycles You probably are already familiar with a form of federated identity It is present in many of the major websites or Applications on your smartphone it allows you to authenticate to various services using your credentials Using your already existing credentials from a different service So what identity federation is is the ability to share identity information across multiple identity management systems A user I authenticate directly with the identity source rather than having multiple sense of credentials for each of the services That they're trying to access the most common protocols in use today are open ID connect and SAML some terminology about federated identity an Identity provider is the source of the identity information. It also authenticates and validates a user's identity a Service provider provides the requested resource that the user is requesting It is also the consumer of the identity information coming from the identity provider An assertion is the statement from the identity provider that contains the information About an authenticating user this assertion contains multiple attributes for example for the user's full name email address date of birth or other things that the Identity provider is releasing to the service provider in Keystone Federated identity is not handled directly from the Keystone service It is handled by an Apache authentication module this module parses the assertion coming from the identity provider and Forwards the user to Keystone alongside the different attributes that it has parsed This is then later processed by the mapping engine which translates these attributes Into attributes of a user which is then created and persisted in the Keystone database So upon authentication a new user is created in the Keystone database and In this example, we can see a form of a mapping Which translates translates the remote user attribute into the name of the user Mappings allow operators to do many things they allow They allow you to grant membership Temporarily grant membership to a group for an authenticating user They allow you to create a project and associate a role to the authenticating user They also can be managed can can also be used to restrict authentication To specific users based on a matching condition. For example, if a colleague of yours named John And you don't like to you wouldn't like him to have access to your cloud Then you can restrict authentication to all users matching John. Not that I would advise that so This is all nice when you're using a browser everything is implemented There is support but what happens when you're trying to to access Keystone and OpenStack from From a CLI or a Python or Java or go SDK You cannot access a browser. So you cannot Use the single sign-on flows that are common among identity providers There are some standards to allow you to authenticate to an identity provider through Either SAML ECP or the open ID connect Resource owner password credential grants, but they're not always enabled and you may not have control over the identity provider to enable them So this leaves you in a pickle Everything works great when a user uses a browser, but they cannot Write applications that make full use of the OpenStack API Around the Queen's cycle we implemented what are called application credentials This works similarly to our passwords in Google They allow you they allow a user to create a secret In Keystone and then use that secret to authenticate directly to Keystone rather than Go again through the external identity provider Permissions for this application credential can be limited to a specific API call or a specific role that a user has on the project and all application credentials are scoped to one project only and And They are also supported in Horizon so you can authenticate using a browser to your identity provider and Inside of Horizon you can create the application credentials for usage and This is pretty good for authentication, but what about authorization? So how do you? specify which users have access to which projects There are multiple ways to do this with federated identity in Keystone The first approach is to assign group membership through mappings. I Will talk a little more about that The second Method is to assign roles manually to the created user as we mentioned before every time a user Like every time a new user authenticates user A new user entity is created in the Keystone database and you can interact with that as if you were interacting with Normal user entities so you can add it to groups. You can add it to projects Another thing that a group mappings that a Federation mappings allow you to do is as we saw here before You can specify a project so Based on Based on the attributes of a user you can directly create a project for them and assign the roles automatically through To that project through the mappings This is not something that I'm going to Talk about in this presentation I'm mostly going to focus in the first two methods and for the third one. I would direct you to the open stock documentation So authorizing their groups so you have a situation where you have a group in the identity provider and this group is a Mapped to a group in Keystone, they may have a similar name or something like that and this group in Keystone is then assigned roles on a project so a user is assigned the group in the identity provider and Every time they authenticate into Keystone They are also assigned to the matching group in in Keystone And this group is what carries the role assignment for the user to access their projects This There are limitations to this first as you can see here you need to create the groups ahead of time So for each project you must have a different group and then you must assign a role to that group on that project and You need some tooling to keep this up to date so that every time a new project is created a new group is created as well So it's a it's not trivial and it requires some Some tooling on the side But one major limitation of this is that a group membership is only valid for the duration of the talk a token This is and it's not actually persisted in the database. So if a user Needs to create an application credential or a trust to be able to use The API or the CLI they would not be able to because They would not Actually be role assignments They would just be in the token and for the duration of of this token which can be 45 minutes so In a Suri we introduced the concept of expiring group memberships So every time a user Authenticates into Keystone and they are carrying a group which is matched and they're carrying a group from the identity provider Which is matched to a group in Keystone They are actually this membership is actually persisted in a database for a limited amount of time Which is configurable on a per IDP basis and every time the user Authenticates and they are again assigned the same group this This timer is refreshed so this now allows users to make use of application credentials and trusts which was not something that they could do before and Was a source of headache for many Many users of of Keystone so The other method which I mentioned was to just treat users as they are normal users So a user authenticates for the first time and Keystone creates a representation for the user in the database by the way this this representation of the user we call a shadow user and Then after that you just add the groups and roles To the user however, you can notice something here that a a first authentication is required so You cannot assign a user to a project if they have not authenticated previously so this really This really kills the user experience, especially for new users because now you need to go to the dashboard authenticate See an error because you do not have access to any project then you have to contact your administrator and ask them to add you to to the project which You are requesting so yes a shadow user is only created after initial authentication and You have the burden is a new to keep the role and group membership in sync rather than delegate them to a centralized identity provider To to solve the problem of the initial authentication We introduced the possibility to create and modify the federated attributes of a user in Keystone So now using the open stack API you can create a federated user before their initial authentication Rather than having them authenticate first see the error and then contact you afterwards And this is not only about creating but you can also update the federated user attributes You can delete the federated user attributes You can also assign multiple federated user attributes to a user in Keystone. So this works like linked accounts so Yes, so we talked about But the first two we're also investigating ways that we can extend the mappings and the mapping engine to be even more powerful and to Not only map users to projects but to also see ways that we can make that more dynamic and more extensible and I encourage all of you to join us in the open stock PTG for Discussions that we will be having about those topics the schedule is not out yet However, the PTG is held from the October from October 26th to the 30th and The keys the Keystone team will have a Meeting room either on zoom or or meet pad and we will be happy to receive your ideas and proposals and see if we can work something out together because this is an area where everyone goes and remits the wheel and It's good to have some some Some collaboration in place and see if we can all sort it together Thank you so much