openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #23831
[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.
Follow ups