[Feature]: 支持兼容CAS协议的SSO，或者支持对接LDAP登录，以提升HiMarket兼容已有认证服务的能力。

[bigevolution]

Problem Statement

部分企业系统鉴权认证依然采取的CAS协议，尚未兼容OIDC协议。

Proposed Solution

支持兼容CAS协议的SSO，或者支持对接LDAP登录，以提升HiMarket兼容已有认证服务的能力。

Alternatives Considered

No response

Affected Component

Authentication/Authorization

Priority

High (significantly improves workflow)

Use Cases

No response

Mockups/Examples

No response

Acceptance Criteria

No response

Additional Context

No response

Checklist

• I have searched existing issues and feature requests
• This feature aligns with the project's goals
• I'm willing to contribute to this feature
• I have provided enough detail for the team to understand the request

[learnerjohn]

不错的建议~

[MisonL]

@learnerjohn 你好，我这边在 fork 上实现了一版「兼容 CAS 协议的 SSO」直连能力（不依赖 OIDC），想确认下是否符合你们对 #156 的预期；如果方向一致，我可以按你们的合入要求提交一个 PR。

功能分支：
https://github.com/MisonL/himarket/tree/feature/cas-auth-support

实现范围与架构落点（保持现有 portal 级认证配置模型）：

• 认证元数据仍然是 portal 级：在 PortalSettingConfig 增加 casConfigs（CasConfig: provider/name/enabled/serverUrl/loginEndpoint/validateEndpoint/logoutEndpoint/identityMapping）。
• 运行时按请求解析 portal 上下文后，再取该 portal 下 casConfigs；不引入全局 CAS 配置。

协议实现方式（CAS ST + serviceValidate）：

• 开发者端获取可用 CAS provider：GET /developers/cas/providers。
• 发起登录：GET /developers/cas/authorize?provider=... -> 重定向到 CAS loginUrl?service=<HiMarket回调地址>。
• 回调处理：GET /developers/cas/callback?ticket=ST-...&state=... -> 调用 validateEndpoint?service=<同一个service>&ticket=... 校验票据，解析 XML（authenticationSuccess/user/attributes），再按 identityMapping 映射到内部 DeveloperExternalIdentity，并签发 HiMarket 自己的 developer token。
• validateEndpoint 为空时默认使用 /p3/serviceValidate；同时支持配置为相对路径或完整 URL。

安全闭环（避免“只跑通不安全”的接入）：

• state 绑定 HttpOnly Cookie（hm_cas_state）并做 TTL 校验，回调必须匹配且未过期，防重放/跨站注入。
• CAS XML 解析开启安全处理：禁用 DOCTYPE/外部实体，避免 XXE。

验证情况（本地最小门禁）：

• 后端：JAVA_HOME=$(/usr/libexec/java_home -v 21) mvn -pl himarket-bootstrap -am test （BUILD SUCCESS）。
• 关键单测覆盖：CasServiceImplTest / CasTicketValidationParserTest / PortalResolvingFilterTest / IdpServiceImplTest 等。

当前边界：

• 这版只实现了 CAS 协议 SSO（ST 票据）接入，未实现 LDAP。
• logoutEndpoint 目前作为配置字段保留，但未实现 CAS 单点登出(SLO)跳转（开发者登出仍走现有 /developers/logout）。

[lexburner]

@MisonL 非常不错的建议，这块在开源方案中可以本地拉起一个 SSO 进行下功能验证吗？

[MisonL]

补充更新一下：我上面那条评论对应的是这个分支的早期状态，当前实现已经继续往前推进了一大截，下面按“和前帖相比发生了什么变化”梳理一下，避免误导。

和前帖相比，当前最新状态的主要变化是：

• 不再只是 developer 侧 CAS。现在 developer / admin 两侧都已经打通，接口和回调链路都补齐了。
• 不再只是最初的 ST + serviceValidate 基础接入。现在已经覆盖 CAS1 / CAS2 / CAS3 / SAML1 多种校验协议。
• 前帖里提到“未实现 LDAP”这一点已经过时。当前分支已经补了 LDAP 登录链路。
• 前帖里提到“logoutEndpoint 仅保留配置、未实现 SLO”这一点也已经过时。现在 front-channel / back-channel logout 都已经接上并做了联调验证。
• 在基础登录之外，又补了 proxy ticket、HEADER response type、MFA、delegated authentication、JWT bearer token exchange 等能力。
• 不只是接口层代码落地了，当前分支还补了本地 auth harness，可以在开源环境里直接拉起一套本地认证联调环境做验证。

