openstack team mailing list archive

[Adam Young <ayoung@xxxxxxxxxx>]

On 07/27/2012 12:50 AM, Ryan Lane wrote:
> > Not in Essex.  When we discussed the Domains blueprint,  one issue that I
> > brought up was nested groups/projects.  That would solve your problem.  It
> > is not currently being developed.
> Ok. I can deal with handling tens of thousands of tokens, but I need
> some way to ensure a user doesn't need to continuously authenticate
> when changing between projects. I'm totally fine saving a long-lived
> token that can be used for authentication, then re-authenticating with
> that token to receive other project tokens. This way the web interface can use
> the long-lived token on the user's behalf for authentication between projects.

You can use a token to get a token.  Look at the authenticate code in 
keystone/service.py

Have the user initially get a non-tenant specific token.  Pass that in 
the x-auth header to POST /tokens/ along with a tenantid  and you will 
get a new one scoped to the tenant


> I'm using the LDAP backend. I'm assuming I'm going to have to modify
> the authenticate method to handle this. Would doing this be enough to
> make this work, or will I need to patch more extensively for this solution?

Tokens are not stored in LDAP.  There are separate back ends for: 
identity, tokens, and service catalog.  LDAP is only wired up for 
Identity.  For Token, the default is KVS, which is in memory only. You 
probably want to use memcached or SQL for the token back end, otherwise 
a reboot of the keystone server will lose you all the tokens.
> I definitely want to solve this legitimately for folsom or grizzly as
> this completely breaks my use case (and likely the use case of most
> private cloud users).
>
> > Again, this is really a group nesting problem.  I am not sure if the domain
> > blueprint would help you out here:
> > https://review.openstack.org/#/c/8114/
> > https://blueprints.launchpad.net/keystone/+spec/keystone-domains
> > http://etherpad.openstack.org/keystone-domains
> I can likely live with adding/removing admins from groups. I'd prefer
> not to, but we require this to some extent right now anyway. I'd
> definitely like to resolve this by grizzly at least, though.
>
> - Ryan