Open Stack

On Tue, Sep 9, 2014 at 8:25 AM, Nathan Kinder <nkinder at redhat.com> wrote:

> 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.
>

Please don't consider LDAP assignment backend as and outcast. It is used
and we have use cases where it's the only way to go.

Some enterprises with strict security policies require all security-related
tasks to be done through AD, and project/roles assignment is one of them.
LDAP assignment backend is a right fit here.
Storing such info in AD provides additional benefit of providing not only
single management point, but also an enterprise-ready cross-datacenter
replication. (Galera or other MySQL replications arguably don't quite work
for this)
>From what I see, the only obstruction here is need for a custom LDAP schema
for AD (which doesn't fly with strict enterprise constraints). That can be
mitigated by using AD-native objectClass'es for projects and groups instead
of 'groupOfNames' and 'organizationalRole': 'organizationalUnit' and
'group'. These object can be managed by commonly used AD tools (not LDAP
editor), but require some changes in Keystone to work. We've hacked
together some patches to Keystone that should make it work and will propose
them in Kilo cycle.
Another missing feature is domains/hierarchical projects. It's not
impossible to implement this in LDAP backend, but we need someone to step
up here. With OUs it should be rather obvious how to store these in LDAP,
but we'll need some algorithmic support as well.

We shouldn't give up on LDAP backend. It's used by a lot of private clouds
and some public ones. The problem is that its users usually aren't ready to
make necessary changes to make it work and so have to bend their rules to
make existing backend work. Some of them already are giving back:
connection pooling has been implemented when one company faced performance
problems with constant connections creating and closing.

Let's keep our hopes up.

-- 

Kind regards, Yuriy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/8bb709eb/attachment-0001.html>