Open Stack

I agree with the vast majority of what Jorge says below. The idea I 
would like to bounce around is that of the unscoped token.

What does it mean conceptually? What is its purpose? Why do we need it? 
Why should a user be given an unscoped token to exchange at a later time 
for a scoped token?

My view is as follows:
i) a user is authenticated and identified, and from this, keystone can 
see that the user has access to a number of different tenants and 
services. Keystone creates an unscoped token to encapsulate this. Note 
that the unscoped token is scoped to the services/tenants available to 
this user, and consequently it is different for each identified user. 
Thus it does have some scope i.e. it cannot be swapped for access to any 
service by any tenant.
ii) the user must choose which service/tenant he wishes to activate. 
This is in line with the principle of least privileges.
iii) the user informs keystone which service(s) and tenant(s) he wishes 
to access and Keystone swaps the unscoped token for one that is scoped 
to the choice of the user.

The issue then becomes, what is the allowable scope of a scoped token? 
Jorge below believes it should cover multiple 
services/endpoints/tenants. So one must then ask, what is the difference 
between the most widely scoped scoped-token and the unscoped token? 
Surely they will have the same scope won't they? In which case there is 
no need for both concepts.

Comments please

regards

David

On 23/10/2012 06:25, Jorge Williams wrote:
> Here's my view:
>
> On making the default token a configuration option:  Like the idea.
>   Disabling the option by default.  That's fine too.
>
> On scoping a token to a specific endpoint:  That's fine, though I
> believe that that's in the API today.  Currently, the way that we scope
> tokens to endpoints is by validating against the service catalog. I'm
> not sure if the default middleware checks for this yet, but the Repose
> middleware does.  If you try to use a token in an endpoint that's not in
> the service catalog the request fails -- well, if the check is turned on.
>
> Obviously, I'd like the idea of scoping a single token to multiple
> tenants / endpoints.
>
> I don't like the idea of calling tokens "sloppy tokens" -- it's
> confusing.   All you have to say is that a token has a scope -- and the
> scope of the token is the set of resources that the token can provide
> access to.  You can limit the scope of a token to a tenant, to a
> endpoint, to a set of endpoints or tenants etc -- what limits you place
> on the scope of an individual token should be up to the operator.
>
> Keep in mind that as we start digging into delegation and fine grained
> authorization (after Grizzly, I'm sure), we'll end up with tokens that
> have a scope of a subset of resources in a single or multiple tenants.
>   So calling them sloppy now is just confusing.  Simply stating that a
> token has a scope (as I've defined above) should suffice.  This is part
> of the reason why I've never liked the term "unscoped" token, because an
> unscoped token does have a scope. It just so happens that the scope of
> that token is the resource that provides a list of available tenants.
>
> -jOrGe W.
>
> On Oct 22, 2012, at 9:57 PM, Adam Young wrote:
>
>> Are you guys +1 ing the original Idea, my suggestion to make it
>> optional, the fact that I think we should call these sloppy tokens?
>>
>> On 10/22/2012 03:40 PM, Jorge Williams wrote:
>>> +1 here too.
>>>
>>> At the end of the day, we'd like the identity API to be flexible
>>> enough to allow the token to be scoped in a manner that the deployer
>>> sees fit.  What the keystone implementation does by default is a
>>> different matter -- and disabling multiple tenant  scope by default
>>> would be fine by me.
>>>
>>> -jOrGe W.
>>>
>>>
>>> On Oct 21, 2012, at 11:10 AM, Joe Savak wrote:
>>>
>>>> +1. ;)
>>>>
>>>> So the issue is that the v2 API contract allows a token to be scoped
>>>> to multiple tenants. For v3, I'd like to have the same flexibility.
>>>> I don't see security issues, as if a token were to be sniffed you
>>>> can change the password of the account using it and use those creds
>>>> to scope tokens to any tenant you wish.
>> Scope should always be kept as limited as possible. Personally, I
>> don't feel like limiting the tenant list makes much difference.  THe
>> more I think about it, the real benefit comes from limiting the
>> endpoints.
>>
>>
>>>>
>>>>
>>>>
>>>> On Oct 20, 2012, at 21:07, "Adam Young" <ayoung at redhat.com
>>>> <mailto:ayoung at redhat.com>> wrote:
>>>>
>>>>> On 10/20/2012 01:50 PM, heckj wrote:
>>>>>> I sent this to the openstack-dev list, and thought I'd double post
>>>>>> this onto the openstack list at Launchpad for additional feedback.
>>>>>>
>>>>>> -joe
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>> *From: *heckj <heckj at mac.com <mailto:heckj at mac.com>>
>>>>>>> *Subject: **[openstack-dev] [keystone] Tokens representing
>>>>>>> authorization to projects/tenants in the Keystone V3 API*
>>>>>>> *Date: *October 19, 2012 1:51:16 PM PDT
>>>>>>> *To: *OpenStack Development Mailing List
>>>>>>> <openstack-dev at lists.openstack.org
>>>>>>> <mailto:openstack-dev at lists.openstack.org>>
>>>>>>> *Reply-To: *OpenStack Development Mailing List
>>>>>>> <openstack-dev at lists.openstack.org
>>>>>>> <mailto:openstack-dev at lists.openstack.org>>
>>>>>>>
>>>>>>> The topic of what a token can or can't represent for the upcoming
>>>>>>> V3 Keystone API  came up - and I wanted to share the conversation
>>>>>>> a bit more broadly to get feedback.
>>>>>>>
>>>>>>>
>>>>>>> A bit of history:
>>>>>>>
>>>>>>> In the V2 API, when you authenticated with just a username and
>>>>>>> password, the token that was provided wasn't entirely clearly
>>>>>>> defined. The reference implementation that Keystone used was to
>>>>>>> create what's been called an 'unscoped' token - which was
>>>>>>> generally limited to only being able to get a list of possible
>>>>>>> tenants/projects and the capability of getting a token specific
>>>>>>> to a user & tenant/project (what's been called a "scoped" token)
>>>>>>>
>>>>>>> Likewise, the reference implementation of the rest of the
>>>>>>> OpenStack projects all require a tenant information to be
>>>>>>> included within the token as that token was the identity refernce
>>>>>>> inforoamtion - and most OpenStack services were wanting to know
>>>>>>> the tenant associated with the token for authorization/ownership
>>>>>>> purposes.
>>>>>>>
>>>>>>> Apparently Rackspace's internal implementation provided a token
>>>>>>> that was immediately valid for all possible tenants to which the
>>>>>>> user was associated, and presumably their internal
>>>>>>> implementations of openstack do whatever work is appropriate to
>>>>>>> discern and provide that information to the various openstack
>>>>>>> services.
>>>>>>>
>>>>>>> The quandary:
>>>>>>>
>>>>>>> In the V3 API, we started off with, and currently define the
>>>>>>> token as being specifically mandated to a single tenant, with a
>>>>>>> new requirement that if you authorize with just a username and
>>>>>>> password, a "default tenant" is used. If for some reason you have
>>>>>>> no tenant associated with the userid, the authorization is to be
>>>>>>> refused. If the user is associated with more than one
>>>>>>> tenant/project, it's possible to use the token to get a list of
>>>>>>> other tenants/projects and request a new token specific to one of
>>>>>>> those other tenant/projects, but the implementation is expected
>>>>>>> to respect and provide a default.
>>>>>
>>>>> I would like to make "default tenant" a configuration option, and
>>>>> have it disabled by default.  Unscoped tokens are a very useful
>>>>> construct.  In the case where the user has many roles across a
>>>>> multitude of projects, it is possible to create huge tokens.  I
>>>>> would prefer unscoped tokens to remain, and to be associated with
>>>>> no tenant.  The only operation Keystone should provide with them is
>>>>> the ability to enumerate tenants, so something like Horizon can
>>>>> then request an appropriately scoped token.
>>>>>
>>>>> I am also in favor of limiting the scope of a token to an
>>>>> endpoint.  Even more-so than tenants, scoping a token to an end
>>>>> point increases security.  Once a token has been scoped to an
>>>>> endpoint, it can only be used on that endpoint.  If an endpoint
>>>>> gets compromised, the damage is limited to resources that endpoint
>>>>> already has access to.  This, in conjunction with pre-auths, could
>>>>> allow a user to perform an action with a minimum of risk in a
>>>>> public cloud environment.
>>>>>
>>>>>
>>>>>>>
>>>>>>> A few folks from Rackspace touched on this at the very tail end
>>>>>>> of the V3 API review session on Thursday, bringing up that they
>>>>>>> had an issue with the token being scoped to a single tenant.
>>>>>>> Since this has significant implications to both security and a
>>>>>>> potential user experience flow, I wanted to bring the issue up
>>>>>>> across the broader community for discussion.
>>>>>>>
>>>>>>> The request outstanding:
>>>>>>>
>>>>>>> Rackspace folks are requesting that the token not be limited to a
>>>>>>> single tenant/project, but instead provides a list of potential
>>>>>>> tenants against which the token should be considered valid.
>>>>> I would like the world to know that we are affectionately calling
>>>>> such tokens "sloppy tokens" and Joe Savak has adopted the nickname
>>>>> of "Sloppy Joe" for championing them.  Allowing it as an option is
>>>>> fine, but I would not recommend that this become the norm, or that
>>>>> we enable this feature by default.
>>>>>>>
>>>>>>> Brief (maybe shoddy) analysis:
>>>>>>>
>>>>>>> This would potentially imply changes to what gets passed as a
>>>>>>> part of the authentication reference in the context passed using
>>>>>>> auth_token middleware - multiple tenants possible instead of the
>>>>>>> currently expected single value - so using that as information
>>>>>>> for create() style mechanisms would need to provide some
>>>>>>> alternative means of clearly defining what tenant/project should
>>>>>>> be owner. It  would provide anyone compromising that particular
>>>>>>> token with a broader spectrum of impact on a replay style attack.
>>>>>>> Likewise, the impact of tenant enable/disable or role changes
>>>>>>> would necessarily mean a broader invalidation of all tokens
>>>>>>> associated with the user.
>>>>>>>
>>>>>>> On the flip side, it has the potential to remove the
>>>>>>> token-reissuance that currently exists when switching contexts
>>>>>>> from one project to another (primarily through horizon or other
>>>>>>> client/UI/dashboard mechanisms that cache the token).
>>>>>>>
>>>>>>> Feedback and Input desired!
>>>>>>>
>>>>>>> -joe
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list:https://launchpad.net/~openstack
>>>>>> Post to     :openstack at lists.launchpad.net
>>>>>> Unsubscribe :https://launchpad.net/~openstack
>>>>>> More help   :https://help.launchpad.net/ListHelp
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> <https://launchpad.net/%7Eopenstack>
>>>>> Post to     : openstack at lists.launchpad.net
>>>>> <mailto:openstack at lists.launchpad.net>
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> <https://launchpad.net/%7Eopenstack>
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> <https://launchpad.net/%7Eopenstack>
>>>> Post to     : openstack at lists.launchpad.net
>>>> <mailto:openstack at lists.launchpad.net>
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> <https://launchpad.net/%7Eopenstack>
>>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>