Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Replace per-vendor OIDC providers (Keycloak, ForgeRock, ...) with a generic OIDC provider type

Offen
#13,854 2 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
java, javascript

Rechercherichtung

Beginne mit AbstractOIDCOAuth2Provider und OAuth2AuthManagerImpl.getUserOAuth2AuthenticationProvider und verfolge dann das oauth_provider-Schema, die Registrierungs-/Aktualisierungsparameter, OauthProviderResponse und Login.vue. Als abgeschlossen gilt die Arbeit, wenn beliebige OIDC-Registrierungen einen generischen Provider und dynamische Login-Schaltflächen verwenden, während bestehende Google-, GitHub- und Keycloak-Registrierungen weiterhin ihre Legacy-Beans verwenden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

type:enhancement
Problem

CloudStack's OAuth2 plugin currently ships one hardcoded Java class and one hardcoded UI block per OIDC vendor (KeycloakOAuth2Provider, ForgeRockOAuth2Provider). Neither class has any vendor-specific logic. Both just implement the standard OIDC authorization-code flow: hit an authorize URL, exchange the code at a token URL, parse the returned id_token JWT, read the email claim. Any OIDC-compliant IdP (Okta, Auth0, Azure AD, etc.) would work against this same code unchanged.

This was called out directly in #13499, which extracted the duplicated Keycloak logic into AbstractOIDCOAuth2Provider so ForgeRock could reuse it as a thin subclass. From that PR's own description:

Perhaps in the future this should be handled as an unbound provider (just a generic OIDC provider, pluggable with any OIDC-compliant server), but for now, this'll do.

As it stands, every new OIDC IdP someone wants means a new Java class plus a new hardcoded block in Login.vue, forever, for zero actual behavior difference. It also has a real limit today: since provider is both the display name and the routing key, and dispatch is a fixed name-to-bean map, a domain can only ever register one keycloak and one forgerock. It can't run two different OIDC IdPs under arbitrary names.

Proposal

Make OIDC a generic provider type instead of one class per vendor.

  • Add a type field distinct from provider (oauth_provider table + registerOauthProvider/updateOauthProvider params + OauthProviderResponse). provider stays a free-text, admin-chosen label (forgerock, okta, hr-corp-idp); type says which code runs it (e.g. oidc).
  • One concrete generic OIDC bean instead of one subclass per vendor.
  • Decouple provider identity from getName(). Right now it's a fixed, parameterless string baked into each bean and used for both dispatch and the bean's own DB lookups. For a shared bean serving many registrations, the provider name needs to be a parameter threaded through verifyUser/verifySecretCodeAndFetchEmail, not a compile-time constant.
  • Dispatch fallback in OAuth2AuthManagerImpl.getUserOAuth2AuthenticationProvider: if no fixed bean matches a name, look up the DB row; if type=oidc, hand off to the generic bean instead of throwing.
  • Move the authorizeUrl/tokenUrl-required check off the hardcoded name list (equalsAny(provider, "keycloak", "forgerock")) onto type == oidc, so it applies to any future name automatically.
  • Login.vue: render OAuth buttons from the registered provider list instead of one hardcoded block per vendor. Needs a display name/icon per row (admin-supplied, or a generic OIDC icon as fallback).
  • Keep google/github/keycloak legacy beans working unchanged. No forced migration, existing rows keep dispatching to their own classes. Only new arbitrary-name registrations go through the generic path.
Non-goals
  • No change to Google/GitHub, they aren't OIDC and keep their own dedicated implementations.
  • No forced migration of existing keycloak registrations.
Related
  • #13499 (adds ForgeRock, extracts the shared AbstractOIDCOAuth2Provider base this proposal builds on)
Vorherrschende Sprache
Java
Sterne
3.1k
Forks
1.4k
Ø Merge
6 T. 20 Std.
Gemergte PRs (30 T.)
27

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/cloudstack

Alle Issues in apache/cloudstack

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.