Open Stack

On 11/10/2012 10:58 AM, David Chadwick wrote:
> 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.

let's compare with Kerberos:  In my view an unscoped token is 
comparaable with a ticket granting ticket:  it cannot be used with any 
service other than the KDC, and it can only be used to get service 
tickets. A service ticket can only be used with a specific service.  If 
that service gets compromised, any tickets it has are useless for access 
to other resources.


If an unscoped token can be used against a wide array of services, we 
have just provided a path for an elevation of privileges attack. If I 
know that a service consumes tokens which can be used on a wide number 
of other services, I can target my attacks against that service in order 
to get access everywhere.

If we are going to provide this functionality, it should be turned off 
by default.

>
> 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
>>