理解单点登录CAS

SSO的实现机制不尽相同,大体分为Cookie机制和Session机制

Weblogic通过Session共享认证信息。Session是一种服务器端机制,但客户端访问服务器时,服务器为客户端创建一个唯一的SessionId,以使在整个交互工程中始终保持状态,而交互的信息则可由应用自行指定,因此用Session方式实现SSO,不能在多个浏览器之间实现单点登录,但可以跨域。[参考这个:http://lijackly.iteye.com/blog/805779]

WebSphere采用Cookie机制,Cookie是客户端机制,存储的内容包括:名字、值
过期时间、路径和域,路径与域合在一起就构成了Cookie的作用范围,因此用Cookie方式可以实现SSO,但域名必须相同。

单点登录分为“服务器”和“客户端”,应用程序第一次访问认证,会把原来的登录画面屏蔽掉,直接转到单点登录的登录页面,当然也可以自行设计该页面;

[list=1]
[*] 认证通过后,单点登录服务器会和应用程序进行一个比较复杂的交互(某种授权机制),CAS使用的就是所谓的Ticket;
[*] 授权完成后,CAS会把页面重定向,回到Web应用(之前的请求URL会跟在跳转到Cas的后面),这样就完成了成功的登录;
[*] 单点登录服务器会在客户端创建一个Cookie,加密的,其中保存用户登录的信息;
[*] 如果此时用户希望访问其他Web应用程序,首先仍然重定向到CAS服务器。此时CAS服务器不再要求用户输入用户名密码,而是首先自动寻找Cookie,根据Cookie中保存的信息登录,之后,CAS重定向回到要访问的客户端应用程序。
[/list]

这样就实现了单点登录。这种体系中,没有通过http进行密码的传递(有用户名传递),因此十分安全。

CAS被设计成一个独立的Web应用,目前是通过若干个Java Servlets来实现的。CAS必须运行在支持SSL的web服务器上。应用程序(客户端)可以通过三个URL路径来使用CAS(loginURL,validation URL,logout URL)。

要点:
[list=1]
[*] 客户端一开始,通常跳过原来的登录界面,而直接转向CAS自带的登录界面,当然也可以在客户端的主界面上增加一个登录之类的按钮来完成跳转工作;
[*] 如果用户喜欢,也可以手工直接进入CAS的登录界面,先进行登录,再选择登录其他的客户端应用程序(这种方式主要用户测试环境);
[*] CAS的登录界面就是所谓的"主体认证",要求输入用户米密码,和普通的登录界面一样;
[*] 主体认证时,CAS获取用户名和密码,然后通过某种认证机制进行认证,通常是LDAP(NQ是用数据库)
[*] 为了进行以后的单点登录,CAS向浏览器送回一个所谓的"内存Cookie",这种cookie并不是真的保存在内存中,而是浏览器一关闭,cookie就自动过期;
[*] 认证成功后,CAS服务器会创建一个很长的、随机生成的字符串,称为"Ticket",随后,CAS将这个Ticket和成功登录的用户,以及服务联系在一起。这个ticket是一次性使用的一种凭证,只对登陆成功的用户及其服务使用一次。使用后立刻失效;
[*] 主体认证完成后,CAS将用户的浏览器重定向,回到原来的应用;CAS客户端,在从应用程序转向CAS的时候,同时也会记录原始请求的URL,因此CAS知道谁在调用自己。CAS重定向的时候,将ticket作为一个参数传递回去;
例如:
原始应用的网址是http://www.itil.com/,在这个网址上,一开始有如下语句,转向CAS服务器的单点登录页面https://secure.oa.com/cas/login?service=http://www.itil.com/auth.aspx;
CAS完成主体认证后,会使用下面URL进行重定向http://www.itil.com/auth.aspx?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。
收到ticket之后,应用程序需要验证ticket,这是通过将ticket传递给一个校验URL来实现的,由CAS提供。
CAS通过校验路径获得了ticket之后,通过内部的数据库对其进行判断,如有效,则返回一个NetID给应用程序。
随后CAS将ticket作废,并且在客户端留下一个cookie。
以后其他应用程序就使用这个cookie进行认证(通过CAS的客户端),而不再需要输入用户名和密码。



[/list]

在实际使用中:

CAS Server是一个Web应用包,部署成功后,也只是一个缺省的实现,在实际使用的时候,还需要根据实际情况做扩展和定制,最主要的是扩展认证(Authetication)接口和CAS Server的界面

认证方式基于:数据库、XML文件、LDAP Server
CAS中采用哪种方式认证与CAS的基本协议是分开的,可以定制和扩展



参考:https://www.ibm.com/developerworks/cn/opensource/os-cn-cas/?ca=drs-tp1608
扩展基于数据库的认证方式

配置DataStore
在CAS Server 中的 %CATALINA_HOME%/webapps/cas/WEB-INF/deployerConfigContext.xml 添加一个新的bean,记录数据库信息
2 配置AuthenticationHandler
提供3个基于JDBC的AuthenticatonHandler,分别为
1、BindModeSearchDatabaseAuthenticationHandler是用所给的用户名和密码去建立数据库连接,根据连接建立是否成功来判断验证成功与否;
2、QueryDatabaseAuthenticationHandler通过配置一个SQL语句查询出密码,与所给密码匹配;
3、SearchModeSearchDatabaseAuthenticationHandler通过配置存放用户验证信息的表、用户名字段和密码字段,构造查询语句来验证;

使用哪个,需要在deployerConfigContext.xml中设置,
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值