We have a customer requesting for Multiple Identity Provider Support

Many large organizations operate in a "Multi-IdP" reality due to mergers, acquisitions, or hybrid cloud strategies. The current single-provider limitation creates several issues:

• Identity Fragmentation: If an organization migrates from LDAP to OIDC, users are often treated as entirely new entities, losing their repository permissions and organization memberships.
• Architectural Overhead: Customers are currently forced to deploy and maintain an external identity broker (like Keycloak) just to aggregate providers before they reach Quay.
• Workflow Disruption: Contractors using one IdP and employees using another cannot easily collaborate within the same Quay instance without complex manual user management.

Proposed Solution: The "Email-Centric" Identity Model
Quay should move toward an identity model where the user's verified email address is the primary key. If a user authenticates via "Provider A" and later via "Provider B," Quay should recognize them as the same user if the email addresses match.
Key Logic:

• Lookup on Login: Upon a successful handshake with any configured IdP, Quay should perform a lookup: SELECT user WHERE email = <authenticated_email>.
• Automatic Linking: If a match is found, the new IdP's unique subject identifier (sub/UUID) should be linked to the existing Quay user profile.
• Permission Persistence: All repository permissions, robot accounts, and organization memberships remain attached to the consolidated user, regardless of which IdP was used for the current session.

Functional Requirements:

• Multi-Provider Configuration: Update config.yaml to support an array of authentication providers (e.g., AUTHENTICATION_PROVIDERS: [...]) rather than a single type.
• Unified Login UI: The login page should dynamically display "Sign in with..." buttons for all configured OIDC/SAML providers alongside standard username/password fields for LDAP.
• Email Verification Enforcement: To prevent account hijacking, Quay must only consolidate accounts if the IdP provides a "Verified Email" claim (e.g., email_verified: true in OIDC).
• Username Collision Handling: If different IdPs provide different usernames for the same email (e.g., jdoe vs john.doe), Quay should allow the user to retain their original Quay username or allow an admin-defined precedence.

Security & Trust Considerations:

• Verification Requirement: Strict enforcement of email verification claims from IdPs to ensure a user cannot "spoof" an account by creating a matching email on a non-verified secondary provider.

Business Impact:

• Seamless Migrations: Enables "Zero-Downtime" migrations from legacy identity systems to modern OIDC providers.
• Reduced TCO: Eliminates the need for customers to manage a separate Keycloak/SSO stack just to support multiple login methods for the registry.
• Enterprise Scalability: Positions Quay as a top-tier choice for Global 2000 companies with complex, federated identity requirements.

User Stories:

• As a Platform Engineer, I want to configure a new OIDC provider (e.g., Okta) alongside our legacy LDAP system, so that users can begin using modern SSO without losing access to their existing private repositories or organization memberships.
• As an IT Administrator, I want users from Company A (using Azure AD) and Company B (using Ping Identity) to log into the same Quay instance and be automatically recognized as the same individuals if they share a verified email, allowing them to collaborate on shared container images immediately.
• As a Lead Developer, I want to be able to log in via my corporate VPN using LDAP and via the public internet using OIDC, and see the exact same "My Repositories" dashboard because Quay recognizes that both identities belong to my verified email address.
• As a Security Officer, I want to allow external contractors to log in via their own GitHub accounts while internal employees use Corporate SSO, ensuring that permissions are managed centrally in Quay based on their email identity rather than maintaining separate local accounts for every partner.