- 浏览: 432511 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
weishuang:
全部无法访问
ArcGIS 资源 -
04023129:
请问一下怎么配置meetme有硬件要求么?
Asterks(软交换)里配置两部简单的SIP软电话 -
jayli426:
请教:
181 正被转接
202 被接受:用于转介
有 ...
所有已知的SIP处理应答状态码 -
ligg5034:
<ww:if test="sftd.equal ...
webwork<ww:if>标签的使用 -
wanggod:
请问我
return (Hello)super.getPort ...
java6 WebServices客户端
技术背景知识:
JA-SIG CAS服务环境搭建,请参考 :JA-SIG(CAS)学习笔记1
JA-SIG CAS业务架构介绍,请参考 :JA-SIG(CAS)学习笔记2
HTTPS所涉及的Java安全证书知识,请参考 :Java keytool 安全证书学习笔记
CAS技术框架
CAS Server
目前,我们使用的CAS Server 3.1.1的是基于Spring Framework编写的,因此在CAS服务器端的配置管理中,绝大多数是Spring式的Java Bean XML配置。CAS 的服务器提供了一套易于定制的用户认证器接口,用户可以根据自身企业的在线系统的认证方式,来定制自己的认证逻辑。不论是传统的用户名/密码方式,还是基于安全证书的方式;是基于关系数据库的存储,还是采用LDAP服务器,CAS Server给我们提供了这些常用的验证器模板代码,只要稍作修改,便可灵活使用了。
对于广大的中国企业用户而言,另一个需要定制的功能莫过于全中文、企业特色的用户身份认证页面了。CAS Server提供了两套系统界面,一套是默认的CAS英文标准页面,另一套则是专门提供给用户来定制修改的。(PS:老外们做事情就是人性化啊~~)那么对CAS Server端的后续学习,我们将围绕着身份认证模块定制和界面定制这两方面展开。
CAS Client
客户端我们使用的是CAS Client 2.1.1。虽然在官方网站上已出现了3.1.0版本的下载,但该版本地代码已经完全重写,使用的package和类名同2.1.1大相径庭了,最关键的是,该版本暂时没有对应的API说明文档。虽然咖啡我对程序版本怀有极大的“喜新厌旧”的心态,但安全起见,还是先2.1.1吧,相信3.1.0的文档耶鲁大学的大牛们已经在整理了,期待中……
CAS Client2.1.1.jar中的代码是相当精炼的,有兴趣的朋友建议阅读一下源码。Jar包中的代码分成三个大部分
1. edu.yale.its.tp.cas.util 包,其中只有一个工具类 SecureURL.java 用来访问HTTPS URL
2. edu.yale.its.tp.cas.proxy包,用来处理Proxy Authentication代理认证的3个类,其中ProxyTicketReceptor.java是 接收PGT回调的servlet,在下文中我们会提及。
3. edu.yale.its.tp.cas.client包,其中包含了CAS Filter ,Tag Library等主要的认证客户端工具类,我们在后面会进行重点介绍。
针对CAS Client的学习,我们的重点将放在CAS Filter 和ProxyTicketReceptor 的配置以及在Java SE环境下,直接使用 ServiceTicketValidator进行Ticket认证实现上。
CAS服务器端应用
定制适合你的身份认证程序
通过前面的学习,我们了解了CAS具有一个良好而强大的SSO功能框架。接下来,我们要学习如何将实际企业应用中的身份认证同CAS进行整合。
简单的说,要将现有企业应用中的认证集成到CAS Server中,只要实现一个名为AuthenticationHandler的一个认证处理Java接口就行。以下是该接口的源代码:
这里我们要说明一下Credentials这个CAS的概念。所谓Credentials是由外界提供给CAS来证明自身身份的信息,简单的如一个用户名/密码对就是一个Credentials,或者一个经过某种加密算法生成的密文证书也可以是一个Credentials。在程序的实现上,Credentials被声明为一个可序列化的接口,仅仅起着标识作用,源代码如下:
CAS的API中,已经为我们提供了一个最常用的实现UsernamePasswordCredentials 用户名/密码凭证,代码如下:
很简单不是吗?就是存储一个用户名和密码的java bean而已。
接下来,我们将一个Credentials传给一个AuthenticationHandler进行认证,首先调用boolean supports(Credentials credentials)方法察看当前传入的Credentials实例,AuthenticationHandler实例现是否支持它?如果支持,再调用boolean authenticate(Credentials credentials)方法进行认证。由于用户名/密码方式是最常用的认证方法,因此CAS为我们提供了一个现成的基于该方式的抽象认证处理类AbstractUsernamePasswordAuthenticationHandler。通常我们只需要继承该类,并实现其中的 authenticateUsernamePasswordInternal方法即可。下面我们给出一个Demo的实现类,它的校验逻辑很简单——仅校验用户名的字符长度是否与密码的相等(这里密码是一个表示长度的整数),如果相等则认为认证通过,请看代码:
介绍到这里,大家应该清楚如何定制自己的AuthenticationHandler类了吧!这里要附带说明的是,在CAS Server的扩展API中已经提供了大量常用认证形式的实现类,它们同CAS Server的war包一同分发:
cas-server-support-generic-3.1.1.jar ——使用Map记录用户认证信息的实现
cas-server-support-jdbc-3.1.1.jar —— 基于Spring JDBC的数据库实现(我们常用的)
cas-server-support-ldap-3.1.1.jar —— 基于LDAP的用户认证实现
更多其他形式的实现各位看官有兴趣的,可以一一阅读源码。
配置你的身份认证程序
完成了定制认证类的代码编写,接下来就是要让CAS Server来调用它了。在CAS的框架中,对程序的配置都是使用Spring Framework的xml文件,这对于熟悉Spring的程序员而言算驾轻就熟了。
配置文件位于应用部署目录的WEB-INF子目录下——deployerConfigContext.xml。在bean id=authenticationManager 的 authenticationHandlers属性中配置我们的AuthenticationHandlers:
<?xml version="1.0" encoding="UTF-8"?>
<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"
class="org.jasig.cas.authentication.AuthenticationManagerImpl">
。。。
。。。
<property name="authenticationHandlers">
<list>
<bean class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler" p:httpClient-ref="httpClient" />
<!—下面就是系统默认的验证器配置,你可以替换它,或者增加一个新的handler -->
<bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" />
</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的基本配置:
上述配置中的init-param是filter的3个必备的属性,下面这张表则是filter全部属性的详细说明:
ProxyTicketReceptor的配置
大家还记得在前面我们说过的Proxy Authentication中的call back URL吗?ProxyTicketReceptor是部署在client端的一个servlet,提供server端回传PGT和PGTIOU的。它的xml部署如下:
<web-app>
...
<servlet>
<servlet-name>ProxyTicketReceptor</servlet-name>
<servlet-class>edu.yale.its.tp.cas.proxy.ProxyTicketReceptor</servlet-class>
<init-param>
<param-name>edu.yale.its.tp.cas.proxyUrl</param-name>
<param-value>https://secure.its.yale.edu/cas/proxy<;/param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>ProxyTicketReceptor</servlet-name>
<url-pattern>/CasProxyServlet</url-pattern>
</servlet-mapping>
...
</webapp>
这里要说明的是它的参数edu.yale.its.tp.cas.proxyUrl。在服务端通过ProxyTicketReceptor将PGT和PGTIOU传给客户端后,ProxyTicketReceptor在进行Proxy Authentication的过程中需要向服务端请求一个ProxyTicket(PT),这个proxyUrl就是服务端的请求入口了。(关于Proxy Authentication的运作原理,参见JA-SIG(CAS)学习笔记2 )
CAS Client端的API应用1.用户可以通过以下两种方式的任意一种,从JSP或servlet中获取通过认证的用户名:
2.获得更完整的受认证用户信息对象CASReceipt Java Bean,可以使用以下语句的任一:
3.手工编码使用CAS Java Object进行用户验证,使用ServiceTicketValidator或者 ProxyTicketValidator(代理认证模式下),在servlet中对用户身份进行验证。
3-1.ServiceTicketValidator
3-2.ProxyTicketValidator
在这里,我们假设上下文环境中的用户已经通过了CAS登录认证,被重定向到当前的servlet下,我们在servlet中获取ticket凭证,servlet的URL对用户身份进行确认。如果上下文参数中无法获取ticket凭证,我们就认为用户尚未登录,那么,该servlet必须负责将用户重定向到CAS的登录页面去。
初战告捷
到今天为止,我们已经通过JA-SIG学习笔记的1-3部分,对CAS这个开源SSO的框架有了个大体的了解和初步的掌握,希望这些知识能为各位步入CAS殿堂打开一扇的大门。咖啡希望在今后的工作应用中,能同大家一块共同探讨,进一步深入了解CAS。
学无止境。。。。。。
JA-SIG CAS服务环境搭建,请参考 :JA-SIG(CAS)学习笔记1
JA-SIG CAS业务架构介绍,请参考 :JA-SIG(CAS)学习笔记2
HTTPS所涉及的Java安全证书知识,请参考 :Java keytool 安全证书学习笔记
CAS技术框架
CAS Server
目前,我们使用的CAS Server 3.1.1的是基于Spring Framework编写的,因此在CAS服务器端的配置管理中,绝大多数是Spring式的Java Bean XML配置。CAS 的服务器提供了一套易于定制的用户认证器接口,用户可以根据自身企业的在线系统的认证方式,来定制自己的认证逻辑。不论是传统的用户名/密码方式,还是基于安全证书的方式;是基于关系数据库的存储,还是采用LDAP服务器,CAS Server给我们提供了这些常用的验证器模板代码,只要稍作修改,便可灵活使用了。
对于广大的中国企业用户而言,另一个需要定制的功能莫过于全中文、企业特色的用户身份认证页面了。CAS Server提供了两套系统界面,一套是默认的CAS英文标准页面,另一套则是专门提供给用户来定制修改的。(PS:老外们做事情就是人性化啊~~)那么对CAS Server端的后续学习,我们将围绕着身份认证模块定制和界面定制这两方面展开。
CAS Client
客户端我们使用的是CAS Client 2.1.1。虽然在官方网站上已出现了3.1.0版本的下载,但该版本地代码已经完全重写,使用的package和类名同2.1.1大相径庭了,最关键的是,该版本暂时没有对应的API说明文档。虽然咖啡我对程序版本怀有极大的“喜新厌旧”的心态,但安全起见,还是先2.1.1吧,相信3.1.0的文档耶鲁大学的大牛们已经在整理了,期待中……
CAS Client2.1.1.jar中的代码是相当精炼的,有兴趣的朋友建议阅读一下源码。Jar包中的代码分成三个大部分
1. edu.yale.its.tp.cas.util 包,其中只有一个工具类 SecureURL.java 用来访问HTTPS URL
2. edu.yale.its.tp.cas.proxy包,用来处理Proxy Authentication代理认证的3个类,其中ProxyTicketReceptor.java是 接收PGT回调的servlet,在下文中我们会提及。
3. edu.yale.its.tp.cas.client包,其中包含了CAS Filter ,Tag Library等主要的认证客户端工具类,我们在后面会进行重点介绍。
针对CAS Client的学习,我们的重点将放在CAS Filter 和ProxyTicketReceptor 的配置以及在Java SE环境下,直接使用 ServiceTicketValidator进行Ticket认证实现上。
CAS服务器端应用
定制适合你的身份认证程序
通过前面的学习,我们了解了CAS具有一个良好而强大的SSO功能框架。接下来,我们要学习如何将实际企业应用中的身份认证同CAS进行整合。
简单的说,要将现有企业应用中的认证集成到CAS Server中,只要实现一个名为AuthenticationHandler的一个认证处理Java接口就行。以下是该接口的源代码:
- public interface AuthenticationHandler {
- /**
- * 该方法决定一个受支持的credentials是否是可用的,
- * 如果可用,该方法返回true,则说明身份认证通过
- */
- boolean authenticate(Credentials credentials) throws AuthenticationException;
- /**
- * 该方法决定一个credentials是否是当前的handle所支持的
- */
- boolean supports(Credentials credentials);
- }
public interface AuthenticationHandler { /** * 该方法决定一个受支持的credentials是否是可用的, * 如果可用,该方法返回true,则说明身份认证通过 */ boolean authenticate(Credentials credentials) throws AuthenticationException; /** * 该方法决定一个credentials是否是当前的handle所支持的 */ boolean supports(Credentials credentials); }
这里我们要说明一下Credentials这个CAS的概念。所谓Credentials是由外界提供给CAS来证明自身身份的信息,简单的如一个用户名/密码对就是一个Credentials,或者一个经过某种加密算法生成的密文证书也可以是一个Credentials。在程序的实现上,Credentials被声明为一个可序列化的接口,仅仅起着标识作用,源代码如下:
- public interface Credentials extends Serializable {
- // marker interface contains no methods
- }
public interface Credentials extends Serializable { // marker interface contains no methods }
CAS的API中,已经为我们提供了一个最常用的实现UsernamePasswordCredentials 用户名/密码凭证,代码如下:
- public class UsernamePasswordCredentials implements Credentials {
- /** Unique ID for serialization. */
- private static final long serialVersionUID = -8343864967200862794L;
- /** The username. */
- private String username;
- /** The password. */
- private String password;
- public final String getPassword() {
- return this.password;
- }
- public final void setPassword(final String password) {
- this.password = password;
- }
- public final String getUsername() {
- return this.username;
- }
- public final void setUsername(final String userName) {
- this.username = userName;
- }
- public String toString() {
- return this.username;
- }
- public boolean equals(final Object obj) {
- if (obj == null || !obj.getClass().equals(this.getClass())) {
- return false;
- }
- final UsernamePasswordCredentials c = (UsernamePasswordCredentials) obj;
- return this.username.equals(c.getUsername())
- && this.password.equals(c.getPassword());
- }
- public int hashCode() {
- return this.username.hashCode() ^ this.password.hashCode();
- }
- }
public class UsernamePasswordCredentials implements Credentials { /** Unique ID for serialization. */ private static final long serialVersionUID = -8343864967200862794L; /** The username. */ private String username; /** The password. */ private String password; public final String getPassword() { return this.password; } public final void setPassword(final String password) { this.password = password; } public final String getUsername() { return this.username; } public final void setUsername(final String userName) { this.username = userName; } public String toString() { return this.username; } public boolean equals(final Object obj) { if (obj == null || !obj.getClass().equals(this.getClass())) { return false; } final UsernamePasswordCredentials c = (UsernamePasswordCredentials) obj; return this.username.equals(c.getUsername()) && this.password.equals(c.getPassword()); } public int hashCode() { return this.username.hashCode() ^ this.password.hashCode(); } }
很简单不是吗?就是存储一个用户名和密码的java bean而已。
接下来,我们将一个Credentials传给一个AuthenticationHandler进行认证,首先调用boolean supports(Credentials credentials)方法察看当前传入的Credentials实例,AuthenticationHandler实例现是否支持它?如果支持,再调用boolean authenticate(Credentials credentials)方法进行认证。由于用户名/密码方式是最常用的认证方法,因此CAS为我们提供了一个现成的基于该方式的抽象认证处理类AbstractUsernamePasswordAuthenticationHandler。通常我们只需要继承该类,并实现其中的 authenticateUsernamePasswordInternal方法即可。下面我们给出一个Demo的实现类,它的校验逻辑很简单——仅校验用户名的字符长度是否与密码的相等(这里密码是一个表示长度的整数),如果相等则认为认证通过,请看代码:
- public class UsernameLengthAuthnHandler
- extends AbstractUsernamePasswordAuthenticationHandler {
- protected boolean authenticateUsernamePasswordInternal( UsernamePasswordCredentials credentials) throws AuthenticationException {
- /*
- * 这里我们完全可以用自己的认证逻辑代替,比如将用户名/密码传入一个SQL语句
- * 向数据库验证是否有对应的用户账号,这不是我们最经常干的事么?
- * 只需要将下面的程序替换掉就OK了!!So easy,so simple!
- /
- String username = credentials.getUsername();
- String password = credentials.getPassword();
- String correctPassword = Integer.toString(username.length());
- return correctPassword.equals(password);
- }
- }
public class UsernameLengthAuthnHandler extends AbstractUsernamePasswordAuthenticationHandler { protected boolean authenticateUsernamePasswordInternal( UsernamePasswordCredentials credentials) throws AuthenticationException { /* * 这里我们完全可以用自己的认证逻辑代替,比如将用户名/密码传入一个SQL语句 * 向数据库验证是否有对应的用户账号,这不是我们最经常干的事么? * 只需要将下面的程序替换掉就OK了!!So easy,so simple! / String username = credentials.getUsername(); String password = credentials.getPassword(); String correctPassword = Integer.toString(username.length()); return correctPassword.equals(password); } }
介绍到这里,大家应该清楚如何定制自己的AuthenticationHandler类了吧!这里要附带说明的是,在CAS Server的扩展API中已经提供了大量常用认证形式的实现类,它们同CAS Server的war包一同分发:
cas-server-support-generic-3.1.1.jar ——使用Map记录用户认证信息的实现
cas-server-support-jdbc-3.1.1.jar —— 基于Spring JDBC的数据库实现(我们常用的)
cas-server-support-ldap-3.1.1.jar —— 基于LDAP的用户认证实现
更多其他形式的实现各位看官有兴趣的,可以一一阅读源码。
配置你的身份认证程序
完成了定制认证类的代码编写,接下来就是要让CAS Server来调用它了。在CAS的框架中,对程序的配置都是使用Spring Framework的xml文件,这对于熟悉Spring的程序员而言算驾轻就熟了。
配置文件位于应用部署目录的WEB-INF子目录下——deployerConfigContext.xml。在bean id=authenticationManager 的 authenticationHandlers属性中配置我们的AuthenticationHandlers:
引用
<?xml version="1.0" encoding="UTF-8"?>
<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"
class="org.jasig.cas.authentication.AuthenticationManagerImpl">
。。。
。。。
<property name="authenticationHandlers">
<list>
<bean class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler" p:httpClient-ref="httpClient" />
<!—下面就是系统默认的验证器配置,你可以替换它,或者增加一个新的handler -->
<bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" />
</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的基本配置:
引用
<web-app>
...
<filter>
<filter-name>CAS Filter</filter-name>
<filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
<param-value>https://secure.its.yale.edu/cas/login<;/param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
<param-value>https://secure.its.yale.edu/cas/serviceValidate<;/param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
<param-value>your server name and port (e.g., www.yale.edu:8080)</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CAS Filter</filter-name>
<url-pattern>/requires-cas-authetication/*</url-pattern>
</filter-mapping>
...
</web-app>
...
<filter>
<filter-name>CAS Filter</filter-name>
<filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
<param-value>https://secure.its.yale.edu/cas/login<;/param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
<param-value>https://secure.its.yale.edu/cas/serviceValidate<;/param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
<param-value>your server name and port (e.g., www.yale.edu:8080)</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CAS Filter</filter-name>
<url-pattern>/requires-cas-authetication/*</url-pattern>
</filter-mapping>
...
</web-app>
上述配置中的init-param是filter的3个必备的属性,下面这张表则是filter全部属性的详细说明:
ProxyTicketReceptor的配置
大家还记得在前面我们说过的Proxy Authentication中的call back URL吗?ProxyTicketReceptor是部署在client端的一个servlet,提供server端回传PGT和PGTIOU的。它的xml部署如下:
引用
<web-app>
...
<servlet>
<servlet-name>ProxyTicketReceptor</servlet-name>
<servlet-class>edu.yale.its.tp.cas.proxy.ProxyTicketReceptor</servlet-class>
<init-param>
<param-name>edu.yale.its.tp.cas.proxyUrl</param-name>
<param-value>https://secure.its.yale.edu/cas/proxy<;/param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>ProxyTicketReceptor</servlet-name>
<url-pattern>/CasProxyServlet</url-pattern>
</servlet-mapping>
...
</webapp>
这里要说明的是它的参数edu.yale.its.tp.cas.proxyUrl。在服务端通过ProxyTicketReceptor将PGT和PGTIOU传给客户端后,ProxyTicketReceptor在进行Proxy Authentication的过程中需要向服务端请求一个ProxyTicket(PT),这个proxyUrl就是服务端的请求入口了。(关于Proxy Authentication的运作原理,参见JA-SIG(CAS)学习笔记2 )
CAS Client端的API应用1.用户可以通过以下两种方式的任意一种,从JSP或servlet中获取通过认证的用户名:
引用
String username = (String)session.getAttribute(CASFilter.CAS_FILTER_USER);
或者
String username = (String)session.getAttribute("edu.yale.its.tp.cas.client.filter.user");
或者
String username = (String)session.getAttribute("edu.yale.its.tp.cas.client.filter.user");
2.获得更完整的受认证用户信息对象CASReceipt Java Bean,可以使用以下语句的任一:
引用
CASReceipt receipt = (CASReceipt )session.getAttribute(CASFilter.CAS_FILTER_RECEIPT);
或者
CASReceipt receipt = (CASReceipt )session.getAttribute("edu.yale.its.tp.cas.client.filter.receipt");
或者
CASReceipt receipt = (CASReceipt )session.getAttribute("edu.yale.its.tp.cas.client.filter.receipt");
3.手工编码使用CAS Java Object进行用户验证,使用ServiceTicketValidator或者 ProxyTicketValidator(代理认证模式下),在servlet中对用户身份进行验证。
3-1.ServiceTicketValidator
- import edu.yale.its.tp.cas.client.*;
- ...
- String user = null;
- String errorCode = null;
- String errorMessage = null;
- String xmlResponse = null;
- /* instantiate a new ServiceTicketValidator */
- ServiceTicketValidator sv = new ServiceTicketValidator();
- /* set its parameters */
- sv.setCasValidateUrl("https://secure.its.yale.edu/cas/serviceValidate");
- sv.setService(urlOfThisService);
- sv.setServiceTicket(request.getParameter("ticket"));
- String urlOfProxyCallbackServlet = "https://portal.yale.edu/CasProxyServlet";
- sv.setProxyCallbackUrl(urlOfProxyCallbackServlet);
- /* contact CAS and validate */
- sv.validate();
- /* if we want to look at the raw response, we can use getResponse() */
- xmlResponse = sv.getResponse();
- if(sv.isAuthenticationSuccesful()) {
- user = sv.getUser();
- } else {
- errorCode = sv.getErrorCode();
- errorMessage = sv.getErrorMessage();
- }
- /* The user is now authenticated. */
- /* If we did set the proxy callback url, we can get proxy tickets with: */
- String urlOfTargetService = "http://hkg2.its.yale.edu/someApp/portalFeed";
- String proxyTicket = ProxyTicketReceptor.getProxyTicket( sv.getPgtIou() , urlOfTargetService);
import edu.yale.its.tp.cas.client.*; ... String user = null; String errorCode = null; String errorMessage = null; String xmlResponse = null; /* instantiate a new ServiceTicketValidator */ ServiceTicketValidator sv = new ServiceTicketValidator(); /* set its parameters */ sv.setCasValidateUrl("https://secure.its.yale.edu/cas/serviceValidate"); sv.setService(urlOfThisService); sv.setServiceTicket(request.getParameter("ticket")); String urlOfProxyCallbackServlet = "https://portal.yale.edu/CasProxyServlet"; sv.setProxyCallbackUrl(urlOfProxyCallbackServlet); /* contact CAS and validate */ sv.validate(); /* if we want to look at the raw response, we can use getResponse() */ xmlResponse = sv.getResponse(); if(sv.isAuthenticationSuccesful()) { user = sv.getUser(); } else { errorCode = sv.getErrorCode(); errorMessage = sv.getErrorMessage(); } /* The user is now authenticated. */ /* If we did set the proxy callback url, we can get proxy tickets with: */ String urlOfTargetService = "http://hkg2.its.yale.edu/someApp/portalFeed"; String proxyTicket = ProxyTicketReceptor.getProxyTicket( sv.getPgtIou() , urlOfTargetService);
3-2.ProxyTicketValidator
- 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);
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。
学无止境。。。。。。
评论
2 楼
melody404
2008-12-24
那么PT验证通过了又怎么向代理提供数据了?
博主多多指点啊
博主多多指点啊
1 楼
melody404
2008-12-24
请问博主
那个ProxyTicketValidator是不是所谓的service方需要验证的
就是被代理的应用
那个ProxyTicketValidator是不是所谓的service方需要验证的
就是被代理的应用
相关推荐
- **成功登录后**:浏览器 URL 将包含一个 `ticket` 参数,例如:`http://kit-gd:9090/examples/servlets/servlet/HelloWorldExample?ticket=ST-3-btmjOBY2e6RHCHRefJ5u`,证明 CAS 单点登录部署成功。 ### 总结 ...
JA-SIG CAS是其最初的开发者,它允许用户通过一个统一的登录界面访问多个相互独立的应用系统,从而简化了用户的登录体验。 CAS Server是CAS的核心组件,它负责处理用户的认证请求。在我们讨论的环境中,CAS Server ...
- **文档**:JA-SIG CAS项目有详细的官方文档和开发者指南,方便用户学习和实施。 - **社区**:活跃的开发者社区提供技术支持和问题解答。 综上所述,基于Java的JA-SIG CAS系统是一个强大且灵活的单点登录解决...
JA-SIG CAS(Central Authentication Service)是Java社区开发的一个开源SSO解决方案,它提供了一个集中式的认证服务器,可以为各种Web应用程序提供安全的身份验证服务。 CAS的核心功能包括: 1. **身份验证**:...
总之,"基于java的开发源码-单点登录系统 JA-SIG CAS.zip"为开发者提供了深入了解和实践SSO机制的机会,通过对源码的学习,不仅可以掌握SSO的基本原理,还能深入到Java Web开发和安全认证的细节中。这对于提升Java...
在本案例中,我们讨论的是基于Java实现的单点登录系统——JA-SIG CAS。这个系统是开源的,由教育高级网(Ja-Sig)开发,旨在提供一种简单而有效的解决方案,为校园环境或企业环境中的各种应用实现安全的单点登录功能...
通过学习这些文档,你可以深入了解如何在你的Java项目中实施JA-SIG CAS,以构建一个高效、安全的单点登录系统。同时,这些资料也可能涵盖了一些实际案例和常见问题的解决方案,帮助你在实际操作中避免陷阱,提高开发...
JA-SIG CAS(Central Authentication Service)是Java社区开发的一个开源SSO项目,旨在简化Web应用的身份验证过程。 CAS的核心功能包括: 1. **统一认证**:用户只需要一个用户名和密码,就能访问所有集成到CAS的...
开发者可以利用源码中的测试用例和示例来理解和学习如何将CAS集成到自己的应用中,以及如何调试和测试CAS的配置。 这个Java单点登录系统的源码是理解SSO工作原理和实践的好资源,对于Java Web开发者来说,深入研究...
这个压缩包“基于Java的实例源码-单点登录系统 JA-SIG CAS.zip”包含了一个完整的CAS服务器和客户端的源代码,可以帮助开发者理解和学习如何在Java环境中构建和集成单点登录系统。 首先,CAS的核心工作流程包括以下...
《DT-RSI-Sig:MetaTrader 4平台的高级交易指标》 在金融交易领域,技术分析是投资者预测市场走势的重要工具,而MetaTrader 4(MT4)平台则是全球最受欢迎的交易平台之一,它提供了丰富的技术指标供用户进行交易...
- **研究目标**:针对Aigis-sig方案,提出了一种FPGA平台上高效且紧凑的软硬件协同实现方法。 #### 四、关键技术与实现 - **核心工作**:设计了一种专门针对Aigis-sig方案参数选择的多项式运算硬件实现架构。 - **...
免责声明:资料部分来源于合法的互联网渠道收集和整理,部分自己学习积累成果,供大家学习参考与交流。收取的费用仅用于收集和整理资料耗费时间的酬劳。 本人尊重原创作者或出版方,资料版权归原作者或出版方所有,...
《MetaTrader 5脚本——深入理解i-sig指标》 在金融交易领域,MetaTrader 5(MT5)是一款广泛使用的交易平台,它为交易者提供了丰富的技术分析工具和自动化交易功能。本篇文章将深入探讨名为"i-sig"的MetaTrader 5...
3. **指定编码为 utf-8-sig,再存入 csv 文件** 使用 `utf-8-sig` 编码格式可以有效地解决上述问题。`utf-8-sig` 实际上是在 `utf-8` 编码的基础上添加了一个 BOM 标记。这样,无论是在文本编辑器还是 Excel 中...