Open Stack

Hi Adam

I think you need to look at this from the modelling perspective first 
before deciding upon the solution to your problem. The first thing to 
ask, is what is (the conceptual model of) a token that is being used by 
Keystone. A token could either contain

i) a set of permissions or
ii) a pointer to a set of permissions held external to the token.

A token can either be
a) opaque or
b) transparent
to any observer. It would be preferable to say it should always be 
opaque, but I dont think this is currently the case.

A token could either be
1. Validatable directly by the recipient
2. Only validated by the issuer
I think V2 is 2. and V3 is 1. but I could be wrong.

A token can be one time use or many time use. I think that currently it 
is the latter.

A token can be a bearer token or tied to the holder (of the 
permissions). Currently I believe it is a bearer token.

I dont fully know what the current Keystone token model is, or if it is 
documented anywhere.  Do you know? I have made my best guesses above for 
the answers I think I know.

Now to your specific questions

On 13/02/2013 14:33, Adam Young wrote:
> Right now, Keystone will allow you to get a token based on a previous
> token.   It does not matter if the original token is for a different
> scope, more restricted, than the second token.
>

If the token is modelled as a set of permissions, then it should not be 
possible to get an increased set of permissions from a token since where 
would they come from? Only an equal or reduced set of permissions should 
be swappable for the original token.

If a token is a pointer to a (super)set of permissions, then it should 
be possible to ask for any subset of permissions from the superset.

My feeling is that perhaps the current token is both:
a (pointer to) a subset of permissions of the user and
a pointer to the superset of permissions of the user. Is this the case?

>
> While writing the trusts implementation, I realize that carrying this
> rule forward would open up a security hole.  A user with a token based
> on a trust would be able to get a new token for any of the privileges of
> the trustor.  The whole point of trusts was to scale down the scope of
> access from a token, not to increase it.

There is clearly a big hole in either the token or trusts model or both 
if this is the case.

If I have a delegated permission (which you call a trust), then this is 
my permission that was delegated to me. I am not the delegator so I 
cannot get any of the permissions belonging to him. Furthermore any 
token I might have that contains my delegated permission, is my token 
and does not belong to the delegator (though he can revoke it), nor does 
it hold the delegator's permissions. It holds the delegator's delegated 
permissions. The delegator still has his own permissions in his own tokens.

So I dont see why, if your delegation model is correct, a delegate can 
ever get his hands on the permissions of the delegator. Something is 
broken if this is the case.

>
> I would like to propose the following rule. It will have to apply to
> both the V2 and V3 versions of the APIs.
>
> Only an unscoped token can be used to retrieve another token.

It depends upon what your model of a token is, and this should be 
completely unrelated to delegation (trusts).

>
>
> In order to get an unscoped token, you have to pass in userid and
> password, or one of the REMOTE_USER mechanisms.
> It is technically OK to use an unscoped token to get another token, so
> long as the time out is honored, but I am not sure if that provides any
> real benefit.
>
> I could make a one-off exception for trust tokens.  However, if we don't
> address this issue now, I suspect it will come back to haunt us later.
>
> Here is a longer rationalization.
>
> Tokens are a symetric shared secret.

Shared between whom? If this is your model of a token, I would suggest 
it is not at a high enough level. It does not say conceptually what the 
token is, but rather how it is implemented.

  If you have the token, you have
> the permissions of the user.

which user? The user to whom the token belongs? Then this is because 
your tokens are currently bearer tokens. So they effectively belong to 
anyone who can grab them.


  Thus, a token should not be spread
> around.

Clearly not if they are bearer tokens.

  Ideally, tokens should contain just the minimal amount of
> permissions to accomplish the task at hand.

Agreed

  THat way, if they get
> intercepted, they can only be used to do minimal amounts of damage.  If
> a user has access to multiple projects (tenants), the token shoud not
> provide access to the tenants other than the one for which it is
> allocated.  Right now, due to token reissue,  a token for Project A can
> be used to get a token for Project B.

Not sure how this fits in with your model of a token being a shared 
secret :-)

>
> In the future, we are talking about scoping tokens to domains,
> endpoints, and other containers.  Lets choose now to limit the amount of
> exposure on a single token.

Lets choose first to have a clear model of what a token is now, and what 
we would like it to be in the future. Otherwise we are just building 
complex layers of spaghetti around some ambiguous ill conceived 
undocumented idea of what a token is or might be.

regards

David

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