<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 02/18/2013 08:29 AM, Alexandra
Shulman-Peleg wrote:<br>
</div>
<blockquote
cite="mid:OF07D4E46A.C7050633-ONC2257B16.0040F506-C2257B16.004A184A@il.ibm.com"
type="cite"><font face="sans-serif" size="2">Hi Adam, </font>
<br>
<br>
<font face="sans-serif" size="2">I would like to verify my
understanding
of trusts and their token renewal. Please read the flow below
and comment
whether we can achieve this. I know that there are still some
missing
parts at the Swift side, but I would like to clarify the trusts
flow before
addressing them. </font>
<br>
<br>
<font face="sans-serif" size="2">Thank you very much,</font>
<br>
<font face="sans-serif" size="2">Alex. </font>
<br>
<br>
<font face="sans-serif" size="2">Motivation: </font>
<br>
<font face="sans-serif" size="2">User A wants to grant user B an
access
to container (C). User A is the owner of C. </font>
<br>
<br>
<font face="sans-serif" size="2">Delegation flow: </font>
<br>
<font face="sans-serif" size="2">1. By using the API of trusts,
user
A (having roles X and Y) registers a "trust" to user B, granting
him role X sufficient to access container C. </font>
<br>
<font face="sans-serif" size="2">2. User B, sends a request for a
token
defined by this trust. User B authenticates with his own
credential (token
or username&password of user B). </font>
<br>
<font face="sans-serif" size="2">3. Based on the defined trust
user B
is granted a token authorizing him to have role X. User B is
listed as
a "trustee" in the generated token (T). </font>
<br>
<font face="sans-serif" size="2">4. User B presents the token T to
Swift
and gains access to container C. </font>
<br>
<font face="sans-serif" size="2">5. When the token is expired,
user B
can renew it by repeating the steps 2-3 above. </font>
<br>
</blockquote>
<br>
Yes. That is exactly how it is supposed to work.<br>
<br>
<blockquote
cite="mid:OF07D4E46A.C7050633-ONC2257B16.0040F506-C2257B16.004A184A@il.ibm.com"
type="cite">
<br>
<br>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">From:
</font><font face="sans-serif" size="1">Adam Young
<a class="moz-txt-link-rfc2396E" href="mailto:ayoung@redhat.com"><ayoung@redhat.com></a></font>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">To:
</font><font face="sans-serif" size="1">OpenStack Development
Mailing List <a class="moz-txt-link-rfc2396E" href="mailto:openstack-dev@lists.openstack.org"><openstack-dev@lists.openstack.org></a>, </font>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">Date:
</font><font face="sans-serif" size="1">13/02/2013 04:34 PM</font>
<br>
<font color="#5f5f5f" face="sans-serif" size="1">Subject:
</font><font face="sans-serif" size="1">[openstack-dev]
[Keystone] Proposed change to token re--issue</font>
<br>
<hr noshade="noshade">
<br>
<br>
<br>
<tt><font size="2">Right now, Keystone will allow you to get a
token
based on a previous <br>
token. It does not matter if the original token is for a
different
<br>
scope, more restricted, than the second token.<br>
<br>
<br>
While writing the trusts implementation, I realize that
carrying this <br>
rule forward would open up a security hole. A user with a
token based
<br>
on a trust would be able to get a new token for any of the
privileges of
<br>
the trustor. The whole point of trusts was to scale down the
scope
of <br>
access from a token, not to increase it.<br>
<br>
I would like to propose the following rule. It will have to
apply to <br>
both the V2 and V3 versions of the APIs.<br>
<br>
Only an unscoped token can be used to retrieve another token.<br>
<br>
<br>
In order to get an unscoped token, you have to pass in userid
and <br>
password, or one of the REMOTE_USER mechanisms.<br>
It is technically OK to use an unscoped token to get another
token, so
<br>
long as the time out is honored, but I am not sure if that
provides any
<br>
real benefit.<br>
<br>
I could make a one-off exception for trust tokens. However,
if we
don't <br>
address this issue now, I suspect it will come back to haunt
us later.<br>
<br>
Here is a longer rationalization.<br>
<br>
Tokens are a symetric shared secret. If you have the token,
you have
<br>
the permissions of the user. Thus, a token should not be
spread <br>
around. Ideally, tokens should contain just the minimal
amount of
<br>
permissions to accomplish the task at hand. THat way, if they
get
<br>
intercepted, they can only be used to do minimal amounts of
damage. If
<br>
a user has access to multiple projects (tenants), the token
shoud not <br>
provide access to the tenants other than the one for which it
is <br>
allocated. Right now, due to token reissue, a token for
Project
A can <br>
be used to get a token for Project B.<br>
<br>
In the future, we are talking about scoping tokens to domains,
<br>
endpoints, and other containers. Lets choose now to limit the
amount
of <br>
exposure on a single token.<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</font></tt><a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font
size="2">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font
size="2"><br>
<br>
</font></tt>
<br>
</blockquote>
<br>
</body>
</html>