- 入门指南
- 数据安全性与合规性
- 组织
- 身份验证和安全性
- 许可
- 租户和服务
- 帐户和角色
- Ai Trust Layer
- 外部应用程序
- 通知
- 日志记录
- 故障排除
- 迁移到 Automation Cloud™
了解身份验证模型
本地用户帐户代表每个用户的帐户,是 UiPath 平台的内部帐户。
本地帐户模型提供了一种独立的身份验证方法。新用户需要收到组织管理员的邀请才能加入。适用于要完全控制平台内用户管理的场景。
在组织设置中,您可以完全控制用户可用的身份验证方法:
-
要允许使用所有可用方法(Google、Microsoft、基本身份验证)以获得最大灵活性,请选择“所有可用方法”选项。
-
要将身份验证限制为仅对 Google 帐户进行身份验证,请选择“Google 登录”选项。
-
要将身份验证仅限于 Microsoft,请选择“Microsoft 登录”选项。
默认情况下,此模型适用于任何新组织。它易于使用、设置快捷,并且便于您的用户使用。
创建用户的流程如下:
- 组织管理员需要获取用户的电子邮件地址,并使用这些电子邮件地址邀请每位用户加入组织。您可以批量执行此操作。
-
每位受邀员工都可通过导航到邀请电子邮件中的链接来接受邀请,并创建一个 UiPath 用户帐户。他们可以:
- 将受邀电子邮件用作用户名并创建密码。
-
使用现有的 Microsoft 帐户(个人、Azure AD 关联帐户或 Office 365 帐户)、Google 帐户(个人或 Google Workspace 帐户)或个人 LinkedIn 帐户登录(或联合)UiPath 用户帐户。
对用户而言,能够使用上述提供商的帐户会非常方便,他们无须记住额外的密码。此外,您还可以使用由组织拥有的 Azure AD 或 Google Workspace 帐户,强制执行组织登录策略。
在此模式中,您创建用户的方式与在基于邀请的模式中的方式相同:您向用户的电子邮件地址发出邀请,并且用户必须创建 UiPath 帐户。区别在于您可以选择强制使用以下两种帐户登录:
- Google 或
- Microsoft
因此,您的用户不会看到所有登录选项,而只会看到您选择的选项。
例如,如果您选择强制要求使用 Microsoft 帐户登录,您的用户将会看到以下内容:
他们仍使用 UiPath 帐户登录。该帐户必须使用发送邀请的电子邮件地址。
目录帐户模型依赖于您与 UiPath 平台集成的第三方目录。 这使您可以在 UiPath 中重用公司已建立的身份方案。
- Azure Active Directory:如果您订阅了 Microsoft Azure 或 Office 365,则可以将 Azure 与 UiPath 平台集成,以便在 UiPath 中使用 Azure Active Directory 的现有用户和组。
- SAML 2.0:允许您将 UiPath 平台与您选择的身份提供程序 (IdP) 集成。 这使您的用户可以使用已在 IdP 中注册的帐户通过单点登录 (SSO) 连接到 UiPath。
目录用户帐户在 UiPath 外部的目录中创建和维护。 目录帐户仅在 UiPath Platform 中引用并用作用户的身份。
与基于邀请的模式的兼容性
您可以继续将基于邀请的模式的所有功能与目录模式结合使用。但是,为了最大限度地利用这些优势,我们建议您完全使用集成目录中的集中式帐户管理功能。
与 Azure Active Directory (Azure AD) 集成后,可以为您的组织提供可扩展的用户和访问权限管理,从而确保您的员工使用的所有内部应用程序都合规。 如果您的组织使用的是 Azure AD 或 Office 365,可以将组织直接连接到 Azure AD 租户,以获得以下好处:
-
通过无缝迁移自动完成用户引导
- 任何 UiPath 平台服务均可随时使用 Azure AD 中的所有用户和组分配权限,而无需在组织目录中邀请和管理 Azure AD 用户。
- 您可以为公司用户名与电子邮件地址不同的用户提供单点登录,而在基于邀请的模式中则无法实现。
- 拥有本地 UiPath 帐户的所有现有用户,其权限都将自动迁移到已连接的 Azure AD 帐户。
-
简化登录体验
- 用户不必接受邀请或创建 UiPath 用户帐户即可访问组织。 通过选择企业 SSO 选项或使用特定于组织的 URL,就可以使用 Azure AD 帐户登录。 如果用户已登录 Azure AD 或 Office 365,则系统会自动为其登录。
- UiPath Assistant 和 Studio 20.10.3 及更高版本可以预配置为使用自定义 Orchestrator URL,从而带来相同的无缝连接体验。
-
使用现有的 Azure AD 组扩展监管和访问权限管理
- Azure AD 安全组或 Office 365 组(也称为目录组)允许您利用现有的组织结构来大规模管理权限。 您不再需要在服务中为每个用户配置权限。
- 如果需要一起管理多个目录组,可以将多个目录组合并为一个组。
-
审核访问权限非常简单。 在使用 Azure AD 组配置所有 UiPath 平台服务中的权限后,您可以利用与 Azure AD 组成员身份关联的现有验证流程。
使用 Azure AD 模式时,“API 访问”选项(“管理” > “租户”)不可用。
如果您当前的流程是使用“API 访问”窗口中的信息来对 UiPath 服务的 API 调用进行身份验证,则您必须改用 OAuth 进行授权,在这种情况下,您不再需要来自 API 访问的信息。
要使用 OAuth,您必须向 UiPath 平台注册外部应用程序。
此模型允许您将 UiPath 平台连接到所选的身份提供程序 (IdP),以便:
- 您的用户可以从单点登录 (SSO) 中受益,
- 您可以在 UiPath 平台中管理目录中的现有帐户,而无需重新创建身份。
UiPath 平台可以连接到任何使用 SAML 2.0 标准的外部身份提供程序。
收益
-
自动引导用户至 UiPath 平台:当 SAML 集成处于活跃状态时,来自外部身份提供程序的所有用户都有权使用基本权限登录到 UiPath 组织。 这意味着:
- 用户可以使用 IdP 中定义的现有公司帐户通过 SSO 登录到您的 UIPath 组织。
- 无需任何进一步的设置,他们将成为Everyone用户组的成员,默认情况下系统会向他们授予用户组织角色。 为了能够在 UiPath Platform 中工作,用户需要适当的角色和许可证。
-
如果您只需要限制对部分用户的访问,则可以在身份提供程序中定义允许访问 UiPath 平台的用户集。
-
用户管理:您可以通过将用户直接分配到组来添加用户,为此,您只需在将用户添加到组时输入其电子邮件地址。
通常,组织管理员从“管理员” > “帐户和组” > “用户”选项卡中管理本地帐户。 但 SAML 用户是 UiPath 生态系统中的目录帐户,因此在此页面上不可见。
将用户添加到组或至少登录一次后 (这会自动将其添加到“Everyone”组),可以在所有 UiPath 服务中搜索到这些用户,以便直接分配角色或分配许可证。
- 属性映射:例如,如果您使用 UiPath Automation Hub,则可以定义自定义属性映射,以将属性从身份提供程序传播到 UiPath 平台。 例如,首次将帐户添加到 Automation Hub 时,系统会填充用户的名字、姓氏、电子邮件地址、职位名称和部门。
系统将根据您的组织目录验证用户的身份。 在这里,根据通过角色和组分配的用户权限,他们只用一组凭据就可以访问您所有的 UiPath 云服务。下图描述了这两种身份模型、它们如何处理各种用户身份,以及联合如何在基于邀请的模式中,将对组织目录中的用户引用执行身份管理,而用户仍将控制其帐户。 但是,如果与 Azure Active Directory (Azure AD) 集成,就会像在 Azure AD 中查看租户目录的内容一样简单,如下面用橙色箭头所示。
以下是为组织选择身份验证设置时要考虑的一些因素:
因素 |
基于邀请 |
具有强制登录选项的基于邀请的模式 |
Azure Active Directory |
SAML |
---|---|---|---|---|
社区版许可证 |
可用 |
可用 |
不可用 |
不可用 |
企业版许可 |
可用 |
可用 |
可用 |
可用 |
支持本地帐户 (UiPath 帐户) |
可用 |
可用 |
可用 |
可用 |
支持目录帐户 |
不可用 |
不可用 |
可用 |
可用 |
用户帐户管理 |
Automation Cloud 组织管理员。 |
Automation Cloud 组织管理员。 |
Azure AD 管理员 |
身份提供程序的管理员 |
用户访问管理 |
Automation Cloud 组织管理员。 |
Automation Cloud 组织管理员。 |
Automation Cloud 用户管理可以完全委派给 Azure AD |
Automation Cloud 组织管理员。 |
单点登录 |
可用(通过 Google、Microsoft 或 LinkedIn) |
可用(通过 Google 或 Microsoft) |
可用(使用 Azure AD 帐户) |
可用(使用 IdP 帐户) |
强制执行复杂的密码策略 |
不可用 |
可用(如果从 IdP 强制执行) |
可用(如果从 AAD 强制执行) |
可用(如果从 IdP 强制执行) |
多重身份验证 |
不可用 |
可用(如果从 IdP 强制执行) |
可用(如果从 AAD 强制执行) |
可用(如果从 IdP 强制执行) |
重用公司现有身份 |
不可用 |
不可用 |
可用 |
可用 |
大规模用户引导 |
不可用(必须邀请所有用户) |
不可用(必须邀请所有用户) |
可用(即时帐户配置) |
可用(即时帐户配置) |
公司外部协作者的访问权限 |
可用(通过邀请) |
可用(通过强制执行 IdP 上的帐户邀请) |
可用 |
可用(如果从 IdP 允许) |
限制来自公司内部网络的访问 |
不可用 |
不可用 |
可用 |
可用(如果从 IdP 强制执行) |
限制对受信任设备的访问 | 不可用 |
不可用 |
可用 |
可用(如果从 IdP 强制执行) |
如果您的公司已使用目录来管理员工帐户,则下表可以帮助您找到更有利的身份验证选项。
因素 | 基于邀请 | 具有强制登录选项的基于邀请的模式 | Azure Active Directory | SAML |
---|---|---|---|---|
已使用 Google Workspace 作为您的身份提供程序? |
用户需要 UiPath 帐户,但也可以使用 SSO |
用户需要 UiPath 帐户,但可以强制要求通过 Google 进行 SSO |
不适用 |
不适用 |
已使用 Office 365 和您的身份提供程序? |
用户需要 UiPath 帐户 |
用户需要 UiPath 帐户 |
您可以向现有用户帐户授予 Automation Cloud 访问权限 |
您可以向现有用户帐户授予 Automation Cloud 访问权限 |
已使用 Azure AD 作为您的身份提供程序? |
用户需要 UiPath 帐户 |
用户需要 UiPath 帐户 |
您可以向现有用户帐户授予 Automation Cloud 访问权限 |
我们建议使用 AAD 集成,而不是 SAML 集成 |
已经在使用其他身份提供程序? |
用户需要 UiPath 帐户 |
用户需要 UiPath 帐户 |
您可以向现有用户帐户授予 Automation Cloud 访问权限 |
您可以向现有用户帐户授予 Automation Cloud 访问权限 |