Open Stack

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121214/862e71ee/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121214/862e71ee/attachment.bin>