I'm just pointing out that the same data used for validating belongsTo on
the server-side is included in the response body (assuming a GET and not
HEAD).
-Dolph
On Thu, Nov 15, 2012 at 2:51 PM, Jorge Williams <
jorge.willi...@rackspace.com> wrote:
> (inline)
>
> On Nov 15, 2012, at 2:06 PM, Dolph Mathews wrote:
>
> Without belongsTo, you can still validate the tenant scope client-side, so
> it's a bit redundant.
>
>
> Not sure what you mean. Can you be more specific?
>
> However, if you're making a HEAD call to validate the token, you obviously
> need the server to do that additional validation for you.
>
>
> Right.
>
>
> -Dolph
>
>
> On Thu, Nov 15, 2012 at 8:20 AM, Jorge Williams <
> jorge.willi...@rackspace.com> wrote:
>
>> No, it's optional.
>>
>> Token validation returns what it normally does. The only thing belongs
>> to does is that you fail token validation if the given tenant is not
>> covered by the scope of the token.
>>
>> -jOrGe W.
>>
>> On Nov 14, 2012, at 11:18 PM, Yee, Guang wrote:
>>
>> > Is "belongsTo" mandatory? If not, what will token validation API return?
>> >
>> > {"access": [list of tokens]}
>> >
>> > ?
>> >
>> >
>> > Guang
>> >
>> >
>> > -----Original Message-----
>> > From: Jorge Williams [mailto:jorge.willi...@rackspace.com]
>> > Sent: Wednesday, November 14, 2012 2:47 PM
>> > To: OpenStack Development Mailing List
>> > Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
>> > 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.sa...@rackspace.com>
>> 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:he...@mac.com]
>> >>> Sent: Tuesday, November 13, 2012 3:59 PM
>> >>> To: Joe Savak
>> >>> Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net
>> > (openstack@lists.launchpad.net)
>> >>> 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.sa...@rackspace.com>
>> 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....@lists.launchpad.net
>> > [mailto:openstack-bounces+joe.savak=rackspace....@lists.launchpad.net]
>> On
>> > Behalf Of heckj
>> >>>> Sent: Tuesday, November 13, 2012 1:34 PM
>> >>>> To: OpenStack Development Mailing List
>> >>>> Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
>> >>>> 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.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.
>> >>>>
>> >>>> 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@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
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>>
>> _______________________________________________
>> 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
