[openstack-dev] [Keystone] Groups, mappings, and tokens

Adam Young ayoung at redhat.com
Tue Dec 18 21:26:33 UTC 2012


One thing became clear to me during the meeting is that none of the 
mechanisms we have been talking about are going to be useful without 
extending the token mechanism.  Let me give you a brief overview, and 
you can tell me what you plan on doing.

With recent refactoring, the token generation moved into

https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L34 


This code process auth via: userid/password, tokens, or REMOTE_USER.

Unfortunately, the identity API authenticate method does too much: it 
authenticates the user and also returns the roles etc:  This makes it 
hard to reuse this code in conjunction with the token generation.  We 
probably need to first and foremost split the identity.authenticate 
method into two pieces, authN and authZ, and then we can make the authZ 
step common to both.

Mapping comes in at the authZ step.  The current logic for a scoped 
token is to enumerate the roles for a given user/tenant pairing.

What needs to happen is we need to use mapping and groups to generate 
the list of roles.

Since the mapping code is so close to implemented, I am OK if we try to 
push through and do groups on top of roles.  I think we still want to 
have a "group" web API, but I can see the argument that with mapping, we 
will be much more capable of mapping to complex LDAP structures.   
However, I am not sure if the mapping mechanism as specified will work 
if there is no implementation that the org_attributes can point to.

Am I correct in understanding that  the difference between the current 
group review request (https://review.openstack.org/#/c/18138/) and the 
Kent approach is how to assign groups to roles?


It is my understanding that, if we were to use  the Kent approach in 
conjunction with LDAP, we would still use groupOfNames for groups, and 
assign users to groups using the members attribute, but then the role 
assignments would be done via mapping.   In the case, the org_attribute 
would be the group, and the os_attribute would be the role for the tenant?

I think we need to lay out the python code necessary to:

1. assign the groups to a role for a tenant
2. create a scoped token where the user gets their roles from the group.

we can call the group "superadmins"  and the role "admin"   the tenant 
"default_tenant".



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121218/91e9311a/attachment.html>


More information about the OpenStack-dev mailing list