JA-SIG（CAS）学习札记【转帖】

JA-SIG（CAS）学习笔记【转帖】

STEP 1，搭建Java Web服务器环境
安装 JDK + Tomcat 6.0.14 ， HTTP端口8080 ， HTTPS端口8443
JAVA_HOME = D:/Java/jdk1.6.0_04
CATALINA_HOME = D:/Java/apache-tomcat-6.0.14
安装完毕，启动Tomcat ，在浏览器上 测试 http://Linly:8080/

出现上述界面，表明系统STEP1成功搭建。

STEP 2，使用Java Keytool工具为系统生成HTTPS证书，并为系统注册
（Java Keytool相关资料可参阅：Java keytool 安全证书学习笔记）， 在DOS窗体运行以下指令（建议编写一个BAT批处理文件执行）

cls
rem please set the env JAVA_HOME before run this bat file
rem delete alia tomcat if it is existed
keytool -delete -alias tomcatsso -keystore %JAVA_HOME%/jre/lib/security/cacerts -storepass changeit
keytool -delete -alias tomcatsso -storepass changeit
（注释： 清除系统中可能存在的名字为tomcatsso 的同名证书）
rem list all alias in the cacerts
keytool -list -keystore %JAVA_HOME%/jre/lib/security/cacerts -storepass changeit
（注释： 列出系统证书仓库中存在证书名称列表）
rem generator a key
keytool -genkey -keyalg RSA -alias tomcatsso -dname "cn=linly" -storepass changeit
（注释：指定使用RSA算法，生成别名为tomcatsso的证书，存贮口令为changeit，证书的DN为"cn=linly" ，这个DN必须同当前主机完整名称一致哦，切记！！！）rem export the key
keytool -export -alias tomcatsso -file %java_home%/jre/lib/security/tomcatsso.crt -storepass changeit
（注释： 从keystore中导出别名为tomcatsso的证书，生成文件tomcatsso.crt）rem import into trust cacerts
keytool -import -alias tomcatsso -file %java_home%/jre/lib/security/tomcatsso.crt -keystore %java_home%/jre/lib/security/cacerts -storepass changeit
（注释：将tomcatsso.crt导入jre的可信任证书仓库。注意，安装JDK是有两个jre目录，一个在jdk底下，一个是独立的jre，这里的目录必须同Tomcat使用的jre目录一致，否则后面Tomcat的HTTPS通讯就找不到证书了）
rem list all alias in the cacerts
keytool -list -keystore %JAVA_HOME%/jre/lib/security/cacerts -storepass changeit
（注释：列出jre可信任证书仓库中证书名单，验证先前的导入是否成功，如果导入成功，应该在列表中能找到tomcatsso这个别名，如下图）[/quote]

同时，在D:/Java/jdk1.6.0_04/jre/lib/security目录下能找到“tomcatsso.crt”这个文件；在C:/Documents and Settings/Linly目录下能找到“.keystore”文件。
满足上述条件则STEP2部署完成。

STEP 3，配置Tomcat的HTTPS服务
编辑D:/Java/apache-tomcat-6.0.14/conf下的server.xml文件，在connector的配置位置添加以下的配置：

?????????? port="8443" minSpareThreads="5" maxSpareThreads="75"
?????????? enableLookups="true" disableUploadTimeout="true"
?????????? acceptCount="100"? maxThreads="200"
?????????? scheme="https" secure="true" SSLEnabled="true"
?????????? keystoreFile="C:/Documents and Settings/new/.keystore" keystorePass="changeit"
?????????? truststoreFile="D:/Java/jdk1.6.0_04/jre/lib/security/cacerts"
?????????? clientAuth="false" sslProtocol="TLS"/>

启动Tomcat，访问https://linly:8443/，出现以下界面说明HTTPS配置生效：


STEP 4，为HelloWorldExample程序配置CAS过滤器
访问http://linly:8080/examples/servlets/servlet/HelloWorldExample，出现以下界面说明应用正常启动：

编辑D:/Java/apache-tomcat-6.0.14/webapps/examples/WEB-INF下的web.xml文件，添加如下信息：

输入用户名/密码 ：linly/linly（任意两个相同的字窜），点击“登录”，出现以下画面：

表示CAS服务器配置运行成功。


STEP 6，测试JA-SIG（CAS）部署结果
启动Tomcat。
测试使用浏览器登陆以下网址：http://linly:8080/examples/servlets/servlet/HelloWorldExample，页面将弹出以下认证框，点击“确定”


页面将重定向到JA-SIG的SSO登录认证页面



输入用户名=密码，如：linly/linly，则通过验证，进入应用的入口界面，如下：


细心的用户将发现，此时的URL不再是：
http://linly:8080/examples/servlets/servlet/HelloWorldExample，
URL的尾端带上了一个ticket参数：
http://linly:8080/examples/servlets/servlet/HelloWorldExample?ticket=ST-2-qTcfDrdFb0bWndWgaqZD
到此，JA-SIG（CAS）服务器的初步SSO部署宣告成功。

使用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平台的服务端和客户端的编程与应用定制等相关内容的进行介绍。

<beans xmlns="http://www.springframework.org/schema/beans"
?????? xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
?????? xmlns:p="http://www.springframework.org/schema/p"
?????? xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

<bean id="authenticationManager"
? p:httpClient-ref="httpClient" />
??????? <!—下面就是系统默认的验证器配置，你可以替换它，或者增加一个新的handler -->
??? <bean???? />
?? </list>
? </property>
</bean>
。。。
。。。
</beans>

