767940 - Issue specific read/write tokens

Status: RESOLVED INVALID

(Cloud Services Graveyard :: Server: Token, defect)

Description

[Alexis Metaireau (:alexis)]

It could be useful to issue different kinds of tokens so we can track who is able to do what exactly.

Each service could tell if it's possible for it to issue read and write tokens or not. And then sign with a particular derivated key from the master one. 

Technically, this would not be that different from having two different services from the reads and for the writes. I suggest that:

1. Issued contain one more key (permission) which can either be read, write or read+write
2. the token is signed with a key that is derivated from the master using the permission as salt.
3. then everything works as usual, but the node part needs to check that it's accepting the given permission.

anyone having thoughts on that?

Comment 1

[Gregory Szorc [:gps]]

How does the token server know which clients can be granted which permissions?

I think the proper way to do this is for each service to expose a set of enumerated permissions. These are just generic strings or integer values that can be combined to form a bit mask, etc. On token request time, the client requests which permissions it wants. Magic ensues. I'm intentionally vague here because a correct permissions model is hard to design. And, there will certainly be cases where read-write are not the only required permissions. We certainly don't want to limit the token server to what a specific use case is today.

Comment 2

[Ryan Kelly [:rfkelly]]

I like the idea of embedding finer-grained permissions in the tokens, and I agree with :gps that enumerating permissions should be up to each application.  For example, some applications might like to have separate "append" and "delete" permissions.

OAuthv2 has a related notion of "scope" built into its design that may be of interest: http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-3.3

It's not clear to me what advantage is gained by deriving separate signing keys for each permission, rather than using a single signing key and embedding the permissions in the token.  It's an interesting idea to be sure, but I'd like to see a clear win that we get in exchange for the additional complexity.

Comment 3

[Tarek Ziadé (:tarek)]

(In reply to Gregory Szorc [:gps] from comment #1)
> How does the token server know which clients can be granted which
> permissions?
> 
> I think the proper way to do this is for each service to expose a set of
> enumerated permissions. These are just generic strings or integer values
> that can be combined to form a bit mask, etc. On token request time, the
> client requests which permissions it wants. Magic ensues. I'm intentionally
> vague here because a correct permissions model is hard to design. And, there
> will certainly be cases where read-write are not the only required
> permissions. We certainly don't want to limit the token server to what a
> specific use case is today.

A list of generic string sounds like the best approach to me, so we can have app-specific permissions 

I also agree there's no need to make the signing more complex

Comment 4

[Alexis Metaireau (:alexis)]

(In reply to Gregory Szorc [:gps] from comment #1)
> How does the token server know which clients can be granted which
> permissions?

Fully agree with you on this. That's the server who knows which permissions are valid or not. I was thinking about making this a configuration setting, in addition to the other already in place.

Another question that come to mind is how the client will ask for a particular permission, and how should we check that she has the right to access this particular permission. If we can come with a complete list of possible permissions, any client would then use a subset of those ifr they want to.

For now we have read, write, append, delete. Anything else?

(In reply to Ryan Kelly [:rfkelly] from comment #2)
> It's not clear to me what advantage is gained by deriving separate signing keys for each
> permission, rather than using a single signing key and embedding the permissions in the
> token.

That's completely true: we don't need to derivate another key. It could be useful only if the nodes didn't had the same access to some resources (for instance if some nodes had the rights to write and some other didn't) but that's not the case.

OAuthV2 "scope" seems to be exactly what we are looking for, except the fact that they don't define the allowed scopes. Do you have any example of a service using this ATM?

Comment 5

[David Chan [:dchan]]

(In reply to Alexis Metaireau (:alexis) from comment #4)
> (In reply to Ryan Kelly [:rfkelly] from comment #2)
> > It's not clear to me what advantage is gained by deriving separate signing keys for each
> > permission, rather than using a single signing key and embedding the permissions in the
> > token.
> 
> That's completely true: we don't need to derivate another key. It could be
> useful only if the nodes didn't had the same access to some resources (for
> instance if some nodes had the rights to write and some other didn't) but
> that's not the case.
> 
> OAuthV2 "scope" seems to be exactly what we are looking for, except the fact
> that they don't define the allowed scopes. Do you have any example of a
> service using this ATM?

Scope is an arbitrary list of service defined permissions from my understanding.
Facebook uses scope
http://developers.facebook.com/docs/reference/dialogs/oauth/

I agree with :gps and :rfkelly on embedding the permissions within the token. Tokenserver may or may not check to see if a service allows the requested permissions. However the service will still have to check the permissions upon receiving the token.

Comment 6

[Alexis Metaireau (:alexis)]

Closing, this will not be handled by the tokenserver.