统一身份认证（CAS）简单说明与设计方案

时间 2019-11-08

标签统一身份认证 cas 简单说明设计方案繁體版

原文原文链接

1. 单点登陆概述

所谓单点登陆（SSO），只当企业用户同时访问多个不一样（类型的）应用时，他们只须要提供自身的用户凭证信息（好比用户名/密码）一次，仅仅一次。SSO解决方案（好比，CAS）负责统一认证用户，若是须要，SSO也能够完成用户的受权处理。能够看出，当企业用户在不一样的应用间切换时，他们不用再重复地输入自身的用户凭证了。在实施SSO后，所用的认证操做都将交给SSO认证中心。现有的SSO解决方案很是多，好比微软的MSN Passport即是典型的SSO解决方案，各Java EE容器都提供了自身的专有SSO能力。web

2. CAS的整体架构

1. CAS简介

CAS（中央认证服务）是创建在很是开放的协议之上的企业级SSO解决方案。诞生于2001年，在2002年发布了CAS2.0协议，这一新的协议提供了Proxy（代理）能力，此时的CAS2.0支持多层SSO能力。到2005年，CAS成为了JA-SIG旗下的重要子项目。因为CAS2.0版本的可扩展能力不是很是完美，并且他的架构设计也不是很卓越，为了使得CAS可以适用于更多场合，JA-SIG打算开发出同时遵循CAS1.0和CAS2.0协议的CAS3.X版本。spring

如今的CAS3全面拥抱Spring技术，好比Spring DI容器和AOP技术、Spring Web MVC、Spring Web Flow、Spring Ldap Template等。浏览器

一般，CAS3由两部份内容构成：CAS3服务器和CAS客户端。因为CAS2.0协议借助于XML数据结构与客户进行交互，所以开发者可使用各类语言编写的CAS3客户与服务器进行通讯。CAS3服务器采用纯Java开发而成，它要求目标运行环境实现了Servlet2.4+规范、提供Java SE 1.4+支持。若是宿主CAS3服务器的目标Java EE容器仅仅实现了Servlet2.3-规范，则在对CAS3服务器进行少许的改造后，CAS3也能运行其中。安全

运行时，CAS3服务器仅仅是一个简单的Web应用，使用者只须要将cas.war直接丢到目标Java EE容器后，即完成了CAS3的部署。服务器

2. CAS词汇概念

TGC(ticket-granting cookie)--------- 授权的票据证实
KDC( Key Distribution Center ) ---------- 密钥发放中心
Service ticket(ST) --------- 服务票据，由 KDC 的 TGS 发放。任何一台 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 ，发放 STcookie

3. CAS工做原理

CAS的单点登陆的认证过程，所用应用服务器受到应用请求后，检查ST和TGT，若是没有或不对，转到CAS认证服务器登陆页面，经过安全认证后获得ST和TGT，再从新定向到相关应用服务器，在回话生命周期以内若是再定向到别的应用，将出示ST和TGT进行认证，注意，取得TGT的过程是经过SSL安全协议的。数据结构

若是通俗形象地说就是：至关于用户要去游乐场，首先要在门口检查用户的身份 ( 即 CHECK 用户的 ID 和 PASS), 若是用户经过验证，游乐场的门卫 (AS) 即提供给用户一张门卡 (TGT)。架构

这张卡片的用处就是告诉游乐场的各个场所，用户是经过正门进来，而不是后门偷爬进来的，而且也是获取进入场所一把钥匙。app

如今用户有张卡，可是这对用户来不重要，由于用户来游乐场不是为了拿这张卡的而是为了游览游乐项目，这时用户摩天楼，并想游玩。加密

这时摩天轮的服务员 (client) 拦下用户，向用户要求摩天轮的 (ST) 票据，用户说用户只有一个门卡 (TGT), 那用户只要把 TGT 放在一旁的票据受权机 (TGS) 上刷一下。

票据受权机 (TGS) 就根据用户如今所在的摩天轮，给用户一张摩天轮的票据 (ST), 这样用户有了摩天轮的票据，如今用户能够畅通无阻的进入摩天轮里游玩了。

固然若是用户玩完摩天轮后，想去游乐园的咖啡厅休息下，那用户同样只要带着那张门卡 (TGT). 到相应的咖啡厅的票据受权机 (TGS) 刷一下，获得咖啡厅的票据 (ST) 就能够进入咖啡厅

当用户离开游乐场后，想用这张 TGT 去刷打的回家的费用，对不起，用户的 TGT 已通过期了，在用户离开游乐场那刻开始，用户的 TGT 就已经销毁了。

3. CAS的实现原理

因为CAS是基于Cookie的服务，因此它使用了Spring CookieGenerator来生成相应Cookie，下面的代码段摘自与CAS服务器的WEB-INF/中的cas-server.xml配置文件。

<bean id="ticketGrantingTicketCookieGenerator"
              class="org.springframework.web.util.CookieGenerator">
              <property name="cookieSecure" value="true" />
              <property name="cookieMaxAge" value="-1" />
              <property name="cookieName" value="CASTGC" />
              <property name="cookiePath" value="/cas" />
       </bean>

一旦用户登陆到CAS服务器后，能够借助于URL为/cas/logout的地址退出，而且这种logout结果将致使浏览器中已存储的Cookie被销毁掉，即销毁CAS与当前用户间已创建的信任关系（Web SSO会话）。

1. AuthenticationHandler认证处理器

浏览项目的web.xml，能够发现以下内容：

<context-param>
              <param-name>contextConfigLocation</param-name>
              <param-value>
                     /WEB-INF/applicationContext.xml,
                     /WEB-INF/deployerConfigContext-acegi.xml
              </param-value>
       </context-param>
       <listener>
              <listener-class>
                     org.jasig.cas.web.init.SafeContextLoaderListener
              </listener-class>
       </listener>

SafeContextLoaderListener实现了SafeContextListener，它借助于ContextLoader -Listener装载Spring DI容器。这样作的缘由是由于Spring在经过ContextLoaderLitener启动时可能出现异常，形成整个CAS不能正常启动，通过SafeContextLoaderListener，则在异常发生时，CAS服务器也能够启动。

在deployerConfigContext.xml中，能够看到只定义了一个Bean：

<beans>
       <bean id="authenticationManager"
              class="org.jasig.cas.authentication.AuthenticationManagerImpl">
              <property name="credentialsToPrincipalResolvers">
                     <list>
                            <bean class="org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver" />
                            <bean class="org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver" />
                     </list>
              </property>
              <property name="authenticationHandlers">
                     <list>
                            <bean class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler" />
                            <bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" />
                     </list>
              </property>
       </bean>
</beans>

SimpleTestUsernamePasswordAuthenticationHandler的做用是若是用户名与密码输入同样，则经过系统认证。这个是开发过程当中经常使用的一个handler，可是在开发完毕后应该除去。

AuthenticationManagerImpl负责认证用户，好比一个admin/admin用户是否合法就是它来验证的。AuthenticationManagerImpl对象会借助于他引用的credentialsToPr -incipalResolvers和authenticationHandlers集合完成用户的认证工做。Authentication -Handlers负责完成用户认证，而credentialsToPrincipalResolvers负责构建认证结果。其中，并非authenticationHandlers的所有集合都参与到用户认证中，一旦某个AuthenticationHandler成功完成用户的认证，则认证进程就到此为止，进而转到credenti -alsToPrincipalResolvers来构建认证结果。credentialsToPrincipalResolvers的过程也相似于此。

2. CAS的时序图

（转）