<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 4 Dec 2013, at 13:28, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 24, 2013 at 9:39 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">The #1 pain point I hear from people in the field is that they need to consume read only LDAP but have service users in something Keystone specific. We are close to having this, but we have not closed the loop. This was something that was Henry's to drive home to completion. Do we have a plan? Federation depends on this, I think, but this problem stands alone.<br>
</blockquote><div><br></div><div>I'm still thinking through the idea of having keystone natively federate to itself out of the box, where keystone presents itself as an IdP (primarily for service users). It sounds like a simpler architectural solution than having to shuffle around code paths for both federated identities and local identities.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Two Solutions:<br>
1 always require domain ID along with the user id for role assignments.<br></blockquote><div><br></div><div>From an API perspective, how? (while still allowing for cross-domain role assignments)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2 provide some way to parse from the user ID what domain it is.<br></blockquote><div><br></div><div>I think you meant this one the other way around: Determine the domain given the user ID.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I was thinking that we could do something along the lines of 2 where we provide "domain specific user_id prefix" for example, if there is just one ldpa service, and they wanted to prefix anyting out of ldap with "ldap@", then an id would be "prefix" "field from LDAP". And would be configured on a per domain basis. THis would be optional.<br>
<br>
The weakness is that itbe Log N to determine which Domain a user_id came from. A better approach would be to use a divider, like '@' and then prefix would be the key for a hashtable lookup. Since it is optional, domains could still be stored in SQL and user_ids could be uuids.<br>
<br>
One problem is if someone comes by later an "must" use email address as the userid, the @ would mess them up. So The default divider should be something URL safe but no likely to be part of a userid. I realize that it might be impossible to match this criterion.<br>
</blockquote><div><br></div></div></div></div></blockquote>I know this sounds a bit like "back to the future', but how about we make a user_id passed via the API a structured binary field, containing a concatenation of domain_id and (the actual) user_id, but rather than have a separator, encode the start positions in the first few digits, e.g. something like:</div><div><br></div><div>Digit #<span class="Apple-tab-span" style="white-space:pre"> </span>Meaning</div><div>0-1<span class="Apple-tab-span" style="white-space:pre"> </span>Start position of domain_id, (e.g. this will usually be 4)</div><div>2-3<span class="Apple-tab-span" style="white-space:pre"> </span>Start position of user_id</div><div>4-N<span class="Apple-tab-span" style="white-space:pre"> </span>domain_id</div><div>M-end<span class="Apple-tab-span" style="white-space:pre"> </span>user_id</div><div><br></div><div>We would run a migration that would convert all existing mappings. Further, we would ensure (with padding if necessary) that this "new" user_id is ALWAYS larger than 64chars - hence we could easily detect which type of ID we had.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>For usernames, sure... but I don't know why anyone would care to use email addresses as ID's.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Actually, there might be other reasons to forbid @ signs from IDs, as they look like phishing attempts in URLs.<br></blockquote><div><br></div><div>Phishing attempts?? They need to be encoded anyway...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></blockquote></div><br></body></html>