On 10/23/2012 01:25 AM, 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.
This is a pretty good distinction. What we were calling "Unscoped" is,
to me, the equivalent of a TGT in Kerberos: a starting point, that has
not been specified to any resources. I'd be willing to entertain a
different name than "Unscoped." Let me throw out "Starting Tokens" as a
straw man, and we can beat it up to come up with a better term.
"Sloppy" was never meant seriously, but more a way to tweak the noses of
the project members named "Joe."
-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
<mailto:openstack-...@lists.openstack.org>>
The topic of what a token can or can't represent for the
upcoming V3 Keystone API came up - and I wanted to share the
conversation a bit more broadly to get feedback.
A bit of history:
In the V2 API, when you authenticated with just a username and
password, the token that was provided wasn't entirely clearly
defined. The reference implementation that Keystone used was to
create what's been called an 'unscoped' token - which was
generally limited to only being able to get a list of possible
tenants/projects and the capability of getting a token specific
to a user & tenant/project (what's been called a "scoped" token)
Likewise, the reference implementation of the rest of the
OpenStack projects all require a tenant information to be
included within the token as that token was the identity
refernce inforoamtion - and most OpenStack services were wanting
to know the tenant associated with the token for
authorization/ownership purposes.
Apparently Rackspace's internal implementation provided a token
that was immediately valid for all possible tenants to which the
user was associated, and presumably their internal
implementations of openstack do whatever work is appropriate to
discern and provide that information to the various openstack
services.
The quandary:
In the V3 API, we started off with, and currently define the
token as being specifically mandated to a single tenant, with a
new requirement that if you authorize with just a username and
password, a "default tenant" is used. If for some reason you
have no tenant associated with the userid, the authorization is
to be refused. If the user is associated with more than one
tenant/project, it's possible to use the token to get a list of
other tenants/projects and request a new token specific to one
of those other tenant/projects, but the implementation is
expected to respect and provide a default.
I would like to make "default tenant" a configuration option, and
have it disabled by default. Unscoped tokens are a very useful
construct. In the case where the user has many roles across a
multitude of projects, it is possible to create huge tokens. I
would prefer unscoped tokens to remain, and to be associated with
no tenant. The only operation Keystone should provide with them
is the ability to enumerate tenants, so something like Horizon can
then request an appropriately scoped token.
I am also in favor of limiting the scope of a token to an
endpoint. Even more-so than tenants, scoping a token to an end
point increases security. Once a token has been scoped to an
endpoint, it can only be used on that endpoint. If an endpoint
gets compromised, the damage is limited to resources that endpoint
already has access to. This, in conjunction with pre-auths, could
allow a user to perform an action with a minimum of risk in a
public cloud environment.
A few folks from Rackspace touched on this at the very tail end
of the V3 API review session on Thursday, bringing up that they
had an issue with the token being scoped to a single tenant.
Since this has significant implications to both security and a
potential user experience flow, I wanted to bring the issue up
across the broader community for discussion.
The request outstanding:
Rackspace folks are requesting that the token not be limited to
a single tenant/project, but instead provides a list of
potential tenants against which the token should be considered
valid.
I would like the world to know that we are affectionately calling
such tokens "sloppy tokens" and Joe Savak has adopted the nickname
of "Sloppy Joe" for championing them. Allowing it as an option is
fine, but I would not recommend that this become the norm, or that
we enable this feature by default.
Brief (maybe shoddy) analysis:
This would potentially imply changes to what gets passed as a
part of the authentication reference in the context passed using
auth_token middleware - multiple tenants possible instead of the
currently expected single value - so using that as information
for create() style mechanisms would need to provide some
alternative means of clearly defining what tenant/project should
be owner. It would provide anyone compromising that particular
token with a broader spectrum of impact on a replay style
attack. Likewise, the impact of tenant enable/disable or role
changes would necessarily mean a broader invalidation of all
tokens associated with the user.
On the flip side, it has the potential to remove the
token-reissuance that currently exists when switching contexts
from one project to another (primarily through horizon or other
client/UI/dashboard mechanisms that cache the token).
Feedback and Input desired!
-joe
_______________________________________________
OpenStack-dev mailing list
openstack-...@lists.openstack.org
<mailto:openstack-...@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
Mailing list:https://launchpad.net/~openstack
Post to :openstack@lists.launchpad.net
Unsubscribe :https://launchpad.net/~openstack
More help :https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
<https://launchpad.net/%7Eopenstack>
Post to : openstack@lists.launchpad.net
<mailto:openstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
<https://launchpad.net/%7Eopenstack>
More help : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>
_______________________________________________
Mailing list: https://launchpad.net/~openstack
<https://launchpad.net/%7Eopenstack>
Post to : openstack@lists.launchpad.net
<mailto:openstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
<https://launchpad.net/%7Eopenstack>
More help : https://help.launchpad.net/ListHelp
<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
