CAS单点登录（一）：单点登录与CAS理论介绍

一、什么是单点登录（SSO）

单点登录主要用于多系统集成，即在多个系统中，用户只需要到一个中央服务器登录一次即可访问这些系统中的任何一个，无须多次登录。

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

二、web系统如何实现单点登录

目前已经有了成熟的单点登录实现方案，比如CAS，我们只要在web系统中应用单点登录方案CAS即可。(主要涉及到注册登录验证等模块的改动)。

三、什么是CAS

CAS (Central Authentication Service) 是耶鲁 Yale 大学发起的一个java开源项目，旨在为 Web应用系统提供一种可靠的单点登录解决方案（ Web SSO ）， CAS 具有以下特点：

- 开源的企业级单点登录解决方案；
- CAS Server 为需要独立部署的 Web 应用—-一个独立的Web应用程序(cas.war)。；
- CAS Client 支持非常多的客户端 ( 指单点登录系统中的各个 Web 应用 ) ，包括 Java, .Net, PHP, Perl, 等。

CAS在2004年12月成立Jasig项目，所以也叫JA-SIG CAS。

官网1：

https://apereo.github.io/cas/5.2.x/index.html

官网2：

https://www.apereo.org/projects/cas/about-cas

论坛：

http://jasig.275507.n4.nabble.com/Jasig-CAS-f275508.html

github：

https://github.com/apereo/cas

开发者快捷资源：

http://developer.jasig.org/

下载链接：

https://www.apereo.org/projects/cas/download-cas

官网开发文档：

https://apereo.github.io/cas/5.2.x/installation/Configuring-Commandline-Shell.html

中文开发文档：

http://www.cassso-china.cn/apereo_github_cas_5.2//apereo.github.io/cas/5.2.x/

四、CAS原理

从结构上看， CAS 包含两个部分： CAS Server 和 CAS Client 。

1、CAS Server

CAS Server 需要独立部署，主要负责对用户的认证工作，它会处理用户名 / 密码等凭证 (Credentials) 。

CAS Server 负责完成对用户的认证工作，需要独立部署。并且有不止一种 CAS Server 的实现， Yale CAS Server 和 ESUP CAS Server 都是很不错的选择。

CAS Server 会处理用户名 / 密码等凭证 (Credentials) ，它可能会到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，对这种方式， CAS 均提供一种灵活但同一的接口 / 实现分离的方式， CAS 究竟是用何种认证方式，跟 CAS 协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。

2、CAS Client

CAS Client 部署在客户端，负责处理本地 Web 应用（客户端）受保护资源的访问请求，并且当需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。

CAS Client 负责部署在客户端（注意，是指 Web 应用），原则上， CAS Client 的部署意味着，当有对本地 Web 应用的受保护资源的访问请求，并且需要对请求方进行身份认证， Web 应用不再接受任何的用户名密码等类似的 Credentials ，而是重定向到 CAS Server 进行认证。

目前， CAS Client 支持（某些在完善中）非常多的客户端，包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等客户端，几乎可以这样说， CAS 协议能够适合任何语言编写的客户端应用。

3、CAS相关词汇和概念

(后面代码小节会详细介绍，这里初步了解即可)

TGC(ticket-granting cookie) —— 授权的票据证明，由 CAS Server 通过 SSL 方式发送给终端用户；

KDC( Key Distribution Center ) —— 密钥发放中心；

ST (Service ticket) —— 服务票据，由 KDC 的 TGS 发放， ST 只能被尝试验证一次。任何一台 Workstation 都需要拥有一张有效的 Service Ticket 才能访问域内部的应用 (Applications) 。如果能正确接收 Service Ticket ，说明在 CASClient-CASServer 之间的信任关系已经被正确建立起来，通常为一张数字加密的证书；

Ticket Granting tieckt(TGT) —— 票据授权票据，由 KDC 的 AS 发放。即获取这样一张票据后，以后申请各种其他服务票据 (ST) 便不必再向 KDC 提交 Credentials （凭证或身份认证信息 ) ；

Authentication Service (AS) —— 认证服务，索取 Crendential ，发放 TGT ；

Ticket-Granting Service (TGS) —— 票据授权服务，索取 TGT ，发放 ST 。

4、CAS协议和工作流程

下图是 CAS 基础协议：

（1）CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求， CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket （ ST ）和 Ticket Granting tieckt(TGT) ，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ）， CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5 ， 6 步中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。

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

（3）CAS 如何实现 SSO

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

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

2) 如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。

