Apache Shiro 集成-Cas

SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。

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访问流程主要有以下步骤：

1. 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。

2. 定向认证：SSO客户端会重定向用户请求到SSO服务器。

3. 用户认证：用户身份认证。

4. 发放票据：SSO服务器会产生一个随机的Service Ticket。

5. 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。

6. 传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。

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

基础协议图

 

如上图：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请求认证时序图如下：

3.2.1.      CAS 如何实现 SSO

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

1) 如果User持有TGC且其还没失效，那么就走基础协议图的Step4，达到了 SSO 的效果；

2) 如果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 Proxy图所示，CAS Client 在基础协议之上，在验证ST时提供了一个额外的PGT URL(而且是 SSL 的入口)给CAS Server，使得CAS Server可以通过PGT URL提供一个PGT给CAS Client。

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

下面是代理认证和提供服务的过程：

如上图所示，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分钟。

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认证，直接访问对应的服务。

 

5.      参考资料

1、 https://wiki.jasig.org/display/CASUM/Introduction

2、 http://www.jasig.org/cas/protocol/

3、 http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html

4、 http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html

5、 http://baike.baidu.com/view/190743.htm

Shiro集成CAS是在1.2版本里新增的功能。

Shiro-cas模块将应用作为CAS客户端与CAS SSO服务器一起保护web应用。

CAS协议的一个基本理解：

1． 如果你想访问一个被CAS客户端保护的应用，而你还没有进行认证。你讲被重定向到CAS服务端的登录页面。在应用中你需要配置CAS的登录url地址。

http://application.examples.com/protected/index.jsp → HTTP 302 → https://server.cas.com/login?service=http://application.examples.com/shiro-cas

2． 当你填上登录名和密码在CAS服务端进行认证后，你就被重定向到一个带有服务端票据的应用URL。服务端票据是一次性使用的令牌，可在CAS服务端标识用户的唯一性（或用户属性）。

https://server.cas.com/login?service=http://application.examples.com/shiro-cas → HTTP 302 → http://application.examples.com/shiro-cas?ticket=ST-4545454542121-cas

3． 应用去CAS服务端询问票据的有效性，CAS服务端响应经过认证的用户唯一标识。CAS客户端将页面转发到受保护的页面。

http://application.examples.com/shiro-cas?ticket=ST-4545454542121-cas → HTTP 302 → http://application.examples.com/protected/index.jsp

如何配置shiro与CAS服务器工作？

在你的应用中添加shiro-cas Maven依赖

<dependency>     <groupId>org.apache.shiro</groupId>     <artifactId>shiro-cas</artifactId>     <version>version</version> </dependency>

在你的应用中添加服务端url，这个url被用来接收CAS服务端票据。

在Shiro配置中定义CasFilter：

[main] casFilter = org.apache.shiro.cas.CasFilter casFilter.failureUrl = /error.jsp

定义过滤器对应的url：

[urls] /shiro-cas = casFilter

这样一来，当用户经过CAS服务端的有效票据认证后被重定向到应用的服务地址（/shiro-cas），这个过滤器接收服务端票据并创建一个可以被CasRealm使用的CasToken。

CasRealm使用被CasFilter创建的CasToken来验证用户的合法性。在你的shiro配置中添加CasRealm：

[main] casRealm = org.apache.shiro.cas.CasRealm casRealm.defaultRoles = ROLE_USER #casRealm.defaultPermissions #casRealm.roleAttributeNames #casRealm.permissionAttributeNames #casRealm.validationProtocol = SAML casRealm.casServerUrlPrefix = https://server.cas.com/ casRealm.casService = http://application.examples.com/shiro-cas

casServerUrlPrefix是CAS服务端地址。

casService是应用服务地址，用来接收CAS服务端票据。

validationProcol值为SAML or CAS，默认是CAS。它依赖于CAS服务器的版本，SAML协议只能使用在CAS server version >= 3.1。

defaultRoles是认证通过后默认角色。

defaultPermissions是认证通过后默认权限。

roleAttributeNames是认证通过的用户的角色属性名称，用逗号分隔。

permissionAttributeNames是认证通过的用户的权限属性名称，用逗号分隔。

CAS服务端可以支持 ‘remember me’ 功能，这个信息通过SAML验证或CAS定制验证发布。你需要在Shiro配置中定义CasSubjectFactory：

[main] casSubjectFactory = org.apache.shiro.cas.CasSubjectFactory securityManager.subjectFactory = $casSubjectFactory

最后，为你的应用增加安全控制。定义需要保护的url地址和需要进行认证的CAS服务端地址：

[main] roles.loginUrl = https://server.cas.com/login?service=http://application.examples.com/shiro-cas [urls] /protected/** = roles[ROLE_USER] /** = anon

一个完整的配置例子：

[main]

casFilter = org.apache.shiro.cas.CasFilter

casFilter.failureUrl = /error.jsp

casRealm = org.apache.shiro.cas.CasRealm

casRealm.defaultRoles = ROLE_USER

casRealm.casServerUrlPrefix = https://server.cas.com/

casRealm.casService = http://application.examples.com/shiro-cas

casSubjectFactory = org.apache.shiro.cas.CasSubjectFactory

securityManager.subjectFactory = $casSubjectFactory

roles.loginUrl = https://server.cas.com/login?service=http://application.examples.com/shiro-cas

[urls]

/shiro-cas = casFilter

/protected/** = roles[ROLE_USER]

/** = anon