[openstack-dev] [Keystone] LDAP support for groups

Adam Young ayoung at redhat.com
Sat Dec 15 02:26:23 UTC 2012


For the sake of argument, let say the we do the following:

roles continue to be organizationalRoles underneath the projects (I am 
working really hard to drop the term tenant)
groups are groupOfNames

user assignment is done by adding the user dn to the roleOccupant 
attribute of the organizationalRole object.

Now we add the rule that group assignement is done in the same attribute.

Now, to determine the roles for a user/project, we need to:

iterate through all of the users of the orgRole.roleOcc attribute.
If the user is there, they have that role.

If there are any groups in there, we need to iterate through each of the 
groups to find out if the user is a member of that group. If they are, 
they have that role.

Does this sound right?

It seems to me that this is a lot of across the Wire LDAP calls, I 
suspect that there are LDAP controls to support it.


This would be the default approach.  I am not sure that it maps to how 
people are setting up their LDAP servers.  If it is not, what kind of 
flexibility do we need to build in?  Does this map at all to how AD 
forces the LDAP schema to look?


On 12/14/2012 02:39 PM, David Chadwick wrote:
> Yes you can do this, but you still have to define the group membership 
> somewhere. This was the point I was addressing. You have to have a 
> group object analogous to existing role objects, and the OC of the 
> group object should tell you it is a gON and not a role
>
> David
>
>
> On 14/12/2012 19:27, Yee, Guang wrote:
>> 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.
>>
>>
>> Guang
>>
>>
>> -----Original Message-----
>> 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
>> two.
>>
>> regards
>>
>> David
>>
>>
>> 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.
>>>
>>> Guang
>>>
>>> *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: ( 2.5.6.8 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 $
>> facsimileTelephoneNumber $
>>>
>>> 9.      !
>>>
>>> 10.  seeAlso $
>>>
>>> 11.
>>>
>>> 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
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>
> _______________________________________________
> 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