Open Stack

On 02/18/2013 08:29 AM, Alexandra Shulman-Peleg wrote:
> Hi Adam,
>
> 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.
>
> Thank you very much,
> Alex.
>
> Motivation:
> User A wants to grant user B an access to container (C). User A is the 
> owner of C.
>
> Delegation flow:
> 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.
> 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).
> 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).
> 4. User B presents the token T to Swift and gains access to container C.
> 5. When the token is expired, user B can renew it by repeating the 
> steps 2-3 above.

Yes. That is exactly how it is supposed to work.

>
>
>
> From: Adam Young <ayoung at redhat.com>
> To: OpenStack Development Mailing List 
> <openstack-dev at lists.openstack.org>,
> Date: 13/02/2013 04:34 PM
> Subject: [openstack-dev] [Keystone] Proposed change to token re--issue
> ------------------------------------------------------------------------
>
>
>
> Right now, Keystone will allow you to get a token based on a previous
> token.   It does not matter if the original token is for a different
> scope, more restricted, than the second token.
>
>
> While writing the trusts implementation, I realize that carrying this
> rule forward would open up a security hole.  A user with a token based
> on a trust would be able to get a new token for any of the privileges of
> the trustor.  The whole point of trusts was to scale down the scope of
> access from a token, not to increase it.
>
> I would like to propose the following rule. It will have to apply to
> both the V2 and V3 versions of the APIs.
>
> Only an unscoped token can be used to retrieve another token.
>
>
> In order to get an unscoped token, you have to pass in userid and
> password, or one of the REMOTE_USER mechanisms.
> It is technically OK to use an unscoped token to get another token, so
> long as the time out is honored, but I am not sure if that provides any
> real benefit.
>
> I could make a one-off exception for trust tokens.  However, if we don't
> address this issue now, I suspect it will come back to haunt us later.
>
> Here is a longer rationalization.
>
> Tokens are a symetric shared secret.  If you have the token, you have
> the permissions of the user.  Thus, a token should not be spread
> around.  Ideally, tokens should contain just the minimal amount of
> permissions to accomplish the task at hand.  THat way, if they get
> intercepted, they can only be used to do minimal amounts of damage.  If
> a user has access to multiple projects (tenants), the token shoud not
> provide access to the tenants other than the one for which it is
> allocated.  Right now, due to token reissue,  a token for Project A can
> be used to get a token for Project B.
>
> In the future, we are talking about scoping tokens to domains,
> endpoints, and other containers.  Lets choose now to limit the amount of
> exposure on a single token.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130218/402c5954/attachment.html>