Skip to content
Platform

多个单点登录提供商

许多企业需要在 Supabase 中配置多个单点登录（SSO）提供商，以支持不同的环境、团队或组织结构。本指南说明了何时以及如何有效地设置多个提供商。

🌐 Many enterprises need multiple single sign-on (SSO) providers configured within Supabase to support different environments, teams, or organizational structures. This guide explains when and how to set up multiple providers effectively.

为什么要有多个单点登录提供商？ #

🌐 Why multiple SSO providers?

需要多个单点登录（SSO）提供商的常见情况包括：

🌐 Common scenarios requiring multiple SSO providers include:

  • 多环境：分开开发、预发布和生产环境
  • 团队分离：不同的业务单元或部门
  • 迁移：从一个身份提供者切换到另一个身份提供者
  • 收购：整合拥有不同身份系统的子公司
  • 测试：独立测试环境与生产环境并存

关键概念：IDP 发起允许每个域无限制的提供者 #

🌐 Key concept: IDP-initiated enables unlimited providers per domain

多个 SAML 应用的传统难题是域名冲突。如果只用 SP 发起的流程，每个 SAML 应用都需要独特的邮箱域名。因为你所有员工都用同一个域名（比如 company.com），这就会产生问题。

🌐 The traditional challenge with multiple SAML apps is domain conflicts. With SP-initiated flow only, each SAML app requires a unique email domain. Since all your employees use the same domain (e.g., company.com), this creates a problem.

解决方案： 使用身份提供者（IdP）发起的流程，这种方式不需要域名配置。你可以在同一个域名下创建无限数量的 SAML 应用。

用例 1：多个环境（开发/测试/生产） #

🌐 Use case 1: Multiple environments (dev/staging/prod)

这是最常见的企业模式，也是 IDP 发起流程的主要使用场景。

🌐 This is the most common enterprise pattern and the primary use case for IDP-initiated flow.

挑战 #

🌐 The challenge

你有三个 Supabase 组织：

🌐 You have three Supabase organizations:

  • 开发（dev-org）
  • 暂存 (staging-org)
  • 生产（prod-org）

所有员工都使用 company.com 邮箱地址。每个环境都需要单独的 SSO 配置。

🌐 All employees use company.com email addresses. You need separate SSO configurations for each environment.

解决办法 #

🌐 The solution

在你的身份提供者中创建三个独立的 SAML 应用，每个指向不同的 Supabase 组织。

🌐 Create three separate SAML apps in your identity provider, each pointing to a different Supabase organization.

在你的身份提供者（Okta、Azure AD、Google Workspace）中 #

🌐 In your identity provider (Okta, Azure AD, Google Workspace)

  1. 创建 “Supabase Dev” SAML 应用
    • 使用开发组织的 ACS URL 进行配置
    • 分配开发者和测试人员
    • 部署标有“Supabase Dev”的应用磁贴
  2. 创建 “Supabase Staging” SAML 应用
    • 使用暂存组织的 ACS URL 配置
    • 分配QA团队和发布经理
    • 部署名为“Supabase Staging”的应用瓦片
  3. 创建 “Supabase Production” SAML 应用
    • 使用生产组织的 ACS URL 进行配置
    • 仅分配生产用户
    • 部署标有“Supabase Production”的应用磁贴

在每个 Supabase 组织中 #

🌐 In each Supabase organization

  1. 导航到仪表板的SSO 设置部分
  2. 启用单点登录
  3. 保持 启用 SP 发起的登录 为“关闭”，这很关键
  4. 从对应的 IDP 应用配置元数据
  5. 设置属性映射
  6. 如果想的话，配置自动加入

结果 #

🌐 Result

  • 用户点击他们需要的环境对应的应用图块
  • 没有域名冲突（所有应用都使用 company.com）
  • 环境之间的清晰隔离
  • 每个环境可以有不同的用户分配和角色

配置示例 #

🌐 Configuration example

这就是三种配置的区别：

🌐 Here's how the three configurations differ:

环境组织IDP 应用名称ACS 链接
开发dev"Supabase 开发"https://...dev-org.../saml/acs
预发布staging"Supabase 预发布"https://...staging-org.../saml/acs
生产prod"Supabase 生产"https://...prod-org.../saml/acs

每个组织 #

