Open Stack

Can you put this up as a review on the identity API? There's already a
rough cut there that could use some love.


-Dolph


On Wed, Jan 23, 2013 at 6:50 PM, Adam Young <ayoung at redhat.com> wrote:

> 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 <OpenStack-dev at lists.openstack.org>
>>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>
>>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130123/49408f52/attachment.html>