盘点认证协议 : 普及篇之ADFS , WS-Federation

首先分享之前的所有文章 , 欢迎点赞收藏转发三连下次一定 >>>>

文章合集 : https://juejin.cn/post/6941642435189538824
Github : https://github.com/black-ant
CASE 备份 : https://gitee.com/antblack/case

• 纯约束型协议 : OAuth , SAML , OIDC , CAS
• 服务器类协议 : RADIUS , Kerberos , ADFS
• 认证方式类 : OTP , 生物认证 (人脸 , 声纹 , 指纹)
• 认证服务器(附带) : AD , LDAP , ADFS

这一篇的深度不会太深 , 主要是对概念的普及 !

一 . 前言

之所以这一篇把 ADFS 放上来主要是因为它和 SAML 协议比较接近, 所以通过它来完善一下 SAML 的认证体系 .

先说一下 ADFS 和 WS-Federation 是什么 .

WIF : .NET Framework 类

WIF (Windows Identity Foundation) : 这个.NET 库用于在NET应用程序和依赖方中驱动基于声明的身份验证。它还可以用作WS-Trust客户端和构建自定义STS

WS-Federation

WS-Federation（简称: WS-Fed ) 属于Web Services Security(简称: WS-Security、WSS: 针对web-service安全性方面扩展的协议标准集合) 的一部分，是由OASIS（https://www.oasis-open.org）发布的标准协议

作用 : WS-Federation的基本目标就是为了能够简化联合（所谓联合: Federation，是指一组相互之间存在安全共享资源关系的领域集合）服务的开发。

流程 : 由依赖方和STS用于协商安全令牌的协议。应用程序使用WS联合从STS请求安全令牌，STS(大多数时候)使用WS联合协议将SAML安全令牌返回给应用程序。这通常是通过HTTP(获取、post和重定向)实现的。

ADFS : Windows 基于 AD 引用实现了 Federation 的服务

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

由Microsoft生产并构建在Windows Identity Foundation (WIF)上的现成安全令牌服务(STS) ,依赖AD进行身份验证。可以在活动(SOAP web服务)或被动(web站点)场景中使用，并支持SAML令牌、WS-Federation、WS-Trust和SAML- protocol

总结 : 这就是说 ADFS 是 Federation 协议的实现 , AD 是身份管理 , ADFS 是一个服务 , 并且实现了很多协议.

• ADFS 1.0 - Windows Server 2003 R2 (additional download)
• ADFS 1.1 - Windows Server 2008 and Windows Server 2008 R2.
• ADFS 2.0 - Windows Server 2008 and Windows Server 2008 R2 (download from Microsoft.com)
• ADFS 2.1 - Windows Server 2012.
• ADFS 3.0 - Windows Server 2012 R2.

STS : 身份认证成员 , 安全令牌颁发者

STS是位于依赖方应用程序和用户之间的代理。STS是安全令牌的颁发者 , STS 有2种 角色 ,

• 身份提供者(IdP) : 当它们验证用户时
• 联合提供者(FP) : 当它们位于信任链的中间，充当其他IdP的“依赖方”时

我们来看一张 ADFS 的概念图 :

二 . 深入 WS-Federation

2.1 WS-Federation 成员解析

WS-Trust
WS-Trust定义了Security Token Service （STS）协议用于请求/发布安全令牌；
通过定义服务模型，安全令牌服务（STS）以及用于请求/发布这些安全令牌的协议（由WS-Security使用并由WS-SecurityPolicy描述）来提供联合的基础.
STS发出了一个由资源提供者信任的令牌，因此请求者必须通过STS验证自己才能获得令牌，然后向资源提供者请求资源以及声明/令牌.

2.2 Metadata Model元数据模型

发起点: 请求者希望最终通信的服务。 给定目标服务的元数据端点引用(metadpoint reference，MEPR)允许请求者获取关于服务的所有需求元数据(例如联合元数据、通信策略、 WSDL 等)。

作用: 联合元数据描述有关如何在联合中使用服务以及服务如何参与联合的设置和信息。

身份: 联合元数据只是服务总体元数据的一个组成部分, 还有一个通信策略，描述发送到服务的 web 服务消息的需求，以及服务、端点和消息的组织结构的 WSDL 描述。

范围: : 联合元数据(如通信策略)的范围可以限定到服务、端点，甚至是消息。 此外，所描述的信息类型可能根据联合中的服务角色而有所不同(例如，目标服务、安全令牌服务…)。

三 . 深入 ADFS

3.1 ADFS 流程

为了更清楚 , 我这里画了一个图来说明

3.2 核心问题

身份令牌 : 有认证就会有令牌
ADFS 种会传递 security token 来表明用户 , 安全令牌包含关于用户的声明，如用户名、组成员、UPN、电子邮件地址、管理员详细信息和电话号码 . 应用程序会自行通过令牌判断该如何处理人员 , 所以 :

• ADFS 做身份验证决策 , 应用做权限管理以及行为控制
• 双方之间的联合信任通过证书进行管理 , 而AD FS服务器可以自签名安全令牌签名和加密证书
  • 发布者和消费应用程序或服务之间的HTTPS通信需要一个公钥基础设施(PKI)

