Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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.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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
(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.commailto: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.commailto:jorge.willi...@rackspace.com]
Sent: Wednesday, November 14, 2012 2:47 PM
To: OpenStack Development Mailing List
Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
(openstack@lists.launchpad.netmailto: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.commailto: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.commailto:he...@mac.com]
Sent: Tuesday, November 13, 2012 3:59 PM
To: Joe Savak
Cc: OpenStack Development Mailing List;
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
(openstack@lists.launchpad.netmailto: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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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
Re: [Openstack] [openstack-dev] 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_validateToken_v2.0_tokens__tokenId__Admin_API_Service_Developer_Operations-d1e1356.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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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
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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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. There's a blueprint to address the need to scope the token down to the service or endpoint level. Basically, service and endpoint isolation. 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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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.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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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.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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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
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
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API
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. 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
