Open Stack

Without belongsTo, you can still validate the tenant scope client-side, so
it's a bit redundant. However, if you're making a HEAD call to validate the
token, you obviously need the server to do that additional validation for
you.


-Dolph


On Thu, Nov 15, 2012 at 8:20 AM, Jorge Williams <
jorge.williams at 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.williams at rackspace.com]
> > Sent: Wednesday, November 14, 2012 2:47 PM
> > To: OpenStack Development Mailing List
> > Cc: openstack at lists.launchpad.net (openstack at 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.savak at 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:heckj at mac.com]
> >>> Sent: Tuesday, November 13, 2012 3:59 PM
> >>> To: Joe Savak
> >>> Cc: OpenStack Development Mailing List; openstack at lists.launchpad.net
> > (openstack at 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.savak at 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.com at lists.launchpad.net
> > [mailto:openstack-bounces+joe.savak=rackspace.com at lists.launchpad.net]
> On
> > Behalf Of heckj
> >>>> Sent: Tuesday, November 13, 2012 1:34 PM
> >>>> To: OpenStack Development Mailing List
> >>>> Cc: openstack at lists.launchpad.net (openstack at 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.williams at 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 at lists.launchpad.net
> >>>> Unsubscribe : https://launchpad.net/~openstack
> >>>> 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
> >
> >
> > _______________________________________________
> > 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121115/59b1ccfd/attachment.html>