It seems like unscoped is a total misnomer. Unscoped just means scoped to keystone. The existence of 'unscoped' tokens seems completely orthogonal to whether a token can be scoped to multiple services/endpoints.
Vish On Nov 13, 2012, at 11:01 AM, Jorge Williams <jorge.willi...@rackspace.com> wrote: > > 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 <d.w.chadw...@kent.ac.uk> 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: openstack-bounces+guang.yee=hp....@lists.launchpad.net >>>> [mailto:openstack-bounces+guang.yee=hp....@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@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" <ayo...@redhat.com >>>>>>>>>> <mailto:ayo...@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 <he...@mac.com <mailto:he...@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-...@lists.openstack.org >>>>>>>>>>>>> <mailto:openstack-...@lists.openstack.org>> >>>>>>>>>>>>> *Reply-To: *OpenStack Development Mailing List >>>>>>>>>>>>> <openstack-...@lists.openstack.org >>>>>>>>>>>>> <mailto:openstack-...@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-...@lists.openstack.org >>>>>>>>>>>>> <mailto:openstack-...@lists.openstack.org> >>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Mailing list:https://launchpad.net/~openstack >>>>>>>>>>>> Post to :openstack@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@lists.launchpad.net >>>>>>>>>>> <mailto:openstack@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@lists.launchpad.net >>>>>>>>>> <mailto:openstack@lists.launchpad.net> >>>>>>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>>>>>> <https://launchpad.net/%7Eopenstack> >>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OpenStack-dev mailing list >>>>>>> openstack-...@lists.openstack.org >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> openstack-...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