🌐 Each organization

  • SP发起：关闭（未配置域）
  • IDP 发起：开启（自动，无需配置）
  • 自动加入：你的偏好（开发环境通常启用，生产环境通常禁用）

用例 2：不同的团队或业务单元 #

🌐 Use case 2: Different teams or business units

有些组织需要将团队隔离在不同的 Supabase 组织中。

🌐 Some organizations need to isolate teams within separate Supabase organizations.

示例场景 #

🌐 Example scenario

  • 工程团队使用 engineering-org
  • 数据团队使用 data-org
  • 两队都有 company.com 封邮件

配置方式 #

🌐 Configuration approach

选项A：由IDP发起，带有不同的应用图标 #

🌐 Option A: IDP-initiated with different app tiles

在你的身份提供商中创建单独的 SAML 应用：

🌐 Create separate SAML apps in your IDP:

  • "Supabase 工程" → 指向 engineering-org
  • "Supabase 数据" → 指向 data-org

给每个应用分配合适的用户。用户只能看到分配给他们的应用块。

🌐 Assign appropriate users to each app. Users only see the tiles they're assigned to.

选项B：IDP和SP发起的角色基路由 #

🌐 Option B: Both IDP and SP-initiated with role-based routing

用同一个域配置两个组织，并启用 SP 发起模式：

🌐 Configure both organizations with SP-initiated enabled using the same domain:

  • 两个组织都添加了 company.com 作为域名
  • 用户可以通过 SP 发起在 supabase.com 登录
  • 系统根据组织成员身份进行路由（先匹配者优先）
  • 还要提供用于显式路由的IDP瓦片

用例3：从一个身份提供商迁移到另一个身份提供商 #

🌐 Use case 3: Migration from one IDP to another

当从一个身份提供商迁移到另一个时，使用多个提供商有助于确保过渡顺利。

🌐 When migrating from one identity provider to another, multiple providers help ensure a smooth transition.

迁移流程 #

🌐 Migration workflow

第一阶段：双重配置 #

🌐 Phase 1: Dual configuration

  1. 配置新的身份提供商作为额外的单点登录提供者
  2. 保持现有的 IDP 活跃
  3. 用小组测试新的IDP
  4. 两个提供商同时运行

第二阶段：逐步推出 #

🌐 Phase 2: Gradual rollout

  1. 分批把用户迁移到新的身份提供商
  2. 更新应用图块分配
  3. 注意问题
  4. 保留旧的 IDP 作为备用

第三阶段：切换 #

🌐 Phase 3: Cutover

  1. 把所有用户迁移到新的身份提供者
  2. 确认没有用户依赖旧的身份提供者
  3. 禁用（不要删除）旧的 IDP 提供者
  4. 注意是否有问题

第四阶段：清理 #

🌐 Phase 4: Cleanup

  1. 验证期后（1-2周）
  2. 删除旧的IDP提供商
  3. 更新文档

用例4：收购和子公司 #

🌐 Use case 4: Acquisitions and subsidiaries

拥有多个邮箱域名的组织需要为每个域名配置提供商设置。

🌐 Organizations with multiple email domains need provider configurations for each domain.

示例场景 #

🌐 Example scenario

  • 母公司：parent.com
  • 子公司1：subsidiary1.com
  • 子公司 2：subsidiary2.com

所有人都通过同一个中央身份提供者认证，但使用不同的邮箱域名。

🌐 All authenticate through the same central IDP but use different email domains.

配置方式 #

🌐 Configuration approach

选项 A：单一提供商，多域名（SP 发起） #

🌐 Option A: Single provider with multiple domains (SP-initiated)

  1. 启用 SP 发起的 SSO 流程
  2. 添加所有域名：parent.com、subsidiary1.com、subsidiary2.com
  3. 配置单个IDP元数据
  4. 任何匹配域的用户都可以通过 supabase.com 登录

选项 B：每个子公司使用不同的提供商（IDP 发起） #

🌐 Option B: Separate providers per subsidiary (IDP-initiated)

  1. 为每个实体创建单独的 SAML 应用
  2. 仅配置为 IDP 发起
  3. 根据子公司分配用户
  4. 更多隔离，更清晰的组织边界

一步步设置指南 #

🌐 Step-by-step setup guide

针对 IDP 发起的多环境模式 #

