单点登录常用协议原理和流程

一、背景

近期公司准备上身份认证平台（IAM），主要有两块内容，一部分是单点登录、一部分是账号生命周期管理。其中涉及几个常用的单点登录标准认证协议，其中有SMAL、LOAP、CAS、OIDC、Oauth2.0，本篇文章简单介绍。

二、单点登录介绍

单点登录是指用户只需输入一次用户密码，在某一个应用完成认证登录后，即可直接进入所有应用系统。由此可以看出，单点登录比统一认证更进一步，它在让所有应用系统使用一套用户密码访问的基础上，还能让用户只需要登录其中一个应用，访问其他应用不在需要再输入这套用户密码。

三、单点登录协议

3.1、CAS协议

CAS（ Central Authentication Service）中央认证服务，是一种独立开发指令协议，旨在为web应用系统提供一种可靠的单点登录方法。

CAS是开源的企业级单点登录方案，Apache2.0许可证，允许修改、发布、商用。
Cas包含两个部分，Cas Server和Cas Client。
    Cas Server需要单独部署，负责对用户的认证工作。
    Cas Client和受保护的客户端应用部署在一起，以Filter的方式保护受保护的资源，负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到Cas Server进行认证。
Cas Client支持多种客户端，包括Java、PHP、Python、.Net、Perl、Apache、uPortal、Ruby等语言。

流程说明： 

I，用户浏览器访问应用中的受保护资源。
II，Cas Client拦截请求，检查请求中是否带有Service Ticket（ST），如果没有就将请求重定向到Cas Server登录地址，并传送Service。
III，用户输入认证信息，登录
IV，用户登录成功，Cas Server随机产生一个相当长度、唯一、不可伪造的Service Ticket，并缓存Service Ticket用于验证，之后重定向到Service地址，并为客户端浏览器设置一个Ticket Granded Cookie（TGC）。
V，Cas Client拿到Service和新产生的Ticket后，请求Cas Server验证Service Ticket。
VI，Cas Server验证通过后，返回用户信息。

协议过程中所有与Cas的交互均采用SSL协议，确保ST和TGC的安全性；过程中有两次重定向的过程；Ticket验证过程对用户来说是透明的。
当用户访问另一个应用的服务再次重定向到Cas Server时，Cas Server会主动获取TGC，如果TGC有效，则直接进入步骤IV，如果TGC失效则需要用户重新认证。

3.2、OAuth2.0协议

OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如用户信息、照片，联系人），而无需将用户名和密码提供给第三方应用。

常见使用场景：

• API访问授权
• 授权登录
• web应用单点登录

认证和授权过程中涉及的三方包括：
服务提供商（IAM）：用户用来存储受保护资源。
用户：受保护资源的拥有者。
客户端（应用）：需要访问受保护资源的第三方应用。

流程说明： 

I，用户打开客户端，客户端要求用户授权。
II，用户同意给与授权，向服务提供商获取一个临时授权码。
III，客户端使用临时授权码，向服务提供商申请令牌。
IV，服务提供商验证临时授权码无误后，向客户端发放令牌。
V，客户端使用令牌，向服务提供商申请获取受保护资源。
VI，服务提供商确认令牌无误后，向客户端开发保护资源。

详细见《浅谈Oauth2.0授权》。

3.3、OIDC协议

OIDC（OpenID Connect），OIDC=(Identity, Authentication) + OAuth 2.0。它在Oauth2.0之上构建了一个身份层，是一个基于Oauth2.0协议的身份认证标准协议。OIDC的核心在于在Oauth2.0的授权流程中，一并提供ID Token来标识用户身份认证信息，ID Token使用JWT格式包装，可以安全地传输给第三方客户端并且容易被验证。此外还提供了UserInfo接口，可以获取用户更完整的信息。OIDC协议可以适用于各种类型的客户端（比如服务端应用，移动APP，JS应用），且完全兼容OAuth2.0。

