Open Stack

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121022/e274d2eb/attachment.html>