+1; I think that's a great overview of where we're starting with domains in Grizzly / identity api v3.
However, where we want to take domains in Grizzly+1 / identity-api v3.1 is certainly ripe for discussion. -Dolph On Tue, Oct 30, 2012 at 10:19 AM, Yee, Guang <[email protected]> wrote: > I agree with Adam.**** > > ** ** > > +1 on Default Domain.**** > > ** ** > > When we first introduced the Keystone Domains BP, things such as > usability, flexibility, consistency, and backward compatibility played a > critical role in our design. 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. **** > > ** ** > > 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.**** > > ** ** > > If you have no need for domains, you don’t have to change anything. > Default Domain is invisible to the V2 APIs.**** > > ** ** > > If you are using domains and your user ID/names are globally unique, you > don’t have to change anything.**** > > ** ** > > 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.**** > > ** ** > > 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.*** > * > > ** ** > > ** ** > > Guang**** > > ** ** > > ** ** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Adam > Young > *Sent:* Tuesday, October 30, 2012 6:34 AM > *To:* [email protected] > > *Subject:* Re: [Openstack] [keystone] Domain Name Spaces**** > > ** ** > > On 10/30/2012 04:00 AM, Henry Nash wrote:**** > > Gabriel, **** > > ** ** > > 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.**** > > ** ** > > To your specific point:**** > > - Let's call the initial Domain, the "Global Domain", rather than the > default domain**** > > 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. > > > **** > > - 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)**** > > That is correct > > **** > > - If they do create some domains, then they indicate (on creation) whether > each of these *share* the namespace of the Global domain, or have their > own *private* namespace. **** > > No. Domain are non-overlapping sets. > > **** > > - If all of these new domains were specified as *shared* 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)**** > > I fail to see the benefit. > > **** > > - If, however, some of these new domains were specified as *private* 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 ]**** > > We are reimplementing tokens/projects here. > > **** > > - It is perfectly possible (but of course up to the Cloud Provider) to > support a mixture of *shared* and *private* 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).**** > > > 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. > > 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. > > > > **** > > ** ** > > Very keen to hear other concerns you may have.**** > > ** ** > > Henry**** > > On 27 Oct 2012, at 21:22, Gabriel Hurley wrote:**** > > > > **** > > 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.*** > * > > **** > > 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.**** > > **** > > 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.**** > > **** > > - Gabriel**** > > **** > > *From:* [email protected] [ > mailto:openstack-bounces+gabriel.hurley=<openstack-bounces+gabriel.hurley=> > [email protected]] *On Behalf Of *Adam Young > *Sent:* Friday, October 26, 2012 4:19 PM > *To:* Henry Nash > *Cc:* OpenStack Development Mailing List; [email protected] ( > [email protected]) > *Subject:* Re: [Openstack] [keystone] Domain Name Spaces**** > > **** > > On 10/26/2012 07:17 PM, Henry Nash wrote:**** > > So to pick up on a couple of the areas of contention:**** > > **** > > 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.**** > > **** > > 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".**** > > 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. > > > > > **** > > 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.**** > > **** > > **** > > Henry**** > > **** > > On 26 Oct 2012, at 17:31, heckj wrote:**** > > > > > **** > > Bringing conversation for domains in Keystone to the broader mailing lists. > **** > > **** > > **** > > On Oct 26, 2012, at 5:18 AM, Dolph Mathews <[email protected]> > wrote:**** > > I think this discussion would be great for both mailing lists. > **** > > **** > > -Dolph > > > **** > > On Fri, Oct 26, 2012 at 5:18 AM, Henry Nash <[email protected]> wrote:*** > * > > Hi**** > > **** > > <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>**** > > **** > > 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:**** > > **** > > - 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.*** > * > > **** > > +1**** > > **** > > Very much what we were thinking for the initial implemenation and rollout > to make it backwards "compatible" with the V2 (non-domain) core API**** > > > > > **** > > - 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.**** > > **** > > Not clear on if you're referring to endpoint regions, or just describing > domain isolation?**** > > **** > > 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.**** > > **** > > > > > **** > > - 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**** > > **** > > 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.**** > > > > > **** > > **** > > - 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)**** > > **** > > Implementation:**** > > **** > > - 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).**** > > **** > > I like the direction of this -- need to digest implications :)**** > > **** > > I like the idea conceptually - but let's be clear on the implications to > the end users:**** > > **** > > 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.**** > > **** > > 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:**** > > **** > > * username**** > > * password**** > > * tenant name**** > > * auth_url**** > > **** > > to access and use the cloud.**** > > **** > > By allowing domains to be their own namespaces, we're adding another > element that will be absolutely required to identify the person > authenticating:**** > > * domain name**** > > **** > > implying a cascade of changes to the user experience all the way down > through horizon.**** > > **** > > > > > **** > > - 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.**** > > - 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.**** > > - 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).**** > > **** > > You're 100% correct.**** > > **** > > How would that work if the role names were not unique across Domains?**** > > **** > > 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.**** > > **** > > 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.**** > > **** > > 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.**** > > **** > > 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.**** > > - Finally, I wanted to raise the subject of whether we should make it a > goal to remain compatible with the v2 API *once the cloud provider starts > creating additional domains*.**** > > **** > > 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.**** > > **** > > 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.**** > > **** > > +1**** > > **** > > **** > > Interested in everyone else's view.**** > > **** > > Henry**** > > **** > > **** > > **** > > **** > > ** ** > > > > > **** > > _______________________________________________**** > > Mailing list: https://launchpad.net/~openstack**** > > Post to : [email protected]**** > > Unsubscribe : https://launchpad.net/~openstack**** > > More help : https://help.launchpad.net/ListHelp**** > > ** ** > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
