<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><base href="x-msg://2808/"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I agree with Adam.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>+1 on Default Domain.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>When we first introduced the Keystone Domains BP, things such as usability, flexibility, consistency, and backward compatibility played a critical role in our design. </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Domains are basically containers for users and projects (formerly tenants) for administrative purposes and are not visible to public/service APIs. Therefore, other OS services need not be domain-aware. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Domains does not affect (public) API backward compatibility, as far as OS services are concerned. Therefore, the globally uniqueness requirement for users and projects remains.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If you have no need for domains, you don’t have to change anything. Default Domain is invisible to the V2 APIs.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If you are using domains and your user ID/names are globally unique, you don’t have to change anything.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If you are using domains and are integrating with an existing identity management system backend such as Active Directory, you can still achieve globally uniqueness by having domain name appended to username (i.e. jdoe@acme), or simply using user email as user name for authentication. And I am sure there are other solutions ways as well.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If you have a use case that has not been covered by the above, please let us know. Or please feel free to join us on the weekly Keystone meeting.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Guang<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> openstack-bounces+guang.yee=hp.com@lists.launchpad.net [mailto:openstack-bounces+guang.yee=hp.com@lists.launchpad.net] <b>On Behalf Of </b>Adam Young<br><b>Sent:</b> Tuesday, October 30, 2012 6:34 AM<br><b>To:</b> openstack@lists.launchpad.net<br><b>Subject:</b> Re: [Openstack] [keystone] Domain Name Spaces<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On 10/30/2012 04:00 AM, Henry Nash wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Gabriel, <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So I think you are right to ask that this is made clear and concrete - I'll work with the core contributors of Keystone to make it so.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>To your specific point:<o:p></o:p></p></div><div><p class=MsoNormal>- Let's call the initial Domain, the "Global Domain", rather than the default domain<o:p></o:p></p></div></blockquote><p class=MsoNormal>No. It is default. It is not global. The other domains do not nest inside this domain. Calling it the Global domain is confusing. I would accept: unnamed domain, or implicit domain, but don't think either of those are an improvement to default.<br><br><br><o:p></o:p></p><div><p class=MsoNormal>- If the Cloud Provider doesn't explicitly create any domains, then everything exists in the Global Domain. There is no need to specify a domain in any calls, since everything will default to the Global domain. The v2 API will work just fine (which knows nothing about domains)<o:p></o:p></p></div><p class=MsoNormal>That is correct<br><br><o:p></o:p></p><div><p class=MsoNormal>- If they do create some domains, then they indicate (on creation) whether each of these <i>share</i> the namespace of the Global domain, or have their own <i>private</i> namespace. <o:p></o:p></p></div><p class=MsoNormal>No. Domain are non-overlapping sets.<br><br><o:p></o:p></p><div><p class=MsoNormal>- If all of these new domains were specified as <i>shared</i> then all user and tenant names are still globally unique. A caller still does not technically need to specify a domain, although scoping things down to a domain (or of course project) is likely for most operations (just like it is today)<o:p></o:p></p></div><p class=MsoNormal>I fail to see the benefit.<br><br><o:p></o:p></p><div><p class=MsoNormal>- If, however, some of these new domains were specified as <i>private</i> then any users who are part of a private domain must specify the domain in order to authenticate. By design, authentication will fail if they don't specify a domain (since you won't exist in the global domain). Once a user in a private domain is authenticated, they are scoped to that domain. [implementation: we need to work out whether the domainID is encoded in the token - this is my assumption since this means the Domain Name/ID is NOT required for subsequent requests....and validation, by Keystone, can still be achieved ]<o:p></o:p></p></div><p class=MsoNormal>We are reimplementing tokens/projects here. <br><br><o:p></o:p></p><div><p class=MsoNormal>- It is perfectly possible (but of course up to the Cloud Provider) to support a mixture of <i>shared</i> and <i>private</i> domains (representing different customer types)....but the point being that the Cloud Provider will tell their customers how they should access they system (i.e. provide them with any domain specification that may or may not be required).<o:p></o:p></p></div><p class=MsoNormal><br>I think that this complicates things. I would instead recommend that a provider either go with a single domain or explicit domaiuns, as mixing the two is wierd, but some installations will need to make their existing deployments work.<br><br>I like the idea that the domain will be implicit from the hostname of the web front end, and also possibly of a Keystone endpoint. This can be done with vhosts for Apache, and a simple config value for Eventlet.<br><br><br><br><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Very keen to hear other concerns you may have.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Henry<o:p></o:p></p><div><div><p class=MsoNormal>On 27 Oct 2012, at 21:22, Gabriel Hurley wrote:<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>There are various options for how Horizon can handle the UX problems associated with adding additional domains. Making it a part of the URL is one which could be supported, but I’m not inclined to make that the only method. The implementation details can be hashed out when we get there.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I am more concerned about the experience for CLI/API users; adding more parameters they have to pass is quite unfriendly. And I have to say that Keystone’s track record for handling “default” options has been quite poor (see “default tenant”). The mixed support for lookups via ID vs. name is also a mess. There needs to be consistency around what is unique and in what scope (which is where this thread started). So far I haven’t heard a concrete answer on that.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>For example, if tenants uniqueness is scoped to a domain, and lookups via tenant name are possible, and there’s a default domain… well haven’t you just painted yourself into a corner where tenant names in the default domain must be unique while names in any other domain do not? It’s these kinds of issues that need to really be thought through.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> </span><o:p></o:p></p></div><div style='margin-left:27.0pt'><p class=MsoNormal style='text-indent:-.25in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-</span><span style='font-size:7.0pt;color:#1F497D'> <span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Gabriel</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> </span><o:p></o:p></p></div><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt;border-width:initial;border-color:initial'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;border-width:initial;border-color:initial'><div><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> </span></span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'><a href="mailto:openstack-bounces+gabriel.hurley=nebula.com@lists.launchpad.net">openstack-bounces+gabriel.hurley=nebula.com@lists.launchpad.net</a> [<a href="mailto:openstack-bounces+gabriel.hurley=">mailto:openstack-bounces+gabriel.hurley=</a><a href="mailto:nebula.com@lists.launchpad.net">nebula.com@lists.launchpad.net</a>]<span class=apple-converted-space> </span><b>On Behalf Of<span class=apple-converted-space> </span></b>Adam Young<br><b>Sent:</b><span class=apple-converted-space> </span>Friday, October 26, 2012 4:19 PM<br><b>To:</b><span class=apple-converted-space> </span>Henry Nash<br><b>Cc:</b><span class=apple-converted-space> </span>OpenStack Development Mailing List; <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a> (<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>)<br><b>Subject:</b><span class=apple-converted-space> </span>Re: [Openstack] [keystone] Domain Name Spaces</span><o:p></o:p></p></div></div></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><div><p class=MsoNormal>On 10/26/2012 07:17 PM, Henry Nash wrote:<o:p></o:p></p></div></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>So to pick up on a couple of the areas of contention:<o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>a) Roles. I agree that role names must stay globally unique. One way of thinking about this is that it is not actually keystone that is creating the "role name space" it is the other services (Nova etc.) by specifying roles in their policy files. Until those services support domain specific segmentation, then role names stay global.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>b) Will multi-domains make it more complicated in terms of authorisation - e.g. will the users have to input a Domain Name into Horizon the whole time? The first thing I would say is that if the cloud administrator has create multiple domains, then the keystone API should indeed require the domain specification. However, that should not mean it should be laborious for a Horizon user. In the case where a Cloud Provider has created domains to encapsulate each of their customers - then if they want to let those customer use horizon as the UI, then I would think they want to be able to give each customer a unique URL which will point to a Horizon that "knows which domain to go to".<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal>Yes, I think that this is the solution. It will involve HTTPD virtual hosts, and horizon can then get an additional config parameter "keystone_domain" as part of the wsgi config.<br><br><br><br><br><o:p></o:p></p></div><div><div><p class=MsoNormal> Maybe the url contains the Domain Name or ID in the path, and Horizon pulls this out of its own url (assuming that's possible) and hence the user is never given an option to chose a domain. A Cloud Admin would use a "non domain qualified url" to get to Horizon (basically as it is now) and hence be able to see the different domains. Likewise, in the case of where the Cloud Provider has not chosen to create any individual domains (and is just running the cloud in the default domain), then the "non domain qualified url" would be used to a Horizon that only showed one, default domain and hence no choice is required.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Henry<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div><div><div><div><p class=MsoNormal>On 26 Oct 2012, at 17:31, heckj wrote:<o:p></o:p></p></div></div><div><p class=MsoNormal><br><br><br><o:p></o:p></p></div><div><div><p class=MsoNormal>Bringing conversation for domains in Keystone to the broader mailing lists.<o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div><div><div><div><p class=MsoNormal>On Oct 26, 2012, at 5:18 AM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<o:p></o:p></p></div></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>I think this discussion would be great for both mailing lists.<br clear=all><o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'>-Dolph<br><br><br><o:p></o:p></p><div><div><p class=MsoNormal>On Fri, Oct 26, 2012 at 5:18 AM, Henry Nash <<a href="mailto:henry.nash@mac.com" target="_blank">henry.nash@mac.com</a>> wrote:<o:p></o:p></p></div><div><div><p class=MsoNormal>Hi<o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal><Not sure where best to have this discussion - here, as a comment to the v3api doc, or elsewhere - appreciate some guidance and will transfer this to the right place><o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>At the Summit we started a discussion on whether things like user name, tenant name etc. should be globally unique or unique within a domain. I'd like to widen that discussion to try and a) agree a direction, b) agree some changes to our current spec. Here's my view as an opening gambit:<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>- When a Keystone instance is first started, there is only one, default, Domain. The Cloud Provider does not need to create any new domains, all projects can exist in this default domain, as will the users etc. There is one, global, name space. Clients using the v2 API will work just fine.<o:p></o:p></p></div></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>+1<o:p></o:p></p></div></div></div></blockquote><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Very much what we were thinking for the initial implemenation and rollout to make it backwards "compatible" with the V2 (non-domain) core API<o:p></o:p></p></div></div><div><p class=MsoNormal><br><br><br><o:p></o:p></p></div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-width:initial;border-color:initial;z-index:auto'><div><div><div><p class=MsoNormal>- If the Cloud Provider wants to provide their customers with regions they can administer themselves and be self-contained, then they create a Domain for each customer. It should be possible for users/roles to be scoped to a Domain so that (effectively) administrative duties can be delegated to some users in that Domain. So far so good - all this can be done with the v3 API.<o:p></o:p></p></div></div></div></blockquote><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Not clear on if you're referring to endpoint regions, or just describing domain isolation?<o:p></o:p></p></div></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>I believe you're describing the key use cases behind the domains mechanism to begin with - user and project partitioning to allow for administration of those to be clearly "owned" and managed appropriately.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><p class=MsoNormal><br><br><br><o:p></o:p></p></div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-width:initial;border-color:initial;z-index:auto'><div><div><p class=MsoNormal>- We still have work to do to make sure items in other OS projects that reference tenants (e.g. Images) can take a Domain or Project ID, but we'll get to that soon enough<o:p></o:p></p></div></div></blockquote><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Everything will continue to work with projects, but once middleware starts providing a DOMAIN_ID and DOMAIN_NAME to the underlying service, it'll be up to them to take advantage of it. Images per domain is an excellent example use case.<o:p></o:p></p></div></div></div><div><p class=MsoNormal><br><br><br><o:p></o:p></p></div><div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt;border-width:initial;border-color:initial;border-left-color:rgb(204, 204,
204);z-index:auto'><div><blockquote style='border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal>- However, Cloud Providers want to start enabling enterprise customers to run more and more of the workloads in OpenStack clouds - over and above, the smaller sized companies that are doing this today. For this to work, the encapsulation of a Domain need, I think, to be able to be stricter - and this is where the name space comes into play. I think we need to allow for a Domain to have its own namespace (i.e. users, roles, projects etc.) as an option. I see this as a first step to allowing each Domain to have its own AuthZ/N service (.e.g external ldap owned and hosted by the customer who will be using the Domain)<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Implementation:<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>- A simplistic version would just allow a flag to specified on Domain creation that said whether this a "private" or "shared" Domain. Shared would use the current global name space (and probably be the default for compatibility reasons).<o:p></o:p></p></div></div></div></blockquote><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>I like the direction of this -- need to digest implications :)<o:p></o:p></p></div></div></div></blockquote><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>I like the idea conceptually - but let's be clear on the implications to the end users:<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Where we're starting is preserving a global name space for project names and user names. Allowing a mix of segregated and global name spaces imposes a burden of additional data being needed to uniquely place authentication and authorization.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>We've been keeping to 2 key pieces of info (username, password) to get authenticated - and then (via CLI or Horizon dashboard) you can choose from a list of protential projects and carry on. In most practical circumstances, any user working primarily from the CLI is already providing 3-4 pieces of information:<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>* username<o:p></o:p></p></div></div><div><div><p class=MsoNormal>* password<o:p></o:p></p></div></div><div><div><p class=MsoNormal>* tenant name<o:p></o:p></p></div></div><div><div><p class=MsoNormal>* auth_url<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>to access and use the cloud.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>By allowing domains to be their own namespaces, we're adding another element that will be absolutely required to identify the person authenticating:<o:p></o:p></p></div></div><div><div><p class=MsoNormal> * domain name<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>implying a cascade of changes to the user experience all the way down through horizon.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><p class=MsoNormal><br><br><br><o:p></o:p></p></div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-width:initial;border-color:initial'><div><div><div><p class=MsoNormal>- A more flexible approach would be to allow the specification of where the various sub-services of Keystone (e.g. AuthN/Z, Service Catalogue, Resources (i.e Users, Projects)) are hosted. The defaults would all point back to the default domain (i.e. are global and shared), but instead could be specified as "self" (I.e. the new Domain), or, in the future, some other external location, e.g. for a remote ldap.<o:p></o:p></p></div></div><div><div><p class=MsoNormal>- As an aside, this multi-name space model could also allow the Cloud Provider their own name space, separate from their customers - i.e. they will have a need to create admins who can just create domains and on-board customers into those domains. These users & roles could exist in the default domain, while all the customers' users/roles exist solely within their own domains.<o:p></o:p></p></div></div><div><div><p class=MsoNormal>- One potential problem I do see is with roles. Today, the role name is, if I understand it correctly, a kind of shared secret between, other services and Keystone - e.g. it is the actual name of a given role, say "ProjectAdmin" , that must match in, say, the Nova policy file and the role assignment in Keystone (please correct me if I have this wrong).<o:p></o:p></p></div></div></div></blockquote><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>You're 100% correct.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-width:initial;border-color:initial'><div><div><p class=MsoNormal>How would that work if the role names were not unique across Domains?<o:p></o:p></p></div></div></blockquote><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Not that we would want admins to ever see Role ID's, or edit policy files with role ID's, but they provide a potential solution.<o:p></o:p></p></div></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>The different role names would need to be accounted for in the policy files the way they're set up today - the enforcement there is all at the service level. There's no current provision for evaluating policy differently based on domain. While that's possible, it sounds like a tremendous cascade of additional complication, as the policy, and roles, are all set up and managed by deployers.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>I think this might be an interesting addition in the future, but want to keep the initial implementation and roll-out of the policy mechanisms and domains consistent and simple for a first roll-out iteration.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt;border-width:initial;border-color:initial;border-left-color:rgb(204, 204,
204);z-index:auto'><div><blockquote style='border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal>What is the desired functionality for a Cloud Provider wanting to give their enterprise customers this level of flexibility - will they have dedicated Nova endpoints anyway? Sounds too rigid. This might tie into another bp we are working on at IBM in terms of using Availability zones to allow Cloud Providers to divide up their compute resources in a more flexible way.<o:p></o:p></p></div></div><div><div><p class=MsoNormal>- Finally, I wanted to raise the subject of whether we should make it a goal to remain compatible with the v2 API<span class=apple-converted-space> </span><i>once the cloud provider starts creating additional domains</i>.<o:p></o:p></p></div></div></div></blockquote><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Joe and I briefly discussed this at the summit. As a migration to v3, we'd obviously be creating the default domain and mapping all existing users/projectse/etc to it. I'd be fine if the v2 implementation ONLY interacted with resources in that default domain; i.e. if you want to use domains, upgrade to a v3 client.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><blockquote style='border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-width:initial;border-color:initial;border-left-color:rgb(204, 204,
204)'><div><div><div><p class=MsoNormal>As stated above, if just the default domain is being used, then fine. And while I agree that, technically, the v2 API should still work with the above if all the other domains point back to the default domain for their sub-services - it feels overly flexible (and maybe wrong conceptually) to support v2 semantics across a multi-domain installation.<o:p></o:p></p></div></div></div></blockquote><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>+1<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><blockquote style='border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-width:initial;border-color:initial;border-left-color:rgb(204, 204,
204)'><div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Interested in everyone else's view.<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Henry<o:p></o:p></p></div></div><div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div></blockquote></div><div><p class=MsoNormal> <o:p></o:p></p></div></blockquote></div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div></div><div><p class=MsoNormal> <o:p></o:p></p></div></div></div></div></div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><br><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><o:p></o:p></pre><pre>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><o:p></o:p></pre><pre>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><o:p></o:p></pre><pre>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><o:p></o:p></pre><p class=MsoNormal><o:p> </o:p></p></div></body></html>