Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
#13,854 2 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
java, javascript

调研方向

从 AbstractOIDCOAuth2Provider 和 OAuth2AuthManagerImpl.getUserOAuth2AuthenticationProvider 开始,然后追踪 oauth_provider schema、注册/更新参数、OauthProviderResponse 和 Login.vue。当任意 OIDC 注册都使用一个通用 provider 和动态登录按钮,同时现有的 Google、GitHub 和 Keycloak 注册继续使用其 legacy beans 时,即表示完成。

由索引模型根据 Issue 内容生成。

描述

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)
主要语言
Java
星标
3.1k
派生
1.4k
平均合并
6 天 20 小时
30 天内合并 PR
27

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

apache/cloudstack 的其他 Issue

查看 apache/cloudstack 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。