- 浏览: 1012968 次
- 性别:
- 来自: 福州
最新评论
-
guanxin2012:
大神,您好。非常感谢您贡献了IKExpression。我们现在 ...
分享开源表达式解析器IK-Expression2.0 -
qqgigas:
LZ,public boolean createUser(LD ...
Sun Directory Server/LDAP学习笔记(二)——API说明及代码样例 -
gao_shengxian:
Hibernate: update T_GX_TEST set ...
优雅Java编程 之 使用Hibernate存储Oracle Spatial对象 -
a78113534:
感谢大神,在安卓里面调用成功了。
发布IK Expression开源表达式解析器 V2.1.0 -
majiedota:
加油
来自开源支持者的第一笔捐赠
技术背景知识:
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。
学无止境。。。。。。
这个我就不懂了,俺是java only哈! 微软的方案在不少企业听说过,主要使用Windows domain机制,用AD做LDAP,全域穿透的方案,具体的就要问微软了
当未授权用户访问受保护的资源时,web应用需要首先重定向到cas请求验证;cas会检查此用户cookie是否存有ticket,如果没有,则显示登录表单要求登录,如果有则会将此ticket传回给web应用;一般情况下,web应用获知此ticket后应再向cas请求验证此ticket是否有效,如果有效,cas会同时返回用户的一些其他属性,如用户名,web应用可据此用户名在自身系统中为此用户建立授权session。因为session已经建立,那么之后的活动便与一般的情形一样了。
所以,各web应用的权限管理机制仍然是必要的,剥离出去的仅仅是用户认证。
但有时候,我们面对的用户可能存在bs cs系统间的切换~
这样不知道大家怎么处理?
个人以为CS和BS间做统一账户是有可能的,但要做SSO,不太现实,除非你用微软的全套,那个完全是嵌入在操作系统级别上的安全机制了
当未授权用户访问受保护的资源时,web应用需要首先重定向到cas请求验证;cas会检查此用户cookie是否存有ticket,如果没有,则显示登录表单要求登录,如果有则会将此ticket传回给web应用;一般情况下,web应用获知此ticket后应再向cas请求验证此ticket是否有效,如果有效,cas会同时返回用户的一些其他属性,如用户名,web应用可据此用户名在自身系统中为此用户建立授权session。因为session已经建立,那么之后的活动便与一般的情形一样了。
所以,各web应用的权限管理机制仍然是必要的,剥离出去的仅仅是用户认证。
但有时候,我们面对的用户可能存在bs cs系统间的切换~
这样不知道大家怎么处理?
通过client filter。
zhouzhengbj 写道
楼主好,请问cas获得proxyticket有没有实例?在jsp页面可以获得proxyticket吗?本人没有自己实践过代理,但从cas的文档上看,proxyticket是应用客户端通过pgt向服务器请求的,得到proxyticket后,通过后端代码去发起代理请求的。proxyticket与浏览器没有直接的关联。
谢谢楼主了 我的cas是根据你这篇文章搭起来的
楼主好,请问cas获得proxyticket有没有实例?在jsp页面可以获得proxyticket吗?
本人没有自己实践过代理,但从cas的文档上看,proxyticket是应用客户端通过pgt向服务器请求的,得到proxyticket后,通过后端代码去发起代理请求的。proxyticket与浏览器没有直接的关联。
不知道cas能不能实现不同域名下的应用之间的集中登录?
是可以的。CAS的认证与域名无关的。
当未授权用户访问受保护的资源时,web应用需要首先重定向到cas请求验证;cas会检查此用户cookie是否存有ticket,如果没有,则显示登录表单要求登录,如果有则会将此ticket传回给web应用;一般情况下,web应用获知此ticket后应再向cas请求验证此ticket是否有效,如果有效,cas会同时返回用户的一些其他属性,如用户名,web应用可据此用户名在自身系统中为此用户建立授权session。因为session已经建立,那么之后的活动便与一般的情形一样了。
所以,各web应用的权限管理机制仍然是必要的,剥离出去的仅仅是用户认证。
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); }
这里我们要说明一下Credentials这个CAS的概念。所谓Credentials是由外界提供给CAS来证明自身身份的信息,简单的如一个用户名/密码对就是一个Credentials,或者一个经过某种加密算法生成的密文证书也可以是一个Credentials。在程序的实现上,Credentials被声明为一个可序列化的接口,仅仅起着标识作用,源代码如下:
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(); } }
很简单不是吗?就是存储一个用户名和密码的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); } }
介绍到这里,大家应该清楚如何定制自己的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);
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);
在这里,我们假设上下文环境中的用户已经通过了CAS登录认证,被重定向到当前的servlet下,我们在servlet中获取ticket凭证,servlet的URL对用户身份进行确认。如果上下文参数中无法获取ticket凭证,我们就认为用户尚未登录,那么,该servlet必须负责将用户重定向到CAS的登录页面去。
初战告捷
到今天为止,我们已经通过JA-SIG学习笔记的1-3部分,对CAS这个开源SSO的框架有了个大体的了解和初步的掌握,希望这些知识能为各位步入CAS殿堂打开一扇的大门。咖啡希望在今后的工作应用中,能同大家一块共同探讨,进一步深入了解CAS。
学无止境。。。。。。
评论
27 楼
zzzczx
2013-09-03
目前最新版本的CAS没有手工编码使用CAS Java Object进行用户验证,使用ServiceTicketValidator或者 ProxyTicketValidator(代理认证模式下),在servlet中对用户身份进行验证。
这些类都没有该怎么办
这些类都没有该怎么办
26 楼
linliangyi2007
2009-02-24
Devin.Chenzx 写道
很想听听你所说的微软全套的解决方案
呵呵
呵呵
这个我就不懂了,俺是java only哈! 微软的方案在不少企业听说过,主要使用Windows domain机制,用AD做LDAP,全域穿透的方案,具体的就要问微软了
25 楼
Devin.Chenzx
2009-02-24
很想听听你所说的微软全套的解决方案
呵呵
呵呵
24 楼
linliangyi2007
2009-02-24
Devin.Chenzx 写道
drliujia 写道
lynxpengpeng 写道
我想请教一个问题。用cas配置成功之后,系统的授权工作怎么做啊?没有cas之前,原系统登录后会在session 里存用户信息之类的,然后通过session 的内容判断权限,是不是有了cas之后,原系统的登录机制没用了,原系统的权限认证和管理就不用了。谢谢,疑惑中。。
当未授权用户访问受保护的资源时,web应用需要首先重定向到cas请求验证;cas会检查此用户cookie是否存有ticket,如果没有,则显示登录表单要求登录,如果有则会将此ticket传回给web应用;一般情况下,web应用获知此ticket后应再向cas请求验证此ticket是否有效,如果有效,cas会同时返回用户的一些其他属性,如用户名,web应用可据此用户名在自身系统中为此用户建立授权session。因为session已经建立,那么之后的活动便与一般的情形一样了。
所以,各web应用的权限管理机制仍然是必要的,剥离出去的仅仅是用户认证。
但有时候,我们面对的用户可能存在bs cs系统间的切换~
这样不知道大家怎么处理?
个人以为CS和BS间做统一账户是有可能的,但要做SSO,不太现实,除非你用微软的全套,那个完全是嵌入在操作系统级别上的安全机制了
23 楼
Devin.Chenzx
2009-02-24
drliujia 写道
lynxpengpeng 写道
我想请教一个问题。用cas配置成功之后,系统的授权工作怎么做啊?没有cas之前,原系统登录后会在session 里存用户信息之类的,然后通过session 的内容判断权限,是不是有了cas之后,原系统的登录机制没用了,原系统的权限认证和管理就不用了。谢谢,疑惑中。。
当未授权用户访问受保护的资源时,web应用需要首先重定向到cas请求验证;cas会检查此用户cookie是否存有ticket,如果没有,则显示登录表单要求登录,如果有则会将此ticket传回给web应用;一般情况下,web应用获知此ticket后应再向cas请求验证此ticket是否有效,如果有效,cas会同时返回用户的一些其他属性,如用户名,web应用可据此用户名在自身系统中为此用户建立授权session。因为session已经建立,那么之后的活动便与一般的情形一样了。
所以,各web应用的权限管理机制仍然是必要的,剥离出去的仅仅是用户认证。
但有时候,我们面对的用户可能存在bs cs系统间的切换~
这样不知道大家怎么处理?
22 楼
寒海芊
2009-02-24
楼主,你好,我是刚开始学习CAS的小菜鸟,想请教一下,现在我有两个应用A和B,同一个人在这两个应用中的用户名和密码可能不同,需要在A中调用B,也就是应用代理模式,此时该如何配置CAS,身份验证的机制又是如何的呢?
谢谢!
谢谢!
21 楼
clasp
2009-02-19
在于CAS代理PGT的传递大家有什么好的办法?
如我某台机用IE登录了系统,哪么我这台机的的其它应用(可能是桌面应用)都不用再登录了。我想到两种方案:
1.IP与PGT对应存在CAS服务上,再通过webservice什么的把本机IP传到服务器去验证,感觉不太安全,
2.通过IE插件进行应用之间的调用(特别是桌面应用)把PGT传到目标应用中去
大家还有别的方案没,
如我某台机用IE登录了系统,哪么我这台机的的其它应用(可能是桌面应用)都不用再登录了。我想到两种方案:
1.IP与PGT对应存在CAS服务上,再通过webservice什么的把本机IP传到服务器去验证,感觉不太安全,
2.通过IE插件进行应用之间的调用(特别是桌面应用)把PGT传到目标应用中去
大家还有别的方案没,
20 楼
bonny
2009-02-17
liuho 写道
目前一个平台有自己的登陆页面,并且这个页面是不能更改的,不知道在这种情况下怎么将CAS的登陆与这个页面联系起来
通过client filter。
19 楼
zhouzhengbj
2009-02-17
linliangyi2007 写道
zhouzhengbj 写道
楼主好,请问cas获得proxyticket有没有实例?在jsp页面可以获得proxyticket吗?本人没有自己实践过代理,但从cas的文档上看,proxyticket是应用客户端通过pgt向服务器请求的,得到proxyticket后,通过后端代码去发起代理请求的。proxyticket与浏览器没有直接的关联。
谢谢楼主了 我的cas是根据你这篇文章搭起来的
18 楼
linliangyi2007
2009-02-10
zhouzhengbj 写道
楼主好,请问cas获得proxyticket有没有实例?在jsp页面可以获得proxyticket吗?
本人没有自己实践过代理,但从cas的文档上看,proxyticket是应用客户端通过pgt向服务器请求的,得到proxyticket后,通过后端代码去发起代理请求的。proxyticket与浏览器没有直接的关联。
17 楼
zhouzhengbj
2009-02-10
楼主好,请问cas获得proxyticket有没有实例?在jsp页面可以获得proxyticket吗?
16 楼
linliangyi2007
2008-12-15
junphine 写道
不知道cas能不能实现不同域名下的应用之间的集中登录?
是可以的。CAS的认证与域名无关的。
15 楼
junphine
2008-12-15
不知道cas能不能实现不同域名下的应用之间的集中登录?
14 楼
skyhits1921
2008-11-27
有没有写好的web应用让我参考一下呀.
13 楼
skyhits1921
2008-11-27
怎么我配置好了后,我打开客户端的页面后,然后页面重定向到cas服务器验证页面,我输入用户名和密码后,然后点击登陆,停了一会后,页面显示:Internet Explorer 无法显示该网页.这是什么问题呀.
12 楼
xzs603
2008-10-13
从上次的重阳吃菜到每次baidu搜到你。
发现你还真是javaeye到大红人~
发现你还真是javaeye到大红人~
11 楼
drliujia
2008-10-07
lynxpengpeng 写道
我想请教一个问题。用cas配置成功之后,系统的授权工作怎么做啊?没有cas之前,原系统登录后会在session 里存用户信息之类的,然后通过session 的内容判断权限,是不是有了cas之后,原系统的登录机制没用了,原系统的权限认证和管理就不用了。谢谢,疑惑中。。
当未授权用户访问受保护的资源时,web应用需要首先重定向到cas请求验证;cas会检查此用户cookie是否存有ticket,如果没有,则显示登录表单要求登录,如果有则会将此ticket传回给web应用;一般情况下,web应用获知此ticket后应再向cas请求验证此ticket是否有效,如果有效,cas会同时返回用户的一些其他属性,如用户名,web应用可据此用户名在自身系统中为此用户建立授权session。因为session已经建立,那么之后的活动便与一般的情形一样了。
所以,各web应用的权限管理机制仍然是必要的,剥离出去的仅仅是用户认证。
10 楼
lynxpengpeng
2008-10-07
我想请教一个问题。用cas配置成功之后,系统的授权工作怎么做啊?没有cas之前,原系统登录后会在session 里存用户信息之类的,然后通过session 的内容判断权限,是不是有了cas之后,原系统的登录机制没用了,原系统的权限认证和管理就不用了。谢谢,疑惑中。。
9 楼
liuho
2008-05-08
目前一个平台有自己的登陆页面,并且这个页面是不能更改的,不知道在这种情况下怎么将CAS的登陆与这个页面联系起来
8 楼
tooor
2008-05-07
请教楼主:
我已经搭建了sso的环境并调试通过.现在要在验证通过并转入应用系统后记录用户名并在应用系统建立session,比如用户每登陆一次该应用系统就增加100点积分.
请问如何在验证通过后把用户名传递给应用系统?
我已经搭建了sso的环境并调试通过.现在要在验证通过并转入应用系统后记录用户名并在应用系统建立session,比如用户每登陆一次该应用系统就增加100点积分.
请问如何在验证通过后把用户名传递给应用系统?
发表评论
-
来自开源支持者的第一笔捐赠
2013-01-09 21:15 57812013年1月9号,一个平凡而又不平常的日子! IK中文分词 ... -
发布 IK Analyzer 2012 FF 版本
2012-10-23 17:50 25081首先感谢大家对IK分词器的关注。 最近一段时间正式公司事务最 ... -
发布 IK Analyzer 2012 版本
2012-03-08 11:23 36176新版本改进: 支持分词歧义处理 支持数量词合并 词典支持中英 ... -
CSDN发生严重用户账号泄密事件
2011-12-21 19:21 2566之前有在CSDN注册过的兄弟们,注意了。。。 如果你的邮箱, ... -
一个隐形的java int溢出
2011-08-30 09:44 7560故事的背景: 笔者最近在做一个类SNS的项目,其中 ... -
雷军 :互联网创业的葵花宝典
2011-05-04 10:35 3596博主评: 这片博客很短 ... -
Luci-mint站内搜索实测
2011-04-02 16:18 4141关于Luci-mint 服务器硬 ... -
发布 IK Analyzer 3.2.8 for Lucene3.X
2011-03-04 17:49 14254IK Analyzer 3.2.8版本修订 ... -
TIPS - XML CDATA中的非法字符处理
2011-02-17 15:03 3305XML解析过程中,常遇见CDATA中存在非法字符,尤其在火星文 ... -
对Cassandra的初体验
2010-10-13 17:58 9137作为“云计算”时代的架构设计人员而言,不懂K-V库会被 ... -
Spring + iBatis 的多库横向切分简易解决思路
2010-10-11 13:43 93551.引言 笔者最近在做一个互联网的“类SNS”应用,应用 ... -
发布 IK Analyzer 3.2.5 稳定版 for Lucene3.0
2010-09-08 14:43 5823新版本IKAnnlyzer3.2.8已发布! 地址: http ... -
关于Lucene3.0.1 QueryParser的一个错误
2010-05-21 21:33 2129表达式1: 引用 id:"1231231" ... -
发布 IK Analyzer 3.2.3 稳定版 for Lucene3.0
2010-05-15 14:13 6718IK Analyzer 3.2.3版本修订 在3.2.0版 ... -
windows平台上的nginx使用
2010-01-28 17:13 3406转载自:http://nginx.org/en/docs/wi ... -
发布IKAnnlyzer3.2.0稳定版 for Lucene3.0
2009-12-07 09:27 9579最新3.2.5版本已经推出,http://linliangyi ... -
在Tomcat下以JNDI方式发布JbossCache
2009-12-04 10:57 3830前言: 看过JbossCache的开发手册,发现在Jb ... -
Spring AOP小例子
2009-11-16 10:35 3405PS: 要注明一下,这个是转载滴,之前漏了说鸟,汗死 这里给 ... -
ActiveMQ 5.X 与 Tomcat 集成一(JNDI部署)
2009-11-10 15:15 5649原文地址:http://activemq.apache.org ... -
发布IKAnalyzer中文分词器V3.1.6GA
2009-11-08 23:10 11857IKAnalyzer3.2.0稳定版已经发布,支持Lucene ...
相关推荐
JA-SIG CAS是其最初的开发者,它允许用户通过一个统一的登录界面访问多个相互独立的应用系统,从而简化了用户的登录体验。 CAS Server是CAS的核心组件,它负责处理用户的认证请求。在我们讨论的环境中,CAS Server ...
4. **JA-SIG CAS学习笔记**: "JA-SIG(CAS)学习笔记2"和"JA-SIG(CAS)学习笔记3"涵盖了CAS的基本概念、架构和配置,以及如何与Java应用集成。JA-SIG是一个高等教育软件联盟,其文档对于理解CAS的教育背景和应用...
《JA-SIG(CAS)学习笔记3.doc》可能涉及的是CAS的高级特性和扩展。例如,单点登出(Single Sign-Out, SSO)功能,使得用户在一处登出,就能自动从所有关联系统中注销。还有服务管理,可以通过CAS管理界面或API来注册...
具体到本次学习笔记中,可以看到提到了如何使用CAS 3.2.1的版本,并且涉及到整合JA-SIG CAS的开发。文档中提到的步骤包括用户从客户端访问服务,服务重定向到CAS服务器的登录界面,用户在CAS服务器登录后获得票据,...
CAS(Central Authentication Service)是基于Java的开源SSO协议实现,由JA-SIG组织开发,旨在简化Web应用的认证流程。 CAS的核心设计愿景是提供一个统一的认证入口点,使得所有应用系统可以通过这个中心服务验证...
【基于Struts的图书信息管理系统设计实现分析】 ...[5] JA-SIG(CAS)学习笔记[EB/OL]. .java 本系统设计充分考虑了实际操作的便捷性和系统的可扩展性,为其他类似信息管理系统的开发提供了参考。