OpenID Connect: Identify user by more JWT claims than just a single one

[heikoettelbruecksap]

Summary:

In our use case, ID tokens of our OpenID connect provider (CF UAA) don't have a single claim that

• uniquely identifies a user and
• is human-readable (= usable in a Kubernetes cluster, e.g. for role bindings, auditing).
  However, currently the API server only supports choosing a single claim (=> usernameClaim) which is treated as (expected to be unique) user name within the cluster.
  Basically I see two options to resolve this situation:
• Specific approach for this use case: Extend the OpenID connect provider to add an additional claim which is both unique and human-readable.
• Generic approach: Extend the API server to allow specifying a simple pattern to define the cluster-internal user name (potentially using multiple claims, e.g. "{origin}|{user_name}").

=> Do you have similar use cases, so the generic approach would help there, too?

Details:

We use CF UAA as OpenID connect provider for Kubernetes clusters, which supports connecting multiple external identity providers (per single identity zone / tenant). Respective ID tokens issued by UAA contain certain information that could be used to identify users from the cluster (e.g. for role bindings within the cluster):

• sub: unique identifier for the user, however a GUID
• email: email address of the user
• origin: identifier for the identity provider by which the user authenticated to UAA
• user_name: user name of the user (within the used identity provider; there might be users from other identity providers with the same user_name, so user_name itself is not yet unique)
• user_id: same as "sub"

[heikoettelbruecksap]

@kubernetes/sig-auth-feature-requests

[k8s-ci-robot]

@heikoettelbruecksap: Reiterating the mentions to trigger a notification:
@kubernetes/sig-auth-feature-requests

In response to this:

@kubernetes/sig-auth-feature-requests

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[heikoettelbruecksap]

@kubernetes/sig-auth-feature-requests

[k8s-ci-robot]

@heikoettelbruecksap: Reiterating the mentions to trigger a notification:
@kubernetes/sig-auth-feature-requests

In response to this:

@kubernetes/sig-auth-feature-requests

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[heikoettelbruecksap]

@kubernetes/sig-auth-feature-requests

[k8s-ci-robot]

@heikoettelbruecksap: Reiterating the mentions to trigger a notification:
@kubernetes/sig-auth-feature-requests

In response to this:

@kubernetes/sig-auth-feature-requests

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[liggitt]

sub: unique identifier for the user, however a GUID
...
origin: identifier for the identity provider by which the user authenticated to UAA
user_name: user name of the user (within the used identity provider; there might be users from other identity providers with the same user_name, so user_name itself is not yet unique)

in this case, using "{origin}|{user_name}" sounds counter to the intent of the identity provider. presumably the sub uniquely identifies the user independently of the authentication origin to allow authentication via other origins to map to the same user. By taking "{origin}|{user_name}" as the identity, it means the same user authenticating via a different origin would lose all kubernetes permissions granted to their first login method

expecting a single claim from the provider the represent the identity seems safest. if you wanted to allow combining claims like this, you could do so with an authentication webhook that added that on top of oidc validation.

/close

[k8s-ci-robot]

@liggitt: Closing this issue.

In response to this:

sub: unique identifier for the user, however a GUID
...
origin: identifier for the identity provider by which the user authenticated to UAA
user_name: user name of the user (within the used identity provider; there might be users from other identity providers with the same user_name, so user_name itself is not yet unique)

in this case, using "{origin}|{user_name}" sounds counter to the intent of the identity provider. presumably the sub uniquely identifies the user independently of the authentication origin to allow authentication via other origins to map to the same user. By taking "{origin}|{user_name}" as the identity, it means the same user authenticating via a different origin would lose all kubernetes permissions granted to their first login method

expecting a single claim from the provider the represent the identity seems safest. if you wanted to allow combining claims like this, you could do so with an authentication webhook that added that on top of oidc validation.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[enj]

@heikoettelbruecksap with #121078 merged, this should be possible now as an alpha feature in v1.29.