另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。

5、cas的验证流程

（1）用户浏览受系统保护的URL。

（2）CAS Client服务端收到请求，Filter拦截该请求，在Filter中判断该用户是否已经登陆，如果已经登陆，就直接进入系统，否则，将请求转发到CAS Server服务端的LoginURL。

（3）在LoginURL中会获取到用户的Cookie，检验用户是否已经在其他相关使用SSO的系统登陆成功。如果已经在其他的系统登陆了，则将请求转回 CAS Client，并且带回一个ticket, CAS Client再次发送请求到ValidateURL。否则，系统提示用户输入ID和PASSWORD。

（4）提交后请求到ValidateURL，CAS Server验证ticket的有效性。然后返回结果给CAS Client。如果ticket有效，则CAS Client应让该用户浏览受保护的资源。否则，重定向到登陆页面，提示用户输入ID和PASSWORD。

（5）校验ID和Password是否匹配。如不匹配，再次要求用户输入ID和PASSWORD。否则，CAS Server记录用户登陆成功。并向浏览器回送Cookie，记录用户已经登陆成功。如果浏览器不支持Cookie，则无法实现单点登陆。

6、用户访问流程实例

用户第一次访问一个CAS 服务的客户web 应用时（例如访问URL ：http://192.168.1.90:8081/web1 ），部署在客户web 应用的cas AuthenticationFilter ，会截获此请求，生成service 参数，然后redirect 到CAS 服务的login 接口，url为https://cas:8443/cas/login?service=http%3A%2F%2F192.168.1.90%3A8081%2Fweb1%2F ，认证成功后，CAS 服务器会生成认证cookie ，写入浏览器，同时将cookie 缓存到服务器本地，CAS 服务器还会根据service 参数生成ticket，ticket 会保存到服务器，也会加在url 后面，然后将请求redirect 回客户web 应用，url 为http://192.168.1.90:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZuMwnbMvxpCBcNAIi6-20 。

这时客户端的AuthenticationFilter 看到ticket 参数后，会跳过，由其后面的TicketValidationFilter 处理，TicketValidationFilter 会利用httpclient 工具访问cas 服务的/serviceValidate 接口, 将ticket 、service 都传到此接口，由此接口验证ticket 的有效性，TicketValidationFilter 如果得到验证成功的消息，就会把用户信息写入web 应用的session里。

至此为止，SSO 会话就建立起来了，以后用户在同一浏览器里访问此web 应用时，AuthenticationFilter 会在session 里读取到用户信息，所以就不会去CAS 认证，如果在此浏览器里访问别的web 应用时，AuthenticationFilter 在session 里读取不到用户信息，会去CAS 的login 接口认证，但这时CAS 会读取到浏览器传来的cookie ，所以CAS 不会要求用户去登录页面登录，只是会根据service 参数生成一个ticket ，然后再和web 应用做一个验证ticket 的交互。

五、代码层次如何实现CAS

知道工作原理和流程之后我们来看看应该怎么在代码上实现CAS

一般来说，我们写Web应用只需要熟悉这几个Filter就可以了，如果不需要https连接，连第一个也不用熟悉。但是有人肯定会想，这些 Filter怎么和我的数据库联系起来呢？不用着急，这些Filter并不直接处理用户的认证，也不直接处理用户的授权，而是把它们交给了认证管理器和决策管理器。

对于这两种管理器，那也是不需要我们写代码的，Acegi也提供了现成的类。那么大家又奇怪了：又是现成的，那怎么和我的数据库关联起来呢？别着急，其实这两个管理器自己也不做事，认证管理器把任务交给了Provider，而决策管理器则把任务交给了Voter，如下图：

现在我要告诉你们，这里的Provider和Voter也是不需要我们写代码的。不要崩溃，快到目标了。Acegi提供了多个Provider 的实现类，也就是说CAS的认证方式有很多种，我们可以到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，对于很多种方式，CAS 均提供一种灵活但同一的接口 / 实现分离的方式， CAS 究竟是用何种认证方式，可以由我们自己来决定，也就是，这个认证的实现细节可以自己定制和扩展。例如如果我们想用数据库来储存用户的认证数据，那么我们就选择DaoAuthenticationProvider。对于Voter，我们一般选择 RoleVoter就够用了，它会根据我们配置文件中的设置来决定是否允许某一个用户访问制定的Web资源。

而DaoAuthenticationProvider也是不直接操作数据库的，它把任务委托给了UserDetailService，如下图：

