On 09/01/2014 01:43 AM, Marcos Fermin Lobo wrote: > Hi all, > > > > I found two functionalities for keystone that could be against each other. > > > > Multi-domain feature (This functionality is new in Juno.) > > --------------------------- > > Link: > http://docs.openstack.org/developer/keystone/configuration.html#domain-specific-drivers > > > Keystone supports the option to specify identity driver configurations > on a domain by domain basis, allowing, for example, a specific domain to > have its own LDAP or SQL server. So, we can use different backends for > different domains. But, as Henry Nash said “it has not been validated > with multiple SQL drivers” > https://bugs.launchpad.net/keystone/+bug/1362181/comments/2 > > > > Hierarchical Multitenancy > > -------------------------------- > > Link: > https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy > > This is nested projects feature but, only for SQL, not LDAP. > > > > So, if you are using LDAP and you want “nested projects” feature, you > should to migrate from LDAP to SQL but, I you want to get multi-domain > feature too you can’t use 2 SQL backends (you need at least one LDAP > backend) because is not validated for multiple SQL drivers… > > > > Maybe I’m losing something, please, correct me if I’m wrong. > > > > Here my questions: > > > > - If I want Multi-domain and Hierarchical Multitenancy > features, which are my options? What should I do (migrate or not migrate > to SQL)? > > - Is LDAP going to deprecated soon?
I think you need to keep in mind that there are two separate backends that support LDAP: identity and assignment. >From everyone I have talked to on the Keystone team, SQL is preferred for the assignment backend. Storing assignment information in LDAP seems to be a non-standard use case. For the identity backend, LDAP is preferred. Many people have users and groups already in an LDAP server, and Keystone should be able to take advantage of those existing users and credentials for centralized authentication. In addition, every LDAP server I know have has better security features than the SQL identity backend offers, such as password policies and account lockout. The multiple domain support for multiple LDAP servers was really designed to allow for separate groups of users from separate identity LDAP servers to be usable in a single Keystone instance. Given that the Keystone team considers SQL as the preferred assignment backend, the hierarchical project blueprint was targeted against it. The idea is that you would use LDAP server(s) for your users and have hierarchical projects in SQL. My personal feeling is that the LDAP assignment backend should ultimately be deprecated. I don't think the LDAP assignment backend really offers any benefit of SQL, and you have to define some non-standard LDAP schema to represent projects, roles, etc., or you end up trying to shoehorn the data into standard LDAP schema that was really meant for something else. It would be interesting to create a poll like Morgan did for the Keystone token format to see how widely the LDAP assignments backend is. Even more interesting would be to know the reasons why people are using it over SQL. Thanks, -NGK > > > > Thanks. > > > > Cheers, > > Marcos. > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
