Open Stack

Hi Guang


On 13/11/2012 16:14, Yee, Guang wrote:
> An unscoped token is basically implicitly scoped to Keystone service right?
> One should be able to use an unscoped token to reset his password, and ask
> Keystone for information pertaining to himself, such as what are his roles,
> what services/endpoints are available to him, and what are his tenants, etc.
> This is helpful for administration UIs such as MC.

agreed

>
> There's a blueprint to address the need to scope the token down to the
> service or endpoint level. Basically, service and endpoint isolation.

I have read your blueprint and I have some comments/questions on it. How 
do you want these to be addressed? By email, or by edits to you blueprint?

regards

David

>
> https://blueprints.launchpad.net/keystone/+spec/service-isolation-and-roles-
> delegation
> http://wiki.openstack.org/Keystone/Service-Isolation-And-Roles-Delegation
>
> It also addresses the intricacies of role delegation, which should be very
> beneficial for cloud services.
>
>
>
> Guang
>
>
>
> -----Original Message-----
> From: openstack-bounces+guang.yee=hp.com at lists.launchpad.net
> [mailto:openstack-bounces+guang.yee=hp.com at lists.launchpad.net] On Behalf Of
> David Chadwick
> Sent: Tuesday, November 13, 2012 7:32 AM
> To: Adam Young
> Cc: OpenStack Development Mailing List; openstack at lists.launchpad.net
> Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing
> authorization to projects/tenants in the Keystone V3 API
>
> Hi Adam
>
> you have pointed out an important difference between an unscoped token
> and a scoped one. The former can only be used with keystone, the latter
> with a cloud service. This also implies that a scoped token can only
> have the scope of a single service, and not multiple services. The user
> must swap the unscoped token for a set of scoped tokens if he wishes to
> access a set of cloud services.
>
> This model is clean and consistent.
>
> Concerning your attack scenario, then the best point of attack is either
> the client (steal his token(s)) or Keystone (get access to any service)
>
> regards
>
> David
>
> On 13/11/2012 14:38, Adam Young wrote:
>> 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
>>>>
>>
>
> _______________________________________________
> 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
>