<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/23/2012 01:25 AM, Jorge Williams
wrote:<br>
</div>
<blockquote
cite="mid:DD1F4B82-F947-4379-A2CA-BB5B823FE01D@rackspace.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Here's my view:
<div><br>
</div>
<div>On making the default token a configuration option: Like the
idea. Disabling the option by default. That's fine too.</div>
<div><br>
</div>
<div>On scoping a token to a specific endpoint: That's fine,
though I believe that that's in the API today. Currently, the
way that we scope tokens to endpoints is by validating against
the service catalog. I'm not sure if the default middleware
checks for this yet, but the Repose middleware does. If you try
to use a token in an endpoint that's not in the service catalog
the request fails -- well, if the check is turned on.</div>
<div><br>
</div>
<div>Obviously, I'd like the idea of scoping a single token to
multiple tenants / endpoints.</div>
<div><br>
</div>
<div>I don't like the idea of calling tokens "sloppy tokens" --
it's confusing. All you have to say is that a token has a
scope -- and the scope of the token is the set of resources that
the token can provide access to. You can limit the scope of a
token to a tenant, to a endpoint, to a set of endpoints or
tenants etc -- what limits you place on the scope of an
individual token should be up to the operator.</div>
<div><br>
</div>
<div>Keep in mind that as we start digging into delegation and
fine grained authorization (after Grizzly, I'm sure), we'll end
up with tokens that have a scope of a subset of resources in a
single or multiple tenants. So calling them sloppy now is just
confusing. Simply stating that a token has a scope (as I've
defined above) should suffice. This is part of the reason why
I've never liked the term "unscoped" token, because an unscoped
token does have a scope. It just so happens that the scope of
that token is the resource that provides a list of available
tenants.</div>
</blockquote>
This is a pretty good distinction. What we were calling "Unscoped"
is, to me, the equivalent of a TGT in Kerberos: a starting point,
that has not been specified to any resources. I'd be willing to
entertain a different name than "Unscoped." Let me throw out
"Starting Tokens" as a straw man, and we can beat it up to come up
with a better term.<br>
<br>
"Sloppy" was never meant seriously, but more a way to tweak the
noses of the project members named "Joe."<br>
<br>
<br>
<blockquote
cite="mid:DD1F4B82-F947-4379-A2CA-BB5B823FE01D@rackspace.com"
type="cite">
<div><br>
</div>
<div>-jOrGe W.</div>
<div><br>
</div>
<div>
<div>
<div>On Oct 22, 2012, at 9:57 PM, Adam Young wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div 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">
+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><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>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>