openstack team mailing list archive

["Yee, Guang" <guang.yee@xxxxxx>]

Is "belongsTo" mandatory? If not, what will token validation API return?

{"access": [list of tokens]}

?


Guang


-----Original Message-----
From: Jorge Williams [mailto:jorge.williams@xxxxxxxxxxxxx] 
Sent: Wednesday, November 14, 2012 2:47 PM
To: OpenStack Development Mailing List
Cc: openstack@xxxxxxxxxxxxxxxxxxx (openstack@xxxxxxxxxxxxxxxxxxx)
Subject: Re: [openstack-dev] [Openstack] Fwd: [keystone] Tokens representing
authorization to projects/tenants in the Keystone V3 API

>From an API perspective the changes required are the following:

	1.  The validate call returns a list of tenants instead of a single
tenant.

If the tenant id is in the URI of the API, then the validation middleware
can assert that the tenant id is in the list of IDs.

Not sure if there's any additional changes, but I don't think so.

An alternative approach is to use the belongsTo query parameter in the
validate call.  So if you know the tenantId of the resource, you can issue a
validate with ?belongsTo="tenatId"  and validation if the tenant is not in
the list of tenatIds for the token.  The belongsTo query parameter is in the
validate token call in the API today

http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_val
idateToken_v2.0_tokens__tokenId__Admin_API_Service_Developer_Operations-d1e1
356.html

And we use it quite a bit in our implementation, when we validate tokens --
that is in the case where a token may have access to multiple tenants.

Thoughts?

-jOrGe W.


On Nov 14, 2012, at 3:53 PM, heckj wrote:

> If we're going to assert it's supported, we're doing an incredible
dis-service to writing a spec to not implement that aspect of the spec, as
that kind of set up just leads to incompatibilities and confusion when
asserting how the spec should be used to provide interoperability.
> 
> If we accept this as a spec addition, then we MUST have an implementation
that makes it clear how we expect to interoperate with that aspect of the
specification, even if it's a configuration option that we don't normally
enable. If we don't test and validate it to prove interoperability, then the
spec is a worthless digital "piece of paper".
> 
> So under that pretext, I welcome suggestions on how to interpret the spec
you're proposing to some concrete implementations that can be verified for
interoperability, and that are compatible with the existing and/or upcoming
implementations for V3 API.
> 
> -joe
> 
> On Nov 14, 2012, at 1:35 PM, Joe Savak <joe.savak@xxxxxxxxxxxxx> wrote:
>> Hi Joe,
>> 	If I'm working across multiple tenants, I'd prefer one token that I
can securely handle that proves access rights to the tenants I'm working
with. Handling multiple tokens increases the complexity of clients needing
to provide multi-tenancy access to an authenticated identity. It also adds
more calls to keystone. 
>> 
>> Again, I think that having the keystone reference implementation restrict
tokens to 1 tenant is fine. We shouldn't have such arbitrary restrictions in
the API contract though. It needs to be extensible and flexible to allow for
the all sorts of use cases that are likely to occur.
>> 
>> Thanks,
>> joe
>> 
>> -----Original Message-----
>> From: heckj [mailto:heckj@xxxxxxx] 
>> Sent: Tuesday, November 13, 2012 3:59 PM
>> To: Joe Savak
>> Cc: OpenStack Development Mailing List; openstack@xxxxxxxxxxxxxxxxxxx
(openstack@xxxxxxxxxxxxxxxxxxx)
>> Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens
representing authorization to projects/tenants in the Keystone V3 API
>> 
>> Hey Joe:
>> 
>> Currently a user scoped token doesn't include a service catalog - mostly
because I think the service catalog generally requires tenant_id's to
interpolate into the values to provide it. That doesn't mean we can't put
in/include service catalog endpoints where that value doesn't need to be
determined.
>> 
>> I'm also questioning the value of providing a token scoped to all tenants
associated with a user - that seems to have the same value as just using a
user token. 
>> 
>> In fact, even if we allow some arbitrary set of tenants to be scoped into
a token along with a user, what on earth should be in the service catalog?
Endpoints relevant to every possible tenant?
>> 
>> This just seems to be a potential explosion of data that is poorly scoped
from a security perspective.
>> 
>> -joe
>> 
>> On Nov 13, 2012, at 1:42 PM, Joe Savak <joe.savak@xxxxxxxxxxxxx> wrote:
>>> Will user-scoped token include the full service catalog? 
>>> 
>>> Also, I thought the consensus was to allow the API contract to be
flexible on how many tenants we can scope the token to. The ref impl can
enforce 1 tenant-scoped token. Are we diverging from this?
>>> 
>>> Thanks,
>>> joe
>>> 
>>> -----Original Message-----
>>> From: openstack-bounces+joe.savak=rackspace.com@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+joe.savak=rackspace.com@xxxxxxxxxxxxxxxxxxx] On
Behalf Of heckj
>>> Sent: Tuesday, November 13, 2012 1:34 PM
>>> To: OpenStack Development Mailing List
>>> Cc: openstack@xxxxxxxxxxxxxxxxxxx (openstack@xxxxxxxxxxxxxxxxxxx)
>>> Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens
representing authorization to projects/tenants in the Keystone V3 API
>>> 
>>> 
>>> On Nov 13, 2012, at 11:01 AM, Jorge Williams
<jorge.williams@xxxxxxxxxxxxx> 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.
>>> 
>>> The consensus from the folks weighing in on this from a security
perspective seems to be that it's kosher to restrict tokens further (the
least privilege thing). Broadening the scope to multiple tenants or sets of
tenants doesn't appear to follow those best practices. If you wanted to
accept a less-scoped token than the scoped to single tenant, you can accept
and use a user-scoped token, at least by my read.
>>> 
>>> -joe
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@xxxxxxxxxxxxxxxxxxx
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@xxxxxxxxxxxxxxxxxxx
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature