Feature Overview (aka. Goal Summary)  

The ability in OpenShift to create trust and directly consume access tokens issued by Multiple external OIDC Authentication Providers  

Goals (aka. expected user outcomes)

Ability to configure Multiple IDP similar to upstream 

+ Multiple IDP support

+ RBAC should work seamlessly with Users/Groups/Service Accounts 

+ Enabling External OAuth with Kube RBAC Proxy should allow customers to leverage authentication configuration on the cluster for authenticating to applications running on the cluster similar to how OpenShift OAuth worked with Oauth-proxy. 

+ Abillity to LogOut from Each of the Identity Providers Separately

{}NON- GOALS

• Any tooling necessary to automate workflows in multi-cluster scenarios. These need to be handled via RHACM or tooling provided by customer
• Supporting workflows outside of standard OIDC protocol definition. 

Requirements (aka. Acceptance Criteria):

1. All the functionality in Goals should work.
2. Customers should be able to configure 2 or more Identity Providers.  
3. The customer should be able to tie into RBAC functionality as before
4. Customers should be able to logout from OpenShift UI for individual Identity Providers. Dependency on Console team 
5. Customers should be able to logout from CLI for individual Identity Provider. Dependency on CLI team. 
6. Support for HyperShift and Layered products

Use Cases (Optional):

1. As a customer, I would like to integrate my OIDC Identity Providers directly with the OpenShift API server. I have Provider1, Keycloak, for SREs and Provider 2, EntraID for normal users 
2. Users would like to login/logout using CLI or UI 

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

Out of Scope

 __ *Note: Following is Out of Scope: Testing with All the OIDC Identity Providers in initial release. This will be done over time. We will target EntraID and Keycloak as initial IDP supported.* 

Background

 Upstream supports Multiple IDP Config.

Upstream Structured Auth: 

The configuration file approach allows you to configure multiple JWT authenticators, each with a unique issuer.url and issuer.discoveryURL. The configuration file even allows you to specify CEL expressions to map claims to user attributes, and to validate claims and user information. The API server also automatically reloads the authenticators when the configuration file is modified. You can use apiserver_authentication_config_controller_automatic_reload_last_timestamp_seconds metric to monitor the last time the configuration was reloaded by the API server. 

https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-authentication-configuration 

https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/3331-structured-authentication-configuration/kep.yaml

GA for Structured Auth is currently 1.34 

Customer Considerations

1. Logout mechanism is TBD as this essentially means we need to clear out the token cached for the user.
2. Seamless UI and CLI support is essential  _ _ 

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  Initial completion during Refinement status.

Interoperability Considerations

Dependancy on Console and CLI teams