Casdoor 的治理价值：Agent 时代先把身份、证据和权限讲清楚

Agent 系统进入企业以后，最难治理的不是模型能不能回答问题，而是谁允许它回答、它代表谁调用工具、它拿到哪些数据、失败时谁负责。Casdoor 的定位正好切到这个问题：它是开源 Agent-first IAM、LLM MCP & agent gateway 和带 Web UI 的 auth server。把它理解成“登录页”会低估它；把它放在身份、证据链和权限治理之间，才接近真实价值。

官方仓库 casdoor/casdoor 使用 Apache-2.0 许可证，默认分支 master。研究时最新 release 为 v3.121.0，发布于 2026-07-21；代码以 Go 为主，React 前端；go.mod 指向 Go 1.25.0 和 toolchain go1.25.8；后端依赖 Beego、Casbin，并引入 MCP Go SDK。官方能力覆盖 OAuth/OIDC、SAML、CAS、LDAP、SCIM、WebAuthn、TOTP/MFA、Face ID、Google Workspace、Azure AD、RBAC/ABAC、组织和多租户、REST API、SDK、Swagger、webhooks、Docker/Compose/Helm。

Agent 身份不应只有一个 service account

很多团队接入 Agent 时会创建一个长期 service account，然后把内部 API 权限一次性给足。这是治理事故的起点。Agent 应该有身份，但更应该有委托上下文：它代表哪个用户、哪个组织、哪个应用、哪个任务运行；token 多久过期；能否调用 MCP 工具；能否读取用户数据；能否触发写操作；审计日志能否还原当时的授权条件。

Casdoor 的组织、多租户、OAuth/OIDC、MCP gateway 和 RBAC/ABAC 能力适合承载这类边界。一个更健康的模式是：人通过 OIDC 登录，Agent 通过短期 token 或受限 client credentials 调用工具，管理后台能看到应用、用户、组织、provider、角色和策略关系。

证据治理：登录成功不是审计完成

Agent 产出的报告、工单、自动修复和数据查询都需要证据。身份系统至少要记录三类事实：认证事实，说明用户或应用如何通过登录；授权事实，说明当时策略为什么允许调用；操作事实，说明哪个 API、MCP 工具、webhook 或 SDK 被调用。Casdoor 提供 REST API、SDK 和 Swagger，方便企业把身份数据纳入内部审计平台。

# 伪代码：Agent 平台不应只校验 token 是否存在
verify_oidc_token(token)
assert org_id == task.org_id
assert scope includes "mcp:tool:read"
assert role permits resource_action
write_audit_event(user, agent, app, org, scope, tool, result)

配置片段：先从最小可信边界开始

试用可以用 Docker 或 Compose；生产应明确 origin、数据库、TLS、secret 和回调地址。

origin = https://iam.example.com
runmode = prod
httpport = 8000
# PostgreSQL/MySQL 使用独立账户、强密码、定期备份
# OIDC redirect_uri 只允许正式域名和明确回调路径

如果 Casdoor 前面有反向代理，必须确认 Host、X-Forwarded-Proto、cookie secure、issuer URL 和回调地址一致。身份系统里最常见的灰色故障不是服务启动失败，而是 issuer、origin、redirect URI 和浏览器 cookie 策略之间互相打架。

治理结论

Casdoor 适合希望把人、应用、组织、Agent 和协议统一管理的团队。它的意义不是替代所有企业安全产品，而是提供一个开源、可审计、协议覆盖足够宽的 IAM 中心。真正的落地标准应是：每个 Agent 调用都能说明身份、委托、权限、证据和边界，而不是只证明“能登录”。