Feature Overview (aka. Goal Summary)  

The ability in OpenShift to create trust and directly consume access tokens issued by external OIDC Authentication Providers using an authentication approach similar to upstream Kubernetes.

BYO Identity will help customers use their Corporate Identities as Source of Truth and have consistent automation and policy management across multiple clusters. 

This feature will add production-ready capabilities such as

• Monitoring and Metrics support
• Multiple IDP support
• Structured Authentication Configuration support as defined in upstream Kubernetes
• End-End testing of OIDC workflows with CLI and Console. 
• Ability for upgraded clusters to seamlessly transition from using OpenShift OAuth to using BYO External OIDC feature.
• OC Exec credential plugin support for OIDC workflows beyond Authentication Code grant 

Goals (aka. expected user outcomes)

All the abilities in BYO implementation mentioned earlier -> Ability in OpenShift to provide a direct, pluggable Authentication workflow such that the OpenShift/K8s API server can consume access tokens issued by external OIDC identity providers. Kubernetes provides this integration as described here. Customer/Users can then configure their IDPs to support the OIDC protocols and workflows they desire such as Client credential flow.

+ OpenShift OAuth server is still available as default option.

+ Ability to switch between External OIDC and OpenShift OAuth seamlessly. Users and Groups to be managed on IDP. 

+ 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. 

+ Ability to have metrics support to detect access attempts 

+ Structured Auth enhancements on par with upstream Kubernetes 

STRETCH GOALS

+ Ability to have CLI exec plugin support for OIDC workflows commonly used by customers. This includes Authorization Code Workflow (With PKCE) as default. Support for refresh tokens. Device Code Grant workflow is commonly used in resource constrained environments. Ability to support this workflow on CLI or have ability to support Exec plugins that provide this workflow today (e.g Kubelogin, init Kubelogin)

NON- GOALS

• Any Hosted Control Plane changes (There are different epics covering this functionality).
• 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 bringing their OIDC compliant Identity providers should be able to use External OIDC functionality  
3. The customer should be able to tie into RBAC functionality as before
4.  

Use Cases (Optional):

1. As a customer, I would like to integrate my OIDC Identity Provider directly with the OpenShift API server.
2. As a customer in multi-cluster cloud environment, I have both K8s and non-K8s clusters using my IDP and hence I need seamless authentication directly to the OpenShift/K8sAPI using my Identity Provider 
3.  

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

High-level list of items that are out of scope.  Initial completion during Refinement status.

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

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

Which other projects and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.