[openstack-dev] [Keystone] LDAP support for groups
guang.yee at hp.com
Fri Dec 14 19:27:53 UTC 2012
What I meant was you should be able to stash both user and group in
roleOccupant. During token creation, we still need to resolve the groups to
find out the user roles anyway. Everything in LDAP is identified by DN and
you should know what you are dealing with by looking at its objectclasses.
From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
Sent: Friday, December 14, 2012 11:04 AM
To: OpenStack Development Mailing List
Cc: Yee, Guang
Subject: Re: [openstack-dev] [Keystone] LDAP support for groups
You could create separate branches of the LDAP tree for groups and
roles, and then use the orgRole OC for entries in both branches,
providing the client has the built in intelligence to know which branch
is the role branch and which branch is the group branch. Otherwise you
can mix groups and roles in the same branch if you use different OCs to
signify the two different types of entry ie. orgRole OC and gON OC.
But I dont see how you can mix groups and roles in the same branch and
use the same OC for both, as nothing can tell the difference between the
On 14/12/2012 18:43, Yee, Guang wrote:
> Having both in a single field should be fine. LDAP group members can be
> both users and groups (nested groups). At the end, you still need to
> walk the tree to resolve unique user membership anyway as token doesn't
> contain any group information.
> *From:*Adam Young [mailto:ayoung at redhat.com]
> *Sent:* Friday, December 14, 2012 10:04 AM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [Keystone] LDAP support for groups
> We are close to getting Groups done in the SQL back end, but we still
> need a schema for LDAP, and it is not super apparent how to close the
> gap on it.
> The schema for role assignment is:
> 1. #
> 2. olcObjectClasses: ( 184.108.40.206 NAME 'organizationalRole'
> 3. DESC 'RFC2256: an organizational role'
> 4. SUP top STRUCTURAL
> 5. MUST cn
> 6. MAY ( x121Address $ registeredAddress $ destinationIndicator $
> 7. preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier
> 8. telephoneNumber $ internationaliSDNNumber $
> 9. !
> 10. seeAlso $
> 12.roleOccupant $ preferredDeliveryMethod $ street $
> 13. postOfficeBox $ postalCode $ postalAddress $
> 14. physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
> And the users are in the roleOccupant field.
> We want to be able to make the roleOccupant included members of groups.
> But I am not sure that having both in a single field is advisable. I
> would rather have a deliberate fields for group members. This was what
> we did in FreeIPA, and I think it is the right approach.
> We could extend roleOccupant with an other object class, but there is no
> obvious class to use.
> We could replace roleOccupant with a different object class. While that
> would make a painful transition, it might be preferable. But again,
> there is no obvious replacement.
> We could make groups a collection underneath organizationalRoles
> Feedback is welcome.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6186 bytes
Desc: not available
More information about the OpenStack-dev