Shadow users (Newton): Unified identity for multiple authentication sources
This is a continuation of the remaining work that began in the Mitaka
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 (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.
- 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.