openstack team mailing list archive

["Yee, Guang" <guang.yee@xxxxxx>]

The keystone-domains blueprint which proposed by HP does not preclude you from doing either one. See

 

https://blueprints.launchpad.net/keystone/+spec/keystone-domains

http://etherpad.openstack.org/keystone-domains

http://etherpad.openstack.org/KeystoneRoles

 

Domains are basically containers for users and projects (formerly tenants) for administrative purposes and are not visible to public/service APIs. If you have a use case that is not covered by the BP, please let us know.

 

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.

 

If you are using domains and 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, or simply using user email as user name for authentication. And I am sure there are other ways as well.

 

 

Guang

 

 

From: openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Joseph Heck
Sent: Wednesday, July 18, 2012 1:26 PM
To: Tim Bell
Cc: Joseph Heck; openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users?

 

Got it. Right now usernames are defined as global across all domains. The side effect of this is that you only need a username and password to auth through keystone, with domain being something that could be "looked up". If we make usernames specific to a domain (I.e. globally unique), then we'll need to make a domain name or id mandatory for the simplest auth case as well. 

 

Some of the gents at HP have been advocating for the additional requirement of domain and segmented namespaces, so far I've been trying to maintain the "only need user and pass to auth" compatibility like the existing structure and V2 API. 

 

What do you think?

-joe


On Jul 18, 2012, at 11:30 AM, Tim Bell <Tim.Bell@xxxxxxx> wrote:

 

Joe,

 

We find the domain approach very interesting for the private cloud scenario also. CERN has several large collaborations, each with multiple projects and independent quotas and roles.  Using a ‘default’ domain, where OS_DOMAINNAME is not specified would be fine for our general use case.

 

My question is if the user id name space is per domain or per IaaS instance ? I suspect this has significant implications in areas such as Horizon login and API compatibility.

 

Tim

 

From: Joseph Heck [mailto:heckj@xxxxxx] 
Sent: 18 July 2012 20:17
To: Tim Bell
Cc: Adam Young; openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users?

 

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=timbell@xxxxxxx

 

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.ch@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+tim.bell=cern.ch@xxxxxxxxxxxxxxxxxxx] On Behalf Of Adam Young
Sent: 18 July 2012 17:46
To: openstack@xxxxxxxxxxxxxxxxxxx
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.  tom@xxxxxxxxxxxxx  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 tom@xxxxxxxxxxxxx.




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.Bell@xxxxxxx> 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.ch@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+tim.bell <mailto:openstack-bounces%2Btim.bell> =cern.ch@xxxxxxxxxxxxxxxxxxx] On Behalf Of John Postlethwait
Sent: 18 July 2012 07:42
To: Rouault, Jason (Cloud Services)
Cc: openstack@xxxxxxxxxxxxxxxxxxx


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.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+jason.rouault=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Adam Young
Sent: Tuesday, July 17, 2012 11:55 AM
To: openstack@xxxxxxxxxxxxxxxxxxx
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 <https://launchpad.net/%7Eopenstack> 
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack <https://launchpad.net/%7Eopenstack> 
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 <https://launchpad.net/%7Eopenstack> 

Post to : openstack@xxxxxxxxxxxxxxxxxxx

Unsubscribe : https://launchpad.net/~openstack <https://launchpad.net/%7Eopenstack> 

More help : https://help.launchpad.net/ListHelp

 


_______________________________________________
Mailing list: https://launchpad.net/~openstack <https://launchpad.net/%7Eopenstack> 
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack <https://launchpad.net/%7Eopenstack> 
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

 

_______________________________________________
Mailing list:  <https://launchpad.net/~openstack> https://launchpad.net/~openstack
Post to     :  <mailto:openstack@xxxxxxxxxxxxxxxxxxx> openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe :  <https://launchpad.net/~openstack> https://launchpad.net/~openstack
More help   :  <https://help.launchpad.net/ListHelp> https://help.launchpad.net/ListHelp

Attachment: smime.p7s
Description: S/MIME cryptographic signature