javaphp都邑技巧_一篇文章彻底弄懂CAS实现SSO单点登录事理

文章目录 [+]

CAS （ Central Authentication Service ）是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 运用系统供应一种可靠的单点登录办理方法（属于 Web SSO ）。

CAS 开始于 2001 年，并在 2004 年 12 月正式成为 JA-SIG 的一个项目。

javaphp都邑技巧_一篇文章彻底弄懂CAS实现SSO单点登录事理

1.2. 紧张特性

（图片来自网络侵删）

1、开源的、多协议的 SSO 办理方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。

2、支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；

3、安全策略：利用票据（ Ticket ）来实现支持的认证协议；

4、支持授权：可以决定哪些做事可以要乞降验证做事票据（ Service Ticket ）；

5、供应高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；

6、支持多种客户端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。

2. SSO 单点登录事理

本文内容紧张针对 Web SSO 。

2.1. 什么是SSO

单点登录（ Single Sign-On , 简称 SSO ）是目前比较盛行的做事于企业业务整合的办理方案之一， SSO 使得在多个运用系统中，用户只须要登录一次就可以访问所有相互信赖的运用系统。

2.2. SSO 事理

2.2.1. SSO 体系中的角色

一样平常 SSO 体系紧张角色有三种：

1、 User （多个）

2、 Web 运用（多个）

3、 SSO 认证中央（ 1 个）

2.2.2. SSO 实现模式的原则

SSO 实现模式一样平常包括以下三个原则：

1、所有的认证登录都在 SSO 认证中央进行；

2、 SSO 认证中央通过一些方法来见告 Web 运用当前访问用户究竟是不是已通过认证的用户；

3、 SSO 认证中央和所有的 Web 运用建立一种信赖关系，也便是说 web 运用必须信赖认证中央。
（单点信赖）

2.2.3. SSO 紧张实现办法

SSO 的紧张实现办法有：

1、共享 cookies

基于共享同域的 cookie 是 Web 刚开始阶段时利用的一种办法，它利用浏览同域名之间自动通报 cookies 机制，实现两个域名之间系统令牌通报问题；其余，关于跨域问题，虽然 cookies本身不跨域，但可以利用它实现跨域的 SSO 。
如：代理、暴露 SSO 令牌值等。

缺陷：不灵巧而且有不少安全隐患，已经被抛弃。

2、 Broker-based( 基于经纪人 )

这种技能的特点便是，有一个集中的认证和用户帐号管理的做事器。
经纪人给被用于进一步要求的电子身份存取。
中心数据库的利用减少了管理的代价，并为认证供应一个公共和独立的 \"大众第三方 \公众。
例如 Kerberos 、 Sesame 、 IBM KryptoKnight （凭据库思想 ) 等。
Kerberos是由麻省理工大学发明的安全认证做事，已经被 UNIX 和 Windows 作为默认的安全认证做事集成进操作系统。

3、 Agent-based （基于代理人）

在这种办理方案中，有一个自动地为不同的运用程序认证用户身份的代理程序。
这个代理程序须要设计有不同的功能。
比如，它可以利用口令表或加密密钥来自动地将认证的包袱从用户移开。
代理人被放在做事器上面，在做事器的认证系统和客户端认证方法之间充当一个 \"大众翻译 \公众。
例如 SSH 等。

4、 Token-based

例如 SecureID,WebID ，现在被广泛利用的口令认证，比如 FTP 、邮件做事器的登录认证，这是一种大略易用的办法，实现一个口令在多种运用当中利用。

5、基于网关

6、基于 SAML

