[openstack-dev] [kesytone][multidomain] - Time to leave LDAP backend?

Nathan Kinder nkinder at redhat.com
Tue Sep 9 04:25:02 UTC 2014



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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list