<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">Are you guys +1 ing the original Idea,
my suggestion to make it optional, the fact that I think we should
call these sloppy tokens?<br>
<br>
On 10/22/2012 03:40 PM, Jorge Williams wrote:<br>
</div>
<blockquote
cite="mid:403C5629-5ECE-4970-A4F5-FAEDC79F0BA9@rackspace.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
+1 here too.
<div><br>
</div>
<div>At the end of the day, we'd like the identity API to be
flexible enough to allow the token to be scoped in a manner that
the deployer sees fit. What the keystone implementation does by
default is a different matter -- and disabling multiple tenant
scope by default would be fine by me.</div>
<div><br>
</div>
<div>-jOrGe W.</div>
<div><br>
</div>
<div><br>
<div>
<div>On Oct 21, 2012, at 11:10 AM, Joe Savak wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#FFFFFF">
<div>+1. ;)</div>
<div><br>
</div>
<div>So the issue is that the v2 API contract allows a
token to be scoped to multiple tenants. For v3, I'd like
to have the same flexibility. I don't see security
issues, as if a token were to be sniffed you can change
the password of the account using it and use those creds
to scope tokens to any tenant you wish.<br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
Scope should always be kept as limited as possible. Personally, I
don't feel like limiting the tenant list makes much difference. THe
more I think about it, the real benefit comes from limiting the
endpoints.<br>
<br>
<br>
<blockquote
cite="mid:403C5629-5ECE-4970-A4F5-FAEDC79F0BA9@rackspace.com"
type="cite">
<div>
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF">
<div>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
On Oct 20, 2012, at 21:07, "Adam Young" <<a
moz-do-not-send="true" href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<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">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 moz-do-not-send="true"
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 moz-do-not-send="true" class="moz-txt-link-freetext" href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a>
Post to : <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>
Unsubscribe : <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a>
More help : <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a></span><br>
<span>Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a></span><br>
<span>Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a></span><br>
<span>More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a></span><br>
</div>
</blockquote>
</div>
_______________________________________________<br>
Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a><br>
Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a><br>
More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>