本地联调这套环境当前包含：

• 本地 CAS
• OpenLDAP
• Mock OIDC
• HiMarket server / frontend / admin

我这边最近一次重新跑本地门禁的命令是：
SKIP_BUILD=1 SKIP_DOCKER_UP=1 CAS_READY_TIMEOUT=420 ./deploy/docker/auth-harness.sh

这轮跑下来的结果是：

• cas-core
• cas-header
• cas-mfa
• cas-delegated
• ldap
• jwt-bearer

上述 phase 都已通过，脚本最终输出是 all selected phases passed。

另外，为了让这条本地验证链路稳定下来，这个分支后面还补了几处真实问题修复：

• 构建阶段强制 clean package，避免本地旧产物污染运行时
• 恢复 bootstrap 的 prod application.yml 配置
• 放通 developer 外部认证回调白名单
• 收缩 admin 前端 Docker build context，避免本地构建过程异常臃肿

所以如果按当前分支的最新状态来描述，它已经不是我前面那条评论里那版“只有 developer CAS 第一阶段接入”的范围了；能力面和本地可验证性都已经往前推进了很多。

[MisonL]

@lexburner 可以，我这边刚按这个要求在本地重新拉起并完整验证了一遍，基于的是当前最新分支状态（已同步上游最新 main）。

这次本地联调使用的是仓库里的 auth harness，命令是：
SKIP_BUILD=1 SKIP_DOCKER_UP=1 CAS_READY_TIMEOUT=420 ./deploy/docker/auth-harness.sh

本地实际参与联调的服务包括：

• HiMarket server
• HiMarket frontend
• HiMarket admin
• 本地 CAS
• OpenLDAP
• Mock OIDC
• 本地 JWKS server

这轮实测里，harness 先后完成并通过了：

• cas-core
• cas-header
• cas-mfa
• cas-delegated
• ldap
• jwt-bearer

最终脚本输出是：all selected phases passed

也就是说，当前这套开源方案里，本地拉起一套 SSO / 认证环境做功能验证是可以直接跑通的；而且验证范围已经不只是最初那版 developer CAS 登录，而是把 developer / admin 两侧的 CAS、LDAP、MFA、delegated、logout、JWT bearer 这些链路都一起跑过了。

[MisonL]

@lexburner 补充同步一下当前最新状态，供 #156 评估是否合入。

我这边已经把两个分支都完成了基于上游最新代码的 rebase / 同步，并重新做了本地真实联调验证。

当前可选分支有两个：

1. cas-auth-support（较小合入面，目标是 CAS JWT 接入支持）
   分支链接：https://github.com/MisonL/himarket/tree/feature/cas-auth-support

2. cas-auth-complete（完整 CAS 能力对接）
   分支链接：https://github.com/MisonL/himarket/tree/feature/cas-auth-complete

这两个分支我都已经完成最新 rebase，并通过了和本地 CAS 环境的联调测试。

本轮我实际重新执行并通过的验证包括：

• feature/cas-auth-support

  • mvn -pl himarket-bootstrap -am package -DskipTests
  • mvn -pl himarket-server -Dtest=IdpServiceImplTest,CasServiceImplTest,AdminCasServiceImplTest,CasServiceDefinitionServiceImplTest -Dsurefire.failIfNoSpecifiedTests=false test
  • admin / frontend 生产构建
  • SKIP_BUILD=1 CAS_READY_TIMEOUT=420 AUTH_HARNESS_PHASES=ldap,cas-header,jwt-bearer ./deploy/docker/auth-harness.sh
  • 结果：all selected phases passed

