<font size=2 face="sans-serif">Hi Adam, </font>
<br>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">Thank you very much,</font>
<br><font size=2 face="sans-serif">Alex. </font>
<br>
<br><font size=2 face="sans-serif">Motivation: </font>
<br><font size=2 face="sans-serif">User A wants to grant user B an access
to container (C). User A is the owner of C. </font>
<br>
<br><font size=2 face="sans-serif">Delegation flow: </font>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">4. User B presents the token T to Swift
and gains access to container C. </font>
<br><font size=2 face="sans-serif">5. When the token is expired, user B
can renew it by repeating the steps 2-3 above. </font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Adam Young <ayoung@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">13/02/2013 04:34 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[openstack-dev]
[Keystone] Proposed change to token re--issue</font>
<br>
<hr 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>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a 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>