知 Zhihu EEAI Notes

2026/07/22

Casdoor 架构评估：把 Agent、企业 IAM 与协议网关放在同一条边界线上

Casdoor 不只是登录页，而是面向企业、AI Agent 和多协议接入的开源 IAM：OAuth/OIDC、SAML、CAS、LDAP、SCIM、MCP 网关、RBAC/ABAC 与多租户边界需要一起设计。

CasdoorIAMOIDCMCP多租户

Casdoor 的价值不在于“又一个开源登录系统”，而在于它把传统 IAM、企业 SSO、AI Agent 网关和多协议授权放进同一个工程边界。现代内部平台已经很少只有一个 Web 应用：有 React 前端、Go 服务、MCP 工具、自动化 Agent、供应商控制台、内部 API、移动端、第三方 SaaS。身份系统如果只处理用户名密码，很快会被 OAuth 回调、SAML 断言、LDAP 目录、SCIM 同步、MFA、组织隔离和审计要求拖垮。

官方仓库是 casdoor/casdoor。公开事实很明确：默认分支为 master，研究时最新 release 为 v3.121.0，发布时间 2026-07-21；项目以 Go 为主，前端为 React，许可证 Apache-2.0；go.mod 指向 Go 1.25.0，并声明 toolchain go1.25.8；后端使用 Beego、Casbin，并包含 MCP Go SDK 相关依赖。官方介绍将它定位为 open-source Agent-first IAM、LLM MCP & agent gateway 和带 Web UI 的 auth server。安全问题上报邮箱是 [email protected]。

协议栈：不要把所有接入都塞进 OAuth

Casdoor 同时支持 OAuth、OIDC、SAML、CAS、LDAP、SCIM、WebAuthn、TOTP/MFA、Face ID、Google Workspace、Azure AD 等能力。真正的架构问题不是“支持多少协议”，而是每种协议承担什么边界。新建 Web 应用优先用 OIDC；企业遗留系统常见 SAML 或 CAS；已有目录系统需要 LDAP；人员生命周期同步应考虑 SCIM；Agent 调用工具和 API 时，则要把 OAuth/OIDC token、MCP server 授权和 API scope 放到一起审查。

一个可执行的选择规则是：用户登录用 OIDC；企业 IdP 对接用 SAML 或 Azure AD/Google Workspace；组织、用户和组的同步用 SCIM；老系统过渡期才保留 CAS/LDAP；Agent 工具调用只接受短期 token 和明确 scope，不把管理员 session 透传给模型。

安装：先跑通边界，再谈替换企业 IAM

官方文档提供 Docker、Docker Compose、Helm 和服务器安装路径。最小试用可以先用容器和独立数据库完成：

git clone https://github.com/casdoor/casdoor.git
cd casdoor
# 生产环境不要直接复用示例 secret、默认数据库密码或公开端口
docker compose up -d

更接近生产的配置要把数据库、issuer、证书、cookie、反向代理和回调地址一起固定。Casdoor 支持 MySQL、PostgreSQL 等数据库；选择数据库时不要只看“能不能启动”，还要考虑备份、时区、字符集、连接池、迁移窗口和高可用。

appname = casdoor
httpport = 8000
runmode = prod
origin = https://iam.example.com
# datasourceName 使用强密码和最小权限账户
# driverName 可按官方支持选择 mysql、postgres 等

授权模型：Casbin 是优势，也是设计责任

Casdoor 使用 Casbin 支撑 RBAC/ABAC。这意味着组织可以把“谁能登录”与“谁能访问什么资源”分开建模。RBAC 适合角色清晰的后台系统，例如 admin、operator、viewer；ABAC 适合需要考虑租户、部门、资源标签、环境、数据分类的系统。不要把所有权限都写成一个巨大 admin 角色，也不要把业务授权完全推给应用自己判断。

在多租户场景，组织是第一道边界。用户、应用、provider、证书、token、角色策略都应确认是否跨组织可见。Agent-first IAM 尤其需要注意：Agent 往往代表某个用户、服务账号或团队运行，必须记录委托关系、过期时间和可调用工具，而不是简单把“某个机器人账号”长期授予全局权限。

运维边界：IAM 不能裸奔

Casdoor 可以作为统一入口，但不能承担所有安全责任。上线时至少要完成：TLS 终止和 HSTS；反向代理只暴露必要端口；管理后台加 MFA；数据库单独备份；secret 不进仓库；OIDC/SAML 回调白名单严格匹配；SCIM token 独立轮换；Swagger/API 访问分级；webhook 签名或来源校验；日志避免记录 access token、refresh token、密码和完整断言。

结论是，Casdoor 适合希望自托管、可审计、可扩展协议栈的团队。它不适合被当作“复制 docker-compose 就上生产”的登录组件。把它放在企业 IAM、Agent 工具网关和多租户授权边界上评估，才能看出这个项目真正的工程含义。