[openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

heckj heckj at mac.com
Fri Oct 19 20:51:16 UTC 2012


The topic of what a token can or can't represent for the upcoming V3 Keystone API  came up - and I wanted to share the conversation a bit more broadly to get feedback.


A bit of history:

In the V2 API, when you authenticated with just a username and password, the token that was provided wasn't entirely clearly defined. The reference implementation that Keystone used was to create what's been called an 'unscoped' token - which was generally limited to only being able to get a list of possible tenants/projects and the capability of getting a token specific to a user & tenant/project (what's been called a "scoped" token)

Likewise, the reference implementation of the rest of the OpenStack projects all require a tenant information to be included within the token as that token was the identity refernce inforoamtion - and most OpenStack services were wanting to know the tenant associated with the token for authorization/ownership purposes.

Apparently Rackspace's internal implementation provided a token that was immediately valid for all possible tenants to which the user was associated, and presumably their internal implementations of openstack do whatever work is appropriate to discern and provide that information to the various openstack services.

The quandary:

In the V3 API, we started off with, and currently define the token as being specifically mandated to a single tenant, with a new requirement that if you authorize with just a username and password, a "default tenant" is used. If for some reason you have no tenant associated with the userid, the authorization is to be refused. If the user is associated with more than one tenant/project, it's possible to use the token to get a list of other tenants/projects and request a new token specific to one of those other tenant/projects, but the implementation is expected to respect and provide a default.

A few folks from Rackspace touched on this at the very tail end of the V3 API review session on Thursday, bringing up that they had an issue with the token being scoped to a single tenant. Since this has significant implications to both security and a potential user experience flow, I wanted to bring the issue up across the broader community for discussion.

The request outstanding:

Rackspace folks are requesting that the token not be limited to a single tenant/project, but instead provides a list of potential tenants against which the token should be considered valid.

Brief (maybe shoddy) analysis:

This would potentially imply changes to what gets passed as a part of the authentication reference in the context passed using auth_token middleware - multiple tenants possible instead of the currently expected single value - so using that as information for create() style mechanisms would need to provide some alternative means of clearly defining what tenant/project should be owner. It  would provide anyone compromising that particular token with a broader spectrum of impact on a replay style attack. Likewise, the impact of tenant enable/disable or role changes would necessarily mean a broader invalidation of all tokens associated with the user.

On the flip side, it has the potential to remove the token-reissuance that currently exists when switching contexts from one project to another (primarily through horizon or other client/UI/dashboard mechanisms that cache the token).

Feedback and Input desired!

-joe




More information about the OpenStack-dev mailing list