<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/04/2013 12:35 PM, Henry Nash
wrote:<br>
</div>
<blockquote
cite="mid:E9CBA362-BD20-4B38-B194-94FB7015F8C7@linux.vnet.ibm.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 4 Dec 2013, at 13:28, Dolph Mathews <<a
moz-do-not-send="true" 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
moz-do-not-send="true"
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>
</blockquote>
This might be the most insane idea I have heard all day. I love it.<br>
<br>
<blockquote
cite="mid:E9CBA362-BD20-4B38-B194-94FB7015F8C7@linux.vnet.ibm.com"
type="cite">
<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>
</blockquote>
<br>
I suspect it is more of a brainstorming attempt than as an actual
proposal. It can't be binary for many reasons, and strings parsing
gets wonky, especially if you assume utf-8 is in there (how many
bytes per character?)<br>
<br>
The interesting idea is appending the domain id instead of
prepending it. It may be an irrelevant change, but worth mulling.<br>
<br>
An interesting approach would be to do domain prepended user ids
using / so that <br>
<br>
user/domain is the ID, and then the URL would be automagically
segmented: If they leave off the domain, then the userid by itself
would still be valid.<br>
<br>
<br>
<blockquote
cite="mid:E9CBA362-BD20-4B38-B194-94FB7015F8C7@linux.vnet.ibm.com"
type="cite">
<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>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>