SAML 授权与访问控制

关于为您的组织定义访问策略和管理 SAML 的指导与方法。

SAML 允许组织利用现有的身份提供商 (IdP) 来管理 Tulip 用户的身份验证和访问权限。本指南将详细介绍通过 SAML 协议实现企业级 IdP 集成的可用选项。

前期准备

• 了解 Tulip 用户角色
• 按角色对预计的 Tulip 用户进行分类，以便您能够根据其 Tulip 角色更新 SAML 属性
• 确定组织内负责配置 IdP 和 Tulip 账户的人员

IdP 配置

当您的 Tulip 实例配置为使用 SAML 登录时，Tulip 会在 Tulip 中的用户与您企业身份提供商（IdP）中的用户之间建立关联。在 IdP 中拥有账户的特定用户，在给定的 Tulip 实例中最多应拥有一个账户。 Tulip 通过一种名为“NameID”的 SAML 特定概念来维护这种关联。NameID 是 SAML 身份验证提供的、由 IdP 定义的不透明标识符类型。

由于 NameID 用于维护此关联，Tulip 要求 NameID 保持稳定，这意味着**Tulip 接收到的特定 IdP 用户的 NameID 在该用户生命周期内不应发生变化。**如果用户的 NameID 发生变化，关联将被中断，您在登录时可能会遇到错误。

Tulip 强烈建议您配置身份提供商（IdP），使其提供的 NameID 不会随时间变化。因此**，Tulip 不建议将姓名或电子邮件地址用作 NameID**，因为这些值可能会随时间变化。我们建议您配置身份提供商（IdP）使用内部对象 ID 或账户名称，这些值可确保永不改变。

请注意，NameID 无需是人可读或可识别的（事实上，出于安全考虑，通常最好使用不可识别的值作为 NameID）。

在配置您的身份提供商 (IdP) 时，我们建议将 NameID 格式设置为**“持久型”（Persistent）**，这会向 Tulip 表明该值在用户生命周期内应保持不变。

在映射 NameID 属性的源值时，请将其映射到已知不可变的值，例如“对象 ID”或“用户主体名称”。

Microsoft Entra

对于使用Microsoft Entra作为身份提供商 (IdP) 的客户，请按照以下具体说明配置您的 Tulip 应用程序，以使用持久性 NameID：

1. 在 Entra 中，从与您的 Tulip 实例关联的企业应用程序开始操作。
2. 在左侧导航菜单中，点击“管理”组下的“单点登录”。
3. 编辑“属性与声明”部分。
4. 在“必需声明”部分，点击名为“唯一用户标识符（Name ID）”的声明行。
5. 确保“名称标识符格式”设置为“持久”。将“来源”设置为“属性”，并选择一个在用户整个生命周期内保持稳定的属性。user.userprincipalname和user.objectid都是不错的选择。

SAML 和 Tulip 配置选项

控制模式

Tulip 控制模式表示**，仅在用户首次登录 Tulip 时，其 Tulip 角色和工作区才会从 SAML 属性映射中获取。**

在 Tulip 中被停用的用户将无法登录。

IdP 控制模式意味着用户的 Tulip 角色和工作区将在每次登录时从 IdP 更新**。**

默认角色映射（仅限 Tulip 控制模式）

首次登录时，所有用户均被授予默认访问级别（具有播放器访问权限的查看者）。随后，账户所有者需要在 Tulip 中手动将角色调整至适当级别。

工作区

了解有关工作区的更多信息

与角色属性类似，现在您可以在创建用户时，选择将用户自动映射到特定的工作区。用户创建后，账户所有者可以灵活地在不同工作区之间转移用户。

SAML 自定义工作区映射

:::(信息) (多个工作区)
请注意，仅在Tulip 控制模式下，您才能将用户映射到多个工作区。

在 IdP 控制模式下，每个用户只能属于一个工作区。
:::

