2、AD FS的应用场景概述

AD FS可应用于何种场景？以应用对象来看，这会产生在企业之间、企业与员工之间、多个Web应用程序之间等等。因此会有如下的联合身份验证方案：

企业到企业的联合：

如果我要连接到某个合作伙伴组织并允许在我的应用程序中使用其帐户，或者在其应用程序中使用我的帐户。

企业到消费者或企业到员工的联合（Web 单一登录方案）：

使企业能够为业务合作伙伴或拥有独立域的其他业务部门提供单一登录。此服务允许拥有外围网络域的企业提供对内部用户帐户的身份验证。

例如，我在工作时可以轻松登录到内部网站。我已登录我的计算机；它使用的是已获得的身份验证凭据。我在一天结束后回家。我想访问这些相同的资源，可以实现这个想法吗？

它允许我通过外部路径登录到这些资源并使用联合身份验证服务将我的内部域帐户连接到此外部资源来实现这个想法，同时允许我使用相同的凭据。

跨多个Web 应用程序的组织内的联合：

如果出于某些原因，您的组织具有使用不同的、可能不同的身份验证存储或无法通过 Windows 本身自动授权用户的不同身份验证机制的 Web 应用程序，则您可以使用这个方案。对于这种情况，您还可以使用联合身份验证服务。

3、企业部署过程概述

在AD FS的企业部署中，我们通常是在已有AD域中进行部署。关于加域部分将不再赘述，直接阐述AD FS的部署过程。建议AD FS代理服务器不加入域环境并部署在DMZ区域。在部署过程中，强烈建议关注证书、域要求、权限等内容。

部署过程主要有以下步骤：

• 部署ADFS 群集NLB

• ADFS 安装与配置

• 部署ADFS 代理服务器（WAP）群集NLB

• ADFS 代理服务器（WAP）安装与配置

关键概念

AD FS管理台界面如下图所示：

1、AD FS相关术语

账户伙伴组织

由联合身份验证服务中的声明提供方信任表示的联合身份验证伙伴组织。帐户伙伴组织包含将访问资源合作伙伴中基于Web的应用程序的用户。

账户联合服务器

账户伙伴组织中的联合服务器。账户联合服务器基于用户身份验证向用户颁发安全令牌。服务器对用户进行身份验证、从特性存储中提取相关属性和组成员身份信息、将此信息打包到声明中，并生成和签名安全令牌（包含声明）以返回给用户（可在以下两种情况下使用，自己的组织或将其发送给合作伙伴组织）。

AD FS 配置数据库

一个数据库，用于存储代表单个AD FS实例或联合身份验证服务的所有配置数据。此配置数据可以存储在SQL Server数据库中，也可以使用Windows Server 2016，Windows Server 2012和2012 R2以及Windows Server 2008和2008 R2附带的Windows内部数据库（WID）功能存储。

可以使用Fsconfig.exe命令行工具为SQL Server创建AD FS配置数据库，也可以使用AD FS联合身份验证服务器配置向导为Windows内部数据库创建AD FS配置数据库。

声明提供方

向其用户提供声明的组织。请参阅账户伙伴组织。

声明提供方信任

在中的 AD FS 管理 "管理单元-中，声明提供方信任通常是在资源伙伴组织中创建的信任对象，以表示信任关系中的组织，该组织的帐户将访问该资源伙伴组织中的资源。声明提供方信任对象由多种标识符、名称和规则组成，这些标识符、名称和规则可标识此伙伴到本地联合身份验证服务。

本地声明提供程序信任

表示AD FS服务器场中基于AD LDS或第三方LDAP的目录的信任对象。本地声明提供程序信任对象由各种标识符、名称和规则组成，用于标识此基于LDAP的目录到本地联合身份验证服务。

联合元数据

用于在声明提供方和信赖方之间配置通信信息，以便正确配置声明提供方信任和信赖方信任的数据格式。数据格式在安全性声明标记语言（SAML）2.0中定义，并在WS-Federation中扩展。

联合服务器

已使用AD FS联合身份验证服务器配置向导配置为充当联合身份验证服务器角色的Windows Server。联合身份验证服务器颁发令牌，并作为联合身份验证服务的一部分。

联合服务器代理

已使用 AD FS 联合服务器代理配置向导进行配置，以充当 Internet 客户端和位于企业网络防火墙后面的联合身份验证服务之间的中间代理服务的 Windows 服务器。

主联合服务器

在联合服务器角色中使用 AD FS 联合服务器配置向导配置的 Windows Server，并且具有 AD FS 配置数据库的读/写副本。

