java实现简单的单点登录4.docx
- 文档编号:23732097
- 上传时间:2023-05-20
- 格式:DOCX
- 页数:10
- 大小:77.95KB
java实现简单的单点登录4.docx
《java实现简单的单点登录4.docx》由会员分享,可在线阅读,更多相关《java实现简单的单点登录4.docx(10页珍藏版)》请在冰豆网上搜索。
java实现简单的单点登录4
下面是登录模块DesktopSSOLoginModule的主体:
login()方法。
逻辑也是非常简单:
先用Cookie来登陆,如果成功,则直接就进入系统,否则需要用户输入用户名和密码来登录系统。
publicbooleanlogin()throwsLoginException{ try{ if(Cookielogin())returntrue; }catch(IOExceptionex){ ex.printStackTrace(); } if(passwordlogin())returntrue; thrownewFailedLoginException(); }
下面是Cookielogin()方法的实体,它的逻辑是:
先从Cookie文件中获得相应的Cookie值,通过身份效验服务效验Cookie的有效性。
如果cookie有效就算登录成功;如果不成功或Cookie不存在,用cookie登录就算失败。
publicbooleanCookielogin()throwsLoginException,IOException{ StringcookieValue=""; intcookieIndex=foundCookie(); if(cookieIndex<0) returnfalse; else cookieValue=getCookieValue(cookieIndex); username=cookieAuth(cookieValue); if(!
username.equals("failed")){ loginSuccess=true; returntrue; } returnfalse; }
用用户名和密码登录的方法要复杂一些,通过Callback的机制和屏幕输入输出进行信息交互,完成用户登录信息的获取;获取信息以后通过userAuth方法来调用远端SSOAuth的服务来判定当前登录的有效性。
publicbooleanpasswordlogin()throwsLoginException{ // //Sinceweneedinputfromauser,weneedacallbackhandler if(callbackHandler==null){ thrownewLoginException("NoCallbackHandlerdefined"); } Callback[]callbacks=newCallback[2]; callbacks[0]=newNameCallback("Username"); callbacks[1]=newPasswordCallback("Password",false); // //Callthecallbackhandlertogettheusernameandpassword try{ callbackHandler.handle(callbacks); username=((NameCallback)callbacks[0]).getName(); char[]temp=((PasswordCallback)callbacks[1]).getPassword(); password=newchar[temp.length]; System.arraycopy(temp,0,password,0,temp.length); ((PasswordCallback)callbacks[1]).clearPassword(); }catch(IOExceptionioe){ thrownewLoginException(ioe.toString()); }catch(UnsupportedCallbackExceptionuce){ thrownewLoginException(uce.toString()); } System.out.println(); Stringauthresult=""; try{ authresult=userAuth(username,password); }catch(IOExceptionex){ ex.printStackTrace(); } if(!
authresult.equals("failed")){ loginSuccess=true; clearPassword(); try{ updateCookie(authresult); }catch(IOExceptionex){ ex.printStackTrace(); } returntrue; } loginSuccess=false; username=null; clearPassword(); System.out.println("Login:
PasswordLoginModuleFAIL"); thrownewFailedLoginException(); }
CookieAuth和userAuth方法都是利用apahce的httpclient工具包和远程的SSOAuth进行http连接,获取服务。
privateStringcookieAuth(Stringcookievalue)throwsIOException{ Stringresult="failed"; HttpClienthttpclient=newHttpClient(); GetMethodhttpget=newGetMethod(SSOServiceURL+Action1+cookievalue); try{ httpclient.executeMethod(httpget); result=httpget.getResponseBodyAsString(); }finally{ httpget.releaseConnection(); } returnresult; } privateStringuserAuth(Stringusername,char[]password)throwsIOException{ Stringresult="failed"; Stringpasswd=newString(password); HttpClienthttpclient=newHttpClient(); GetMethodhttpget=newGetMethod(SSOServiceURL+Action2+username+"&password="+passwd); passwd=null; try{ httpclient.executeMethod(httpget); result=httpget.getResponseBodyAsString(); }finally{ httpget.releaseConnection(); } returnresult; }
还有一个地方需要补充说明的是,在本样例中,用户名和密码的输入都会在屏幕上显示明文。
如果希望用掩码形式来显示密码,以提高安全性,请参考:
4 当前方案的安全局限性
当前这个WEB-SSO的方案是一个比较简单的雏形,主要是用来演示SSO的概念和说明SSO技术的实现方式。
有很多方面还需要完善,其中安全性是非常重要的一个方面。
我们说过,采用SSO技术的主要目的之一就是加强安全性,降低安全风险。
因为采用了SSO,在网络上传递密码的次数减少,风险降低是显然的,但是当前的方案却有其他的安全风险。
由于cookie是一个用户登录的唯一凭据,对cookie的保护措施是系统安全的重要环节:
∙cookie的长度和复杂度
在本方案中,cookie是有一个固定的字符串(我的姓名)加上当前的时间戳。
这样的cookie很容易被伪造和猜测。
怀有恶意的用户如果猜测到合法的cookie就可以被当作已经登录的用户,任意访问权限范围内的资源
∙cookie的效验和保护
在本方案中,虽然密码只要传输一次就够了,可cookie在网络中是经常传来传去。
一些网络探测工具(如sniff,snoop,tcpdump等)可以很容易捕获到cookie的数值。
在本方案中,并没有考虑cookie在传输时候的保护。
另外对cookie的效验也过于简单,并不去检查发送cookie的来源究竟是不是cookie最初的拥有者,也就是说无法区分正常的用户和仿造cookie的用户。
∙当其中一个应用的安全性不好,其他所有的应用都会受到安全威胁
因为有SSO,所以当某个处于 SSO的应用被黒客攻破,那么很容易攻破其他处于同一个SSO保护的应用。
这些安全漏洞在商业的SSO解决方案中都会有所考虑,提供相关的安全措施和保护手段,例如Sun公司的AccessManager,cookie的复杂读和对cookie的保护都做得非常好。
另外在OpneSSO ()的架构指南中也给出了部分安全措施的解决方案。
5 当前方案的功能和性能局限性
除了安全性,当前方案在功能和性能上都需要很多的改进:
∙当前所提供的登录认证模式只有一种:
用户名和密码,而且为了简单,将用户名和密码放在内存当中。
事实上,用户身份信息的来源应该是多种多样的,可以是来自数据库中,LDAP中,甚至于来自操作系统自身的用户列表。
还有很多其他的认证模式都是商务应用不可缺少的,因此SSO的解决方案应该包括各种认证的模式,包括数字证书,Radius, SafeWord ,MemberShip,SecurID等多种方式。
最为灵活的方式应该允许可插入的JAAS框架来扩展身份认证的接口
∙我们编写的Filter只能用于J2EE的应用,而对于大量非Java的Web应用,却无法提供SSO服务。
∙在将Filter应用到Web应用的时候,需要对容器上的每一个应用都要做相应的修改,重新部署。
而更加流行的做法是Agent机制:
为每一个应用服务器安装一个agent,就可以将SSO功能应用到这个应用服务器中的所有应用。
∙当前的方案不能支持分别位于不同domain的Web应用进行SSO。
这是因为浏览器在访问Web服务器的时候,仅仅会带上和当前web服务器具有相同domain名称的那些cookie。
要提供跨域的SSO的解决方案有很多其他的方法,在这里就不多说了。
Sun的AccessManager就具有跨域的SSO的功能。
∙另外,Filter的性能问题也是需要重视的方面。
因为Filter会截获每一个符合URL映射规则的请求,获得cookie,验证其有效性。
这一系列任务是比较消耗资源的,特别是验证cookie有效性是一个远程的http的调用,来访问SSOAuth的认证服务,有一定的延时。
因此在性能上需要做进一步的提高。
例如在本样例中,如果将URL映射从“.jsp”改成“/*”,也就是说filter对所有的请求都起作用,整个应用会变得非常慢。
这是因为,页面当中包含了各种静态元素如gif图片,css样式文件,和其他html静态页面,这些页面的访问都要通过filter去验证。
而事实上,这些静态元素没有什么安全上的需求,应该在filter中进行判断,不去效验这些请求,性能会好很多。
另外,如果在filter中加上一定的cache,而不需要每一个cookie效验请求都去远端的身份认证服务中执行,性能也能大幅度提高。
∙另外系统还需要很多其他的服务,如在内存中定时删除无用的cookie映射等等,都是一个严肃的解决方案需要考虑的问题。
6 桌面SSO的实现
从WEB-SSO的概念延伸开,我们可以把SSO的技术拓展到整个桌面的应用,不仅仅局限在浏览器。
SSO的概念和原则都没有改变,只需要再做一点点的工作,就可以完成桌面 SSO 的应用。
桌面SSO和WEB-SSO一样,关键的技术也在于如何在用户登录过后保存登录的凭据。
在WEB-SSO中,登录的凭据是靠浏览器的cookie机制来完成的;在桌面应用中,可以将登录的凭证保存到任何地方,只要所有SSO的桌面应用都共享这个凭证。
从网站可以下载一个简单的桌面SSO的样例(
6.1桌面样例的部署
1.运行此桌面SSO需要三个前提条件:
a)WEB-SSO的身份认证应用应该正在运行,因为我们在桌面SSO当中需要用到统一的认证服务
b) 当前桌面需要运行Mozilla或Netscape浏览器,因为我们将ticket保存到mozilla的cookie文件中
c) 必须在JDK1.4以上运行。
(WEB-SSO需要JDK1.5以上)
2.解开desktopsso.zip文件,里面有两个目录bin和lib。
3.bin目录下有一些脚本文件和配置文件,其中config.properties包含了三个需要配置的参数:
a)SSOServiceURL要指向WebSSO部署的身份认证的URL
b)SSOLoginPage要指向WebSSO部署的身份认证的登录页面URL
c)cookiefilepath要指向当前用户的mozilla所存放cookie的文件
4.在bin目录下还有一个login.conf是用来配置JAAS登录模块,本样例提供了两个,读者可以任意选择其中一个(也可以都选),再重新运行程序,查看登录认证的变化
5.在bin下的运行脚本可能需要作相应的修改
a) 如果是在unix下,各个jar文件需要用“:
”来隔开,而不是“;”
b)java 运行程序需要放置在当前运行的路径下,否则需要加上java的路径全名。
6.2桌面样例的运行
样例程序包含三个简单的Java控制台程序,这三个程序单独运行都需要登录。
如果运行第一个命叫“GameSystem”的程序,提示需要输入用户名和密码:
效验成功以后,便会显示当前登录的用户的基本信息等等。
这时候再运行第二个桌面Java应用(mailSystem)的时候,就不需要再登录了,直接就显示出来刚才登录的用户。
第三个应用是logout,运行它之后,用户便退出系统。
再访问的时候,又需要重新登录了。
请读者再制裁执行完logout之后,重新验证一下前两个应用的SSO:
先运行第二个应用,再运行第一个,会看到相同的效果。
我们的样例并没有在这里停步,事实上,本样例不仅能够和在几个Java应用之间SSO,还能和浏览器进行SSO,也就是将浏览器也当成是桌面的一部分。
这对一些行业有着不小的吸引力。
这时候再打开Mozilla浏览器,访问以前提到的那两个WEB应用,会发现只要桌面应用如果登录过,Web应用就不用再登录了,而且能显示刚才登录的用户的信息。
读者可以在几个桌面和Web应用之间进行登录和logout的试验,看看它们之间的SSO。
6.3桌面样例的源码分析
桌面SSO的样例使用了JAAS(要了解JAAS的详细的信息请参考AuthenticationModule)的Java实现,来完成 Java应用可插拔的安全认证模块。
使用JAAS作为Java应用的安全认证模块有很多好处,最主要的是不需要修改源代码就可以更换认证方式。
例如原有的Java应用如果使用JAAS的认证,如果需要应用SSO,只需要修改JAAS的配置文件就行了。
现在在流行的J2EE和其他 Java的产品中,用户的身份认证都是通过JAAS来完成的。
在样例中,我们就展示了这个功能。
请看配置文件login.conf
Xml代码
1.DesktopSSO {
2.desktopsso.share.PasswordLoginModule required;
3.desktopsso.share.DesktopSSOLoginModule required;
当我们注解掉第二个模块的时候,只有第一个模块起作用。
在这个模块的作用下,只有test用户(密码是12345)才能登录。
当我们注解掉第一个模块的时候,只有第二个模块起作用,桌面SSO才会起作用。
所有的Java桌面样例程序都是标准JAAS应用,熟悉JAAS的程序员会很快了解。
JAAS中主要的是登录模块(LoginModule)。
下面是SSO登录模块的源码:
Java代码
1.public class DesktopSSOLoginModule implements LoginModule {
2. ..........
3. private String SSOServiceURL = "";
4. private String SSOLoginPage = "";
5. private static String cookiefilepath = "";
6. .........
在config.properties的文件中,我们配置了它们的值:
Xml代码
1.SSOServiceURL=:
8080/SSOAuth/SSOAuth
2.SSOLoginPage=:
8080/SSOAuth/login.jsp
3.cookiefilepath=C:
\\Documents and Settings\\yw137672\\Application Data\\Mozilla\\Profiles\\default\\hog6z1ji.slt\\cookies.txt
SSOServiceURL和SSOLoginPage成员变量指向了在Web-SSO中用过的身份认证模块:
SSOAuth,这就说明在桌面系统中我们试图和Web应用共用一个认证服务。
而cookiefilepath成员变量则泄露了一个“天机”:
我们使用了Mozilla浏览器的cookie文件来保存登录的凭证。
换句话说,和Mozilla共用了一个保存登录凭证的机制。
之所以用Mozilla是应为它的Cookie文件格式简单,很容易编程访问和修改任意的Cookie值。
(我试图解析InternetExplorer的cookie文件但没有成功。
)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- java 实现 简单 单点 登录