Authentication, Authorization and Domain Archiecture
The keystone implementation up to and including Grizzly is proving to be inflexible in being able to address a number of requirements in the how authentication and authorization are handled when you have a number of different customers being ‘hosted” by a cloud provider, where typically each customer is represented by a domain. This proposal examines those requirements and sets out how we might modify the current architecture to support these.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Henry Nash
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Henry Nash
Related branches
Related bugs
Sprints
Whiteboard
The original Havana etherpads that relate to this are:
https:/
https:/
Related: https:/
we reserve the right to prepend the user id with @<3 letters>@
For domain specific backends, it will be @dom@ followed by a uuid for the domain id, and then and @ and then the userid in the domain-specific format.
So if the userid were to be an email addres: say <email address hidden>
the domain id could be 18a3a3e2cf6b49b
and the userid would then be
@dom@18a3a3e2cf
The domain id would then be parsed out of the user id and used to locate the domain specific backend.
Implied in this is that we expand the user id fields in the assignment backends large enough to store the userids. It might make sense in the assignment backend to store the id in the unparsed format as a composite key and in two fields.
LDAP and SQL identity backends will be grandfathered in with no @tla@. If a userid is missing @tal@ it will be assumed to be in the default identity backend.
Work Items
Dependency tree
* Blueprints in grey have been implemented.