当您使用“ AD FS联合身份验证服务器配置向导”并选择用于创建新联合身份验证服务以使该计算机成为服务器场中的第一台联合身份验证服务器的选项时，将创建主联合身份验证服务器。

此服务器场中的所有其他联合服务器必须将在主联合服务器上所做的更改复制到本地存储的AD FS配置数据库的只读副本。由于所有联合服务器可以平等地读取和写入到存储在 SQL Server 上的配置数据库，AD FS 配置数据库存储在 SQL 数据库时，术语“主联合服务器”不适用。

信赖方

接收和处理声明的组织。请参阅资源伙伴组织。

信赖方信任

在“AD FS管理”管理单元中，信赖方信任是通常在以下情况中创建的信任对象：

• 帐户伙伴组织，代表信任关系中的组织，其帐户将访问资源合作伙伴组织中的资源。

• 资源伙伴组织，用于表示联合身份验证服务与单个基web的应用程序之间的信任。

信赖方信任对象由各种标识符、名称和规则组成，用于此伙伴或本地联合身份验证服务的Web应用程序。

资源联合服务器

资源伙伴组织中的联合服务器。资源联合服务器通常基于由帐户联合服务器颁发的安全令牌来向用户颁发安全令牌。

服务器接收安全令牌、验证签名、将声明规则逻辑应用到未打包的声明以产生所需的传出声明，并根据传入的安全令牌中的信息生成新的安全令牌(带有传出声明)，并对新的令牌进行签名以返回到用户，最终返回到 Web 应用程序。

资源伙伴组织

由联合身份验证服务中的信赖方信任表示的联合身份验证伙伴。资源伙伴颁发基于声明的安全令牌，其中包含帐户伙伴中的用户可以访问的基于 Web-发布的应用程序。

2、特性存储-角色

Active Directory 联合身份验证服务使用术语“特性存储”来指代组织用来存储其用户帐户及其相关属性值的目录或数据库。

在身份提供者组织中进行配置后，AD FS 从存储中检索这些属性值并基于该信息创建声明，以便在信赖方组织中托管的Web应用程序或服务可以在联合用户（其帐户存储在身份提供者组织中的用户）尝试访问该应用程序或服务时做出适当的授权决策。

特性存储如何符合 AD FS 部署目标

用户特性存储的位置以及用户进行身份验证的位置决定了如何设计AD FS以支持用户身份。根据特性存储库的位置以及用户访问应用程序的位置（在Intranet或Internet中），可以使用以下部署目标之一：

• 为您的Active Directory用户提供对声明感知的应用程序和服务的访问权限：在此目标中，组织用户在以下情况下访问受AD FS保护的应用程序或服务（您自己的应用程序或服务或合作伙伴的应用程序或服务） 登录到公司Intranet中的Active Directory。

• 为您的Active Directory用户提供对其他组织的应用程序和服务的访问权限：在此目标下，组织用户可以在以下情况下访问受AD FS保护的应用程序或服务（您自己的应用程序或服务或合作伙伴的应用程序或服务），当他们登录到公司Intranet中的特性存储以及从Internet远程登录。

• 向另一组织中的用户提供对声明感知应用程序和服务的访问权限：在此目标中，另一个组织中位于该组织企业 intranet 上特性存储中的用户帐户必须访问 AD FS-组织中受保护的应用程序。当位于组织外围网络特性存储中的基于使用者的用户帐户必须提供对您组织中受 AD FS 保护的应用程序的访问权限时，此目标也适用。

AD FS 支持的特性存储

AD FS 支持范围广泛的目录和数据库存储，可用于提取管理员-定义的属性值并使用这些值填充声明。AD FS 支持任何以下目录或数据库作为特性存储：

• Windows server 2003 中的 Active Directory， (Active Directory 域服务) windows server 2008 中的 AD DS，windows server 2012 和 2012 R2，以及 windows server 2016 中的 AD DS。

• 所有版本的 Microsoft SQL Server 2005、SQL Server 2008、SQL Server 2012、SQL Server 2014 和 SQL Server 2016。

• 自定义特性存储。

3、声明-角色

在基于声明的身份模型中，声明在联合过程中起着至关重要的作用。它们是确定所有基于Web的身份验证和授权请求结果的关键组件。此模型支持组织以一种标准化方法跨安全和企业界限安全地投影数字标识和权限或声明。

什么是声明？以最简单的形式来说，声明是关于用户的简单声明（例如，名称，身份，组），主要用于授权访问Internet上任何位置的基于声明的应用程序。每个语句对应一个存储在声明中的值。

获取声明来源

