openstack team mailing list archive

[Dolph Mathews <dolph.mathews@xxxxxxxxx>]

+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 <guang.yee@xxxxxx> 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:* openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx [mailto:
> openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx] *On Behalf Of *Adam
> Young
> *Sent:* Tuesday, October 30, 2012 6:34 AM
> *To:* openstack@xxxxxxxxxxxxxxxxxxx
>
> *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:* openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx [
> mailto:openstack-bounces+gabriel.hurley=<openstack-bounces+gabriel.hurley=>
> nebula.com@xxxxxxxxxxxxxxxxxxx] *On Behalf Of *Adam Young
> *Sent:* Friday, October 26, 2012 4:19 PM
> *To:* Henry Nash
> *Cc:* OpenStack Development Mailing List; openstack@xxxxxxxxxxxxxxxxxxx (
> openstack@xxxxxxxxxxxxxxxxxxx)
> *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 <dolph.mathews@xxxxxxxxx>
> wrote:****
>
> I think this discussion would be great for both mailing lists.
> ****
>
>  ****
>
> -Dolph
>
>
> ****
>
> On Fri, Oct 26, 2012 at 5:18 AM, Henry Nash <henry.nash@xxxxxxx> 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     : openstack@xxxxxxxxxxxxxxxxxxx****
>
> Unsubscribe : https://launchpad.net/~openstack****
>
> More help   : https://help.launchpad.net/ListHelp****
>
> ** **
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>