On 10/20/2012 01:50 PM, heckj wrote:
I sent this to the openstack-dev list, and thought I'd double post
this onto the openstack list at Launchpad for additional feedback.
-joe
Begin forwarded message:
*From: *heckj <he...@mac.com <mailto:he...@mac.com>>
*Subject: **[openstack-dev] [keystone] Tokens representing
authorization to projects/tenants in the Keystone V3 API*
*Date: *October 19, 2012 1:51:16 PM PDT
*To: *OpenStack Development Mailing List
<openstack-...@lists.openstack.org
<mailto:openstack-...@lists.openstack.org>>
*Reply-To: *OpenStack Development Mailing List
<openstack-...@lists.openstack.org
<mailto:openstack-...@lists.openstack.org>>
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.
I would like to make "default tenant" a configuration option, and have
it disabled by default. Unscoped tokens are a very useful construct.
In the case where the user has many roles across a multitude of
projects, it is possible to create huge tokens. I would prefer unscoped
tokens to remain, and to be associated with no tenant. The only
operation Keystone should provide with them is the ability to enumerate
tenants, so something like Horizon can then request an appropriately
scoped token.
I am also in favor of limiting the scope of a token to an endpoint. Even
more-so than tenants, scoping a token to an end point increases
security. Once a token has been scoped to an endpoint, it can only be
used on that endpoint. If an endpoint gets compromised, the damage is
limited to resources that endpoint already has access to. This, in
conjunction with pre-auths, could allow a user to perform an action with
a minimum of risk in a public cloud environment.
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.
I would like the world to know that we are affectionately calling such
tokens "sloppy tokens" and Joe Savak has adopted the nickname of "Sloppy
Joe" for championing them. Allowing it as an option is fine, but I
would not recommend that this become the norm, or that we enable this
feature by default.
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
_______________________________________________
OpenStack-dev mailing list
openstack-...@lists.openstack.org
<mailto:openstack-...@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