Active Directory 联合身份验证服务 (AD FS) 中的联合身份验证服务定义哪些声明在联合伙伴之间交换。但是，在它可以执行此操作前必须首先借助检索到的或计算的值填充或获取声明来源。每个声明值表示用户、组或实体的值，并且以下列两种方式之一获取来源：

• 从特性存储中检索构成声明的值时，例如，从 Active Directory 用户帐户的特性中检索销售部门的属性值时。

• 在传入声明的值转换为另一个基于在规则中表示逻辑的值时。例如，当具有域管理员值的传入声明作为传出声明发送之前，转换为管理员的新值时。

声明可以包含诸如电子-邮件地址、用户主体名称 (UPN)、组成员身份和其他帐户属性之类的值。

声明流

其他方依赖于声明的值来为其所托管的基于 Web 的应用程序执行授权任务。这些参与方在“AD FS管理”管理单元中称为“信赖方”。

联合身份验证服务负责协调许多不同参与方之间的信任关系。它被设计为用于处理和流动来自最初源声明（也称为-AD FS声明提供方）的受信任声明交换，并将其传递给信赖方。然后信赖方使用这些声明做出授权决定。

使用此过程的声明流称为声明管道。通过声明管道的声明流有三个步骤：

• 从声明提供方收到的声明由声明提供方信任上的接受转换规则进行处理。这些规则可确定哪些声明接受自声明提供方。

• 接受转换规则的输出用作颁发授权规则的输入，这些规则可确定是否允许用户访问信赖方。

• 接受转换规则的输出用作颁发转换规则的输入，这些规则可确定将发送到信赖方的声明。

声明颁发的方式

在编写声明规则时，声明规则根据传入声明源是在声明提供方信任还是在信赖方信任上，编写规则不同。在为声明提供方信任编写声明规则时，传入声明是从受信任声明提供方发送到联合身份验证服务的声明。在为信赖方信任编写规则时，传入声明是由适用的声明提供方信任的声明规则输出的声明。

声明说明

声明说明表示 AD FS 支持且可在联合元数据中发布的声明类型的列表。

将发布到联合元数据的声明说明集合存储在 AD FS 配置数据库中。这些声明说明用于联合身份验证服务的各个组件。

每个声明说明包括声明类型 URI、名称、发布状态和描述。您可以使用“ AD FS管理”管理单元中的“声明描述”节点来管理声明描述集合。您可以使用管理单元修改声明说明的发布状态。可以使用以下设置：

• 在联合元数据中发布此声明作为此联合身份验证服务可以接受（发布为已接受）的声明类型：指示此联合身份验证服务将从其他声明提供方接受的声明类型。

• 在联合元数据中发布此声明作为此联合身份验证服务可以发送(发布为已发送)的声明类型：指示此联合身份验证服务提供的声明类型。它们作为联合身份验证服务愿意发送给其他服务的声明类型。声明提供方发送的实际声明类型通常是此列表的子集。

4、声明规则-角色

声明的转换规则(通过 Claim Engine执行)，规则即：如果服务器收到声明A，则颁发声明B，ADFS向外(relying party应用)发出的声明受claim rule约束，需要在claim rules事先约定（需要进行转换/映射）。

5、声明管道-角色

Active Directory 联合身份验证服务(ADFS)中的声明管道表示声明在发出之前必须遵循联合身份验证服务的路径。该联合身份验证服务管理通过声明管道的各个阶段（也包括声明规则引擎处理声明规则）对声明进行流动的整个端到端过程。

声明管道过程由三个高级-阶段组成。此过程中的每个阶段都初始化声明规则引擎以处理特定于该阶段的声明规则。这些阶段(的出现)顺序如下：

• 接受传入声明 — 声明管道中的此阶段用于从令牌中提取传入声明并消除不需要或受信任的声明。提取这些声明之后，会运行组成声明提供方信任的接受转换规则集的接受规则。这些规则可以用于传递或添加新声明，这些声明随后可以在声明管道的后续阶段中使用。此阶段的输出用作第二个和第三个阶段的输入。

• 授权声明请求者 — 此阶段由声明引擎用于基于是否允许令牌请求者获取给定信赖方的令牌来发出允许或拒绝声明。但是，需要先运行组成信赖方信任的发出授权规则集或委派授权规则集的授权规则，然后才能进行此阶段。

• 发出传出声明 — 此阶段用于发出传出声明并沿管道发送它们（它们在管道中会打包为安全令牌）。但是，需要先运行组成信赖方信任的发出转换规则集的发出规则（这会确定将作为传出声明发出的声明），然后才能进行此阶段。

