← Back to team overview

openstack team mailing list archive

Re: [keystone] Multi-tenants per user, authentication tokens and global roles

 

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




Follow ups

References