Configurable identity mapper strategies

[liggitt]

https://trello.com/c/cSa9BKUL/512-3-configurable-identity-user-provisioning-strategies

On login, we currently auto-provision a unique username for new identities. Additional strategies should exist.

This PR adds a mappingMethod option to all identity providers:

oauthConfig:
  identityProviders:
  - challenge: false
    login: false
    mappingMethod: "..."
    ...

mappingMethod can be set to the following values:

• lookup
  • Administrator wants to manually configure identity/user mappings. Login process should only look up existing mappings, not create them
• generate (prior default behavior)
  • Provision with generation of unique usernames (e.g. "bob", "bob2")
  • This strategy should not be used in combination with LDAP group sync
• claim (new default)
  • Provision with deterministic username, fail if username is already mapped to another identity
• add
  • Provision with deterministic username, add to existing user if username is already mapped to another identity
  • Needed when multiple identity providers are configured which identity the same set of users and map to the same usernames

TODO:

• Decide on default strategy... probably "claim"
• Decide on name for "claim" and "generate" strategies
• Decide on name for identityProvider field name (currently "mappingMethod")
• split out tests (Configurable identity mapper strategies #5060 (comment))
• Open ansible issue - Ensure support for identity provider mappingMethod openshift-ansible#900
• Open doc issue - Add mappingMethod docs for identity providers openshift-docs#1196

Followups:

• Surface a nicer error to the user when the identity provision fails lookup and claim strategies (currently get a 500 Internal Error, internally there's a UserIdentityMapping NotFound error or a ClaimError) - Surface user identity claim failures to user better #5915
• Surface a nicer error to the admin when there's a claim strategy failure (they may want to switch to add or replace) - Surface user identity claim failures to cluster admin better #5914

Fixes #5009

[liggitt]

@stevekuznetsov @deads2k

[liggitt]

[test]

[stevekuznetsov]

GoDoc here might be helpful, before reading further I thought this would be stomp strategy.

[liggitt]

https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/5658/ flake #5025

[liggitt]

comments addressed

[liggitt]

The current default (by virtue of being the only option) is "generate", which automatically generates a unique username in case of preferredUsername conflicts between identity providers.

I would like to change the default for new configs and existing configs which don't specify a strategy to use "claim". This would have the following impact on existing configurations:

• Users that had already logged in and been assigned a uniquified username would be unaffected
• New logins that encountered a conflict with an existing username would fail.
  • If a cluster admin really wanted the deconflict behavior, they could update their config to specify "generate"
  • If a cluster admin wanted both identity providers to map to the same user, they could update their config to specify "add"

@smarterclayton, this is technically a behavior change, but I haven't encountered anyone using multiple identity providers who wanted the generate behavior... ruling on changing this?

[smarterclayton]

+1 do it

On Tue, Oct 13, 2015 at 2:50 PM, Jordan Liggitt [email protected]
wrote:

The current default (by virtue of being the only option) is "generate",
which automatically generates a unique username in case of
preferredUsername conflicts between identity providers.

I would like to change the default for new configs and existing configs
which don't specify a strategy to use "claim". This would have the
following impact on existing configurations:

• Users that had already logged in and been assigned a uniquified
  username would be unaffected
• New logins that encountered a conflict with an existing username
  would fail.
  • If a cluster admin really wanted the deconflict behavior, they
    could update their config to specify "generate"
  • If a cluster admin wanted both identity providers to map to the
    same user, they could update their config to specify "add"

@smarterclayton https://github.com/smarterclayton, this is technically
a behavior change, but I haven't encountered anyone using multiple identity
providers who wanted the deconflict behavior... ruling on changing this?

—
Reply to this email directly or view it on GitHub
#5060 (comment).

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/5826/)

[liggitt]

Tagging with compatibility, deserves a mention in release notes

[liggitt]

@deads2k PTAL

[deads2k]

Why would anyone ever choose this? It seems crazy.

[liggitt]

removed

[liggitt]

comments addressed, still need to split up tests

[liggitt]

comments addressed

[liggitt]

[merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/3635/) (Image: devenv-fedora_2472)

[openshift-bot]

Evaluated for origin test up to 75710d5

[liggitt]

@danmcp, in https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/3634/:

remote: error: unable to create temporary file: File exists        
remote: fatal: failed to write object        
error: unpack failed: unpack-objects abnormal exit
To verifier:/data/src/github.com/openshift/source-to-image-bare
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'verifier:/data/src/github.com/openshift/source-to-image-bare'

[liggitt]

re[merge]

[openshift-bot]

Evaluated for origin merge up to 75710d5