Open Stack

David,

All good questions.  On this, as on most things, I think we are in a 
similar mindset.  My concern is not getting the token abstraction 
correct, but the fact that what I am proposing will break some form of 
backwards compatibility.

I'm concerned that by focusing too much on the theoretical, I won't get 
the resolution I need to move forward before the code freeze.

I'll try to answer your questions in line.


On 02/13/2013 11:15 AM, David Chadwick wrote:
> 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.
Correct.  Even PKI based Tokens are really transparent.


>
> 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.
You are correct,except for the versioning.  V2 supports both UUID and 
PKI based tokens.  V3 will support both as well.  UUID tokens must be 
validated by the issuer, PKI can be validated by the recipient. SHA  
HASHes of the PKI tokens may be used like UUID tokens as well, for size 
constraint reasons.
>
> A token can be one time use or many time use. I think that currently 
> it is the latter.
Correct
>
> A token can be a bearer token or tied to the holder (of the 
> permissions). Currently I believe it is a bearer token.
Correct. And I agree that it is wrong.

>
> 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.
That is what I am trying to accomplish.  There may be more elegant ways 
to do this, but my recommendation is the simplest.  Two kinds of tokens, 
and only unscoped can be used to get another token. I see it as an 
analogue to TGTs in Kerberos.
>
> 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?
I'd have to think about it, but I don't think it is a superset.  At 
least, there is no case that I know of where a token contains anything 
that is not in the set of permissions associated to the user directly.

>
>>
>> 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.
Agreed. And, while I could fix it in the trusts model, I think it is 
worthwhile to fix it for all tokens.

>
> 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 the fix I could put in place is that you cannot use a trust-issued 
token to get another token.  I am just going for an even-more-strict 
rule than that.

>
> 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.
Agreed. I never understood the justification for the current 
implementation.  Bascially, though, any valid token for a user can be 
used to get another token, even if the new token is scoped to another 
tenant/project.  I want to  remove this.

>
>>
>> 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).

Exactly.  Trusts is broken without it, but really, so is a lot of other 
things.

>
>>
>>
>> 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.
Shared between three parties:  the user, keystone, and the remote 
service.  Much of the workflow depends on remote services handing over 
tokens to other remote services.  Trusts will provide a better mechanism 
for that, but we need trusts in place before we can rework the other 
services.

>
>  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.

Yes, and My proposal does not fix this.  While I like your previous 
proposal to put a public key into the token, I am not proposing that 
yet.  I am probably more prone to use X509 than to further extend the 
token mechanism.  But that is a tale for another day.

>
>
>  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.
Technically, I am removing something that can currently be done now 
which I consider dangerous. Like removing peanut oil from the spaghetti 
sauce.  Doesn't mean that we shouldn't have a solid model, just that 
this needs to move forward on its own.


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