SAML(Security Assertion Markup Language ，安全断言标记措辞）的涌现大大简化了 SSO ，并被 OASIS 批准为 SSO 的实行标准。
开源组织 OpenSAML 实现了 SAML 规范。

3. CAS 的基本事理

3.1. 构造体系

从构造体系看， CAS 包括两部分： CAS Server 和 CAS Client 。

3.1.1. CAS Server

CAS Server 卖力完成对用户的认证事情 , 须要独立支配 , CAS Server 会处理用户名 / 密码等凭据(Credentials) 。

3.1.2. CAS Client

卖力处理对客户端受保护资源的访问要求，须要对要求方进行身份认证时，重定向到 CAS Server 进行认证。
（原则上，客户端运用不再接管任何的用户名密码等 Credentials ）。

CAS Client 与受保护的客户端运用支配在一起，以 Filter 办法保护受保护的资源。

3.2. CAS 事理和协议

3.2.1. 根本模式

根本模式 SSO 访问流程紧张有以下步骤：

访问做事： SSO 客户端发送要求访问运用系统供应的做事资源。
定向认证： SSO 客户端会重定向用户要求到 SSO 做事器。
用户认证：用户身份认证。
发放票据： SSO 做事器会产生一个随机的 Service Ticket 。
验证票据： SSO 做事器验证票据 Service Ticket 的合法性，验证通过后，许可客户端访问做事。
传输用户信息： SSO 做事器验证票据通过后，传输用户认证结果信息给客户端。

下面是 CAS 最基本的协议过程：

CAS实现SSO单点登录事理

根本协议图

如上图： CAS Client 与受保护的客户端运用支配在一起，以 Filter 办法保护 Web 运用的受保护资源，过滤从客户端过来的每一个 Web 要求，同时， CAS Client 会剖析 HTTP 要求中是否包含要求 Service Ticket( ST 上图中的 Ticket) ，如果没有，则解释该用户是没有经由认证的；于是 CAS Client 会重定向用户要求到 CAS Server （ Step 2 ），并通报 Service （要访问的目的资源地址）。
Step 3 是用户认证过程，如果用户供应了精确的 Credentials ， CAS Server 随机产生一个相称长度、唯一、不可假造的 Service Ticket ，并缓存以待将来验证，并且重定向用户到 Service 所在地址（附带刚才产生的 Service Ticket ） , 并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ）； CAS Client 在拿到 Service 和新产生的 Ticket 过后，在 Step 5 和 Step6 中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。

在该协议中，所有与 CAS Server 的交互均采取 SSL 协议，以确保 ST 和 TGC 的安全性。
协议事情过程中会有 2 次重定向的过程。
但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对付用户是透明的（利用 HttpsURLConnection ）。

CAS 要求认证时序图如下：

CAS实现SSO单点登录事理

3.2.1. CAS 如何实现 SSO

当用户访问另一个运用的做事再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：

如果 User 持有 TGC 且其还没失落效，那么就走根本协议图的 Step4 ，达到了 SSO 的效果；如果 TGC 失落效，那么用户还是要重新认证 ( 走根本协议图的 Step3) 。

3.2.2. CAS 代理模式

该模式形式为用户访问 App1 ， App1 又依赖于 App2 来获取一些信息，如： User -->App1 -->App2。

这种情形下，假设 App2 也是须要对 User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定引导致 User 的 IE 窗口一直地闪动 ) ， CAS 引入了一种 Proxy 认证机制，即 CAS Client 可以代理用户去访问其它 Web 运用。

代理的条件是须要 CAS Client 拥有用户的身份信息 ( 类似凭据 ) 。
之前我们提到的 TGC 是用户持有对自己身份信息的一种凭据，这里的 PGT 便是 CAS Client 端持有的对用户身份信息的一种凭据。
凭借TGC ， User 可以免去输入密码以获取访问其它做事的 Service Ticket ，以是，这里凭借 PGT ， Web运用可以代理用户去实现后真个认证，而无需前端用户的参与。

下面为代理运用（ helloService ）获取 PGT 的过程：（注： PGTURL 用于表示一个 Proxy 做事，是一个回调链接； PGT 相称于代理证； PGTIOU 为取代理证的钥匙，用来与 PGT 做关联关系；）

