ADFS(全称：Active Directory Federation Services，活动目录联合服务）是由微软自Windows Server 2003 R2起，在各个Server版本操作系统中提供的一个软件组件，其最新版本是集成在Windows Server 2012 R2的AD FS 3.0。

简介

ADFS使用基于Claims的访问控制验证模型来实现联合认证。它提供 Web 单一登录技术，这样只要在会话的有效期内，就可对一次性的对用户所访问的多个Web应用程序进行验证。

我们可以将 ADFS 理解为组织域内与公网之外用户桥梁。我们编写的应用程序作为Internet服务在公网部署，当程序需要对域内的用户进行验证时，就可以委托 ADFS 服务器进行验证。 ADFS 服务提供了一个 AD FS 联合服务器代理，这类似于一个只提供了登录界面的应用程序，我们将相关域用户的验证过程委托给该程序进行处理，该程序将提示用户输入验证凭据（这可以是在浏览器中弹出登录提示框或跳转到一个登录页面的形式），随后其将所获取的凭据传递给AD FS联合身份验证服务。 AD FS 作为AD的一部分有权限（其拥有AD域管理员的权限）使用AD DS的标准方式认证一个域内的用户，如果认证成功，AD FS 将会依据应用程序预先设定的信息需求，以Claims的形式将安全令牌信息返还给我们的应用程序。

关于Claims

在基于Claims的联合身份验证的过程中，当身份验证提供方完成对于用户身份的验证，返还用户的相关信息时，其数据信息实体被称之为令牌（Token），其中的相关信息字段被称为声明（Claims）。令牌保证了用户身份的真实性，并包含了实用信息，其结构如下图所示。

基于传统的开发方式，创建一个应用程序（即服务提供商）并保证多种身份验证机制可以协调工作并不是一件简单的工作。首先，我们需要决定对于特定的应用程序，哪一种身份验证技术最为合适。如果应用程序允许用户通过不同的方式进行访问，例如，允许同属一个组织下的域用户群体，或者跨越不同组织的多个域下的域用户群体，再或者同时允许这些域用户及传统的注册用户通过公网对应用程序进行访问，那么使用传统的单一的身份验证机制是完全不能满足这些需求的。在这些需求下，应用程序应该以直接经由用户所属的组织或系统处获取对应用户验证的结果。同时，也需要从一个AD目录服务或其它某处查询到用户相关的信息，并且保证这些信息可以在公网上，能够以统一的方式进行传递。
基于Claims的身份验证（Claims-based identity）为我们提供了这种统一的身份验证方式，让不同的服务提供商可以通过公网，获得所需要的保存在用户所属组织内部的关于用户的验证信息。其基本流程如下图所示。

首先，用户通过客户端（如浏览器），访问服务提供商（如图中①过程，相对于身份验证提供方也可以称其为信赖方RP）。信赖方向身份验证提供方提出验证请求（如图中②所示），身份验证提供方会要求用户输入登陆凭据（如用户名及验证码）。在通过其验证确认后，身份验证提供方会将验证成功的消息及该用户相关的数据信息以令牌的方式交还给信赖方（如图中③所示）。

以我的站点与某第三方联合身份验证系统的验证流程为例，其过程也可以用如下的时序图阐明。

如前所述，我们涉及到两个新的概念，依赖方与安全令牌服务。
信赖方（RP，Relying Party）就相当于服务提供商，也就是由我们构建的依赖声明的应用程序（如我的网站）。信赖方有时也被称为“声明感知应用程序”或“基于声明的应用程序”。信赖方作为应用程序需要使用由安全令牌服务（STS）所颁发的令牌，并从令牌中提取声明，从而进行用户身份的验证和用户信息的获取。
安全令牌服务（STS，Security Token Service），信赖方所使用的令牌的创建者就是安全令牌服务。它作为一个Web服务存在。STS可以由我们自行构建，也可以应用已有的实现，AD联合身份验证服务（AD FS）就是一个STS的实现。
为了充分利用基于Claims的身份验证机制，我们将会使用由微软提供的用于支撑应用程序实现联合认证功能的可供依赖的基础架构。这些技术包括：AD联合身份验证服务（AD FS，Active Directory Federation Services），与Windows身份验证基础类库（WIF，Windows Identity Foundation）。

关于WIF

Windows身份验证基础类库（WIF，Windows Identity Foundation）是一组.NET Framework类，它为我们提供了实现基于声明标识的应用程序的基础框架。在具体的实现过程中，主要利用了其中的WSFederation Authentication Module（WS-FAM）HTTP模块。

概念总结

以上给出的相关概念层层递进，相似的概念在不同领域层次有着不同的称谓，为了方便理解，下面对这些概念的关系进行简单的总结。

在AD FS中的称谓在SAML中的称谓概念简述Security Token 安全令牌Assertion 声明作为安全信息的封装，用于描述一个用户的信息，它在联合身份验证的访问请求期间被创建。Claims Provider 声明提供方Identity Provider (IdP) 身份验证提供方为用户创建安全令牌的联合身份认证程序。Relying Party 信赖方Service Provider (SP) 服务提供商收到联合身份验证服务信赖的请求并使用安全令牌的应用程序。Claims 声明Assertion attributes 属性声明在安全令牌中的关于用户的数据信息。

下图对相关的领域结构进行了划分。

(本文转载于Hendry's Blog)

何谓单点登录

什么是单点登录？单点登录（英：Single Sign On，简称SSO），是一种使用单个ID和密码进行身份验证以访问多个Web网站和服务的机制。

单点登录现在在WEB世界获得了广泛的应用，很多网站支持的Google、Github、Facebook、Twitter、微信、QQ等第三方账号登录就属于单点登录。

现在说起单点登录，一般指的都是Web SSO，但实际上，单点登录并不限于Web应用，也不是一项新技术，十多年来它已被很多大型企业用户应用在本地系统。

单点登录的效果

单点登录里用户的认证处理统一在一个地方集中管理，这有以下几个效果：

方便管理
包括用户和管理员
用户使用应用系统时，能够一次登录，多次使用。用户不再需要每次输入用户名称和用户密码，也不需要牢记多套用户名称和用户密码。
系统管理员只需要维护一套统一的用户账号，方便、简单。提高安全
将ID /密码集中在一起统一加强安全管理，泄漏的风险可以降低。
当然，一旦泄露，影响也是更加灾难性的。简化开发
开发新的应用系统时，可以直接使用单点登录平台的用户认证服务。主要实现方式

同一个域名下的各个Web应用可以通过共享Cookie从而很简单的就能实现单点登录。
但如果要考虑跨域，单点登录的实现方式主要有代理人(英：Agent)、反向代理(英：Reverse proxy)、 联合身份验证（英：Federated Identity）等方式。

代理人方式

代理人方式通过将代理软件嵌入Web服务器中来实现身份验证。

反向代理方式

反向代理方式通过在Web浏览器和Web应用程序之间安装反向代理服务器并在其中安装身份验证代理来实现身份验证。

联合身份验证方式联合身份验证（英：Federated Identity）通过把用户身份的验证过程与被该用户访问的服务提供商（英：Service Provider，简称SP）进行逻辑分离，在保证用户身份信息被隔离在用户所属系统的内部的同时，为受信任的服务提供商提供所需要的用户信息。

当服务提供商需要对用户的身份进行验证时，会将相关的验证过程转交给身份验证提供方（英：Identity Provider，简称IdP），当用户经由身份验证提供方成功登录后，身份验证提供方会将用户的身份验证凭据和用户相关的信息返还给服务提供商，从而实现服务提供商对于用户身份的验证，以及对于用户信息获取。
联合身份验证方式可以在不使用cookie的情况下在不同域之间打包传输认证信息，也能实现云服务SSO。

常见的联合身份验证的实现有SAML、OpenID、JWT及OAuth等，

(SAML)

SAML(全称：Security Assertion Markup Language，安全断言标记语言，发音sam-el）是一个基于XML格式传输用户认证信息的开放标准。

(OpenID Connect)

OpenID Connect 是一套基于 OAuth 2.0 协议的轻量认证级规范，提供通过 API 进行身份交互的框架。

(JWT)

JWT（全称：Json Web Token）是一个基于JSON格式传输用户认证信息的开放标准。

JWT将用户信息加密到token里，服务器不保存任何用户信息。服务器通过使用保存的密钥验证token的正确性，只要正确即通过验证。

优点是在分布式系统中，很好地解决了单点登录问题，很容易解决了session共享的问题。缺点是无法作废已颁布的令牌/不易应对数据过期。

(OAuth2)

OAuth本质上只是一个授权框架而不是身份认证协议，但在第三方账号登录里被直接当作身份认证机制而获得广泛应用。