上面所有三个阶段都执行声明规则处理，但使用不同的规则集。如上所述，每个阶段都有一组基于传入声明的发布者（受理规则）或为其发布声明的目标服务（授权和发布规则）的关联规则。

声明与令牌无关，但通过封装在安全令牌中的网络传输。不管传入或传出安全令牌的格式如何，声明规则都会对声明进行操作。

声明规则包含管理员-定义的逻辑，声明引擎通过该逻辑接受传入声明、基于请求者的身份授权声明，并颁发信赖方所需的声明。最后，由声明引擎确定哪些声明将进入在声明流过声明管道之后颁发的安全令牌中。

如下图所示，声明管道负责将声明流过各个管道阶段的整个-端-到端过程，以便最终获得发出的声明，该声明将通过信赖参与方信任。图中的传出声明表示发出的声明。

6、声明引擎-角色

声明引擎(Claims Engine)是联合身份验证服务中的唯一实体，负责在您配置的所有联合信任关系中运行每个规则集(Claims Rule)，并将输出结果移交给声明管道(Claims Pipeline)。

7、AD FS 中的URL

统一资源标识符(URI)是用作唯一标识符的字符串。在 AD FS 中，URI 用于标识合作伙伴网络地址和配置对象。用于标识合作伙伴网络地址时，URI 始终是 URL。用于标识配置对象时，URI 可以是 URN，也可以是 URL。

用作合作伙伴网络地址的URI

下表介绍了 AD FS 中的管理员最常处理的标识符：

信赖方标识符的URI 前缀匹配

URI 的路径语法按层次结构组织，并由所有 "/" 字符或所有 "：" 字符分隔。因此，该路径可以基于分隔字符拆分为多个路径部分。当前缀匹配时，每个部分必须与这些规则控制匹配大小写的匹配规则完全匹配。

在向联合身份验证服务发出的请求中标识信赖方时，AD FS 将使用前缀匹配逻辑来确定 AD FS 配置数据库中是否有匹配的信赖方信任。

例如，如果 AD FS 配置(数据库 URI1)中的信赖方标识符是传入请求(URI2)中信赖方标识符的前缀，则必须满足以下条件：

• 必须忽略(结尾分隔符斜杠)和路径节或颁发机构的冒号。

• URI1 和 URI2 的方案和授权部分必须完全匹配（不区分大小写）。

• URI1 的每个路径部分必须与 URI2 的(相应路径部分所选)的区分大小写完全匹配。

• URI2 的路径部分可以比 URI1 多，但 URI1 的路径部分不能比 URI2 多。

• URI1 的路径部分不能比 URI2 多。

• 如果 URI1 具有查询字符串，它必须与 URI2 查询字符串完全匹配。

• 如果 URI1 具有片段，它必须与 URI2 片段完全匹配。

AD FS 原理

下图为ADFS的整体过程（集成了Azure环境）：

1、关键原理

• 用户向ADFS为访问APPX请求令牌（有生存周期）。

• ADFS验证用户身份，向AD进行验证。

• 验证通过，为其颁发可访问APPX的安全令牌（该安全令牌中包含了此用户的声明）。

• 用户用此安全令牌可访问该应用程序。

2、企业到员工的联合

1. 用户浏览app（信任STS），身份未得到验证。

2. 重定向到ADFS的STS以请求安全令牌。

3. AD FS向AD进行该用户的验证，验证通过，查询其用户属性并颁发带有声明的安全令牌。

4. 用户用此安全令牌进行对app的访问。

5. 验证通过，app向用户返回cookies和页面。

3、企业到企业的联合

用户-合作伙伴的、app-你的环境中的：

• 伙伴用户浏览你的app，身份未得到验证，但获知你ADFS STS的URL。

• 重定向到你的STS(Security Token Service)，该用户非你组织的，你的ADFS通过主领域发现将其组织的ADFS STS的URL返回。

• 重定向到其组织的STS为其请求ST（安全令牌）。

• 其组织的STS向其AD进行验证。

• 验证通过，返回其组织STS颁发的ST。

• 再次重定向到你的STS，你的STS对其组织颁发的ST进行处理。

• 返回一个新的可用于访问你的app的ST。

• 伙伴用户向你的app 发送新ST。

• app验证通过，为伙伴用户返回cookies和页面。

总结

前面为大家介绍联合身份验证是一个跨组织和平台边界实现标识、身份验证和授权的过程，极大的扩充了web应用的能力，并梳理了AD FS相关的概念和知识，最后展示其运作的原理，希望借由了解AD FS能帮助到大家日常的IT运维和运营工作。下期我们将继续扩大为大家分享AD FS的企业部署，把部署前的各种要求、准备及实施进行讨论。