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

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

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

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 等。

本文内容紧张针对 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.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 访问流程紧张有以下步骤：

下面是 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 ，然后做下面的事情：

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 ) ---------- 密钥发放中央；

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 分钟。

4.2. ST/PT 安全性

ST （ Service Ticket ）是通过 Http 传送的，因此网络中的其他人可以 Sniffer 到其他人的 Ticket 。
CAS 通过以下几方面来使 ST 变得更加安全（事实上都是可以配置的）：

1、 ST 只能利用一次

CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会打消做事端缓存中的该Ticket ，从而可以确保一个 Service Ticket 不被利用两次。

2、 ST 在一段韶光内失落效

CAS 规定 ST 只能存活一定的韶光，然后 CAS Server 会让它失落效。
默认有效韶光为 5 分钟。

3、 ST 是基于随机数天生的

ST 必须足够随机，如果 ST 生成规则被猜出， Hacker 就即是绕过 CAS 认证，直接访问 对应的做事。