Open Stack

On 10/23/2012 01:25 AM, 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.
This is a pretty good distinction.  What we were calling "Unscoped" is, 
to me, the equivalent of a TGT in Kerberos:  a starting point, that has 
not been specified to any resources.  I'd be willing to entertain a 
different name than "Unscoped."  Let me throw out "Starting Tokens" as a 
straw man, and we can beat it up to come up with a better term.

"Sloppy" was never meant seriously, but more a way to tweak the noses of 
the project members named "Joe."


>
> -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 
>>>>> <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 
>>>> <https://help.launchpad.net/ListHelp>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121023/f3b1266b/attachment-0001.html>