IDP 和 SP
这涉及到 ADFS 是一个认证方还是非认证方 , 答案是 : ADFS 中都可以配置 , ADFS 即可以让应用认证 , 也可以去 SSO 中完成认证 , 只不过作为 IDP 时 , AD DS认证成功后，AD FS的STS (security token service)组件会发出安全令牌。

怎么理解联合

就像一个 SSO 集群 , 可以去对方的地方认证 , 也可以让对方到你这里认证 , 只是通过一定的协议颁发令牌即可

ADFS 认证的方式 :

• 表单验证: 这种身份验证方法适用于发布在公司网络之外的资源，并且客户端可以通过internet访问这些资源。
• Windows集成验证: 这是默认的认证方法，适用于在企业网络中发布的资源，并且只能从内网资源访问。

3.3 其他知识点

Account Store/Attribute store :
Active Directory联合身份验证服务使用术语“属性存储”来指组织用来存储其用户帐户及其关联的属性值的目录或数据库

claims provider (CP):
声明提供方，是联合身份验证服务，负责收集和验证用户，构建声明，并将声明打包为安全令牌（Security Token），ADFS本身就是典型的CP

claims provider trust (CPT) :
受ADFS信赖的其他CP，根据Claims Rules向ADFS发送声明，受信任的CP用户可以访问ADFS配置（relying party trust）中的relying party

relying party(RP) :
信赖方，即声明的消费方，需要依赖ADFS进行用户验证的应用程序，信赖方向Claim Provider请求并接收claims provider传过来的Claims（Claim需要根据Claim Rule进行转换/映射）

relying party trust :
可以理解为ADFS的“白名单”，受信任的RP才能向接收到ADFS发送的Token/Claims

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

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

信任的传递 :
为安全起见，ADFS服务器部署在内网，不直接对外网提供服务，而是通过部署在外围网络（屏蔽子网）的代理服务器进行转发信任（trust ) ,信任的方向（Trust Direction）是One-way trust 或者Two-way trust , Trust Transitivity（信任的传递）是可传递信任

四 . 知识点

4.1 WS联合会 和 SAML 的区别

目标

• WS : 浏览器重定向（URL中的消息）-浏览器POST（HTML格式的消息）-SOAP（通过HTTP）
  
• SAML : 浏览器重定向（URL中的消息）-浏览器POST（HTML格式的消息）-工件（引用断言+ SOAP调用）-SOAP（通过HTTP）- 反向SOAP（通过HTTP）

支持安全令牌

• WS : SAML断言，X509证书，kerberos
• SAML : SAML断言-其他任何令牌类型（通过SubjectConfirmation 元素嵌入在SAML断言中）

服务依赖关系

• WS : WS-Trust ，WS-Policy，WS-SecurityPolicy。WS-Eventing (订阅单一注销消息)。WS-Transfer和WS-ResourceTransfe
• SAML : 无

元数据

• WS :
  • 联盟元数据格式的描述。
  • 说明此元数据的安全传输。
  • 可以保存有关多个联盟的信息
• SAML :
  • SSO等的元数据描述。
  • 按角色进行组织（IdP，SP，属性请求者，PDP …）

登出

• WS : 可以由SP或（主要）STS发起，后者将向所有RP发送注销消息
• SAML : 一样

断言

• WS : 基于参考令牌的使用（即，可以进行WS-Transfer GET检索实际令牌的EPR )
• SAML :
  • 工件配置文件（完整的SAML响应）
  • URI绑定（仅获得SAML断言）
  • SAML还定义的机制来请求或查询现有断言（由受试者或声明类型）

认证等级

• WS :
  -WS-Trust定义参数（AuthenticationType ）。WS-Fed指定预定义的值（例如Ssl，SslSndKey，智能卡）。
• SAML : SAML 2.0提供了更广泛和可扩展的认证上下文

隐私

• WS :
  • 请求者可以表达其请求的安全令牌的保护要求（protectData 要求和STS的确认）。
  • 隐私声明可以通过WS-Transfer检索。
• SAML :
  • SAML提供一系列选项，以约束断言的使用＆范围
  • 这些约束可能源自SP或IdP

联盟

• WS :
  • 由提供身份映射及其管理的Pseudonym服务（可选…）执行。
  • 假名服务可以独立于IP / STS，并且可以存储与假名关联的令牌。
  • 映射可以由请求者（主要…）或资源（SP）的所有者创建。
  • 对化名的所有操作（获取，设置，创建或删除）都是通过WS-Transfer（及其扩展名WS-ResourceTransfer来过滤这些操作的范围）完成的。
• SAML :
  • 身份映射是IdP的一部分。尽管灵活性较低（？），但它避免了假名服务与断言生成器（WS- *中的IP / STS）之间还需要另一个协议。
  • 映射是由IdP创建的，但可以由IdP或SP进行更改
  • SAML在其AuthNRequest中没有提供与ClientPseudonym相似的概念 。名称ID管理协议（和SPProviderID）不用于瞬时ID映射。

总结 :

感觉还是没讲清楚 , 这方面能查阅的资料比较少 ,而英文看到的又有误差 , 很多都没有解释清楚 ,

ADFS 是一个很重量级的认证方式 ,通常在一些大型企业中可以看到 , 说句心里话 , 碰到 Windows 的东西就怂了 , 太难查问题了 , 文档是多 ,但是一个概念居然有4,5个描述他的文档 , 还每个不同 , 就是折磨了