🌐 For IDP-initiated multi-environment pattern

这是大多数企业推荐的模式。

🌐 This is the recommended pattern for most enterprises.

步骤 1：规划你的环境 #

🌐 Step 1: Plan your environments

文档：

🌐 Document:

  • 组织名称和标识名
  • 环境用途（开发、测试、生产）
  • 哪些用户需要访问哪些环境
  • 每个环境的默认角色

步骤 2：在你的身份提供商中创建 SAML 应用 #

🌐 Step 2: Create SAML apps in your IDP

对于每个环境，按照你的服务提供商的指南来创建一个 SAML 应用：

🌐 For each environment, follow your provider-specific guide to create a SAML app:

命名规范示例 #

🌐 Naming convention example

  • Supabase - 生产
  • Supabase - 测试环境
  • Supabase - 开发

使用一致的命名来帮助用户识别正确的环境。

🌐 Use consistent naming to help users identify the right environment.

步骤 3：配置每个 Supabase 组织 #

🌐 Step 3: Configure each Supabase organization

针对每个组织：

🌐 For each organization:

  1. 导航到仪表板的SSO 设置部分
  2. 启用单点登录
  3. 确认 启用 SP 发起的登录 是“关闭”
  4. 上传或粘贴对应 IDP 应用的元数据
  5. 配置属性映射：
    • 电子邮件（必填）：映射到 email
    • 名字（可选）：映射到 name 或 displayName
  6. 配置自动加入设置：
    • 开发者：通常在拥有“开发者”角色时启用
    • 分阶段部署：通常在“开发者”角色下启用
    • 产品：通常禁用（仅限明确邀请）
  7. 保存配置

第4步：分别测试每个环境 #

🌐 Step 4: Test each environment separately

对于每个环境：

🌐 For each environment:

  1. 打开你的 IDP 仪表板（Okta、Azure、Google）
  2. 点击对应的应用图块
  3. 验证是否重定向到正确的 Supabase 组织
  4. 检查用户信息是否填写正确
  5. 验证自动加入行为（如果启用）

查看SSO 测试与最佳实践指南了解全面的测试流程。

🌐 See the SSO Testing and Best Practices guide for comprehensive testing procedures.

第5步：在你的身份提供商中分配用户 #

🌐 Step 5: Assign users in your IDP

在你的身份提供商中配置应用分配：

🌐 Configure app assignments in your IDP:

  • 生产：仅限生产用户（限制性）
  • 部署环境：QA团队、发布经理、高级工程师
  • 开发：所有工程师和测试人员（宽松）

用户只能看到分配给他们的应用磁贴。

🌐 Users only see app tiles they're assigned to.

第6步：记录并沟通 #

🌐 Step 6: Document and communicate

为你的团队创建文档：

🌐 Create documentation for your team:

  • 哪个应用图标对应哪个环境
  • 每个环境的访问请求流程
  • 命名规范和组织结构
  • 紧急访问流程（非单点登录拥有者账户）

用户访问管理 #

🌐 User access management

IDP 应用分配策略 #

🌐 IDP app assignment strategies

按环境的访问控制 #

🌐 Per-environment access control

通过在你的身份提供商中管理应用分配来控制谁可以访问每个环境：

🌐 Control who can access each environment by managing app assignments in your IDP:

Engineering Team:
├─ Supabase Dev (assigned) ✅
├─ Supabase Staging (assigned) ✅
└─ Supabase Prod (assigned) ✅
QA Team:
├─ Supabase Dev (assigned) ✅
├─ Supabase Staging (assigned) ✅
└─ Supabase Prod (NOT assigned) ❌
Contractors:
├─ Supabase Dev (assigned) ✅
├─ Supabase Staging (NOT assigned) ❌
└─ Supabase Prod (NOT assigned) ❌

角色分配模式 #

🌐 Role assignment patterns

选项 1：每个环境不同的默认角色 #

🌐 Option 1: Different default roles per environment

  • 开发者：自动加入“管理员”角色（开发者需要完全控制权限）
  • 分阶段：自动加入“开发者”角色
  • 产品：不自动加入，只能通过明确邀请，分“只读”或“开发者”

选项2：角色固定，手动晋升 #