而我们要做的，就是实现这个UserDetailService。说了这么多总算是引出了我们开发中的关键，那就是我们要实现自己的UserDetailService，它就是连接我们的数据库和Acegi的桥梁。UserDetailService的要求也很简单，只需要一个返回org.springframework.security.userdetails.User对象的 loadUserByUsername(String userName)方法。因此，怎么设计数据库都可以，不管我们是用一个表还是两个表还是三个表，也不管我们是用户-授权，还是用户-角色-授权，还是用户-用户组-角色-授权，这些具体的东西Acegi统统不关心，它只关心返回的那个User对象，至于怎么从数据库中读取数据，那就是我们自己的事了。

反过来再看看上面的过程，我们发现，即使我们要做的只是实现自己的UserDetailService类，但是我们不得不在Spring中配置那一大堆的Bean，包括几个Filter，几个Manager，几个Provider和Voter，而这些配置往往都是重复的无谓的。好在Acegi 2.0也认识到了这个问题，所以，它设计了一个<http>标签，让Acegi的配置得到了简化。

在后面具体的部署实施中我们再来详细讲这些细节。

六、CAS的相关接口和处理逻辑

1、Ticket介绍

概念介绍

CAS的核心就是其Ticket，及其在Ticket之上的一系列处理操作。CAS的主要票据有TGT、ST、PGT、PGTIOU、PT，其中TGT、ST是CAS1.0协议中就有的票据，PGT、PGTIOU、PT是CAS2.0协议中有的票据。

TGT（Ticket Grangting Ticket）

TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。用户在CAS认证成功后，CAS生成cookie，写入浏览器，同时生成一个TGT对象，放入自己的缓存，TGT对象的ID就是cookie的值。当HTTP再次请求到来时，如果传过来的有CAS生成的cookie，则CAS以此cookie值为key查询缓存中有无TGT ，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。

ST（Service Ticket）

ST是CAS为用户签发的访问某一service的票据。用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，如果用户的请求中包含cookie，则CAS会以此cookie值为key查询缓存中有无TGT，如果存在TGT，则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。

PGT（Proxy Granting Ticket）

Proxy Service的代理凭据。用户通过CAS成功登录某一Proxy Service后，CAS生成一个PGT对象，缓存在CAS本地，同时将PGT的值（一个UUID字符串）回传给Proxy Service，并保存在Proxy Service里。Proxy Service拿到PGT后，就可以为Target Service（back-end service）做代理，为其申请PT。

PGTIOU（Proxy Granting Ticket IOU）

PGTIOU是CAS协议中定义的一种附加票据，它增强了传输、获取PGT的安全性。

PGT的传输与获取的过程：Proxy Service调用CAS的serviceValidate接口验证ST成功后，CAS首先会访问pgtUrl指向的https url，将生成的 PGT及PGTIOU传输给proxy service，proxy service会以PGTIOU为key，PGT为value，将其存储在Map中；然后CAS会生成验证ST成功的xml消息，返回给Proxy Service，xml消息中含有PGTIOU，proxy service收到Xml消息后，会从中解析出PGTIOU的值，然后以其为key，在map中找出PGT的值，赋值给代表用户信息的Assertion对象的pgtId，同时在map中将其删除。

PT（Proxy Ticket）

PT是用户访问Target Service（back-end service）的票据。如果用户访问的是一个Web应用，则Web应用会要求浏览器提供ST，浏览器就会用cookie去CAS获取一个ST，然后就可以访问这个Web应用了。如果用户访问的不是一个Web应用，而是一个C/S结构的应用，因为C/S结构的应用得不到cookie，所以用户不能自己去CAS获取ST，而是通过访问proxy service的接口，凭借proxy service的PGT去获取一个PT，然后才能访问到此应用。

类和方法

CAS Ticket类图如下：

TicketGrantingTicket 的 grantServiceTicket方法

方法声明：public synchronized ServiceTicket grantServiceTicket(final String id,final Service service, final ExpirationPolicy expirationPolicy, final boolean credentialsProvided)

方法描述：

1）生成SerivceTicketImpl

2）更新属性：

this.previousLastTimeUsed = this.lastTimeUsed;

this.lastTimeUsed = System.currentTimeMillis();

this.countOfUses++;

3）给service对象的principal属性赋值

4）将service对象放入map services

ServiceTicket 的 grantTicketGrantingTicket方法

方法声明：

public TicketGrantingTicket grantTicketGrantingTicket(final String id, final Authentication authentication,final ExpirationPolicy expirationPolicy)

