Shadow users (Newton): Unified identity for multiple authentication sources¶
This is a continuation of the remaining work that began in the Mitaka release. Only the summary is reproduced here for convenience.
Locally managed users are handled slightly differently than users backed by LDAP, which are handled significantly differently than users backed by federation. Available APIs, relevant APIs, and token validation responses all vary. For example, users receive different types of IDs, passwords may or may not be stored in keystone, and in the case of federation, may not be able to receive direct role assignments. Future additional authentication methods pose a risk of complicating things further.
Instead of continuing down this path, we can refactor our user persistence to separate identities from their locally-managed credentials, if any. The result will be a unified experience for both end users and operators.
See the Mitaka spec (Problem Description).
See the Mitaka spec (Proposed Change) for the originally-proposed changes and additional detail.
Separate user identities from their local-managed credentials. This was accomplished in the Mitaka release.
Shadow federated users. This was accomplished in the Mitaka release.
Create concrete role assignments for federated users.
Shadow LDAP users.
Drop the “EPHEMERAL” user type mapping. Given that federated users are no longer ephemeral, we can ignore the “ephemeral” vs “local” user type and treat all users equally.
Relax the requirement for mappings to result in group memberships. Now that we’re able to grant authorization to federated users using concrete role assignments, we can drop the requirement for the mapping engine to result in any authorization (via group membership) at all.
See the Mitaka spec (Alternatives).
See the Mitaka spec (Security Impact).
See the Mitaka spec (Notifications Impact).
Other End User Impact¶
See the Mitaka spec (Other End User Impact).
See the Mitaka spec (Performance Impact).
Other Deployer Impact¶
See the Mitaka spec (Other Deployer Impact).
See the Mitaka spec (Developer Impact).
Shadow LDAP users in new database tables.
Make concrete role assignments after federated mapping is evaluated.
Update federated authentication notifications to reflect local identities.
Refactor the mapping engine (to resolve tech debt).
Drop support for “federated” tokens.
See the Mitaka spec (Dependencies).
See the Mitaka spec (Documentation Impact).
See the Mitaka spec (References).