RFE Overview

In the IDP configuration, for OpenID, add the ability to specify a list of additional claims in the ID token for the purpose of logging those additional claims as part of the user information in the API server audit log. The Kubernetes API server audit log is already configured to log any Extra attributes in the UserInfo struct.

Goals

The ability to configure the OpenShift OpenID authentication with additional claims that would be useful information to provide in the audit log. For example, IBM gives users the ability to create trusted profile identities in order to grant federated users access to resources in IBM Cloud. For managed OpenShift clusters, the user that is created in OpenShift and authenticated against is represented by the UUID of the trusted profile. The profile id is what is logged in the audit event for the user. This is missing key information, the federated user identity who assumed the trusted profile.

This Section:* A list of specific needs or objectives that a Feature must deliver to satisfy the Feature.. Some requirements will be flagged as MVP. If an MVP gets shifted, the feature shifts. If a non MVP requirement slips, it does not shift the feature.

Requirement	Notes	isMvp?
New optional configuration option for OpenID configuration to specify a set of extra user claims.	This is similar to functionality Kubernetes supports in some of their authentication plugins like the webhook authenticator https://github.com/kubernetes/kubernetes/blob/d29e3bd7aa4978f10a01b9dfdebb2a647634f8fe/staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/webhook/webhook.go#L178-L194. They don’t support it in the OIDC authenticator, in favor of supporting it in a new, more generic JWT authenticator. https://github.com/kubernetes/enhancements/pull/3332/files#diff-bcfdf0eafa4b619c41b856e2a0292d10cf3b761075955b1c7de6838885e2c70dR490	YES
When OAuth constructs the User Identity from the ID token, it will pull these specified extra claims from the ID token and map them into the User identity as Extra properties.	The oauth server https://github.com/openshift/oauth-server/blob/master/pkg/oauth/external/openid/openid.go#L202C22-L202C48 will need to pull the extra claims defined in the configuration from the ID token (if present) and map them into the Extra map on the DefaultUserIdentityInfo struct. https://github.com/openshift/oauth-server/blob/a06e5302aa7cfc99bd3ab003e3790c36873a181c/pkg/api/types.go#L67. The Kubernetes API server audit log is already configured to log the Extra map on the user info struct if present.	YES

This Section:

This Section: What does the person writing code, testing, documenting need to know? What context can be provided to frame this feature.

Questions to be addressed:

What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
Does this feature have doc impact?
New Content, Updates to existing content, Release Note, or No Doc Impact
If unsure and no Technical Writer is available, please contact Content Strategy.
What concepts do customers need to understand to be successful in [action]?
How do we expect customers will use the feature? For what purpose(s)?
What reference material might a customer want/need to complete [action]?
Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.
What is the doc impact (New Content, Updates to existing content, or Release Note)?