Open Stack

On 02/18/2013 01:56 PM, Ali, Haneef wrote:
>
> Hi Adam,
>
> Do you have request/response for the following steps based on V3 token 
> structure?
>
> <!--
>
> 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).
>
> à
>
the V3-auth API implementation is still under review.  Take a look at:

https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md

For the docs.

> Also, what is the token expiry time?  I believe it is lesser of 
> default token expiry time and trust duration.
>
Correct.
>
> Thanks
>
> Haneef
>
> *From:*Adam Young [mailto:ayoung at redhat.com]
> *Sent:* Monday, February 18, 2013 6:06 AM
> *To:* Alexandra Shulman-Peleg
> *Cc:* openstack-dev at lists.openstack.org
> *Subject:* Re: [openstack-dev] [Keystone] Proposed change to token 
> re--issue
>
> 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> <mailto:ayoung at redhat.com>
> To: OpenStack Development Mailing List 
> <openstack-dev at lists.openstack.org> 
> <mailto: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 
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> 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/20130220/e9458271/attachment.html>