<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/20/2012 01:50 PM, heckj wrote:<br>
</div>
<blockquote cite="mid:E2414BBA-4EDB-4AA1-9CB5-A298CBB0FCF0@mac.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
I sent this to the openstack-dev list, and thought I'd double post
this onto the openstack list at Launchpad for additional feedback.
<div>
<div><br>
</div>
<div>-joe<br>
<div><br>
<div>Begin forwarded message:</div>
<blockquote type="cite">
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"><span
style="font-family:'Helvetica'; font-size:medium;
color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span
style="font-family:'Helvetica'; font-size:medium;">heckj
<<a moz-do-not-send="true"
href="mailto:heckj@mac.com">heckj@mac.com</a>><br>
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"><span
style="font-family:'Helvetica'; font-size:medium;
color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span
style="font-family:'Helvetica'; font-size:medium;"><b>[openstack-dev]
[keystone] Tokens representing authorization to
projects/tenants in the Keystone V3 API</b><br>
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"><span
style="font-family:'Helvetica'; font-size:medium;
color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span
style="font-family:'Helvetica'; font-size:medium;">October
19, 2012 1:51:16 PM PDT<br>
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"><span
style="font-family:'Helvetica'; font-size:medium;
color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span
style="font-family:'Helvetica'; font-size:medium;">OpenStack
Development Mailing List <<a moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
</span></div>
<div style="margin-top: 0px; margin-right: 0px;
margin-bottom: 0px; margin-left: 0px;"><span
style="font-family:'Helvetica'; font-size:medium;
color:rgba(0, 0, 0, 1.0);"><b>Reply-To: </b></span><span
style="font-family:'Helvetica'; font-size:medium;">OpenStack
Development Mailing List <<a moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
</span></div>
<br>
<div>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.<br>
<br>
<br>
A bit of history:<br>
<br>
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)<br>
<br>
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.<br>
<br>
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.<br>
<br>
The quandary:<br>
<br>
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.<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:E2414BBA-4EDB-4AA1-9CB5-A298CBB0FCF0@mac.com"
type="cite">
<div>
<div>
<div>
<blockquote type="cite">
<div><br>
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.<br>
<br>
The request outstanding:<br>
<br>
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.<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
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. <br>
<blockquote cite="mid:E2414BBA-4EDB-4AA1-9CB5-A298CBB0FCF0@mac.com"
type="cite">
<div>
<div>
<div>
<blockquote type="cite">
<div><br>
Brief (maybe shoddy) analysis:<br>
<br>
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.<br>
<br>
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).<br>
<br>
Feedback and Input desired!<br>
<br>
-joe<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Mailing list: <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
Post to : <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>
Unsubscribe : <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
More help : <a class="moz-txt-link-freetext" href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a>
</pre>
</blockquote>
<br>
</body>
</html>