方法描述：在CAS3.3对CAS2.0协议的实现中，PGT是由ST签发的，调用的就是ServiceTicket的grantTicketGrantingTicket方法。方法返回的TicketGrantingTicket对象，表征的是一个PGT对象，其中的ticketGrantingTicket属性的值是签发ST的TGT对象。

TicketGrantingTicket 的 expire方法

方法声明：void expire()

方法描述：

在CAS的logout接口实现中，要调用TGT对象的expire方法，然后会在缓存中清除此TGT对象。

expire方法的内容：循环遍历 services 中的Service对象，调用其logoutOfService方法。具体Service实现类中的logoutOfService方法的实现，要通知具体的应用，客户要退出。

TGT、ST、PGT、PT关系

（1）ST是TGT签发的。用户在CAS上认证成功后，CAS生成TGT，用TGT签发一个ST，ST的ticketGrantingTicket属性值是TGT对象，然后把ST的值redirect到客户应用。

（2）PGT是ST签发的。用户凭借ST去访问Proxy service，Proxy service去CAS验证ST（同时传递PgtUrl参数给CAS），如果ST验证成功，则CAS用ST签发一个PGT，PGT对象里的ticketGrantingTicket是签发ST的TGT对象。

（3）PT是PGT签发的。Proxy service代理back-end service去CAS获取PT的时候，CAS根据传来的pgt参数，获取到PGT对象，然后调用其grantServiceTicket方法，生成一个PT对象。

2、认证相关的类和流程

Credentials

用户提供的用于登录用的凭据信息，如用户名/ 密码、证书、IP 地址、Cookie 值等。比如 UsernamePasswordCredentials ，封装的是用户名和密码。CAS 进行认证的第一步，就是把从UI 或request 对象里取到的用户凭据封装成Credentials 对象，然后交给认证管理器去认证。

AuthenticationHandler

认证Handler, 每种AuthenticationHandler 只能处理一种Credentials ，如AbstractUsernamePasswordAuthenticationHandler 只负责处理 UsernamePasswordCredentials 。

Principal

封装用户标识，比如 SimplePrincipal, 只是封装了用户名。认证成功后， credentialsToPrincipalResolvers 负责由Credentials 生成 Principal 对象。

CredentialsToPrincipalResolvers

负责由 Credentials 生成 Principal 对象，每种 CredentialsToPrincipalResolvers 只处理一种Credentials ，比如 UsernamePasswordCredentialsToPrincipalResolver 负责从UsernamePasswordCredentials 中取出用户名，然后将其赋给生成的 SimplePrincipal 的 ID 属性。

AuthenticationMetaDataPopulators

负责将 Credentials 的一些属性赋值给 Authentication 的 attributes 属性。

Authentication

Authentication是认证管理器的最终处理结果， Authentication 封装了 Principal ，认证时间，及其他一些属性（可能来自 Credentials ）。

AuthenticationManager

认证管理器得到 Credentials 对象后，负责调度AuthenticationHandler 去完成认证工作，最后返回的结果是 Authentication 对象。

CentralAuthenticationService

CAS 的服务类，对 Web 层提供了一些方法。该类还负责调用 AuthenticationManager 完成认证逻辑。

认证类的序列图如下：

认证的相关类图如下：

3、cas server的接口

CAS 服务端总共对外定义了9 个接口，客户端通过访问这9 个接口与服务端交互，这9个接口为：

接口	说明
/login	认证接口
/logout	退出接口，负责销毁认证cookie
/validate	验证ticket 用的接口，CAS1.0 定义
/serviceValidate	验证ticket 用的接口，CAS2.0 定义，返回xml 格式的数据
/proxy	支持代理认证功能的接口
/proxyValidate	支持代理认证功能的接口
/CentralAuthenticationService	用于和远程的web services 交互
/remoteLogin（新增）	认证接口
/directLogin（新增）	认证接口

详细说明：

/login

录流程这部分要考虑到不同种类用户凭证的获取方案，以及客户应用传来的service 、gateway 、renew 参数的不同取值组合，CAS 为了实现流程的高度可配置性，采用了spring Web Flow 技术。通过CAS 发布包里的login-webflow.xml 、cas-servlet.xml 、applicationContext.xml 这3 个文件可以进行相关配置。

CAS 默认的登录处理流程图如下：

说明：

