Open Stack

On 23/01/2013 21:14, Adam Young wrote:
> Tokens are not where we want Keystone to be long term.  Since they are
> bearer tokens, they are susceptible to relay attacks.  Thus, I don't
> want the authentication process bound to only producing tokens.
>
> If we do /v3/authn/tokens  as the API for creating new tokens, we can do
> /v3/authn/X509 or something else in the future.
>
>
> Also, the token format should be nailed down, and simplified from the
> artifacts that the current tokens contain.  We need to remove the term
> metadata from usage, and instead talk in terms of the contents of the
> token itself.
>
>
> Here's a strawman.
> {
> user : { id,  other user specific attributes },
> domain : {id},
> project : { roles [role ids]},

dont you need the project id as well?
What is the significance of putting the roles inside the project 
construct rather than simply listing them as separate elements as

project: {id}
roles: {role ids}

By the way, introducing holder of key into tokens solves the bearer 
problem and does not require SSL/TLS. What it requires is simply that 
the client signs the message containing the token with the key and 
includes a nonce/timestamp in the signed message so that the recipient 
can validate that the user is the holder of the token and the token has 
not been replayed.

so then you would have the additional fields
key : {X.509 PKC}
timestamp : {validity time of token}

regards

David


> auth_mechanisms[],
> services:[
>      compute: [https://nova/endpoint],
>      identity: [https://keystone/endpoint],
> ...
> ]
> }
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev