Shadow users (Newton): Unified identity for multiple authentication sources

bp shadow-users-newton

Note

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.

Problem Description

See the Mitaka spec (Problem Description).

Proposed Change

See the Mitaka spec (Proposed Change) for the originally-proposed changes and additional detail.

1. Separate user identities from their local-managed credentials. This was accomplished in the Mitaka release.
2. Shadow federated users. This was accomplished in the Mitaka release.
3. Create concrete role assignments for federated users.
4. Shadow LDAP users.
5. 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.
6. 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.

Alternatives

See the Mitaka spec (Alternatives).

Security Impact

See the Mitaka spec (Security Impact).

Notifications Impact

See the Mitaka spec (Notifications Impact).

Other End User Impact

See the Mitaka spec (Other End User Impact).

Performance Impact

See the Mitaka spec (Performance Impact).

Other Deployer Impact

See the Mitaka spec (Other Deployer Impact).

Developer Impact

See the Mitaka spec (Developer Impact).

Implementation

Assignee(s)

Primary assignee:

• rderose

Other contributors:

• dstanek
• dolphm

Work Items

1. Shadow LDAP users in new database tables.
2. Make concrete role assignments after federated mapping is evaluated.
3. Update federated authentication notifications to reflect local identities.
4. Refactor the mapping engine (to resolve tech debt).
5. Drop support for “federated” tokens.

Dependencies

See the Mitaka spec (Dependencies).

Documentation Impact

See the Mitaka spec (Documentation Impact).

References

See the Mitaka spec (References).