企业官网建设流程全解析

• 模型推理服务
• 人工智能
• 后端
• 大模型
• MLOps
• LLMOps

导读

本文讲解如何在 BentoML 云服务平台 BentoCloud 上启用基于 SAML 2.0 协议的单点登录（SSO），让组织成员直接使用企业既有的身份提供商（IdP）凭据安全访问 BentoCloud 资源。读完本文，你将掌握 SAML 配置参数的含义、在 IdP 侧创建 SAML 2.0 应用的方法、上线后的验证步骤，以及 SSO 用户的角色管理与权限边界，完整覆盖企业接入 BentoCloud SSO 的全流程。

SAML 与 BentoCloud 的对接模型

SAML（Security Assertion Markup Language）是一种基于 XML 的开放标准，用于在**身份提供商（Identity Provider，IdP）与服务提供商（Service Provider，SP）**之间安全地传递用户认证与授权数据。在 BentoCloud 的对接模型里：

• BentoCloud 充当服务提供商（SP）：负责接收 IdP 签发的断言（assertion），据此为用户建立会话并授予平台访问权限；
• 组织自有的 IdP（如 Okta/Auth0）充当身份提供商：负责校验用户凭据，并向 BentoCloud 签发包含用户身份信息的 SAML 断言。

对接完成后，你的用户无需在 BentoCloud 上另行注册密码，而是直接使用企业或组织的既有账号凭据即可安全访问 BentoCloud 资源，这既统一了账号入口，也避免了在多个平台重复维护口令。

该功能面向 BentoCloud 的企业级部署形态。在 BYOC（Bring Your Own Cloud）模式下，BentoCloud 可部署进组织自有的私有云环境，SAML SSO 与之配合可进一步把身份认证也纳入组织的管控边界之内，相关背景可参见 Bring Your Own Cloud 概述 以及 AWS / Azure / GCP 三份 BYOC 接入指南（aws.rst、azure.rst、gcp.rst）。

第一步：准备并提交 SAML 配置参数

在启用 SSO 之前，你需要先从组织的 IdP 侧收集以下三项参数，并通过安全渠道提供给 BentoML 团队，由其完成 BentoCloud 侧的 SAML 配置：

需要注意：这些参数必须通过安全渠道传递。BentoML 团队会邀请你加入其安全保险库（secure vault）平台来共享这些参数；如果你尚未接入该平台，请向 BentoML 团队提供一个邮箱地址以接收保险库邀请。切勿通过明文邮件、聊天工具等不安全渠道发送证书与端点信息。

从协议角度看，三个参数分别对应 SAML 元数据中 IdP 的entityID、签名证书（用于验证Response/Assertion的签名）与SingleSignOnService的登录端点，是 IdP 侧 SAML 2.0 应用元数据的核心字段，缺一不可。

第二步：在身份提供商中创建 SAML 2.0 应用

在你组织的 IdP（例如 Okta）中创建一个新的SAML 2.0 应用（或等效类型），并填入以下两项 BentoCloud 侧的端点配置：

Application Callback URL（断言消费端点 / ACS URL）：

https://bentoml-prod.firebaseapp.com/__/auth/handler

该 URL 是 BentoCloud（SP）接收并消费 IdP 所签发 SAML 响应的端点，IdP 会在认证成功后把 SAML 断言 POST 到这里，因此必须在 IdP 应用中精确配置。

Application Login URI（登录启动 URI）：

https://<your-org-name>.cloud.bentoml.com/signup

其中<your-org-name>需要替换为 BentoCloud 提供给你的组织子域名或组织名称。这个 URI 是 BentoCloud 内的端点，用户访问它即可发起 SAML 登录流程（SSO 登录/注册入口）。

配置完成后，将这三项参数（Issuer、X.509 证书、Login URL）连同 IdP 侧应用配置一并提交给 BentoML 团队，由其完成 BentoCloud 侧的 SAML 对接。

第三步：验证与测试 SAML 配置

当 BentoML 团队在 BentoCloud 侧完成 SAML 配置后，按以下步骤验证链路是否打通：

1. 访问 BentoCloud 的登录/注册页面：https://<your-org-name>.cloud.bentoml.com/signup；
2. 页面上应只出现一个 “Continue with SSO” 选项（而非与普通账号密码登录并列的多个入口）；
3. 点击该选项后，应被重定向到你的身份提供商的登录页面；
4. 使用 IdP 中的企业凭据登录；
5. 登录成功后应被引导返回 BentoCloud，并获得一个已激活的会话（active session）。

如果第 2 步出现多个登录选项或第 3 步未正确跳转，通常是 IdP 侧的 Callback URL / Login URI 配置与 BentoCloud 侧元数据不一致所致，应回到第二步核对两端端点是否完全匹配（包括协议、域名与路径）。

第四步：SSO 用户与角色管理

新用户自动开户

当新用户通过 SSO 首次登录时，BentoCloud 会自动在其所在组织下创建对应的用户账号，默认角色为 Developer。组织管理员如需调整新用户的角色，可通过 BentoCloud 的管理界面修改。

BentoCloud 角色与权限边界

结合 BentoCloud 的用户管理文档，平台共有三种角色，权限从高到低依次为：

• Admin（管理员）：拥有 BentoCloud 内最高级别访问权限，可管理平台全部资源，并独占计费信息查看/编辑、成员增删、角色变更等管理能力；
• Developer（开发者）：具备开发与运维相关功能的全面访问权限，可创建/终止/恢复/删除 Deployment、更新 Deployment 配置、推送/删除 Bento 与模型等，但不涉及计费与用户管理；
• Endpoint User（端点用户）：主要面向对已部署模型发起推理调用的使用者，仅具备运行推理、查看/拉取 Bento 与模型、创建受保护端点访问令牌等有限权限。

具体到 SSO 场景，默认分配的 Developer 角色意味着新成员登录后即可参与部署与模型管理工作；若某些成员只需调用已上线的推理端点，管理员应将其调整为 Endpoint User。

两个关键注意事项

1. 在 IdP 中删除/禁用用户不会自动同步到 BentoCloud。该用户的 BentoCloud 会话在过期前仍然有效。要彻底移除某用户对 BentoCloud 的访问，必须由组织管理员在 BentoCloud 平台内手动删除该用户的成员关系；
2. 如需对 SSO 会话之外的自动化场景做细粒度授权（例如 CI/CD 流水线调用受保护端点），可结合 API Token 管理使用个人或组织级令牌，为不同工作流分配 Developer Operations Access 或 Protected Endpoint Access 权限。

安全与运维建议

• 证书与端点信息全程走安全渠道：SAML 证书、Issuer 与登录端点属于敏感配置，务必通过 BentoML 团队提供的保险库平台传递，不要在邮件或聊天工具中明文流转；
• 登录入口保持唯一：验证阶段确认signup页面只暴露 “Continue with SSO” 单一入口，避免出现弱口令与 SSO 并存带来的管理盲区；
• 定期盘点 SSO 用户：由于 IdP 侧的人员变动不会自动同步，建议组织管理员定期对照 IdP 目录与 BentoCloud 成员列表，及时在 BentoCloud 中删除离职成员的账号；
• 角色最小化：按职责分配角色，把大多数成员维持在 Developer 或 Endpoint User，将 Admin 仅授予必要的管理员，降低误操作与安全风险。

参考文档

• BentoCloud SSO with SAML（本文原始文档）
• Manage users（角色与权限明细）
• Bring Your Own Cloud 概述
• Manage API tokens（令牌鉴权与受保护端点）

• 模型推理服务
• 人工智能
• 后端
• 大模型
• MLOps
• LLMOps