（1） InitialFlowSetupAction: 是流程的入口。用 request.getContextPath() 的值来设置 cookie 的 Path 值， Cookie 的 path 值是在配置文件里定义的，但这个 Action 负责将 request.getContextPath() 的值设置为 Cookie 的 path 值，这是在 cas 部署环境改变的情况下，灵活地设置 cookie path 的方式；把 cookie 的值以及 service 参数的值放入 requestContext 的 flowscope 里。

（2）GenerateServiceTicketAction 此 Action 负责根据 service 、 GTC cookie 值生成 ServiceTicket 对象， ServiceTicket 的 ID 就是返回给客户应用的 ticket 参数，如果成功创建 ServiceTicket ，则转发到 WarnAction ，如果创建失败，且 gateway 参数为 true ，则直接redirect 到客户应用，否则则需要重新认证。

（3）viewLoginForm 这是登录页面， CAS 在此收集用户凭证。 CAS 提供的默认实现是 /WEB-INF/view/jsp/simple/ui/casLoginView.jsp 。

（4）bindAndValidate 对应 AuthenticationViaFormAction 的 doBind 方法，该方法负责搜集登录页面上用户录入的凭证信息（用户名、密码等），然后把这些信息封装到 CAS 内部的 Credentials 对象中。用户在 casLoginView.jsp 页面上点击提交后，会触发此方法。

（5）submit 对应 AuthenticationViaFormAction 的 submit 方法 , 如果 doBind 方法成功执行完，则触发 submit 方法，此方法负责调用centralAuthenticationService 的 grantServiceTicket 方法，完成认证工作，如果认证成功，则生成 TicketGrantingTicket 对象，放在缓存里， TicketGrantingTicket 的 ID 就是 TGC Cookie 的 value 值。

（6） warn CAS 提供了一个功能：用户在一个 web 应用中跳到另一个 web 应用时， CAS 可以跳转到一个提示页面，该页面提示用户要离开一个应用进入另一个应用，可以让用户自己选择。用户在登录页面 viewLoginForm 上选中了 id=”warn” 的复选框，才能开启这个功能。

WarnAction 就检查用户有没有开启这个功能，如果开启了，则转发到showWarnView, 如果没开启，则直接redirect 到客户应用。

（7）SendTicketGrantingTicketAction 此Action 负责为response 生成TGC Cookie ，cookie 的值就是 AuthenticationViaFormAction 的submit 方法生成的 TicketGrantingTicket 对象的 ID 。

（8）viewGenerateLoginSuccess 这是 CAS 的认证成功页面。

第一次访问Web 应用的流程走向图如下：

已经登录web1 后，访问web1 的资源（web1 没有启动session ），或访问web2 的资源走向图如下：

/logout

（对应实现类 org.jasig.cas.web.LogoutController ）

处理逻辑：

1） removeCookie

2）在服务端删除TicketGrantingTicket 对象（此对象封装了cookie 的value 值）

3）redirect 到退出页面，有2 种选择：

if(LogoutController 的followServiceRedirects 属性为true 值，且url 里的service 参数非空){

redirect 到 sevice 参数标识的url

} else {

redirect 到内置的casLogoutView （cas/WEB-INF/view/jsp/default/ui/casLogoutView.jsp ），如果url 里有url 参数，则此url 参数标识的链接会显示在casLogoutView 页面上。

}

/serviceValidate

（对应实现类 org.jasig.cas.web.ServiceValidateController ）

处理逻辑：

如果service 参数为空或ticket 参数为空，则转发到failureView （/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationFailure.jsp ）

验证ticket 。以ticket 为参数，去缓存里找ServiceTicketImpl 对象，如果能找到，且没有过期，且ServiceTicketImpl 对象对应的service 属性和service 参数对应，则验证通过，验证通过后，请求转发至casServiceSuccessView （cas/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationSuccess.jsp ），验证不通过，则转发到failureView 。

4、CAS Client配置参数

CASFilter 参数说明：