• feature/cas-auth-complete

  • mvn -pl himarket-bootstrap -am package -DskipTests
  • mvn -pl himarket-server -Dtest=IdpServiceImplTest,CasServiceImplTest,AdminCasServiceImplTest,CasServiceDefinitionServiceImplTest -Dsurefire.failIfNoSpecifiedTests=false test
  • admin / frontend 生产构建
  • SKIP_BUILD=1 CAS_READY_TIMEOUT=420 ./deploy/docker/auth-harness.sh
  • 结果：all selected phases passed

如果社区准备合 PR，我建议就是现在，且二选一即可：

• 如果希望先以更小的变更面合入，建议选择 cas-auth-support
• 如果希望一次性拿到完整 CAS 能力矩阵，建议选择 cas-auth-complete

下面按功能与架构角度分别说明这两个分支。

---

方案 A：cas-auth-support

定位：

• 以较小合入面为目标，先把 HiMarket 的 CAS / JWT 接入骨架和本地可验证链路落稳
• 适合作为分阶段合入版本

功能侧改动

1. Portal 级认证配置模型落地

• 认证配置仍然维持在 portal 级，不引入全局单例 CAS 配置
• Admin 侧可以维护 portal 绑定的外部认证提供方配置
• 运行时根据 portal 上下文解析该 portal 的认证方式

2. Developer / Admin 两侧外部认证接入骨架打通

• 开发者端与管理端都补齐了 provider discovery、authorize、callback、exchange 等入口
• 登录成功后换发 HiMarket 自己的 access token，而不是把外部票据直接透传给业务层

3. CAS Header Response 支持

• 支持 CAS Header Response 模式
• 已完成 developer / admin 两侧联调
• 已验证登录回调、token 交换、回注销链路

4. JWT Bearer + JWKS 支持

• 支持标准 OAuth2 JWT Bearer grant
• 支持通过 JWKS 做签名校验
• 已在本地 harness 中完成真实换 token 验证

5. LDAP 作为本地认证配套能力接入

• 开发者端和管理端都支持 LDAP 登录联调
• 这部分在 support 分支里主要承担“本地认证验证面”的支撑作用，便于一起验证认证编排链路

6. 本地 auth harness / docker 联调能力补齐

• 增加本地 CAS / OpenLDAP / JWKS server / mock auth fixtures
• 可以在开源环境直接起完整本地认证验证面，不依赖外部企业 SSO 环境

7. 认证安全与稳定性加固

• callback / state / whitelist / URL 编码 / 本地 portal service definition 这类基础安全与稳定性问题都做了收口
• 修过一轮本地构建产物污染、前端构建、回调白名单等真实问题，保证本地验证链路稳定

cas-auth-support 架构图

flowchart LR
  AdminUI[Admin UI<br/>Portal Auth Settings] --> AdminAPI[HiMarket Admin API]
  AdminAPI --> PortalCfg[(Portal-level Auth Config)]

  DevBrowser[Developer Browser] --> HMServer[HiMarket Server]
  OpsBrowser[Admin Browser] --> HMServer

  PortalCfg --> HMServer

  HMServer --> CAS[Local CAS]
  HMServer --> LDAP[OpenLDAP]
  HMServer --> JWKS[JWKS Server]

  CAS --> Callback[CAS Callback / Code Exchange]
  LDAP --> LDAPLogin[LDAP Login Endpoints]
  JWKS --> JwtGrant[JWT Bearer Grant Validation]

  Callback --> HMToken[HiMarket Access Token]
  LDAPLogin --> HMToken
  JwtGrant --> HMToken

  Harness[Auth Harness] --> HMServer
  Harness --> CAS
  Harness --> LDAP
  Harness --> JWKS

Loading

适合合入这个分支的原因

• 变更面更小
• 更适合作为第一阶段 PR
• 已经具备真实本地联调门禁，不是只停留在接口层“看起来可用”

---

方案 B：cas-auth-complete

定位：

• 在 cas-auth-support 之上，完整对接 CAS 能力矩阵
• 适合作为“一次性交付完整 CAS 方案”的合入版本

功能侧改动

cas-auth-complete 包含 cas-auth-support 的全部能力，并在此基础上补齐了完整 CAS 运行面：

1. 完整协议矩阵

