Replace per-vendor OIDC providers (Keycloak, ForgeRock, ...) with a generic OIDC provider type
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- java, javascript
- Área
- authentication, backend, database, frontend
Línea de trabajo
Comienza con AbstractOIDCOAuth2Provider y OAuth2AuthManagerImpl.getUserOAuth2AuthenticationProvider; después, sigue el esquema oauth_provider, los parámetros de registro/actualización, OauthProviderResponse y Login.vue. Se considera terminado cuando los registros OIDC arbitrarios usan un proveedor genérico y botones de inicio de sesión dinámicos, mientras que los registros existentes de Google, GitHub y Keycloak siguen usando sus beans heredados.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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)
- Lenguaje dominante
- Java
- Estrellas
- 3.1k
- Forks
- 1.4k
- Merge medio
- 6 d 20 h
- PR fusionados (30 d)
- 27
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/cloudstack
-
bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
apache/cloudstack#14222 ·
-
create-kubernetes-binaries-iso.sh builds the ISO without setting a volume ID on EL8 based os's Abiertobug component:kubernetes
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
apache/cloudstack#14180 ·
-
bug component:projects component:UI
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
apache/cloudstack#14070 · 5 comentarios ·
-
component:backup
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
apache/cloudstack#14013 ·
-
KVM agent fails to connect to Ceph RBD storage pool after upgrading Ceph client to Tentacle 20.2.4 Abiertobug component:ceph
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
apache/cloudstack#13989 · 3 comentarios ·
Todos los issues de apache/cloudstack
Issues similares
-
bug untriaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
opensearch-project/ml-commons#5094 ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
-
emitter:client:csharp feature
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
affects/8.10 affects/8.9 component/clients kind/bug likelihood/mid severity/mid
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Two open-case totals on one screen: the Programs tile says 15,858 and the nav badge says 15,868 Abiertobug frontend maui-pilot
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100