[Openstack] Capture of the Keystone/LDAP Role discussion

Adam Young ayoung at redhat.com
Fri Feb 3 02:54:44 UTC 2012


Had a chat with some long time Identity Management developers.  They 
cautioned me against using organizationalRole as it is often abused in 
organizations and we might have conflicts..  However, it seems like 
using organizationalUnit for tenants is corrent, and very much in 
keeping with what happens is many hosting providers.

So I now suggest that tenants become objectType organizationalUnit and 
roles are done as groupOfNames within the tenants.


On 02/02/2012 03:54 PM, Adam Young wrote:
>> We still need some way to differentiate between roles and tenants,
>> otherwise subtree searches will cause problems.
>>
>> In nova we handled this by assigning the owner attribute on tenants,
>> but no owner on roles. This allowed tenants to be found via a search
>> like this:
>>
>>    (&(objectclass=groupofnames)(owner=*))
>>
>> Roles are then discovered by a search like this, using the tenant as 
>> a base:
>>
>>    (objectclass=groupofnames)
>>
>> Alternatively, we could add schema for roles and projects. It seems a
>> little overkill to add schema just to differentiate these for subtree
>> searches, though.
>
> I don't love this solution, as it is not really very self documenting, 
> and it would be easy enough for someone to mess it up.
>
>   objectClasses: ( 2.5.6.9 NAME 'groupOfNames'
>   SUP top
>   STRUCTURAL
>   MUST ( cn )
>   MAY ( member $
>         businessCategory $
>         seeAlso $
>         owner $
>         ou $
>         o $
>         description )
>
> Seems like what we really want is organizationalRole  from 
> http://www.ietf.org/rfc/rfc4519.txt
>
> 3.10.  'organizationalRole'
>
>    The 'organizationalRole' object class is the basis of an entry that
>    represents a job, function, or position in an organization.
>    (Source: X.521 [X.521])
>
>       ( 2.5.6.8 NAME 'organizationalRole'
>          SUP top
>          STRUCTURAL
>          MUST cn
>          MAY ( x121Address $ registeredAddress $ destinationIndicator $
>                preferredDeliveryMethod $ telexNumber $
>                teletexTerminalIdentifier $ telephoneNumber $
>                internationalISDNNumber $ facsimileTelephoneNumber $
>                seeAlso $ roleOccupant $ preferredDeliveryMethod $
>                street $ postOfficeBox $ postalCode $ postalAddress $
>                physicalDeliveryOfficeName $ ou $ st $ l $
>                description ) )
>
>
> With the users going in the  roleOccupant  field.  This is in  
> core.ldif  in the schema 





More information about the Openstack mailing list