Private name spaces for domains
With the v3 API, the Domain concept is designed to encapsulate users and projects representing some kind of logical entity (e.g. division in an enterprise, customer of a service provider etc.). However, in an effort preserve backward compatibility with the v2 API, the name space for user-defined identifiers (e.g. user name, project name) are required to still be globally unique, rather than simply unique to the holding domain. This requirement for global uniqueness will cause problems for certain cloud providers - hence what is needed is for each domain to have a private name space. From an implementation point of view, migrations from v2 Identity implementations are protected, since they will be initially stored in a single (Default) domain (which means the v2 uniqueness requirements will of course still hold true within that single domain)
Blueprint information
- Status:
- Complete
- Approver:
- Joseph Heck
- Priority:
- Medium
- Drafter:
- Henry Nash
- Direction:
- Approved
- Assignee:
- Henry Nash
- Definition:
- Approved
- Series goal:
- Accepted for grizzly
- Implementation:
-
Implemented
- Milestone target:
-
2013.1
- Started by
- Henry Nash
- Completed by
- Thierry Carrez
Related branches
Related bugs
Sprints
Whiteboard
Issue (from Jason Rouault): I have an issue with username not being globally unique... This will mean that users will need to provide domain information in addition to their credentials to log into the system. So to get a scoped token they would potentially need to provide username, password, tenantId, and domainId
Additionally, having globally unique names also keeps Swift ACLs that are based on usernames from breaking.
Response: So first of all, the use of multiple name spaces is optional, so it is perfectly OK for a cloud provider to chose to have all domains to share a common name space (or indeed to just stick with the one initial common domain). In such circumstances, the v2 API along with assumptions on user name global uniqueness remain unchanged.
However, I do not believe that such a configuration will be acceptable to cloud providers that increasingly want to host large enterprises (and to give each one their own domain name space). Such enterprises will not accept the restriction that they cannot user their own usernames or indeed call a Project "My Test" because some other customer of the cloud provider got there first.
[JR Comment: I am fine with tenant names not being globally unique (tenantIds can just be passed when getting a scoped token), my issue was with usernames. Most, if not all, enterprises use email as the username... so collisions are very unlikely. Your desire for additional scoping seems like overkill. As long as this is totally optional in V3, that is preferred]
In this case, the cloud provider would specify domains with private name spaces. Here, yes, I am saying that to log into the system the API will require a domain name or id (both ARE globally unique). However, in reality I would expect that a Cloud Provider that was hosting customers in their own domains, would want to be able to give a customer a url to use to get to a Horizon log in screen where the domain was already effectively defined (e.g. Domain name part of the url). We would extend Horizon to pick off this domain name and feed that into the API for log in, for example. Once authenticated a user would most likely have their token scoped to a domain, if not a project within a domain. In terms of the use of user_name as a unique key by other projects - this would need to change, by using user_name.
[ JR Comment: this is about more than Horizon, it affects the REST apis. Most folks interact with OpenStack via the APIs and not the GUI. So, they will be required to pass domain info in your example]
I will be writing up a more comprehensive API proposal and attaching it here to prompt further discussion.
Etherpad for discussion: https:/
After further consultation with contributors, it was agreed that making this optional (and potentially ending up with a mixture of domains with private name spaces and some sharing a global name space) would be confusing to many administrators and users. Hence the concept is still being implemented, but all domains will have their own name space for user, group and project names. See: https:/
Gerrit topic: https:/
Addressed by: https:/
Implement name space for domains
Work Items
Work items:
Modify uniqueness constraints on names in User, Group and Project Entities: TODO