CAS实现SSO单点登录事理

如上面的 CAS Proxy 图所示， CAS Client 在根本协议之上，在验证 ST 时供应了一个额外的PGT URL( 而且是 SSL 的入口 ) 给 CAS Server ，使得 CAS Server 可以通过 PGT URL 供应一个 PGT 给 CAS Client 。

CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td) ，就可以通过 PGT 向后端 Web 运用进行认证。

下面是代理认证和供应做事的过程：

CAS实现SSO单点登录事理

如上图所示， Proxy 认证与普通的认证实在差别不大， Step1 ， 2 与根本模式的 Step1,2 险些一样，唯一不同的是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。

3.2.3. 赞助解释

CAS 的 SSO 实现办法可简化理解为： 1 个 Cookie 和 N 个 Session 。
CAS Server 创建 cookie，在所有运用认证时利用，各运用通过创建各自的 Session 来标识用户是否已登录。

用户在一个运用验证通过后，往后用户在同一浏览器里访问此运用时，客户端运用中的过滤器会在 session 里读取到用户信息，以是就不会去 CAS Server 认证。
如果在此浏览器里访问别的 web 运用时，客户端运用中的过滤器在 session 里读取不到用户信息，就会去 CAS Server 的 login 接口认证，但这时CAS Server 会读取到浏览器传来的 cookie （ TGC ），以是 CAS Server 不会哀求用户去登录页面登录，只是会根据 service 参数天生一个 Ticket ，然后再和 web 运用做一个验证 ticket 的交互而已。

3.3. 术语阐明

CAS 系统中设计了 5 中票据： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。

Ø Ticket-granting cookie(TGC) ：存放用户身份认证凭据的 cookie ，在浏览器和 CAS Server 间通讯时利用，并且只能基于安全通道传输（ Https ），是 CAS Server 用来明确用户身份的凭据；

Ø Service ticket(ST) ：做事票据，做事的惟一标识码 , 由 CAS Server 发出（ Http 传送），通过客户端浏览器到达业务做事器端；一个特定的做事只能有一个惟一的 ST ；

Ø Proxy-Granting ticket （ PGT ）：由 CAS Server 颁发给拥有 ST 凭据的做事， PGT 绑定一个用户的特定做事，使其拥有向 CAS Server 申请，得到 PT 的能力；

Ø Proxy-Granting Ticket I Owe You （ PGTIOU ） : 浸染是将通过凭据校验时的应答信息由 CAS Server 返回给 CAS Client ，同时，与该 PGTIOU 对应的 PGT 将通过回调链接传给 Web 运用。
Web 运用卖力掩护 PGTIOU 与 PGT 之间映射关系的内容表；

Ø Proxy Ticket (PT) ：是运用程序代理用户身份对目标程序进行访问的凭据；

其它解释如下：

Ø Ticket Granting ticket(TGT) ：票据授权票据，由 KDC 的 AS 发放。
即获取这样一张票据后，往后申请各种其他做事票据 (ST) 便不必再向 KDC 提交身份认证信息 (Credentials) ；

Ø Authentication service(AS) --------- 认证用做事，索取 Credentials ，发放 TGT ；

Ø Ticket-granting service (TGS) --------- 票据授权做事，索取 TGT ，发放 ST ；

Ø KDC( Key Distribution Center ) ---------- 密钥发放中央；

4. CAS 安全性

CAS 的安全性仅仅依赖于 SSL 。
利用的是 secure cookie 。

4.1. TGC/PGT 安全性

对付一个 CAS 用户来说，最主要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体得到， Hacker 能够找到该 TGC ，然后伪装 CAS 用户访问所有授权资源。
PGT 的角色跟 TGC 是一样的。

从根本模式可以看出， TGC 是 CAS Server 通过 SSL 办法发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。

TGT 的存活周期默认为 120 分钟。