<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">David,<div><br></div><div>So a few things are going on here:</div><div><br></div><div>1) Traditionally (in the pre-domain world), user name was "globally unique"....which really means unique within all openstack services sharing a keystone instance.  The same was true of tenant name.</div><div>2) In v3, if we kept this the same, then enterprises would find this restriction (particularly the one for tenants) unacceptable - some of them will expect free-rein over what they can call any names attribute (e.g. project name, user name etc.) inside the domain in which they are being hosted</div><div>3) So v3, optionally allows the creation of a domain with a private name space for user names and/or project names</div><div>4) For Users, when they are created, you can optionally specify the domain they are "owned by".  If you specify a domain (say, "Kent") which was created with a private user name space, then for that specific user, its name only has to be unique within that domain (i.e. there can be other "David"'s in other private user space domains as well as a "David" shared across all other non-private domains).   That is what the comment is trying to say.</div><div>5) To answer your other questions specifically:</div><div>- How do you tell if a user name is globally or domain-unique?  For a v3 api, the domain_id of the owning domain is in the user entity, look that up and see if it is has the 'private_user_namespace' flag set to True.  </div><div>- Who is the owner of a "globally unique username"?  It can be any domain that has 'private_user_namespace' flag set to False, including the default domain<br><div><div>On 26 Jan 2013, at 17:08, Dolph Mathews wrote:</div><div>- In your example of the two different domains, these would not be the same user in the current implementation that is underway - i.e. a user is either globally-unique or domain-unique.</div><div><br></div><div>As an aside, we had the discussion as to whether we should just say that all domains have private name spaces....although we are trying to balance (as usual) backward compatibility with adding new features.  For instance, one implication of a domain with a private user namespace is that, as Dolph says, you must either supply user_ID or username+domain in order to authenticate.  We wanted to keep that requirement to ONLY those domains that really needed it...not make it the norm for v3.  This would, for instance, allow a Folsom cloud provider, who hosts many individual or small enterprise accounts, to upgrade to Grizzly and</div><div><br></div><div>a) Continue to host all those existing accounts (by default the all users and projects will be in the default domain)</div><div>b) Start to add medium enterprises in domains (who perhaps are happy without private namespaces)...without affecting a)</div><div>c) Start to add some larger enterprises in domains with their own private namespaces...without affecting a) or b)</div><div><br></div><div>Henry</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Relevant blueprint: <a href="https://blueprints.launchpad.net/keystone/+spec/domain-name-spaces">https://blueprints.launchpad.net/keystone/+spec/domain-name-spaces</a><div><br></div><div style="">Corresponding spec change: <a href="https://review.openstack.org/#/c/18805/">https://review.openstack.org/#/c/18805/</a></div>
<div style=""><br></div><div style="">These changes have not been implemented yet.</div><div style=""><br></div><div style="">Essentially it's an opt-in change of behavior per domain. Auth for users and projects within those domains must either be identified by globally-unique ID, or a combinations of owning domain and user/project name.</div>
<div style=""><br></div><div style="">Users and projects are namespaced by their owning domain, so the configuration of two different domains wouldn't apply to a single user or project.</div></div><div class="gmail_extra"><br clear="all">
<div><div><br></div>-Dolph</div>
<br><br><div class="gmail_quote">On Sat, Jan 26, 2013 at 4:04 AM, David Chadwick <span dir="ltr"><<a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The keystone v3 API contains the following statement in the Users section<br>
<br>
Either globally or domain unique username, depending on owning domain.<br>
<br>
Can someone explain what this means please.<br>
<br>
More specifically, this states that a username is either globally unique across all domains, or is locally defined in a domain.<br>
<br>
First question. How can anyone tell the difference between a globally unique username and a domain specific username?<br>
<br>
Second, who or what is the owning domain for a globally unique username?<br>
<br>
Finally why should the owning domain determine whether the username is globally unique or not? What if owning domain 1 determines that username1 is globally unique and owning domain 2 determines that username1 is locally unique to itself?<br>

<br>
thanks<br>
<br>
David<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></div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></body></html>