Perhaps a poor analogy with email - The domain is an arbitrary string that's intended for tenant isolation in large openstack environments. It's a place to hang policy so that you can delegate things like "password changing" (where the keystone backend supports it) to someone other than the keystone-uber-administrator.
I expect almost any smaller/smallish deployment of OpenStack to likely use just a single domain, which is mostly ignored. It's really a mechanism in place for service-provider sized clouds, or where you want to be able to enforce hard boundaries in permissions between groups of tenants by customizing the policy.json files to respect domain_id information. I would expect that in any implementation, it would be independent of email domain names or such - At least that wouldn't be a way that I'd slice up permissions across projects. -joe On Jul 18, 2012, at 9:25 AM, Tim Bell wrote: > Thanks…. My worry is the username. Currently, I have > > OS_USERNAME=timbell > > Not > > OS_USERNAME=timb...@cern.ch > > Does that mean in the future that my > > OS_USERNAME=timbell > OS_DOMAINNAME=cern.ch > > I would like that I could still register as timbell in my domain even if > someone else on the same OpenStack instance has a user id of timbell. > > Cross domain, federated identity as part of an authorization layer would be > an interesting development (as we look to federated clouds and bursting) but > I didn’t see something like that in v3. > > Tim > > From: openstack-bounces+tim.bell=cern...@lists.launchpad.net > [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of > Adam Young > Sent: 18 July 2012 17:46 > To: openstack@lists.launchpad.net > Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users? > > The idea of a Domain is that it is a single administrative entity, such as a > company. > > When a person joins a company, they get an email adddress. THat address > does not change regardless of the position they hold. > > Tenants are administrative groupings below that. It is unfortunate that we > used the name tenants for this, as it actually contradicts the usual meaning > of the term. We will be shortly switching back to using the term projects, > and I think that is clearer. > > > It certainly makes sense for a user to belong to one domain, but have access > to a project controlled in another domain. Here is a scenario. Joe's > Sporting Goods and Local Bank are both companies that have a presense in a > coud provider. Each has their own domain. t...@localbank.com is going to > set up a Point of Sale system for Joe. So Joe creates a project called > joes-point-of-sale and provides access to user t...@localbank.com. > > > > > On 07/18/2012 02:46 AM, Matt Joyce wrote: > I could see service users and security / operations teams having a need to > span many domains. > > -Matt > > On Tue, Jul 17, 2012 at 11:24 PM, Tim Bell <tim.b...@cern.ch> wrote: > > I thought that the v3 API supports domains as a group of tenants which would > make the question rather different. > > Thus, I guess the question is > > A. Should there be users in multiple tenants in a single domain ? > > B. Should there be users in multiple domains ? > > > There are clear use cases for A (such as researchers working on multiple > projects sharing project quotas) > > For B, it is less clear as if I am a domain administrator, I do not want to > be told that I cannot allocate user X since another domain has already taken > it. On the other hand, there is a clear architectural benefit from having the > concept of identity (and authentication) split off from roles and projects. > > Tim > > From: openstack-bounces+tim.bell=cern...@lists.launchpad.net > [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of > John Postlethwait > Sent: 18 July 2012 07:42 > To: Rouault, Jason (Cloud Services) > Cc: openstack@lists.launchpad.net > > Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users? > > Forcing a user to remember different usernames and/or passwords for each > project they are a part of, when it is possible they are part of N projects, > really isn't an acceptable option in my opinion. > > I believe that regardless of the engineering complexities, the end users > shouldn't have to feel pain in order to make engineering the solutions and > features they interact with easier. Software is for end users (in their > various forms) and as such we need to take that into account when we make > decisions. While no functionality is lost per se, there is a major end-user > impact, and that should be reason enough to implement it… > > > John Postlethwait > Nebula, Inc. > 206-999-4492 > > On Tuesday, July 17, 2012 at 4:15 PM, Rouault, Jason (Cloud Services) wrote: > > One benefit is the user does not need to have multiple sets of credentials to > interact with multiple projects. > > Jason > > From: openstack-bounces+jason.rouault=hp....@lists.launchpad.net > [mailto:openstack-bounces+jason.rouault=hp....@lists.launchpad.net] On Behalf > Of Adam Young > Sent: Tuesday, July 17, 2012 11:55 AM > To: openstack@lists.launchpad.net > Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users? > > On 05/29/2012 01:18 PM, Caitlin Bestler wrote: > One of the major complication I see in the API is that users can be > associated with multiple tenants. > > What is the benefit of this? What functionality would be lost if a human user > merely had to use a different account with each tenant? > > There are numerous issues with multi-tenant users. For example, if a user is > associated with multiple tenants, who resets the user’s password? > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > Did you ever get an answer? This has been discussed in depth. > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
