← Back to team overview

openstack team mailing list archive

Re: [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.chadwick@xxxxxxxxxx>
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.com@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx]
On Behalf Of David Chadwick Sent: Tuesday, November 13, 2012 7:32
AM To: Adam Young Cc: OpenStack Development Mailing List;
openstack@xxxxxxxxxxxxxxxxxxx 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 -- 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"
<ayoung@xxxxxxxxxx <mailto:ayoung@xxxxxxxxxx>>
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 <heckj@xxxxxxx
<mailto:heckj@xxxxxxx>> *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-dev@xxxxxxxxxxxxxxxxxxx
<mailto:openstack-dev@xxxxxxxxxxxxxxxxxxx>>
*Reply-To: *OpenStack Development Mailing List
<openstack-dev@xxxxxxxxxxxxxxxxxxx
<mailto:openstack-dev@xxxxxxxxxxxxxxxxxxx>>

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-dev@xxxxxxxxxxxxxxxxxxx
<mailto:OpenStack-dev@xxxxxxxxxxxxxxxxxxx>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





_______________________________________________
Mailing list:https://launchpad.net/~openstack
Post to     :openstack@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
<mailto:openstack@xxxxxxxxxxxxxxxxxxx> Unsubscribe
: https://launchpad.net/~openstack
<https://launchpad.net/%7Eopenstack> More help   :
https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
<https://launchpad.net/%7Eopenstack> Post to     :
openstack@xxxxxxxxxxxxxxxxxxx
<mailto:openstack@xxxxxxxxxxxxxxxxxxx> Unsubscribe :
https://launchpad.net/~openstack
<https://launchpad.net/%7Eopenstack> More help   :
https://help.launchpad.net/ListHelp





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





_______________________________________________
Mailing list: https://launchpad.net/~openstack Post to     :
openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
https://launchpad.net/~openstack More help   :
https://help.launchpad.net/ListHelp


_______________________________________________ Mailing list:
https://launchpad.net/~openstack Post to     :
openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe :
https://launchpad.net/~openstack More help   :
https://help.launchpad.net/ListHelp



References