Replace per-vendor OIDC providers (Keycloak, ForgeRock, ...) with a generic OIDC provider type
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
- Bereich
- authentication, backend, database, frontend
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
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
typefield distinct fromprovider(oauth_providertable +registerOauthProvider/updateOauthProviderparams +OauthProviderResponse).providerstays a free-text, admin-chosen label (forgerock,okta,hr-corp-idp);typesays 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 throughverifyUser/verifySecretCodeAndFetchEmail, not a compile-time constant. - Dispatch fallback in
OAuth2AuthManagerImpl.getUserOAuth2AuthenticationProvider: if no fixed bean matches a name, look up the DB row; iftype=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")) ontotype == 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/keycloaklegacy 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
keycloakregistrations.
Related
- #13499 (adds ForgeRock, extracts the shared
AbstractOIDCOAuth2Providerbase this proposal builds on)
- Vorherrschende Sprache
- Java
- Sterne
- 3.1k
- Forks
- 1.4k
- Ø Merge
- 6 T. 20 Std.
- Gemergte PRs (30 T.)
- 27
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus apache/cloudstack
-
bug
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
apache/cloudstack#14222 ·
-
create-kubernetes-binaries-iso.sh builds the ISO without setting a volume ID on EL8 based os's Offenbug component:kubernetes
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
apache/cloudstack#14180 ·
-
bug component:projects component:UI
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
apache/cloudstack#14070 · 5 Kommentare ·
-
component:backup
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
apache/cloudstack#14013 ·
-
KVM agent fails to connect to Ceph RBD storage pool after upgrading Ceph client to Tentacle 20.2.4 Offenbug component:ceph
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
apache/cloudstack#13989 · 3 Kommentare ·
Alle Issues in apache/cloudstack
Ähnliche Issues
-
certification
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 80/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
[BUG] ECR GetAuthorizationToken returns a proxyEndpoint for the default region, not the request's Offenbug ecr
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Needs: Triage Type: Feature request
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
AntennaPod/AntennaPod#8794 ·
-
agentic-workflows
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
github/copilot-sdk#2760 ·