首次登录时，系统会根据用户工作区属性中显示的组来分配工作区访问权限。此后，Tulip将不再读取该用户的工作区属性，任何工作区变更都必须由账户所有者在平台中进行。

默认工作区映射

首次登录时，所有用户将获得您所选默认工作区的访问权限。随后，账户所有者可调整工作区访问权限。

用户组

在所有 SAML 配置中，您均可将用户映射到 Tulip的“用户组”{target=_blank} 功能中。

用户组存在于账户级别。一旦用户被映射到某个用户组，他们将在所有工作区中成为该用户组的成员。

启用“用户组”选项后，您将能够根据 SAML 中某个属性的值，将来自身份提供商 (IdP) 的用户映射到 Tulip 中的用户组。

之后，您可以指定最多 100 个 SAML 属性，并将每个属性的值映射到一个用户组。这样，一个用户即可被映射到多个用户组。

用户组映射与控制模式的行为

用户组成员资格的行为取决于您的“控制模式”设置。

• Tulip 控制模式：用户通过 SAML 映射的组仅在首次登录时生效。此后，可在 Tulip 内管理组成员身份，且任何手动更改将在后续登录时保留。
• IdP 控制模式：每次登录时，系统都会根据用户的当前 SAML 属性重新计算其完整的组成员身份。Tulip 会分配映射计算出的所有组，并将用户从映射未涵盖的任何组中移除，包括在 Tulip 中手动分配的组。

身份验证选项

如果您希望使用 FIDO 密钥进行用户身份验证，则需要“禁用身份验证方法匹配”。

身份验证上下文类

身份验证上下文类是用户进行身份验证的指定方法。

启用后，用户只能使用指定方法进行身份验证。

如果禁用，身份提供商将完全负责身份验证方法的选择。

强制身份验证

Tulip 使用 SAML 的forceAuthn参数来控制用户是否必须在每次登录时通过其身份提供商（IdP）重新认证，或者是否可以重用现有的操作系统级 SAML 会话。 Tulip 不使用isPassive参数。此处的现有会话是指操作系统级别的 SAML 会话（例如，与您的身份提供商绑定的 Windows 会话），而不是 Tulip 专有的会话。

强制身份验证开启（默认）：Tulip 发送forceAuthn=true，要求用户在每次登录时都必须主动通过其身份提供商进行身份验证，无论是否存在现有的操作系统级 SAML 会话。此设置可确保用户无法绕过重新身份验证。

强制身份验证关闭：Tulip 发送forceAuthn=false。如果用户已有被身份提供商（IdP）识别的有效操作系统级 SAML 会话，则将自动登录 Tulip，无需重新输入凭据。

自定义

用户登录的可选自定义设置。

登录按钮标签- 自定义 Tulip 登录页面上 SAML 登录按钮的文本。

自定义支持邮箱- 设置当用户遇到 SAML 登录错误时显示的自定义邮箱地址。这可引导用户联系您的内部 IT 支持团队。若留空，将使用默认支持邮箱地址“support@tulip.co”。

桌面播放器：用于身份验证的操作系统默认浏览器

如果您的 SSO 登录或 OAuth 连接器授权需要通过默认浏览器才能实现的集成，可将 Tulip 播放器配置为在操作系统默认浏览器中打开身份验证流程，而非在嵌入式窗口中打开。

版本要求

若要使用操作系统默认浏览器进行身份验证，您必须满足以下 Tulip 版本要求：* 桌面播放器 2.8 或更高版本* Factory 版本 318 或更高版本

功能行为

此行为既适用于通过 SSO 登录桌面播放器，也适用于在 Tulip 应用内授权 OAuth 连接器。在这两种情况下，当用户发起身份验证时，其默认系统浏览器将打开以处理以下流程：

1. 系统浏览器启动并跳转至您所在组织的身份提供商（IdP）登录页面。
2. 用户在浏览器中完成登录（输入凭据、完成多因素认证等），操作流程与在网页上完全一致。
3. 身份验证完成后，浏览器页面将显示以下消息：“完成！您可以关闭此窗口。”
4. 浏览器窗口保持打开状态，不会自动关闭。用户应手动将其关闭。
5. Tulip Desktop Player 会检测到登录已完成，并正常继续处理。

