Open Stack

Sorry I am a little late to this thread.

" When we talk about Roles,  we mean the permissions a given user has in a
given tenant.  As such,  it is a three way relationship, and LDAP does not
handle those well."

Have we also consider services and global roles? There was security bug
regarding tenant role conflicts/overlaps.

https://bugs.launchpad.net/keystone/+bug/890411

How are they being handled in your LDAP design?



Guang



-----Original Message-----
From: openstack-bounces+guang.yee=hp.com at lists.launchpad.net
[mailto:openstack-bounces+guang.yee=hp.com at lists.launchpad.net] On Behalf Of
Adam Young
Sent: Thursday, February 02, 2012 12:55 PM
To: Ryan Lane; openstack at lists.launchpad.net
Subject: Re: [Openstack] Capture of the Keystone/LDAP Role discussion

On 02/02/2012 11:50 AM, Ryan Lane wrote:
>> Based on discussions with numerous people,  It seems that the subtree
>> approach (as done by nova deprecated)  is the norm.
>>
> It's a normal approach taken by a number of applications, yes. It's
> not a bad way to handle this, and we are already doing it in nova. The
> plus of doing it this way, rather than key-value pairs on users, is
> that when a tenant is deleted, all of the roles are deleted with it.
> Also, referential integrity plugins can remove userdns from tenants
> and roles when a user is deleted.
>
> It'll still be necessary for admins to remove users from roles when
> removed from tenants, and we can't depend on that, so we should handle
> that case.

I'll make sure that gets in.

>
>> What seems to vary the most amongst LDAP servers is not the schema,  but
the
>> method used to query for membership in nested groups.   In OpenLDAP,  the
>> syntax involves sets
>>
>> http://www.openldap.org/faq/data/cache/1133.html
>> http://www.openldap.org/faq/data/cache/1134.html
>>
>> Whereas in Active directory,  it involves  using
LDAP_MATCHING_RULE_IN_CHAIN
>> rule OID.
>>
>> In the 389 (Fedora) Directory Server as well as OpenLDAP it is also
possible
>> to use   the deference control in conjunction with the  memberof plugin.
>>
>>
>> However,  we might not need to query for nested group membership.  For
>> example, lets assume a tenant has 3 administrative roles:  user
management,
>> network management, VM management. In addition,  users that do not have
an
>> explicit admin role get read only access to the resources of that tenant.
>> So a user that has the right to manage networks for that tenant would
have
>> to appear in both the members list of that tenant as well as in the
>> networkMgmt role.  The first is provided for read only access, and the
>> second for the ability to modify the network.  It is a little redundant.
We
>> could perhaps put a constraint on the roles that they will only allow
users
>> that are listed in the general membership for that tenancy.
>>
> It shouldn't be necessary to do nested searching. When searching for
> tenant roles for a user, it should be enough to search for the user as
> a member of roles using the tenant as a base.
>
> Even if nested group searching is necessary, it's possible to do
> nested searching without support for it on the LDAP server side. A
> recursive search works here. memberOf is also a possibility, but it
> needs to be supported on the server side; also, some servers use
> memberOf, and some use isMemberOf, so we'd have to make that
> configurable.

>
> It's likely best to assume some server in use won't support plugins or
> extensions. We can discover capabilities from the server and use a
> more efficient method if it's available, while falling back to the
> less efficient method. Short-lived caches of the results can also
> alleviate performance problems due to inefficient queries.

Right.   First step is getting something to function, and then we can 
performance tune.
>
>> There was some talk about nesting tenancies for resellers.  This is
somewhat
>> different from nested group member ship, as entry in the lower level
tenant
>> should *not* provide access to all resources of the containing tenancy.
>> Permissions go the other way around:  if I am an admin of the container,
I
>> can manage elements of the contained.  It does mean that the Keystone
server
>> needs to be smart enough to check all of the levels of nesting from
lowest
>> to highest to see if a user has the appropriate role for the requested
>> operation.
>>
>> So,  to summarize:  Roles will be entites under tenants,  with a member
>> field that indicates the users that have that role.
>>
>>
> 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


>
> - Ryan


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp
-------------- 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/attachments/20120203/6b1805e1/attachment.bin>