On Nov 13, 2012, at 11:35 AM, heckj wrote: > So maintaining a token scoped to just the user, and a mechanism to scope it > to a tenant sound like all goodness. We can absolutely keep the API such that > it can provide either. > > Right now, our auth_token middleware implicitly requires a tenant in that > scoping to work. If someone wanted to support a token scoped to just a user > for the services, they'd need a different middleware there. Keystone as a > service *doesn't* use the auth_token middleware, so with the V3 API we can > make it provide services appropriately based on a token scoped only to the > user. > > All that in place, allow a token to be indeterminate scoped to multiple > tenants is fraught with security flaws, and if we continue to provide > unscoped tokens, that should obviate the need for token scoped to multiple > tenants.
I'm not sure I'm following you there. I don't see how unscoped tokens obviate the need to scope to multiple tenants, these may be driven by different concerns. Again, I think we need to have some flexibility in how we scope tokens. The API should be flexible enough to support different models -- I think that scoping a token to multiple tenants is useful in cases such as delegation -- where a single identity may be issued revokable access to a set of resources in multiple projects. > > - joe > > > On Nov 13, 2012, at 9:17 AM, David Chadwick <[email protected]> wrote: >> 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: [email protected] >>> [mailto:[email protected]] On Behalf Of >>> David Chadwick >>> Sent: Tuesday, November 13, 2012 7:32 AM >>> To: Adam Young >>> Cc: OpenStack Development Mailing List; [email protected] >>> 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" <[email protected] >>>>>>>>> <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> >>>>>>>>>>>> *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 >>>>>>>>>>>> <[email protected] >>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>> *Reply-To: *OpenStack Development Mailing List >>>>>>>>>>>> <[email protected] >>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> [email protected] >>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Mailing list:https://launchpad.net/~openstack >>>>>>>>>>> Post to :[email protected] >>>>>>>>>>> Unsubscribe :https://launchpad.net/~openstack >>>>>>>>>>> More help :https://help.launchpad.net/ListHelp >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Mailing list: https://launchpad.net/~openstack >>>>>>>>>> <https://launchpad.net/%7Eopenstack> >>>>>>>>>> Post to : [email protected] >>>>>>>>>> <mailto:[email protected]> >>>>>>>>>> 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 : [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>>>>> <https://launchpad.net/%7Eopenstack> >>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-dev mailing list >>>>>> [email protected] >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