参数	是否必须	说明
com.olymtech.cas.client.filter.loginUrl	是	指定 CAS 提供登录页面的 URL
com.olymtech.cas.client.filter.validateUrl	是	指定 CAS 提供 service ticket 或 proxy ticket 验证服务的 URL
com.olymtech.cas.client.filter.serverName	是	指定客户端的域名和端口，是指客户端应用所在机器而不是 CAS Server 所在机器，该参数或 serviceUrl 至少有一个必须指定
com.olymtech.cas.client.filter.serviceUrl	否	该参数指定过后将覆盖 serverName 参数，成为登录成功过后重定向的目的地址
com.olymtech.cas.client.filter.wrapRequest	否	如果指定为 true，那么 CASFilter 将重新包装 HttpRequest,并且使 getRemoteUser() 方法返回当前登录用户的用户名
com.olymtech.cas.client.filter.noFilter	否	设置不过滤的路径，语法如下：/name1/,/name2
com.olymtech.cas.client.filter.proxyCallbackUrl	否	用于当前应用需要作为其他服务的代理(proxy)时获取 Proxy Granting Ticket 的地址
com.olymtech.cas.client.filter.authorizedProxy	否	用于允许当前应用从代理处获取 proxy tickets，该参数接受以空格分隔开的多个 proxy URLs，但实际使用只需要一个成功即可。当指定该参数过后，需要修改 validateUrl 到 proxyValidate，而不再是 serviceValidate
com.olymtech.cas.client.filter.renew	否	如果指定为 true，那么受保护的资源每次被访问时均要求用户重新进行验证，而不管之前是否已经通过
com.olymtech.cas.client.filter.gateway	否	指定 gateway 属性

七、CAS安全性

CAS 的安全性从 v1 到 v3 ，都很依赖于 SSL ，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的传输安全性。

1、TGC 安全性

对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问所有授权资源。

TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保CAS 的安全性。但 CAS 的传输安全性仅仅依赖于 SSL 。

TGC 面临的风险主要并非传输窃取，而是存活周期内（ logout 前）被使用（如：离开了电脑）或窃取。

TGC 有自己的存活周期。可以在 web.xml 中，通过 grantingTimeout 来设置 CAS TGC 存活周期的参数，参数默认是 120 分钟，在合适的范围内设置最小值，太短，会影响 SSO 体验，太长，会增加安全性风险。

2、ST 安全性

ST （ Service Ticket ）是通过 Http 传送的，网络中的其他人可以 Sniffer 到其他人的 Ticket 。CAS 协议从几个方面让 Service Ticket 变得更加安全：

1） ST 只能使用一次： CAS 协议规定，无论 ST 验证是否成功， CAS Server 都会将服务端的缓存中清除该 Ticket ，从而可以确保一个 Service Ticket 不被使用两次；

2） ST 在一段时间内失效：假设用户拿到 ST 之后，他请求服务的过程又被中断了， ST 就被空置了，事实上，此时 TS 仍然有效。 CAS 规定 Service Ticket 只能存活一定的时间，然后 CAS Server 会让它失效。可通过在 web.xml 中配置参数，让 ST 在多少秒内失效。

3） ST 是基于随机数生成的。

八、实现单点登录的开发流程

通过上面的学习我们已经对单点登录以及CAS有了一定的了解，那么我们怎么入手搭建集群的单点登录呢?

步骤如下：

1、搭建部署cas server

首先我们肯定是要下载cas server的代码，然后进行用户名密码验证认证方式的选型，选型结束后进行相应配置以及登录界面的修改等等。

然后把cas server的war包发布到服务器上，运行即可。

2、web项目中集成cas client

cas server搭建完成后登录认证模块已经有了，那么怎么跟我们的web项目关联起来呢? 这就需要在web 项目中集成cas的client客户端了，集成了之后，对cas client的配置文件进行配置，对应到cas server的地址，这样它们就能联系起来了。

九、cas server认证方式的选型

我们之前已经说过了cas支持很多种认证方式，我们即可把用户名密码写在xml中，然后cas来读取之后跟用户输入的帐号密码对比，也可以把用户名密码存在数据库中。

目前cas提供给了以下认证方式：

- GENERIC
- JAAS
- JDBC —— 关系型数据库
- MongoDB —— 非关系数据库
- LDAP
- LEGACY
- RADIUS
- SPNEGO
- TRUSTED
- X509
- OAUTH
- OPENID

在cas server的默认配置中，可以修改认证管理器中的认证处理器属性链表，增加或者修改相应的认证方式。

有些认证方式对于web开发，基本上不太好用或者不常用，因为他们的配置太不灵活或者太专业化。在此之所以列举了那么多关于cas的认证处理器，主要为了让大家知道，cas支持这种认证方式。比如现在新浪微博就对外开通了oauth认证接口，如果哪一天公司进行战略转形，希望用cas接新浪微博账号认证，那么就可以直接在此基础上进行好好研究。

一般LDAP和数据库比较常用，我们接下来会着重讲这两种的运用。

原文：

https://blog.csdn.net/zzq900503/article/details/54646828

转载于:https://www.cnblogs.com/Jimc/p/10151890.html