介绍 Simmetric Chat Enterprise 插件
支持 SAML 2.0 和 OIDC 的 SSO、SCIM 供应、不可篡改的审计日志、白标、加密备份,以及面向受监管团队的 air-gap 许可。
Enterprise 是插件,不是分叉
开源项目交付 enterprise 层级最常见的方式是分叉:一个私有分支,与社区代码库渐行渐远,直到升级变成迁移项目。Simmetric Chat 选择了另一条路。enterprise 层级以可选插件包的形式交付——@simmetric-chat/enterprise——由社区服务器在启动时通过插件加载器加载。社区服务器在启动时探测该包:
- 找到且有效 → 插件注册其路由,enterprise 功能上线。
- 未安装 → 一行 info 级日志注明社区构建,服务器照常继续。
- 找到但损坏 → 服务器大声退出。损坏的 enterprise 安装绝不会静默降级到社区——半坏的 SSO 栈比没有更糟。
同一份许可管理该层级。社区代码库是 AGPL-3.0;enterprise 插件是单独许可的商业包,许可 JWT(LICENSE_KEY)就是解锁功能的钥匙。没有有效许可,enterprise 路由仍然挂载,但每个被门控的功能都以 402 响应,并附带命名功能和层级的显式 JSON 载荷——你的集成代码可以根据许可状态分支,而不是猜测。
身份:开箱即用的 SSO 和 SCIM
单点登录支持企业实际运行的两种协议:SAML 2.0(带 login、callback 和 metadata 端点,用于 IdP 发起的流程)和 OIDC(基于当前 OpenID Connect 客户端库的浏览器重定向流程的 login 和 callback)。两者都绑定到同一个管理员可配置的 SSO 面板。
配置在关键处保持灵活。OIDC 可以完全从管理员 SSO 面板配置(在数据库中加密静态存储)、完全从环境变量配置,或两者兼有——设置时 env 优先,因此 infrastructure-as-code 部署可以固定提供商设置,而面板在其他情况下保持为事实来源。内置提供商覆盖 Google、GitHub 和 Microsoft Entra,通用提供商接受任何发现文档。
SCIM 2.0 闭环生命周期:通过标准 SCIM 协议进行用户和组供应,端点受 Bearer token 保护。当 HR 在你的身份提供商中注销用户时,其 Simmetric Chat 账户通过同一流程停用——没有孤儿账户,没有电子表格驱动的取消供应。SSO 和 SCIM 结合在一起,意味着你的 IdP 仍然是关于谁存在、谁能登录的唯一权威。
无法被重写的审计日志
审计日志有一个尴尬的特性:它们越有价值,就越值得被修改。Simmetric Chat 的 enterprise 审计日志在数据库层面而非应用层面强制执行不可篡改。
一个专用的 Postgres 角色——simmetric_audit_writer——在审计表上只持有 INSERT 权限。enterprise 插件通过一个以该角色身份认证的独立连接池写入审计事件,因此 UPDATE 和 DELETE 在数据库层面失败,而非依靠应用约定。读取者刻意走另一条路:通过标准应用连接,该连接有 SELECT,但完全是另一个角色——写入者不能读,读取者不能写。
该保证对自己的配置是诚实的:设置了写入者密码时,启动日志确认不可篡改保证已生效;缺失时,审计日志仍会记录事件,但启动警告会说明数据库级不可篡改未被强制执行。故障安全默认值加上诚实的启动日志——这是该平台处处使用的模式。
审计日志通过事件日志查看器向管理员公开,由 audit_log_immutable 许可标志门控。身份验证事件、文档操作、设置更改、DLP 绕过、保留更改——这条线索就是"实际发生了什么?"的答案,并与社区 RBAC 故事组合:对日志本身的访问是一项权限。
白标和加密备份
两项功能面向将自己的 Simmetric Chat 交付给客户或将其作为具有严格数据策略的内部基础设施运行的团队:
白标在专用许可标志下移除面向客户表面的产品痕迹——嵌入式 widget、品牌默认值、UI 级定制。为客户部署知识助手的咨询公司可以将助手呈现为客户自己的;平台留在幕后。
备份超越了数据库转储:计划任务和按需任务产生加密的备份存档,保留策略决定保留什么、保留多久,权限划分区分谁可以配置目标、谁可以运行任务、谁可以检查日志、谁可以恢复。最后这一区分很重要——触发备份与将生产数据恢复到任意工作区是不同级别的信任,权限模型正是这样对待它们的。
面向受监管环境的 air-gap 许可
需要 SSO、不可变审计和受控备份的环境,往往正是没有互联网访问的环境。enterprise 许可正是为此构建:许可是一个 RS256 签名的 JWT,其嵌入的公钥随社区服务器交付。验证在本地进行——服务器对照嵌入密钥检查签名,因此无需可访问的许可服务器。在服务器环境中设置 LICENSE_KEY,重启,功能解锁;移除它,它们以显式 402 响应关闭回社区。
这一设计意味着 enterprise 部署完全在数据中心内部运行:通过 Ollama 的本地 LLM、本地向量存储、本地嵌入、本地 OCR,以及现在的本地许可验证。Air-gap 不是事后拧上的降级模式——它是这个产品围绕设计的部署形态。
这对 v0.22 产品线意味着什么
社区和 enterprise 产品线同步前进。社区服务器将 enterprise 插件声明为可选对等依赖;加载器在启动时解析它,共享插件上下文注入核心关注点(auth、crypto、数据库、logger),因此插件只能依赖共享契约,绝不依赖社区内部。社区版本和 enterprise 版本针对同一共享版本构建,版本不匹配会在启动时大声失败,而不是在运行时表现异常。
对操作员来说,实际总结是:安装插件包,设置有效的 LICENSE_KEY,在管理面板中配置 SSO,设置审计写入者密码,然后重启。启动日志会准确告诉你这些步骤中哪些成功了。社区层级保持 AGPL-3.0 且功能完整——SSO、审计和备份在其之上是附加的,由许可而非代码分叉门控。