预期权限提示

根据用户的操作系统和浏览器配置不同，用户可能会遇到一到两个权限提示：

1. Desktop Player 防火墙/本地服务器权限（操作系统级别）

当启动身份验证时，Desktop Player 会创建一个临时本地服务器来接收身份验证响应。根据操作系统和安全设置的不同，可能会出现系统防火墙或网络访问提示，询问是否允许 Desktop Player 接受传入连接。

• 所需操作：允许该连接。这是预期行为，且是完成登录的必要步骤。
• 根据操作系统设置的不同，此提示可能仅在首次出现，也可能每次都会出现。

2. 浏览器本地网络访问权限（浏览器级别）

用户通过身份提供商完成登录后，浏览器的身份验证完成页面会向上述本地服务器发送请求，将结果发回桌面播放器。某些浏览器会显示权限提示，询问是否允许该页面访问本地网络上的设备。

• 需采取的操作：允许访问。这是身份验证流程中安全且预期的步骤。
• 该请求仅发往localhost，且仅包含加密的身份验证响应。此时不会传输任何敏感凭据。

面向用户的差异总结

下表对比了默认身份验证与操作系统浏览器启用身份验证的行为：

示例：在您的身份提供商（IdP）中创建访问组

以下示例将帮助您了解如何将 SAML 设置中的各种选项结合使用。

创建标准化的 Tulip 角色

每个用户都需要在您的身份提供商（IdP）中指定一个角色属性，以便用户使用其 IdP 用户名和密码通过身份验证后，Tulip 能够确定其权限。

您还可以利用此“角色”字段，通过标准命名约定来确定用户可访问的站点。虽然“角色”字段可以仅作为一组变量，但建议您将用户分配到身份提供商（IdP）内的Tulip 专用组中，并将这些组映射到相应属性。

角色

每个用户在单个工作区中将被分配一个角色。

当 Tulip 收到用户的多个有效角色时，将应用以下逻辑：

如果该集合包含任何内置角色（如操作员、构建者等），Tulip 将根据静态内部层级结构，选择等级最高的内置角色。自定义角色在层级上始终低于所有内置角色，因此只要存在任何内置角色，自定义角色就不会被选中。

如果该集合仅包含自定义角色，Tulip 将选择 SAML 负载中收到的第一个自定义角色。

了解 Tulip用户角色。

站点

假设您的组织有两个站点，每个站点都配有一个Tulip Instance 。

我们可以按其所在地（分别是德克萨斯州和伦敦）来表示每个站点。

结合站点和角色

我们可以将这两个属性结合起来，创建一个用于分配用户的组矩阵。我们建议组织在值的前后添加“Tulip”，以便于筛选。

命名约定：tulip-siteRole

如果简·史密斯是德克萨斯站点的主管，则应将其分配到tulip-texasAccountOwner 组。如果简·史密斯还需要查看伦敦站点的权限，则可将其添加到tulip-londonViewer 组。

将这些组作为 Tulip 的属性进行暴露

在您的身份提供商（IdP）中，简应拥有一个名为 tulip-role 的属性，其中将映射她所属的、包含前缀“tulip-”的所有组。

当她登录 Tulip 时**，tulip-role**属性将包含两个值：**tulip-texasAccountOwner 和 tulip-londonViewer。**您可以针对每个Tulip instance 分别配置角色映射，确保她在每个实例中获得正确的权限。

全局角色

您可能还希望创建全局访问角色，例如“Viewer”角色。这些用户将能够以相同的权限登录到每个Tulip instance 。推荐的格式如下：

tulip-globalViewer

您需要在“账户设置”中的 SAML 配置页面，为每个独立实例分别设置此角色映射，才能使该用户访问各个实例。