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

Reply via email to