<div dir="ltr">Can you put this up as a review on the identity API? There's already a rough cut there that could use some love.</div><div class="gmail_extra"><br clear="all"><div><div><br></div>-Dolph</div>
<br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 6:50 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 01/23/2013 05:06 PM, David Chadwick wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 23/01/2013 21:14, Adam Young wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tokens are not where we want Keystone to be long term. Since they are<br>
bearer tokens, they are susceptible to relay attacks. Thus, I don't<br>
want the authentication process bound to only producing tokens.<br>
<br>
If we do /v3/authn/tokens as the API for creating new tokens, we can do<br>
/v3/authn/X509 or something else in the future.<br>
<br>
<br>
Also, the token format should be nailed down, and simplified from the<br>
artifacts that the current tokens contain. We need to remove the term<br>
metadata from usage, and instead talk in terms of the contents of the<br>
token itself.<br>
<br>
<br>
Here's a strawman.<br>
{<br>
user : { id, other user specific attributes },<br>
domain : {id},<br>
project : { roles [role ids]},<br>
</blockquote>
<br>
dont you need the project id as well?<br>
</blockquote></div>
Absolutely, sloppiness on my part.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What is the significance of putting the roles inside the project construct rather than simply listing them as separate elements as<br>
<br>
project: {id}<br>
roles: {role ids}<br>
</blockquote>
<br></div>
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:<br>
<br>
<br>
projects : [{ id: id1, roles [role1, role2]}, { id: id2, roles [role1, role3]},<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
</blockquote></div>
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.<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
so then you would have the additional fields<br>
key : {X.509 PKC}<br>
timestamp : {validity time of token}<br>
</blockquote></div>
Good additions.<div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
regards<br>
<br>
David<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
auth_mechanisms[],<br>
services:[<br>
compute: [<a href="https://nova/endpoint" target="_blank">https://nova/endpoint</a>],<br>
identity: [<a href="https://keystone/endpoint" target="_blank">https://keystone/endpoint</a>],<br>
...<br>
]<br>
}<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>