Domain specific Identifiers
With the ability to split Identity across multiple backends, we now have no way to identify whiuch backend to look in in order to lookup a user from a userid.
Users IDs in SQL are unique, but the ids used on other systems may well conflict: LDAP, SAML, and so forth tend to be scoped by the domain. The logical approch then is to embed the domain identifier into the userid. THis blueprint is for enumerating the details in order to make that work with keystone
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Not
- Drafter:
- Adam Young
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
- Dolph Mathews
Related branches
Related bugs
Sprints
Whiteboard
Keystone will continue to support UUID based Identifies, and assume that they are in the SQL backend. If the identifier has an @ in the middle of it, the left section is the user or group identifier, and the right section is the domain identifier.
the assignment backend needs to be capable of dealing with both forms of identifiers (this is unnecessary if assignments to federated identities isn't supported. for example, remote idp -> attribute mapping to groups -> role assignments to groups)
the counter-argument to this is basically if keystone's identity management functionality only represents a single identity provider, then you don't have to worry about retrieving "users" in a federated environment -- it's simply out of scope.
Work Items
Work items:
call Domain specific identifiers DSI: DONE
establish scheme for identifiers: TODO
change assignments backend to accept DSI: TODO
make identity manager handle splitting DSI for user and group: TODO