我们发现authenticationHandlers属性是一个list，在这个list中可以配置多个AuthenticationHandlers。这些AuthenticationHandlers形成了一个验证器链，所有提交给CAS的Credentials信息将通过这个验证器链的链式过滤，只要这链中有一个验证器通过了对Credentials的验证，就认为这个Credentials是合法的。这样的设计使得我们可以很轻松的整合不同验证体系的已有应用到同一个CAS上，比如：A验证器负责校验alpha系统提交的Credentials，它是基于LDAP服务器的；B验证器负责校验beta系统提交的Credentials，它是一个传统的RDB用户表认证；C验证器负责校验gamma系统提交的基于RSA证书加密的Credentials。3种完全不同的用户身份认证通过配置就可以统一在同一个CAS服务内，很好很强大，不是吗！！

定制身份验证登录界面
????? CAS Server在显示界面层view使用了“主题Theme”的概念。在{project.home}/webapp/WEB-INF/view/jsp/目录下，系统默认提供了两套得UI —— default和simple 。default方案使用了CSS等相对复杂得界面元素，而simple方案提供了最简化的界面表示方式。在整个的CAS Server服务器端，有四个界面是我们必须要实现的：
??? casConfirmView.jsp —— 确认信息（警告信息）页面
??? casGenericSuccess.jsp —— 登陆成功提示页面
??? casLoginView.jsp —— 登录输入页面
??? casLogoutView.jsp —— SSO登出提示页面
这些都是标准的jsp页面，如何实现他们，完全由您说了算，除了名字不能改。

CAS为view的展示提供了3个级别的定制方式，让我们从最直观简单的开始吧。

1． 采用文件覆盖方式：直接修改default中的页面或者将新写好的四个jsp文件覆盖到default目录中。这种方式最直观和简单，但咖啡建议各位在使用这种方式前将原有目录中的文件备份一下，以备不时之需。

2． 修改UI配置文件，定位UI目录：在CAS Server端/webapp/WEB-INF/classes/ 目录下，有一个名为default_views.properties的属性配置文件，你可以通过修改配置文件中的各个页面文件位置，指向你新UI文件，来达到修改页面展示的目的。

3． 修改配置文件的配置文件，这话看起来有点别扭，其实一点不难理解。在方法2中的default_views.properties文件是一整套的UI页面配置。如果我想保存多套的UI页面配置就可以写多个的properties文件来保存这些配置。在CAS Server端/webapp/WEB-INF/目录下有cas-servlet.xml和cas.properties两个文件，cas-servlet.xml使用了cas.properties文件中的cas.viewResolver.basename属性来定义view属性文件的名字，因此你可以选者直接修改cas-servlet.xml中的viewResolver 下的basenames属性，或者修改cas.properties中的cas.viewResolver.basename属性，指定新的properties文件名，这样可以轻松的替换全套UI。

CAS客户端配置及API应用
CASFilter的配置
???? 对于大部分web应用而言，使用CAS集成统一认证是相对简单的事，只要为需要认证的URL配置edu.yale.its.tp.cas.client.filter.CASFilter认证过滤器。下面我们就针对过滤器的配置进行说明。首先参看一下Filter的基本配置：


ProxyTicketReceptor的配置
??? 大家还记得在前面我们说过的Proxy Authentication中的call back URL吗？ProxyTicketReceptor是部署在client端的一个servlet，提供server端回传PGT和PGTIOU的。它的xml部署如下：

import edu.yale.its.tp.cas.client.*; ... String user = null; String errorCode = null; String errorMessage = null; String xmlResponse = null; List proxyList = null; /* instantiate a new ProxyTicketValidator */ ProxyTicketValidator pv = new ProxyTicketValidator(); /* set its parameters */ pv.setCasValidateUrl("https://secure.its.yale.edu/cas/proxyValidate"); pv.setService(urlOfThisService); pv.setServiceTicket(request.getParameter("ticket")); String urlOfProxyCallbackServlet = "https://portal.yale.edu/CasProxyServlet"; pv.setProxyCallbackUrl(urlOfProxyCallbackServlet); /* contact CAS and validate */ pv.validate(); /* if we want to look at the raw response, we can use getResponse() */ xmlResponse = pv.getResponse(); /* read the response */ if(pv.isAuthenticationSuccesful()) { user = pv.getUser(); proxyList = pv.getProxyList(); } else { errorCode = pv.getErrorCode(); errorMessage = pv.getErrorMessage(); /* handle the error */ } /* The user is now authenticated. */ /* If we did set the proxy callback url, we can get proxy tickets with this method call: */ String urlOfTargetService = "http://hkg2.its.yale.edu/someApp/portalFeed"; String proxyTicket = ProxyTicketReceptor.getProxyTicket( pv.getPgtIou() , urlOfTargetService);

在这里，我们假设上下文环境中的用户已经通过了CAS登录认证，被重定向到当前的servlet下，我们在servlet中获取ticket凭证，servlet的URL对用户身份进行确认。如果上下文参数中无法获取ticket凭证，我们就认为用户尚未登录，那么，该servlet必须负责将用户重定向到CAS的登录页面去。

初战告捷
????? 到今天为止，我们已经通过JA-SIG学习笔记的1-3部分，对CAS这个开源SSO的框架有了个大体的了解和初步的掌握，希望这些知识能为各位步入CAS殿堂打开一扇的大门。咖啡希望在今后的工作应用中，能同大家一块共同探讨，进一步深入了解CAS。

查看更多 下一篇