Replace per-vendor OIDC providers (Keycloak, ForgeRock, ...) with a generic OIDC provider type
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- java, javascript
- Ambito
- authentication, backend, database, frontend
Direzione di ricerca
Inizia con AbstractOIDCOAuth2Provider e OAuth2AuthManagerImpl.getUserOAuth2AuthenticationProvider, quindi segui lo schema oauth_provider, i parametri di registrazione/aggiornamento, OauthProviderResponse e Login.vue. Il lavoro è completo quando registrazioni OIDC arbitrarie utilizzano un provider generico e pulsanti di accesso dinamici, mentre le registrazioni Google, GitHub e Keycloak esistenti continuano a utilizzare i relativi bean legacy.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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)
- Lingua principale
- Java
- Stelle
- 3.1k
- Fork
- 1.4k
- Merge medio
- 6g 20h
- PR unite (30g)
- 27
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di apache/cloudstack
-
bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
apache/cloudstack#14222 ·
-
create-kubernetes-binaries-iso.sh builds the ISO without setting a volume ID on EL8 based os's Apertabug component:kubernetes
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
apache/cloudstack#14180 ·
-
bug component:projects component:UI
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
apache/cloudstack#14070 · 5 commenti ·
-
component:backup
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
apache/cloudstack#14013 ·
-
KVM agent fails to connect to Ceph RBD storage pool after upgrading Ceph client to Tentacle 20.2.4 Apertabug component:ceph
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
apache/cloudstack#13989 · 3 commenti ·
Tutte le issue di apache/cloudstack
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
elastic/gradle-plugins#157 ·
-
enhancement Tools
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
apache/rocketmq-dashboard#5008 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
DETECT_PARAMETER_NAMES=false silently disables @ConstructorProperties-based Creator detection too Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
FasterXML/jackson-databind#6229 ·