JA-SIG（CAS）学习笔记2

背景知识： 
什么是SSO（Single Sign On）单点登陆： 
所谓单点登陆是指基于用户/会话认证的一个过程，用户只需一次性提供凭证（仅一次登陆），就能够访问多个应用。 
目前单点登陆主要基于Web的多种应用程序，即经过浏览器实现对多个B/S架构应用的统一帐户认证。 

JA-SIG（CAS）的设计愿景： 
简单的说，CAS（Central Authentication Service – 中心认证服务）的目的就是使分布在一个企业内部各个不一样异构系统的认证工做集中在一块儿，经过一个公用的认证系通通一管理和验证用户的身份。在CAS上认证的用户将得到CAS颁发的一个证书，使用这个证书，用户能够在认可CAS证书的各个系统上自由穿梭访问，不须要再次的登陆认证。打个比方：对于加入欧盟的国家而言，在他们国家中的公民能够凭借着本身的身份证，在整个欧洲旅行，不用签证。对于企业内部系统而言，CAS就是这个颁发欧盟认证的系统，其它系统都是加入欧盟的国家，它们要共同遵照和认可CAS的认证规则。 
所以CAS的设计愿景就是： 
1。实现一个易用的、能跨不一样Web应用的单点登陆认证中心； 
2。实现统一的用户身份和密钥管理，减小多套密码系统形成的管理成本和安全漏洞； 
3。下降认证模块在IT系统设计中的耦合度，提供更好的SOA设计和更弹性的安全策略 

CAS1.0服务架构实现： 
传统的用户认证流程 
咱们以A公司的员工日志管理系统为例，以下图： 

使用CAS后的用户认证流程

示意图中，CAS相关部分被标示为蓝色。在这个流程中，员工AT向日志系统请求进入主页面，他的浏览器发出的HTTP请求被嵌入在日志系统中的CAS客户端（HTTP过滤器）拦截，并判断该请求是否带有CAS的证书；若是没有，员工AT将被定位到CAS的统一用户登陆界面进行登陆认证，成功后，CAS将自动引导AT返回日志系统的主页面。 


CAS的程序逻辑实现 
要完成上述的认证业务，CAS须要一个认证中心服务器CAS -Server和嵌入在不一样业务系统方的认证客户端CAS-Client的协同。 

在CAS1.0协议中，CAS-Server提供的三个验证服务接口（web服务URL）： 
1. 用户登陆URL，形如 https://casserver/cas/servlet/login 
2. 用户凭证校验URL，形如 https://casserver/cas/servlet/validate 
3. 用户登出URL，形如 https://casserver/cas/servlet/logout 

在CAS-Client端，CAS提供了多样化的语言支持，其中用于java的是一个casclient.jar包。目前的版本为2.1.1，其中提供了三种形式的凭证校验： 
1. 用于Java Servlets的Filter — edu.yale.its.tp.cas.client.filter.CASFilter 
2. 用于JSP页面的CAS Tag Library 
3. 通用Java API Object — ServiceTicketValidator / ProxyTicketValidator 

一般，企业应用程序基于浏览器的B/S模式，这种状况下，系统的用户凭证（一个由CAS服务器生成的惟一 id号，也称之为ticket）借助cookie和URL参数方式实现；在B/S环境中，大多状况下，咱们只须要配置CAS Filter或者使用CAS Tag Library就能够轻松实现的验证客户端。 
若是应用是以普通的C/S模式运行，则须要应用程序本身来维护这个ticket在上下文环境中的传输和保存了。这时候就须要手工调用ServiceTicketValidator / ProxyTicketValidator对象的方法，向CAS 服务器提交认证，并获取认证结果进行相应的处理。 


CAS服务的具体实现 
环境假设：用户User要访问业务系统Biz；Biz系统部署在bizserver上；CAS的系统搭建在服务器casserver上。

