Open Stack

seems like we need a clear design for next generation tokens that
everyone can agree on. But also an extensible design to cater for 
outliers. In our federation design doc we show the Token Issuing Service 
and Token Validation Service as plugin modules to Keystone that can be 
replaces so that outliers can replace the standard service with one of 
their own choosing

regards

David


On 13/11/2012 17:35, 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.
>
> - joe
>
>
> On Nov 13, 2012, at 9:17 AM, David Chadwick <d.w.chadwick at 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.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
>>>
>>
>> _______________________________________________ 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
>