Feature Overview (aka. Goal Summary)

This feature aims to enhance the Red Hat Developer Hub (RHDH) login experience by supporting multiple, simultaneously available authentication methods on the login screen. Currently, RHDH is typically configured to present a single, default sign-in method. However, large, regulated enterprise customers, particularly those undergoing mergers or acquisitions, often require the ability to support users coming from two or more distinct, separate identity systems. This feature will provide the necessary flexibility to accommodate heterogeneous enterprise environments, ensuring all users can access RHDH, regardless of which core identity system they belong to.

Goals (aka. expected user outcomes)

• For the User:
  • As a user, I can easily identify and select my specific organization's login button/link on the RHDH sign-in screen, so that I can authenticate with my existing corporate credentials and access the portal.
• For the Platform Engineering Team/Administrator:
  • As a Platform Engineer, I can configure RHDH to display and support multiple active sign-in methods (e.g., OAuth2 providers, LDAP/Active Directory) simultaneously, so that RHDH can serve users from distinct corporate domains or systems.
  • As a Platform Engineer, I can assign a unique, descriptive label to each authentication provider displayed on the login screen, so that end-users clearly understand which identity system they are connecting to.

Requirements (aka. Acceptance Criteria):

1. As a Platform Engineer, I want to configure a minimum of two distinct authentication providers (e.g., two separate AD providers, two different OIDC configurations, or a mix) in RHDH, so that the login screen presents multiple, active options.
2. As a Platform Engineer, I want the ability to specify a unique, user-friendly label (e.g., "Sign in with Red Hat ID," "Sign in with Acquired Company A Domain") for each configured provider, so that users are not confused when choosing their login method.
3. As an RHDH User, I want to click a specific, labeled button/link corresponding to my organizational login system on the RHDH login page, so that I am correctly redirected to my organization's identity provider for authentication.
4. As an RHDH user, I want the default sign-in experience to be maintained if only one authentication provider is configured, so that the user experience remains simple in single auth provider environments.
5. As a Platform Engineer, I want the multiple authentication options to be displayed in a clear, standardized UI format that is consistent with the RHDH theme (light/dark), including localization.

Out of Scope (Optional)

• User migration or automated account linking between the different identity providers. This feature focuses purely on authentication choice at login.

• Advanced authorization logic based on the chosen IdP (e.g., assigning different roles solely based on which button was clicked). User authorization will still rely on the standard RHDH role/group management based on the successful authentication payload.
• Dynamic provider discovery (e.g., using email domain to automatically redirect a user to the correct IdP). Users must explicitly click the correct option.

Customer Considerations (Optional)

• Security and Auditing: The platform engineering team will require a clear audit trail that logs which specific Identity Provider (IdP) was used for a successful login event. This is critical for regulated environments.

• Labeling Clarity: The custom labels for each IdP must be carefully considered to be immediately understood by the target user base (e.g., using "Former Corp A" vs. "New Corp B"). We must provide clear configuration instructions and character limits for these labels.

Documentation Considerations

• Configuration: Detailed, step-by-step instructions for Platform Engineers on how to enable and configure multiple providers in the RHDH backend configuration files (app-config.yaml), including examples for different common IdP types (e.g., two Okta instances, or Okta + Keycloak).
• UI Customization: Documentation on how to specify the display label for each provider and any potential options for custom icons (if supported).
• Security Impact: Documentation should explicitly state that this feature does not change how RHDH handles user authorization after successful authentication.