🌐 Option 2: Consistent roles, manual promotion

  • 所有环境：自动加入“开发者”角色
  • 根据需要手动提升为“管理员”或“所有者”
  • 提供稳定的基线，明确的提升

选项 3：不自动加入，手动控制 #

🌐 Option 3: No auto-join, explicit control

  • 所有环境：自动加入已禁用
  • 发送带有适当角色的明确邀请
  • 最大控制，更高管理开销

根据你们组织的安全状况和操作偏好来选择。

🌐 Choose based on your organization's security posture and operational preferences.

最佳实践 #

🌐 Best practices

命名规范 #

🌐 Naming conventions

IDP 应用名称 #

🌐 IDP app names

使用一致且具有描述性的名称，清楚地指示环境：

🌐 Use consistent, descriptive names that clearly indicate the environment:

  • ✅ “Supabase - 正式环境”
  • ✅ "Supabase 生产环境"
  • ❌ “Supabase”（不明确）
  • ❌ “SUPA_PROD”（缩写不清楚）

Supabase 组织名称 #

🌐 Supabase organization names

尽可能匹配你的 IDP 应用名称：

🌐 Match your IDP app names when possible:

  • IDP 应用："Supabase - 生产" → 组织：acme-production
  • IDP 应用："Supabase - Staging" → 组织：acme-staging
  • IDP 应用："Supabase - Dev" → 组织：acme-development

配置同步 #

🌐 Configuration synchronization

保持关键设置在各环境中同步：

🌐 Keep critical settings synchronized across environments:

  • 属性映射：在所有提供商中应该相同
  • 证书设置：协调所有环境的续期
  • 安全账户：每个组织都需要一个非SSO的所有者账户

配置漂移检查清单 #

🌐 Configuration drift checklist

  • 属性映射在各个环境中一致
  • 所有供应商的证书到期日期都有记录
  • 所有组织中都有非单点登录的拥有者账户
  • 自动加入设置是故意的（不是意外的）
  • 适合每个环境的默认角色

先在低环境下测试 #

🌐 Testing in lower environments first

总是在非生产环境中测试 SSO 更改：

🌐 Always test SSO changes in non-production environments:

  1. 在开发环境中进行更改
  2. 彻底测试（参见测试指南）
  3. 部署到预发布环境并进行验证
  4. 监控问题（1-2天）
  5. 在低使用期部署到生产环境
  6. 在生产部署后密切监控

安全注意事项 #

🌐 Security considerations

环境隔离 #

🌐 Environment isolation

  • 不要在不同环境之间重复使用元数据（存在安全风险）
  • 每个环境应该有独特的 ACS URL
  • 确认 IDP 应用分配是否正确（别不小心给了生产环境权限）

访问审核 #

🌐 Access reviews

  • 对谁有权限访问生产环境的季度审查
  • 确认 IDP 应用的任务是否是最新的
  • 移除已更改角色的用户的访问权限
  • 审查自动加入配置（还合适吗？）

紧急访问 #

🌐 Break-glass access

每个组织至少必须有一个非SSO的拥有者账户：

🌐 Each organization must have at least one non-SSO owner account:

  • 创建专用的“破玻璃”账户
  • 把凭证存到安全的密码管理器里
  • 定期（每季度）测试这些账户
  • 记录紧急访问程序

故障排除 #

🌐 Troubleshooting

用户访问了错误的环境 #

🌐 Users accessing the wrong environment

症状 #

🌐 Symptom

用户点击了“Supabase 生产环境”图块，但看到的是开发环境。

🌐 User clicks "Supabase Prod" tile but sees the dev environment.

原因 #

🌐 Causes

  • 元数据配置错误（在环境之间交换了）
  • ACS 的网址指向了错误的组织
  • 用户把错误的组织加到书签了

解决办法 #

🌐 Solution

  1. 在 IDP 应用配置中验证 ACS URL
  2. 比较 Supabase SSO 设置中的元数据
  3. 检查组织别名是否与预期环境匹配
  4. 让用户清除浏览器的Cookies然后再试一次
  5. 确认用户点击的是正确的应用图标

环境之间的配置漂移 #

🌐 Configuration drift between environments

症状 #

🌐 Symptom

单点登录在开发环境能用，但在预发布或生产环境会失败。

🌐 SSO works in dev but fails in staging or production.

原因 #