主要术语：

• EU：End User，一个人类用户。
• RP：Relying Party，用来代指Oauth2.0中受信任的客户端，身份认证和授权信息的消费方。
• OP：OpenID Provider，有能力提供EU认证的服务，用来为RP提供EU的身份认证信息。
• ID Token：JWT格式的数据，包含EU的身份认证信息。
• UserInfo EndPoint：用户信息接口，受Oauth2.0保护，RP使用Access Token访问时，返回授权用户的信息，必须使用https。

流程说明：

I，RP发送一个认证请求给OP。
II，OP对EU身份进行认证，然后提供授权。
III，OP把ID Token和Access Token返回给RP。
IV，RP使用Access Token访问UserInfo EndPoint。
V，UserInfo EndPoint返回EU的Claims。 

OIDC定义了三种认证方式

• 授权码流程(Authorization Code Flow)：基于OAuth2的授权码流程，在原来code换取Access token的基础上增加了一个Id token。
• 隐式流程(Implicit Flow)：基于OAuth2的简化流程，在原来从授权服务器重定向到第三方应用仅返回Access token的基础上增加了一个Id token。
• 混合流程(Hybrid Flow)：混合了授权码流程(Authorization Code Flow)和隐式流程(Implici Flow)，能够按照参数配置的不同，控制Id token的返回位置与Access token的有无。

3.4、SAML协议

SAML（Security Assertion Markup Language）是一个基于XML的开源标准数据格式，它在当事方之间交换身份验证和授权数据，尤其是在身份提供者和服务提供者之间交换。SAML解决的最重要的需求是网页浏览器单点登录，SAML规范定义了三个角色：服务提供者（SP）、身份提供者（IDP）、用户（Client）。
SAML可用于安全身份认证和授权，主要用在Saas单点登录场景。
SAML1.0和SAML2.0并不兼容。
在用SAML解决的使用案例中，用户从服务提供者那里请求一项服务，服务提供者请求身份提供者并从那里获得一个身份断言，服务提供者基于这一断言判断用户是否有权执行这项服务。基本流程如下：

流程说明：  

1，Client去访问SP的某个受保护资源。
2，SP没有Client的认证信息，会生成一个SAML的认证请求数据包，并把这个数据包放在一个html的form中的隐藏域中，返回给Client。
3，这个form会自动把认证请求提交给事先配置好的IDP地址。
4，IDP也需要认证Client，于是返回给Client一个认证界面，可以是用户名密码认证，也可以是其它可行的方式。
5，Client提交认证信息给IDP。
6，IDP认证完成后，会为Client生成一些断言，包含Client的身份、权限等，签名后放在form中返回给Client。
7，包含断言数据的form自动提交到SP。
8，SP验证断言数据，得到Client的身份和权限，返回Client想要访问的资源。 

3.5、LDAP协议

轻型目录访问协议（Lightweight Directory Access Protocol）是一个开放的，中立的，工业标准的应用协议，通过IP协议提供访问控制和维护分布式信息的目录信息。LDAP的一个常用用途是单点登录，用户可以在多个服务中使用同一个密码，通常用于公司内部网站的登录中（这样他们可以在公司计算机上登录一次，便可以自动在公司内部网上登录）。

常见的LDAP实现:

• openLDAP
• Active Directory

 3.6、Radius

远程认证拨号用户服务（Remote Authentication Dial In User Service）由RFC2865，RFC2866定义，是应用最广泛的AAA协议。RADIUS是一种C/S结构的协议，它的客户端最初就是NAS（Net Access Server）服务器，任何运行RADIUS客户端软件的计算机都可以成为RADIUS的客户端。RADIUS协议认证机制灵活，可以采用PAP、CHAP或者Unix登录认证等多种方式。RADIUS是一种可扩展的协议，它进行的全部工作都是基于Attribute-Length-Value的向量进行的。RADIUS也支持厂商扩充厂家专有属性。