在 SharePoint Server 中计划用户身份验证方法
适用于：
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
注意
此处提到的用户身份验证方法适用于 SharePoint Server 2013、SharePoint Server 2016、SharePoint Server 2019 和 SharePoint Server 订阅版。
了解 SharePoint Server 支持的用户身份验证类型和方法，以及如何确定要将哪些类型和方法用于 Web 应用程序和区域。
了解 Microsoft 365 中的 SharePoint 身份验证。
注意
在 SharePoint Server 订阅版中，我们现在支持 OIDC 1.0 身份验证。 有关如何使用此新身份验证类型的详细信息，请参阅 OpenID Connect 1.0 身份验证。
简介
用户身份验证可根据身份验证提供程序验证用户的身份，身份验证提供程序是包含用户凭据且可以确认用户正确提交了这些凭据的目录或数据库。 Active Directory 域服务 (AD DS) 是身份验证提供程序的一个示例。 身份验证提供程序的其他术语包括用户目录和属性存储。
身份验证方法是一种特定的帐户凭据交换，以及断言用户标识的其他信息。 身份验证方法的结果是一种通常采用令牌形式的证明，其中包含指明身份验证提供程序已对用户进行身份验证的声明。
身份验证类型是针对一个或多个身份验证提供程序验证凭据的特定方法，有时使用行业标准协议。 身份验证类型可以使用多种身份验证方法。
在验证用户身份后，授权过程将确定用户可以访问的网站、内容和其他功能。
用户身份验证类型和方法的规划应确定：
每个 Web 应用程序和区域的用户身份验证类型和方法
支持既定身份验证类型和方法所需的身份验证基础结构
注意
SharePoint Server 2016、SharePoint Server 2019 和 SharePoint Server 订阅版不再支持 Windows 经典模式身份验证。
基于声明的身份验证
AD DS 中的用户标识基于用户帐户。 要成功进行身份验证，用户需提供帐户名以及知道密码的证明。 要确定资源的访问权，应用程序可能必须查询 AD DS 的帐户属性和其他信息，例如组成员身份或网络中的角色。 虽然此功能适用于 Windows 环境，但它不会横向扩展到支持 Internet、合作伙伴或基于云的计算模型的第三方身份验证提供程序和多供应商环境。
使用基于声明的标识，用户可从通常受信任的标识提供程序中获得数字签名安全令牌。 该令牌包含一组声明。 每个声明都表示有关用户的特定数据项，例如用户的姓名、组成员身份和网络上的角色。 基于声明的身份验证是使用基于声明的标识技术和基础结构的用户身份验证。 支持基于声明的身份验证的应用程序可获得来自用户的安全令牌而不是凭据，并使用声明中的信息确定资源的访问权。 不需要任何单独的目录服务（例如 AD DS）查询。
Windows 中基于声明的身份验证基于 Windows Identity Foundation (WIF)（是一组用于实现基于声明的标识的 .NET Framework 类）而构建。 基于声明的身份验证依赖于 WS 联合身份验证、WS 信任等标准以及安全声明标记语言 (SAML) 等协议。
有关基于声明的身份验证的详细信息，请参阅以下资源：
Claims-based Identity for Windows (white paper)（Windows 基于声明的标识（白皮书））
由于基于声明的身份验证广泛用于用户身份验证、服务器到服务器身份验证以及应用身份验证，因此，我们建议对 SharePoint Server 服务器场的所有 Web 应用程序和区域使用基于声明的身份验证。 有关详细信息，请参阅规划 SharePoint Server 中的服务器到服务器身份验证。 使用基于声明的身份验证时，所有支持的身份验证方法均可用于你的 Web 应用程序，并且你可以利用使用服务器到服务器身份验证和应用身份验证的 SharePoint Server 中的新功能和方案。
对于基于声明的身份验证，SharePoint Server 会自动将所有用户帐户更改为声明标识。 此更改会导致每个用户的安全令牌 (也称为声明令牌) 。 声明令牌包含与该用户有关的声明。 Windows 帐户将转换为 Windows 声明。 基于表单的成员身份用户将转换为基于表单的身份验证声明。 SharePoint Server 可以使用基于 SAML 的令牌中包含的声明。 此外，SharePoint 开发人员和管理员可以使用更多声明来扩充用户令牌。 例如，Windows 用户帐户和基于表单的帐户可以使用 SharePoint Server 使用的额外声明进行扩充。
您不必是声明架构师，就可以在 SharePoint Server 中使用基于声明的身份验证。 不过，实现基于 SAML 令牌的身份验证需要与你的基于声明的环境的管理员进行协商，如规划基于 SAML 令牌的身份验证中所述。
SharePoint Server 2013 中的经典模式身份验证
在 SharePoint 2013 中，当在管理中心中创建 Web 应用程序时，只能指定基于声明的身份验证的身份验证类型和方法。 在 SharePoint 的早期版本中，还可以在管理中心中为 Web 应用程序配置经典模式身份验证。 经典模式身份验证使用 Windows 身份验证并且 SharePoint 2013 将用户帐户视为 AD DS 帐户。
若要配置 Web 应用程序以使用经典模式身份验证，必须使用 New-SPWebApplication PowerShell cmdlet 创建它。 为经典模式身份验证配置的 SharePoint 2010 产品 Web 应用程序在您升级到 SharePoint 2013 时将保留其身份验证设置。 但是，建议您在升级到 SharePoint 2013 之前，将您的 Web 应用程序迁移到基于声明的身份验证。
SharePoint 2013 服务器场可以包含使用这两种模式的混合 Web 应用程序。 某些服务不会区分传统 Windows 帐户和 Windows 声明帐户的用户帐户。
若要详细了解如何在升级前进行迁移，请参阅从经典模式身份验证迁移到基于声明的身份验证。
有关在升级后进行迁移的详细信息，请参阅Migrate from classic-mode to claims-based authentication in SharePoint Server。
有关如何在 SharePoint 2013 中创建使用经典模式身份验证的 Web 应用程序的信息，请参阅创建 web 应用程序在 SharePoint 服务器中使用经典模式身份验证。 不能将使用基于声明的身份验证的 Web 应用程序迁移到使用经典模式身份验证。
重要
Office Online 只能由使用基于声明的身份验证的 SharePoint 2013 Web 应用程序使用。 Office Online 呈现和编辑在使用经典模式身份验证的 SharePoint 2013 Web 应用程序上无法工作。 如果您将使用经典模式身份验证的 SharePoint 2010 Web 应用程序迁移到 SharePoint 2013，您必须将其迁移到基于声明的身份验证以允许它们使用 Office Online。
支持的身份验证类型和方法
SharePoint Server 支持以下身份验证类型的各种身份验证方法和身份验证提供程序：
Windows 身份验证
基于表单的身份验证
基于 SAML 令牌的身份验证
Windows 身份验证
Windows 身份验证类型利用现有的 Windows 身份验证提供程序 (AD DS) 以及 Windows 域环境使用的身份验证协议来验证连接客户端的凭据。 Windows 身份验证方法，这两种基于声明的身份验证都使用此方法包括：
NTLM
Kerberos
摘要
基本
有关详细信息，请参阅本文中的规划 Windows 身份验证。
观看 SharePoint 2013 和 SharePoint Server 2016 中的 Windows 声明身份验证视频
虽然并非 Windows 身份验证类型，SharePoint Server 同样支持匿名身份验证。 用户无需验证其凭据即可访问 SharePoint 内容。 默认情况下禁用匿名身份验证。 使用 SharePoint Server 发布不需要安全性且可供所有用户使用的内容（例如公共 Internet 网站）时，通常使用匿名身份验证。
除了启用匿名身份验证外，还必须配置匿名访问 (对站点和站点资源) 权限。
注意
即使在针对匿名和窗体身份验证的 SharePoint 设置被禁用的情况下，由 SharePoint 创建的用于服务 Web 应用程序的 Internet Information Services (IIS) 网站也始终启用匿名身份验证和窗体身份验证方法。 这是有意要这么做的，因为如果直接在 IIS 设置中禁用匿名身份验证或窗体身份验证会导致在 SharePoint 网站上出错。
基于表单的身份验证
基于表单的身份验证是基于 ASP.NET 成员身份和角色提供程序身份验证的基于声明的标识管理系统。 可以对存储在身份验证提供程序中的凭据使用基于表单的身份验证，例如：
AD DS
SQL Server 数据库之类的数据库
Novell eDirectory、Novell Directory Services (NDS) 或 Sun ONE 等轻型目录访问协议 (LDAP) 数据存储
基于表单的身份验证根据用户在登录表单（通常是一个网页）中键入的凭据验证用户身份。 未经身份验证的请求会重定向到登录页，用户必须在其中提供有效凭据并提交表单。 系统会为经过身份验证的请求发布一个 Cookie，其中包含用于重建后续请求的标识的项。
观看 SharePoint 2013 和 SharePoint Server 2016 中基于窗体的声明身份验证视频
注意
使用基于表单的身份验证，用户帐户凭据将以明文形式发送。 因此，不应使用基于表单的身份验证，除非还使用安全套接字层 (SSL) 加密网站通信。
有关详细信息，请参阅规划基于表单的身份验证。
基于 SAML 令牌的身份验证
SharePoint Server 中基于 SAML 令牌的身份验证使用 SAML 1.1 协议和 WS 联合身份验证被动请求者配置文件 (WS-F PRP)。 它需要与基于声明的环境的管理员进行协商，无论该环境是你自己的内部环境还是合作伙伴环境。 如果使用 Active Directory 联合身份验证服务 (AD FS) 2.0，您将具有基于 SAML 令牌的身份验证环境。
基于 SAML 令牌的身份验证环境包含标识提供程序安全令牌服务 (IP-STS)。 IP-STS 代表其帐户包含在关联的身份验证提供程序中的用户颁发 SAML 令牌。 令牌可以包含有关用户的任何数量的声明，例如用户名和用户所在的组。 AD FS 2.0 服务器是 IP-STS 的示例。
SharePoint Server 利用 IP-STS 颁发给授权用户的令牌中包含的声明。 在声明环境中，接受 SAML 令牌的应用程序称为信赖方 STS (RP-STS)。 信赖方应用程序接收 SAML 令牌并使用其中的声明来决定是否授予客户端对所请求资源的访问权限。 在 SharePoint Server 中，配置为使用 SAML 提供程序的每个 Web 应用程序都作为单独的 RP-STS 条目添加到 IP-STS 服务器中。 一个 SharePoint 场可以在 IP-STS 中表示多个 RP-STS 条目。
观看 SharePoint 2013 和 SharePoint Server 2016 中基于 SAML 的声明身份验证视频
基于 SAML 令牌的身份验证的身份验证提供程序组取决于您的声明环境中的 IP-STS。 如果使用 AD FS 2.0，身份验证提供程序 (AD FS 2.0) 的属性存储可能包括：
Windows Server 2003 Active Directory 和 Windows Server 2008 中的 AD DS
SQL Server 2005 和 SQL Server 2008 的所有版本
自定义属性存储
有关详细信息，请参阅规划基于 SAML 令牌的身份验证。
为 LDAP 环境选择身份验证类型
基于表单的身份验证或基于 SAML 令牌的身份验证可以使用 LDAP 环境。 使用与当前 LDAP 环境匹配的身份验证类型。 如果还没有 LDAP 环境，建议使用基于表单的身份验证，因为它不太复杂。 但是，如果你的身份验证环境支持 WS 联合身份验证 1.1 和 SAML 1.1，则建议使用 SAML。 SharePoint Server 具有内置的 LDAP 提供程序。
规划 Windows 身份验证
对于基于声明的身份验证而言，规划和实现 Windows 身份验证方法的过程类似。 Web 应用程序的基于声明的身份验证不会增加实现 Windows 身份验证方法的复杂性。 本节概括了如何规划 Windows 身份验证方法。
NTLM 和 Kerberos 协议
NTLM 和 Kerberos 协议都属于集成 Windows 身份验证方法，这使得用户可以无缝地进行身份验证，而不会收到输入凭据的提示。 例如：
从 Internet Explorer 访问 SharePoint 网站的用户使用用于运行 Internet Explorer 进程的凭据进行身份验证。 默认情况下，这些凭据是用户用于登录计算机的凭据。
使用集成 Windows 身份验证方法访问 SharePoint 资源的服务或应用程序会尝试使用正在运行的线程的凭据（默认情况下是进程的标识）进行身份验证。
NTLM 是实现的最简单形式的 Windows 身份验证，通常不需要额外的身份验证基础结构配置。 创建或配置 Web 应用程序时，请选择此选项。
Kerberos 协议支持票证身份验证。 使用 Kerberos 协议需要对环境进行更多配置。 若要启用 Kerberos 身份验证，客户端和服务器计算机必须建立到域密钥发行中心 (KDC) 的受信任连接。 配置 Kerberos 协议时需要在安装 SharePoint Server 之前在 AD DS 中设置服务主体名称 (SPN)。
应考虑使用 Kerberos 身份验证的原因如下：
Kerberos 协议是最强大的集成 Windows 身份验证协议，并支持高级安全功能，其中包括客户端和服务器的高级加密标准 (AES) 加密和相互身份验证。
Kerberos 协议允许委派客户端凭据。
在可用的安全身份验证方法中，Kerberos 需要的域控制器网络流量最少。 Kerberos 可减少某些情况下的页面延迟，或增加某些情况下前端 Web 服务器可处理的页面的数量。 Kerberos 还可降低域控制器上的负载。
Kerberos 协议是一个许多平台和供应商支持的开放式协议。
Kerberos 身份验证可能不适合的原因如下：
Kerberos 身份验证需要比其他身份验证方法更多的基础结构和环境配置才能正常工作。 在很多情况下，配置 Kerberos 协议需要域管理员权限。 Kerberos 身份验证可能难以设置和管理。 Kerberos 配置不当可能会阻止对您的网站的成功验证。
Kerberos 身份验证需要客户端计算机连接到 KDC 和 AD DS 域控制器。 在 Windows 部署中，KDC 是一个 AD DS 域控制器。 虽然此网络配置在组织 Intranet 上很常见，但面向 Internet 的部署通常不会以这种方式进行配置。
以下步骤概括了如何配置 Kerberos 身份验证：
通过在 AD DS 中为 SQL Server 服务帐户创建 SPN 可为 SQL Server 配置 Kerberos 身份验证。
为将使用 Kerberos 身份验证的 Web 应用程序创建 SPN。
安装 SharePoint Server 服务器场。
在该服务器场中配置特定服务以使用特定帐户。
创建将使用 Kerberos 身份验证的 Web 应用程序。
摘要式和基本身份验证
使用摘要式身份验证方法，用户帐户凭据将以 MD5 消息摘要的形式发送到承载 Web 应用程序或区域的 Web 服务器上的 Internet Information Services (IIS) 服务。 使用基本身份验证方法，用户帐户凭据将以明文形式发送。 因此，除非还使用 SSL 来加密网站流量，否则不应使用基本身份验证方法。
如果您的环境使用仅支持对网站进行摘要式身份验证或基本身份验证的 Web 浏览器或服务，则可能必须使用这些较旧的身份验证方法。
与 NTLM、Kerberos 和匿名身份验证不同，可从与 Internet Information Services (IIS) 管理单元中的 Web 应用程序或区域对应的网站属性中配置摘要式身份验证方法和基本身份验证方法。
如果使用基于声明的身份验证，请参阅：
规划基于表单的身份验证
若要使用基于表单的身份验证对不基于 Windows 或外部的标识管理系统对用户进行身份验证，必须在 Web.config 文件中注册成员资格提供程序和角色管理器。 SharePoint Server 使用标准 ASP.NET 角色管理器界面来收集有关当前用户的组信息。 SharePoint Server 中的授权过程会将每个 ASP.NET 角色视为一个域组。 在 Web.config 文件中注册角色管理器正如注册用于身份验证的成员身份提供程序一样。
如果要从管理中心网站管理成员身份用户或角色，您必须在管理中心网站的 Web.config 文件中注册成员身份提供程序和角色管理器。 在承载内容的 Web 应用程序的 Web.config 文件中注册成员资格提供程序和角色管理器。
有关配置基于表单的身份验证的详细步骤，请参阅为 SharePoint Server 中基于声明的 Web 应用程序配置基于表单的身份验证
规划基于 SAML 令牌的身份验证
用于实现基于 SAML 令牌的提供程序的体系结构包含以下组件：
SharePoint Security Token Service 此服务将创建由服务器场使用的 SAML 令牌。 该服务会自动创建并在服务器场中的所有服务器上启动。 该服务用于服务器场之间的通信，因为所有服务器场之间的通信都使用基于声明的身份验证。 该服务还用于为使用基于声明的身份验证的 Web 应用程序实现的身份验证方法。 这些方法包括 Windows 身份验证、基于表单的身份验证和基于 SAML 令牌的身份验证。
令牌签名证书 (ImportTrustCertificate) 此证书是从 IP-STS 导出，然后复制到场中的一台服务器并将其添加到场的“受信任的根颁发机构”列表的证书。 使用此证书创建 SPTrustedIdentityTokenIssuer 后，不能使用它创建另一个证书。 若要使用该证书创建其他 SPTrustedIdentityTokenIssuer，则必须先删除现有 SPTrustedIdentityTokenIssuer。 在删除现有项之前，必须取消它与可能使用它的所有 Web 应用程序的关联。
标识声明 标识声明是来自 SAML 令牌的声明，它是用户的唯一标识符。 只有 IP-STS 的所有者知道令牌中的哪个值对每个用户始终是唯一的。 标识声明是在映射所有所需声明的过程中作为常规声明映射创建的。 充当标识声明的声明是在创建 SPTrustedIdentityTokenIssuer 时声明的。
其他声明 这些声明包含来自描述用户的 SAML 票证的额外声明。 其中可能包括用户角色、用户组或其他种类的声明（如年龄）。 所有声明映射都是作为对象创建的，并在 SharePoint Server 服务器场中的服务器之间进行复制。
领域 在 SharePoint 声明体系结构中，与配置为使用基于 SAML 令牌的提供程序的 SharePoint Web 应用程序关联的 URI 或 URL 代表领域。 在服务器场中创建基于 SAML 的身份验证提供程序时，应指定您希望 IP-STS 识别的领域或 Web 应用程序 URL（一次指定一个）。 第一个领域是在创建 SPTrustedIdentityTokenIssuer 时指定的。 可以在创建 SPTrustedIdentityTokenIssuer 之后添加更多领域。 可使用类似如下的语法指定领域：
$realm = "urn:sharepoint:mysites"。 将领域添加到 SPTrustedIdentityTokenIssuer 中后，必须使用该领域标识符在 IP-STS 服务器上创建 RP-STS 信任。 该过程涉及为 Web 应用程序指定 URL。SPTrustedIdentityTokenIssuer 这是在 SharePoint 场中创建的对象，它包含与 IP-STS 通信以及从 IP-STS 接收令牌所必需的值。 创建 SPTrustedIdentityTokenIssuer 时，指定要使用的令牌签名证书、第一个领域、表示标识声明的声明以及任何其他声明。 只能将来自 STS 的令牌签名证书与一个 SPTrustedIdentityTokenIssuer 相关联。 但是，创建 SPTrustedIdentityTokenIssuer 后，可以为额外的 Web 应用程序添加更多领域。 将领域添加到 SPTrustedIdentityTokenIssuer 中后，还必须将其作为信赖方添加到 IP-STS 中。 SPTrustedIdentityTokenIssuer 对象会在 SharePoint Server 服务器场中的各个服务器之间复制。
信赖方安全令牌服务 (RP-STS) 在 SharePoint Server 中，配置为使用 SAML 提供程序的每个 Web 应用程序都将作为一个 RP-STS 条目添加到 IP-STS 服务器中。 SharePoint Server 服务器场可以包含多个 RP-STS 条目。
标识提供者安全令牌服务 (IP-STS) 此服务是声明环境中的安全令牌，代表包含在关联用户目录中的用户颁发 SAML 令牌。
下图演示了 SharePoint Server SAML 令牌声明体系结构。
SAML 令牌声明体系结构
SPTrustedIdentityTokenIssuer 对象是使用多个参数创建的，其中包括：
单个身份声明。
单个 SignInURL 参数。
SignInURL 参数指定将用户请求重定向到的 URL，以便向 IP-STS 进行身份验证。
单个 Wreply 参数。
某些 IP-STS 服务器需要 Wreply 参数，该参数设置为 true 或 false。 False 是默认值。 仅当 IP-STS 需要时，才使用 Wreply 参数。
多个领域。
多个声明映射。
若要使用 SharePoint Server 实现基于 SAML 令牌的身份验证，请执行以下步骤，这些步骤需要提前规划：
从 IP-STS 导出令牌签名证书。 将该证书复制到 SharePoint Server 服务器场中的某台服务器上。
定义将用作用户的唯一标识符的声明。 此声明称为标识声明。 用户主体名称 (UPN) 或者用户电子邮件名称经常用作用户标识符。 应与 IP-STS 的管理员协商确定正确的标识符，因为只有 IP-STS 的所有者知道令牌中将始终对每个用户唯一的值。 确定用户的唯一标识符是声明映射过程的一部分。 可使用 Microsoft PowerShell 创建声明映射。
定义额外的声明映射。 定义 SharePoint Server 场将使用的传入令牌中的额外声明。 用户角色是一种可用于向 SharePoint Server 服务器场中的资源分配权限的声明。 来自没有映射的传入令牌的所有声明将被丢弃。
使用 PowerShell 创建新身份验证提供程序以导入令牌签名证书。 该过程将创建 SPTrustedIdentityTokenIssuer。 在此过程中，可以指定已映射的标识声明和其他声明。 创建并指定一个领域，该领域与要为基于 SAML 令牌的身份验证配置的第一个 SharePoint Web 应用程序相关联。 创建 SPTrustedIdentityTokenIssuer 后，可以为额外的 SharePoint Web 应用程序创建和添加更多领域。 此过程使你能够将多个 Web 应用程序配置为使用相同的 SPTrustedIdentityTokenIssuer。
对于添加到 SPTrustedIdentityTokenIssuer 中的每个领域，必须在 IP-STS 上为其分别创建一个 RP-STS 条目。 可以在 SharePoint Web 应用程序存在之前创建此项。 无论如何，您都必须在创建 Web 应用程序之前规划 URL。
对于现有或新的 SharePoint Web 应用程序，将其配置为使用新创建的身份验证提供程序。 创建 Web 应用程序时，身份验证提供程序将在管理中心中显示为受信任的标识提供程序。
您可以配置多个基于 SAML 令牌的身份验证提供程序。 但是，一个服务器场中只能使用一次令牌签名证书。 所有已配置的提供程序都将作为选项显示在管理中心中。 来自不同受信任 STS 环境的声明不会发生冲突。
如果对合作伙伴公司以及您自己的包含 IP-STS 的环境实现基于 SAML 令牌的身份验证，建议您与内部声明环境的管理员在您的内部 IP-STS 与合作伙伴 STS 之间建立单向信任关系。 此方法不需要将身份验证提供程序添加到 SharePoint Server 场。 它还允许声明管理员管理整个声明环境。
重要
在 SharePoint Server 中使用基于声明的身份验证时，不再需要将网络负载平衡设置为单个相关性。
注意
[!注意] 当 Web 应用程序配置为使用基于 SAML 令牌的身份验证时， SPTrustedClaimProvider 类不为人员选取器控件提供搜索功能。 在人员选取器控件中输入的任何文本都将自动显示，好像已进行解析一样，而不管它是否是有效用户、组或声明。 如果你的 SharePoint Server 解决方案将使用基于 SAML 令牌的身份验证，你应该规划创建自定义声明提供程序来实现自定义搜索和名称解析。
有关使用 AD FS 配置基于 SAML 令牌的身份验证的详细步骤，请参阅在 SharePoint Server 中使用 AD FS 配置基于 SAML 的声明身份验证。
为 Web 应用程序规划区域
区域代表用于访问 Web 应用程序中的相同网站的不同逻辑路径。 每个 Web 应用程序最多可以包含五个区域。 在创建 Web 应用程序时，管理中心将创建名为 default 的区域。 若要创建其他区域，请扩展 Web 应用程序并选择剩余的区域名称：Intranet、Extranet、Internet 或自定义。
规划区域将取决于以下内容：
- 基于声明的身份验证（建议） 可以在单个区域实现多个身份验证提供程序。 还可以使用多个区域。
在一个区域中实现多种类型的身份验证
如果您使用基于声明的身份验证并实现多种身份验证方法，则建议您在默认区域实现多种身份验证方法。 这将为所有用户生成同一 URL。
在同一区域实现多种身份验证方法时，存在以下限制：
只能在区域中实现一个基于表单的身份验证实例。
管理中心允许您同时使用集成 Windows 方法和基本方法。 否则，无法在区域上实现多种类型的 Windows 身份验证。
如果为一个服务器场配置了多个基于 SAML 令牌的身份验证提供程序，则在创建 Web 应用程序或新区域时，所有这些提供程序都将作为选项出现。 可以在同一区域中配置多个 SAML 提供程序。
下图演示了在合作伙伴协作网站的默认区域中实现的多种类型的身份验证。
在默认区域实现的多种类型的身份验证
在该示意图中，来自不同目录存储区的用户使用同一 URL 访问合作伙伴网站。 合作伙伴公司周围的虚框显示用户目录与默认区域中配置的身份验证类型之间的关系。
规划爬网内容
爬网组件需要使用 NTLM 来访问内容。 必须至少将一个区域配置为使用 NTLM 身份验证。 如果未在默认区域中配置 NTLM 身份验证，则爬网组件可以使用配置为使用 NTLM 身份验证的其他区域。
实现多个区域
如果打算为 Web 应用程序实现多个区域，可以使用以下指南：
使用默认区域来实现最安全的身份验证设置。 如果请求无法与特定区域关联，则会应用默认区域的身份验证设置和其他安全策略。 默认区域是在您创建 Web 应用程序时创建的区域。 通常，最安全的身份验证设置是为最终用户进行访问而设计的。 因此，最终用户可能会访问默认区域。
尽量减少为用户提供访问所需的区域数。 每个区域都与新的 IIS 网站和域关联，以便访问 Web 应用程序。 仅在需要时添加新接入点。
确保至少将一个区域配置为对爬网组件使用 NTLM 身份验证。 除非有必要，否则不要为索引组件创建专用区域。
下图显示了为符合对合作伙伴协作网站的不同身份验证类型而实现的多个区域。
每种身份验证类型对应一个区域
在该示意图中，默认区域用于远程员工。 每个区域都具有与其相关的不同 URL。 员工使用其他区域，具体取决于他们是在办公室工作还是远程工作。