Open Stack

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