Replace per-vendor OIDC providers (Keycloak, ForgeRock, ...) with a generic OIDC provider type
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 35/100
- Tipo de issue
- Funcionalidade
- Clareza
- Claramente especificada
- Status de atividade
- Ativa
- Stack de tecnologia
- java, javascript
- Domínio
- authentication, backend, database, frontend
Direção de pesquisa
Comece com AbstractOIDCOAuth2Provider e OAuth2AuthManagerImpl.getUserOAuth2AuthenticationProvider e, em seguida, rastreie o schema oauth_provider, os parâmetros de registro/atualização, OauthProviderResponse e Login.vue. Está concluído quando registros OIDC arbitrários usam um provider genérico e botões de login dinâmicos, enquanto os registros existentes do Google, GitHub e Keycloak continuam usando seus beans legados.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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)
- Linguagem predominante
- Java
- Estrelas
- 3.1k
- Forks
- 1.4k
- Merge médio
- 6d 12h
- PRs com merge (30d)
- 26
Guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de apache/cloudstack
-
bug
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 90/100
apache/cloudstack#14222 ·
-
create-kubernetes-binaries-iso.sh builds the ISO without setting a volume ID on EL8 based os's Abertabug component:kubernetes
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 88/100
apache/cloudstack#14180 ·
-
bug component:projects component:UI
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 88/100
apache/cloudstack#14070 · 5 comentários ·
-
component:backup
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
apache/cloudstack#14013 ·
-
KVM agent fails to connect to Ceph RBD storage pool after upgrading Ceph client to Tentacle 20.2.4 Abertabug component:ceph
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
apache/cloudstack#13989 · 3 comentários ·
Todas as issues de apache/cloudstack
Issues semelhantes
-
documentation
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
inu-appcenter/memorIN-backend#288 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
-
frontend maui-pilot pilot-ask question
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Abertaarea/plugin
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
kestra-io/plugin-kestra#190 ·