Open Stack

On 01/23/2013 05:06 PM, David Chadwick wrote:
>
> 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?
Absolutely,  sloppiness on my part.

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

THere is a proposal to make tokens that span multiple tokens.  I should 
account for that, as I think I was doing it implicitly.  So:


projects : [{ id: id1, roles [role1, role2]}, { id: id2, roles [role1, 
role3]},

>
> 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.
Are you saying that the whole web requests would then be signed? Yes, 
that would work, and would be very effecient, but it would require 
extending all of the HTML aware parts to allow for signatures.  I think 
that would be a  very valuable extension.
>
> so then you would have the additional fields
> key : {X.509 PKC}
> timestamp : {validity time of token}
Good additions.
>
> 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