• 标准 CAS
• CAS1
• CAS2
• CAS3 / serviceValidate
• SAML1 ticket validation

2. Developer / Admin 双侧完整打通

• 不只是 developer 侧
• admin 侧同样补齐 authorize / callback / exchange / logout / service definition 相关链路

3. Proxy Ticket / Proxy Callback 能力

• 补齐 PT / proxy 相关链路
• 本地 harness 已验证 developer / admin 两侧 proxy ticket 流程

4. Single Logout 能力

• front-channel logout
• back-channel logout
• 本地 harness 已验证登录后的吊销与回注销效果

5. CAS Header / MFA / Delegated Authentication

• CAS Header Response
• CAS MFA
• CAS Delegated Authentication
• Delegated 链路使用本地 mock OIDC 做联调支撑

6. LDAP / JWT Bearer 与 CAS 共存编排

• 不是单点能力孤立接入，而是放入统一认证编排里一起工作
• 本地 harness 会把 CAS / LDAP / JWT Bearer 放在同一个验证面里跑通

7. 属性同步与会话语义补齐

• 完善 CAS attributes 到 HiMarket 用户信息的映射与同步
• 对 Remember Me / TTL / 会话租期做了对齐处理
• 对 SAML 多值属性解析、SLO parser、协议细节健壮性做过修正

8. CAS service definitions 与高级策略导出

• 增加 CAS service definitions 导出能力
• 覆盖更完整的 access strategy / attribute release / proxy policy / MFA policy / time-based policy / unauthorized redirect policy 等高级配置面
• Admin UI 里也补齐了相应配置入口和说明

9. 完整本地认证验证面

• 本地 full harness 已覆盖：
  • cas-core
  • cas-header
  • cas-mfa
  • cas-delegated
  • ldap
  • jwt-bearer
• 其中 cas-core 内部又覆盖 developer / admin 的 CAS、CAS1、CAS2、SAML1、proxy、logout 等完整路径

cas-auth-complete 架构图

flowchart LR
  AdminUI[Admin UI<br/>CAS Config / Policy / Service Definitions] --> AdminAPI[HiMarket Admin API]
  AdminAPI --> PortalCfg[(Portal-level Auth Config)]
  AdminAPI --> ServiceDefs[CAS Service Definition Export]

  DevBrowser[Developer Browser] --> HMServer[HiMarket Server]
  OpsBrowser[Admin Browser] --> HMServer

  PortalCfg --> HMServer
  ServiceDefs --> CAS[Local CAS]

  HMServer --> CAS
  HMServer --> LDAP[OpenLDAP]
  HMServer --> JWKS[JWKS Server]

  CAS --> CASCore[CAS / CAS1 / CAS2 / CAS3 / SAML1]
  CAS --> Proxy[Proxy Ticket / Proxy Callback]
  CAS --> SLO[Front-channel / Back-channel Logout]
  CAS --> MFA[MFA Flow]
  CAS --> Delegated[Delegated Auth]

  Delegated --> MockOIDC[Mock OIDC]

  CASCore --> TokenIssue[HiMarket Token Issue / Session]
  Proxy --> TokenIssue
  MFA --> TokenIssue
  LDAP --> TokenIssue
  JWKS --> TokenIssue

  SLO --> TokenRevoke[HiMarket Token Revoke]

  Harness[Full Auth Harness] --> HMServer
  Harness --> CAS
  Harness --> LDAP
  Harness --> JWKS
  Harness --> MockOIDC

Loading

适合合入这个分支的原因

• 一次性拿到完整 CAS 能力，不需要再开第二轮协议补齐 PR
• 本地已经有完整可重复的联调验证路径
• 从协议面、运行面、配置面、验证面四层都更完整

---

结论

如果要合 PR，我建议现在就可以开始，二选一即可：

• 要更稳、更小步：cas-auth-support
  https://github.com/MisonL/himarket/tree/feature/cas-auth-support

• 要一次性完整交付：cas-auth-complete
  https://github.com/MisonL/himarket/tree/feature/cas-auth-complete

如果 maintainer 倾向其中一个方向，我这边就按那个分支来整理 PR。