Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
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 smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
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 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
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 mailto: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:cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell mailto:openstack-bounces%2Btim.bell=cern...@lists.launchpad.net mailto: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 mailto: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 tel: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 [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net mailto:hp@lists.launchpad.net] *On Behalf Of *Adam Young *Sent:* Tuesday, July 17, 2012 11:55 AM *To:* openstack@lists.launchpad.net mailto: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 https://launchpad.net/%7Eopenstack Post to :openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net 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
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
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 mailto:openstack-bounces%2Btim.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 https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net
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=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
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
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:he...@me.com] Sent: 18 July 2012 20:17 To: Tim Bell Cc: Adam Young; openstack@lists.launchpad.net 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=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 mailto:openstack-bounces%2Btim.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
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
I personally want to see keystone be able to operate as a point of authentication on instances. I don't think everyone wants to see me succeed at that. There is one major impediment to doing that well. That's really providing an NSS style lookup service for verifying users exist in keystone. This would be a necessity for openssh to allow passage of credentials to pam in the event a user did not previously exist in /etc/passwd So... on one hand I think there is tremendous value in keeping usernames unique and domains identifiable as a default and a selectable from a list of availables. On the other hand unless we can build an NSS interface to keystone the benefit I want isn't there. =P That being said. With domains coming into existence can we operate with projects functioning more like groups? Can we not have to choose an operating project ( tenant ) when authenticating to APIs? And just have the individual APIs query all associated projects ( tenants ) and provide appropriate ACLs? As we would see in a posix group? Maybe even map to posix groups on the back end. Maybe that's just a pipe dream. -Matt On Wed, Jul 18, 2012 at 1:26 PM, Joseph Heck he...@mac.com wrote: 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.b...@cern.ch 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:he...@me.com] *Sent:* 18 July 2012 20:17 *To:* Tim Bell *Cc:* Adam Young; openstack@lists.launchpad.net *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=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
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
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
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. smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 (mailto:hp@lists.launchpad.net)] On Behalf Of Adam Young Sent: Tuesday, July 17, 2012 11:55 AM To: openstack@lists.launchpad.net (mailto: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 (mailto: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 (mailto:openstack@lists.launchpad.net) Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
Hi Caitlin, A user is able to be associated with multiple tenants in the current API as well - this API just attempt to make is significantly more clear what you're asking for and what you're getting back. It was one of the earliest requests and requirements of the auth system. For the back-ends of Keystone that allow resetting of passwords, it would generally be an administrator of Keystone (as it is today) that would be required to reset a user's password, but with the additional domain model, it's possible to expand that a bit if a local implementation wanted to allow a domain admin to reset a user's password as well. -joe On May 29, 2012, at 10:18 AM, 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
Allowing a user to be associated with multiple tenants (a.k.a. projects) is what we have currently, and it works reasonably well. It has not produced a significantly more complicated system. I would argue the flipside of your point, which is that the admin permission system in keystone is particularly convoluted and not clearly scoped. The lack of differentiation between the abilities of a project admin vs. a system admin, etc the fact that being granted admin permissions on *any* project gives you admin permissions for *all* of your Openstack installation... There are some very odd issues in the details of that side of the equation. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Caitlin Bestler Sent: Tuesday, May 29, 2012 10:18 AM To: openstack@lists.launchpad.net Subject: [Openstack] Identity API v3 - Why allow multi-tenant users? 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
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
On Tue, 2012-05-29 at 17:18 +, 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? The use case that immediately springs to mind is that of a consultant. A consultant may be working for several clients that all happen to use one OpenStack-powered provider, and it would be handy for that consultant to only have to worry about a single set of login credentials, but still be able to access the relevant parts of all the tenants for which he or she is working. I could imagine several other somewhat similar scenarios, such as the value-added reseller; having multiple tenants allows them to ensure the proper client is billed the proper amount, while still being able to perform whatever their value-add is. -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
In the research environment, we have frequent cases where a user is associated with multiple tenants. For example, when you are finishing work on a previous project but are mainly working on the new one. As we move towards domain/tenant/user, we need to ensure that the tools support multi-tenant per user. Correct accounting is critical. This does require extra code but it is relevant given the use cases. Tim Bell CERN From: openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of Caitlin Bestler Sent: 29 May 2012 19:18 To: openstack@lists.launchpad.net Subject: [Openstack] Identity API v3 - Why allow multi-tenant users? 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? smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
Tim Bell wrote: ➢ In the research environment, we have frequent cases where a user is associated with multiple tenants. For example, when you are finishing work on a previous project but are mainly working on the new one. As we move towards domain/tenant/user, we need to ensure that the tools support multi-tenant per user. Correct accounting is critical. This does require extra code but it is relevant given the use cases. What you are describing strikes me as a single tenant with multiple projects. It is similar to a corporate environment with multiple departments. I am seeing a major problem here when the tenants are truly separate and the only possible administrator in common is the service provider. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
Terminology: Project == Tenant. They are equivalent in Keystone parlance. What you're referring to as a tenant in that last email is the role a domain might play going forward in Keystone. All the best, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Caitlin Bestler Sent: Tuesday, May 29, 2012 11:47 AM To: Tim Bell; openstack@lists.launchpad.net Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users? Tim Bell wrote: ➢ In the research environment, we have frequent cases where a user is associated with multiple tenants. For example, when you are finishing work on a previous project but are mainly working on the new one. As we move towards domain/tenant/user, we need to ensure that the tools support multi-tenant per user. Correct accounting is critical. This does require extra code but it is relevant given the use cases. What you are describing strikes me as a single tenant with multiple projects. It is similar to a corporate environment with multiple departments. I am seeing a major problem here when the tenants are truly separate and the only possible administrator in common is the service provider. ___ 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
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
Just to echo Tim's comments here about the research space - we certainly have this requirement over in NeCTAR (Australia's national cloud for research). Australia actually has entire institutions setup to work in this mode - helping out multiple universities simultaneously with software development et al, and it's certainly a common case with our OpenStack cloud. Regards, Tom On 05/30/2012 07:16 AM, Gabriel Hurley wrote: Terminology: Project == Tenant. They are equivalent in Keystone parlance. What you're referring to as a tenant in that last email is the role a domain might play going forward in Keystone. All the best, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Caitlin Bestler Sent: Tuesday, May 29, 2012 11:47 AM To: Tim Bell; openstack@lists.launchpad.net Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users? Tim Bell wrote: ➢ In the research environment, we have frequent cases where a user is associated with multiple tenants. For example, when you are finishing work on a previous project but are mainly working on the new one. As we move towards domain/tenant/user, we need to ensure that the tools support multi-tenant per user. Correct accounting is critical. This does require extra code but it is relevant given the use cases. What you are describing strikes me as a single tenant with multiple projects. It is similar to a corporate environment with multiple departments. I am seeing a major problem here when the tenants are truly separate and the only possible administrator in common is the service provider. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