图例说明： 
Step1: 用户第一次访问Biz系统主页http://bizserver/index.jsp ;部署在Biz系统上的CASFilter发现用户还没有登陆，将用户重定向的CAS登陆界面 https://casserver/cas/servlet/login?service=http://bizserver/index.jsp ，同时在重定向的URL上用service参数将用户的目标地址传给CAS服务器。 

Step2:用户在CAS的登陆页上输入用户名密码登陆，CAS服务器认证经过后，生成一个ticket，并带在目标地址的尾部返回客户端的浏览器redirect：http://bizserver/index.jsp?ticket=casticket. 

Step3:客户端浏览器得到CAS服务器的认证应答，取得凭证ticket后，使用重定向的连接http://bizserver/index.jsp?ticket=casticket访问Biz服务 

Step4: BizServer上的CASFilter再次过滤访问请求，并得到ticket凭证。Filter将使用该凭证经过URL https://casserver/cas/servlet/validate?service= http://bizserver/index.jsp &ticket=casticket 向CAS认证中心确认对应的服务请求和凭证是否有效。根据CAS服务器返回的结果，若是凭证有效，则CASFilter容许用户进入http://bizserver/index.jsp 所指向的页面；不然，再次重定向到https://casserver/cas/servlet/login?service=http://bizserver/index.jsp 上要求用户进行认证。 


CAS2.0服务架构实现： 
CAS2.0的协议主要是针对web应用的SSO功能加强的协议，它在1.0协议基础上扩展了Proxy Authentication（代理认证）能力。那么什么是Proxy Authentication呢？！ 

代理认证Proxy Authentication 
假设有一下这样的应用场景：用户AT早晨来到公司，他的第一件事就是进入公司的Portal系统浏览一天的新咨询，如股票信息、天气状况、业界新闻。他经过CAS的身份认证登陆了门户系统，看到了他订制的信息。以后，他要访问portal中的邮件信息，看看有没有新的邮件。这时候Portal系统必须访问他的IMAP服务器，这须要他的私人密码。咱们知道Portal是经过CAS对AT进行认证的，所以Portal上没有AT的我的密码信息。这时，咱们发现，Portal须要表明AT的身份向IMAP服务器提交身份认证，而这正是Proxy Authentication的做用。 

CAS2.0系统架构中的角色

CAS2.0系统中的用到的凭证（ticket）

以上对于CAS2.0协议中用到的5种ticket的说明，乍看起来也许会让你云里雾里的。不要紧，下面咱们就来详细阐述这5种凭证在实际认证流程中的做用。在阐述具体流程前，咱们要先关注一下2.0协议中对客户端配置的需求. 

CAS2.0的客户端配置 
在2.0协议中，CAS-Server端的配置与1.0基本一致。但在客户端上，多增长了一个call back URL，该URL用来提供server端向client端传输PGT时使用。所以，除了要配置edu.yale.its.tp.cas.client.filter.CASFilter做为认证过滤器外，还要配置edu.yale.its.tp.cas.proxy.ProxyTicketReceptor这个servlet，做为server回传PGT的call back URL，以下：

CAS2.0代理认证流程 
如下的流程图模拟上述的用户AT经过Portal向他的IMAP邮件服务器请求电子邮件的认证过程。在该过程当中，充当Service和Proxy两个角色的Portal使用CAS Filter对访问其自身的用户进行CAS认证；同时Portal要使用ProxyTicketReceptor servlet接收来自CAS server的PGT信息，并使用ProxyTicketValidator对象向CAS获取访问IMAP服务器的Proxy Ticket凭证；最终从IMAP服务器上获取AT用户的mail信息。一样的，这里的IMAP服务器也要接受并承认CAS对其用户的认证管理，同时它本身也成为二级Proxy，在有须要的状况下，同样能够向它的back-end Service发起Proxy Authentication代理认证请求……

其中蓝色线表示HTTP或HTTPS的请求；红色线表示应答；黑色线表示来自CAS server端的回调操做。 

到此，本章节对JA-SIG（CAS）的总体功能和身份认证业务架构进行初步的讲解，在后续的章节中，咱们将对CAS平台的服务端和客户端的编程与应用定制等相关内容的进行介绍。