🌐 Causes

  • 不同提供商之间的属性映射不同
  • 证书在某个环境过期了，但其他环境没有
  • 域配置不一致（如果使用 SP 发起的话）

解决办法 #

🌐 Solution

  1. 并排比较单点登录配置
  2. 检查属性映射是否相同
  3. 核实证书到期日期
  4. 在所有环境中使用同一个用户账号进行测试
  5. 查看 IDP 审计日志中的身份验证失败情况

用户看不到预期的应用图标 #

🌐 Users don't see expected app tiles

症状 #

🌐 Symptom

用户在 IDP 仪表板上找不到“Supabase Staging”图块。

🌐 User cannot find "Supabase Staging" tile in IDP dashboard.

原因 #

🌐 Causes

  • 用户未在IDP中分配到应用
  • 应用未在 IDP 上部署/发布
  • 用户看错地方了（不同的IDP门户）

解决办法 #

🌐 Solution

  1. 在 IDP 管理控制台验证应用分配
  2. 检查应用是否已发布/活跃
  3. 确认用户已登出并重新登录到 IDP
  4. 确认用户正在查看正确的 IDP 门户（有些组织有多个）

自动加入把用户添加到错误的组织 #

🌐 Auto-join adding users to wrong organization

症状 #

🌐 Symptom

用户应该加入生产环境，却加入了开发环境。

🌐 User joins dev environment when they should join production.

原因 #

🌐 Cause

用户点击了错误的应用图标，自动加入已启用。

🌐 User clicked wrong app tile, auto-join is enabled.

预防 #

🌐 Prevention

  • 在生产环境中禁用自动加入（仅限明确邀请）
  • 使用清晰的应用图标命名
  • 哪个磁贴对应哪个环境的文档
  • 考虑为不同环境使用不同的 IDP 组

补救 #

🌐 Remediation

  1. 将用户从错误的组织中移除
  2. 向正确的组织发送明确邀请
  3. 向用户说明正确的应用图标使用方法
  4. 考虑关闭自动加入以防止再次发生

多个组织使用同一域名（SP发起的混淆） #

🌐 Multiple organizations with same domain (SP-initiated confusion)

症状 #

🌐 Symptom

开启 SP 发起并且多个组织中有相同域名时，用户会被导向意外的组织。

🌐 With SP-initiated enabled and same domain in multiple organizations, users get routed to unexpected organization.

原因 #

🌐 Cause

SP 发起的路由使用第一个匹配的提供者。

🌐 SP-initiated routing uses first matching provider.

解决办法 #

🌐 Solution

  • 推荐： 切换为仅 IDP 发起（禁用 SP 发起）
  • 从除一个组织之外的所有组织中移除域配置
  • 提供清晰的IDP应用图标以便明确路由
  • 文档说明组织用户应该通过SP发起访问

从单一供应商迁移到多个供应商 #

🌐 Migration from single to multiple providers

如果你现在只有一个单点登录提供商，但需要添加更多：

🌐 If you currently have a single SSO provider and need to add more:

第一阶段：规划 #

🌐 Phase 1: Planning

  1. 决定使用哪种模式（环境、团队等）
  2. 记录新的组织结构
  3. 为每个环境识别用户
  4. 制定用户沟通策略

第二阶段：创建新组织 #

🌐 Phase 2: Create new organizations

  1. 创建额外的 Supabase 组织
  2. 在每个组织中配置项目
  3. 如有需要，迁移数据（见项目转移）

第3步：配置单点登录提供商 #

🌐 Phase 3: Configure SSO providers

  1. 在你的身份提供商中创建更多 SAML 应用
  2. 在每个新组织中配置单点登录
  3. 一开始禁用自动加入
  4. 小组测试

第四阶段：迁移用户 #

🌐 Phase 4: Migrate users

  1. 向用户告知变化
  2. 把用户分配到合适的 IDP 应用
  3. 测试用户能否访问正确的环境
  4. 如果想的话，启用自动加入

第5阶段：注销旧配置（如适用） #

🌐 Phase 5: Decommission old configuration (if applicable)

  1. 把所有用户迁移到新结构
  2. 确认没人依赖旧配置
  3. 禁用旧的单点登录提供商
  4. 注意问题
  5. 验证期后删除

下一步 #

🌐 Next steps