Open Stack

Hi Adam,

Will the proposed v3-auth api format change ( or include some additional meta data ) to support  trust? If so what is the additional meta data that is required to get the token defined by trust?
   <!—
User B, sends a request for a token defined by this trust.
  -->


From: Adam Young [mailto:ayoung at redhat.com]
Sent: Wednesday, February 20, 2013 7:01 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Keystone] Proposed change to token re--issue

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<mailto: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<mailto: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/20130221/663754c5/attachment.html>