Re: [Openstack] [Keystone] Splitting the Identity Backend
Adam Young wrote: Currently, the Identity backend has Domains, Users , Groups, Roles, Role Assignments and Projects. I've proposed splitting it into 3 distinct pieces. Domain, Identity, and Projects. [...] I think it makes sense. The main blueprint for this is: https://blueprints.launchpad.net/keystone/+spec/split-identity with supporting blueprints for pieces that can be completed interdependently. If this is a project you intend to complete in the Havana cycle, it would be nice to propose the series goal to Havana and set target milestones for when you think that work would land. Cheers, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] Splitting the Identity Backend
Hi Adam I would propose splitting the backend into two conceptually distinct types of attributes, and then each of these high level types can be arbitrary split into different databases depending upon their sources of authority and who administers them. Your proposal would be just one specialisation of this more general model. The high level distinction I would make is between (read only) identity attributes and (writable) authorisation attributes. The latter are the ones used by the OpenStack services for making access control decisions, whilst the former are never used or seen by the OpenStack services, but are used by organisations to identify and group users into different sets. So HR databases and LDAP servers typically store these identity attributes. An attribute mapping function is needed to map between the former and the latter. We can then organise the user login function as follows: 1. A user logs in and is identified and authenticated, and a set of identity attributes are assigned to him by the authentication function. This could be from a read only LDAP service, or by a federated IDP. It should be pluggable and installation dependent. It could even be done by the user presenting an X.509 certificate and the information extracted from it. This part of Keystone should be highly flexible and adaptable to suit different deployment models. 2. The attribute mapping function maps from his identity attributes to his authz attributes. This can be a null mapping function if needed e.g. if the read only backend LDAP happens to store the users OpenStack projects and roles. But in most cases it will not be null. The mappings are set up by the Keystone administrator. 3. The users authz attributes are stored in his Keystone entry, which must be a writeable database owned by Keystone. Each time the user logins, his authz attributes will be updated to match his current identity attributes. So if an organisation promotes an employee, and changes his LDAP attributes, this could have the effect of automatically escalating his rights in Openstack. Conversely, if an employee is demoted, his rights in OpenStack could be automatically downgraded. It would all depend upon what the mapping rules were ie. whether they were fixed to a user's login ID (in which case his authz attributes would not change) or whether they depended upon his roles in his organisation (in which case they would automatically change). 4. The token is created based on his authz attributes as now, and everything continues as now. So taking the current mix of identity attributes that you identify below, they would be split as follows Domains, Roles, and Projects would be stored in Keystone's writeable database (as they are authz attributes) Groups and User Names (and Passwords) would be stored in the read only identity databases. Role assignments would be done by the attribute mapping function. If you want to split Domains into their own separate Keystone database, this fine, it does not effect the overall model. So, your proposal fits into this high level model, but this high level model provides much more flexibility to implementers and will allow for future expansion regards David On 20/05/2013 17:46, Adam Young wrote: Currently, the Identity backend has Domains, Users , Groups, Roles, Role Assignments and Projects. I've proposed splitting it into 3 distinct pieces. Domain, Identity, and Projects. Here is the rationale: Somewhere between a third and a half of the OpenStack deployments are using LDAP. However, the mapping from LDAP to Identity does not work. LDAP is almost always a read only datasource. While Keystone *can* manage these, it should also be possible to treat the users and groups piece as externally managed. In addition, several organizations have multiple LDAP servers. Not a huge number of servers, but more than one is a very common scenario due to a merger. Each of these should map to a domain. Thus, domain management has to be extracted out of the LDAP backend. Identity would contain users and groups. Projects would contain Projects, Roles, and Role Assignments. Domains would contain only domains. For people happily deploying SQL, nothing should change. A single Database instance can still serve all three backends. It should only mean removing some foreign key constraints. For people that are deploying the current LDAP code and are happy with the layout, we will continue to support the LDAP Project backend. Say an organization has two LDAP servers, and also maintains a public facing cloud backed by SQL. Each of the two LDAP servers would have configurations that correspond to the current layout, although limited only to the user and group subtrees. The domain registry would live in the SQL backend. It would have two entries for the LDAP servers, and these would be immutable. Dynamic domain allocation and deletion would work only for the
Re: [Openstack] [Keystone] Splitting the Identity Backend
OK, I think it makes sense. If we keep roles and role assignments in the same place, we don't have the ability to do more complex assignments. So the four backends would then be: Domains Identity (Users, groups) Assignments (could also be called mapping) Projects (Includes roles) Assuming that an existing user has a SQL Identity backend, it would work like this. Domains would be SQL only. The other pieces would be primarily SQL. An LDAP backend will get a variable name from paste. For each domain, the user can specify that any of the other pieces is supported by a specific LDAP backend. Otherwise, it will default to SQL. If an existing user is doing writable LDAP and wishes to contine, all they will gain is the SQL datastore with the domain data in it. This allows us to plug pam/sssd in as well. Those will be Identity only. On 05/21/2013 06:18 AM, David Chadwick wrote: Hi Adam I would propose splitting the backend into two conceptually distinct types of attributes, and then each of these high level types can be arbitrary split into different databases depending upon their sources of authority and who administers them. Your proposal would be just one specialisation of this more general model. The high level distinction I would make is between (read only) identity attributes and (writable) authorisation attributes. The latter are the ones used by the OpenStack services for making access control decisions, whilst the former are never used or seen by the OpenStack services, but are used by organisations to identify and group users into different sets. So HR databases and LDAP servers typically store these identity attributes. An attribute mapping function is needed to map between the former and the latter. We can then organise the user login function as follows: 1. A user logs in and is identified and authenticated, and a set of identity attributes are assigned to him by the authentication function. This could be from a read only LDAP service, or by a federated IDP. It should be pluggable and installation dependent. It could even be done by the user presenting an X.509 certificate and the information extracted from it. This part of Keystone should be highly flexible and adaptable to suit different deployment models. 2. The attribute mapping function maps from his identity attributes to his authz attributes. This can be a null mapping function if needed e.g. if the read only backend LDAP happens to store the users OpenStack projects and roles. But in most cases it will not be null. The mappings are set up by the Keystone administrator. 3. The users authz attributes are stored in his Keystone entry, which must be a writeable database owned by Keystone. Each time the user logins, his authz attributes will be updated to match his current identity attributes. So if an organisation promotes an employee, and changes his LDAP attributes, this could have the effect of automatically escalating his rights in Openstack. Conversely, if an employee is demoted, his rights in OpenStack could be automatically downgraded. It would all depend upon what the mapping rules were ie. whether they were fixed to a user's login ID (in which case his authz attributes would not change) or whether they depended upon his roles in his organisation (in which case they would automatically change). 4. The token is created based on his authz attributes as now, and everything continues as now. So taking the current mix of identity attributes that you identify below, they would be split as follows Domains, Roles, and Projects would be stored in Keystone's writeable database (as they are authz attributes) Groups and User Names (and Passwords) would be stored in the read only identity databases. Role assignments would be done by the attribute mapping function. If you want to split Domains into their own separate Keystone database, this fine, it does not effect the overall model. So, your proposal fits into this high level model, but this high level model provides much more flexibility to implementers and will allow for future expansion regards David On 20/05/2013 17:46, Adam Young wrote: Currently, the Identity backend has Domains, Users , Groups, Roles, Role Assignments and Projects. I've proposed splitting it into 3 distinct pieces. Domain, Identity, and Projects. Here is the rationale: Somewhere between a third and a half of the OpenStack deployments are using LDAP. However, the mapping from LDAP to Identity does not work. LDAP is almost always a read only datasource. While Keystone *can* manage these, it should also be possible to treat the users and groups piece as externally managed. In addition, several organizations have multiple LDAP servers. Not a huge number of servers, but more than one is a very common scenario due to a merger. Each of these should map to a domain. Thus, domain management has to be extracted out of the LDAP
[Openstack] [Keystone] Splitting the Identity Backend
Currently, the Identity backend has Domains, Users , Groups, Roles, Role Assignments and Projects. I've proposed splitting it into 3 distinct pieces. Domain, Identity, and Projects. Here is the rationale: Somewhere between a third and a half of the OpenStack deployments are using LDAP. However, the mapping from LDAP to Identity does not work. LDAP is almost always a read only datasource. While Keystone *can* manage these, it should also be possible to treat the users and groups piece as externally managed. In addition, several organizations have multiple LDAP servers. Not a huge number of servers, but more than one is a very common scenario due to a merger. Each of these should map to a domain. Thus, domain management has to be extracted out of the LDAP backend. Identity would contain users and groups. Projects would contain Projects, Roles, and Role Assignments. Domains would contain only domains. For people happily deploying SQL, nothing should change. A single Database instance can still serve all three backends. It should only mean removing some foreign key constraints. For people that are deploying the current LDAP code and are happy with the layout, we will continue to support the LDAP Project backend. Say an organization has two LDAP servers, and also maintains a public facing cloud backed by SQL. Each of the two LDAP servers would have configurations that correspond to the current layout, although limited only to the user and group subtrees. The domain registry would live in the SQL backend. It would have two entries for the LDAP servers, and these would be immutable. Dynamic domain allocation and deletion would work only for the domains backed by SQL. The main blueprint for this is: https://blueprints.launchpad.net/keystone/+spec/split-identity with supporting blueprints for pieces that can be completed interdependently. Comments welcome. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] Splitting the Identity Backend
Hello Adam, I have been waiting for a separation such as this. There is no way HP would allow us to muck with their LDAP servers other than read only. Mark -Original Message- From: Openstack [mailto:openstack-bounces+mark.m.miller=hp@lists.launchpad.net] On Behalf Of Adam Young Sent: Monday, May 20, 2013 9:47 AM To: openstack Subject: [Openstack] [Keystone] Splitting the Identity Backend Currently, the Identity backend has Domains, Users , Groups, Roles, Role Assignments and Projects. I've proposed splitting it into 3 distinct pieces. Domain, Identity, and Projects. Here is the rationale: Somewhere between a third and a half of the OpenStack deployments are using LDAP. However, the mapping from LDAP to Identity does not work. LDAP is almost always a read only datasource. While Keystone *can* manage these, it should also be possible to treat the users and groups piece as externally managed. In addition, several organizations have multiple LDAP servers. Not a huge number of servers, but more than one is a very common scenario due to a merger. Each of these should map to a domain. Thus, domain management has to be extracted out of the LDAP backend. Identity would contain users and groups. Projects would contain Projects, Roles, and Role Assignments. Domains would contain only domains. For people happily deploying SQL, nothing should change. A single Database instance can still serve all three backends. It should only mean removing some foreign key constraints. For people that are deploying the current LDAP code and are happy with the layout, we will continue to support the LDAP Project backend. Say an organization has two LDAP servers, and also maintains a public facing cloud backed by SQL. Each of the two LDAP servers would have configurations that correspond to the current layout, although limited only to the user and group subtrees. The domain registry would live in the SQL backend. It would have two entries for the LDAP servers, and these would be immutable. Dynamic domain allocation and deletion would work only for the domains backed by SQL. The main blueprint for this is: https://blueprints.launchpad.net/keystone/+spec/split-identity with supporting blueprints for pieces that can be completed interdependently. Comments welcome. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
