java实现单点登录

《java实现单点登录》由会员分享，可在线阅读，更多相关《java实现单点登录（25页珍藏版）》请在装配图网上搜索。

1、摘要：单点登录（SSO）的技术被越来越广泛地运用到各个领域的软件系统当 中。本文从业务的角度分析了单点登录的需求和应用领域；从技术本身的角度分 析了单点登录技术的内部机制和实现手段，并且给出Web-SSO和桌面SSO的 实现、源代码和详细讲解；还从安全和性能的角度对现有的实现技术进行进一步 分析，指出相应的风险和需要改进的方面。本文除了从多个方面和角度给出了对 单点登录（SS0）的全面分析，还并且讨论了如何将现有的应用和SSO服务结 合起来，能够帮助应用架构师和系统分析人员从本质上认识单点登录，从而更好 地设计出符合需要的安全架构。关键字：SSO, Java, J2EE, JAAS1什么是单点

2、登陆单点登录（Single Sign On），简称为、。，是目前比较流行的企业业务整合 的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可 以访问所有相互信任的应用系统。较大的企业内部，一般都有很多的业务支持系统为其提供相应的管理和IT服 务。 例如财务系统为财务人员提供财务的管理、计算和报表服务；人事系统为人事部 门提供全公司人员的维护服务；各种业务系统为公司内部不同的业务提供不同的 服务等等。这些系统的目的都是让计算机来进行复杂繁琐的计算工作，来替代人 力的手工劳动，提高工作效率和质量。这些不同的系统往往是在不同的时期建设 起来的，运行在不同的平台上；也许是由不同厂商开

3、发，使用了各种不同的技 术和标准。如果举例说国内一著名的IT公司（名字隐去），内部共有60多个 业务系统，这些系统包括两个不同版本的SAP的ERP系统，12个不同类型和 版本的数据库系统，8个不同类型和版本的操作系统，以及使用了3种不同的防 火墙技术，还有数十种互相不能兼容的协议和标准，你相信吗？不要怀疑，这种 情况其实非常普遍。每一个应用系统在运行了数年以后，都会成为不可替换的企 业IT架构的一部分，如下图所示。Customers Suppliers Employees PartnersSupplyCommunications Custom e-businessChain Applicati

4、ons Applications ApplicationsApplications随着企业的发展，业务系统的数量在不断的增加，老的系统却不能轻易的替换， 这会带来很多的开销。其一是管理上的开销，需要维护的系统越来越多。很多系 统的数据是相互冗余和重复的，数据的不一致性会给管理工作带来很大的压力。 业务和业务之间的相关性也越来越大，例如公司的计费系统和财务系统，财务系 统和人事系统之间都不可避免的有着密切的关系。为了降低管理的消耗，最大限度的重用已有投资的系统，很多企业都在进行着企 业应用集成（EAI）。企业应用集成可以在不同层面上进行：例如在数据存储 层面上的数据大集中，在传输层面上的通用数据

5、交换平台，在应用层面上的 业务流程整合，和用 户界面上的通用企业门户等等。事实上，还用一个层 面上的集成变得越来越重要，那就是身份认证的整合，也就是单点登录。通常来说，每个单独的系统都会有自己的安全体系和身份认证系统。整合以前， 进入每个系统都需要进行登录，这样的局面不仅给管理上带来了很大的困难，在 安全方面也埋下了重大的隐患。下面是一些著名的调查公司显示的统计数据：用户每天平均16分钟花在身份验证任务上-资料来源：IDS频繁的IT用户平均有21个密码-资料来源：NTA Monitor Password Survey 49%的人写下了其密码，而67% 的人很少改变它们每79秒出现一起身份被窃事

6、件-资料来源：National Small Business Travel Assoc全球欺骗损失每年约12B -资料来源：Comm Fraud Control Assoc到2007年，身份管理市场将成倍增长至$4.5B -资料来源：IDS 使用单点登录整合后，只需要登录一次就可以进入多个系统，而不需要重新登 录，这不仅仅带来了更好的用户体验，更重要的是降低了安全的风险和管理的消 耗。请看下面的统计数据：提高IT效率：对于每1000个受管用户，每用户可节省$70K帮助台呼叫减少至少1/3,对于10K员工的公司，每年可以节省每用户$75,或者 合计$648K生产力提高：每个新员工可节省$1K，每

7、个老员工可节省$350资料来源：Giga ROI回报：7.5到13个月 资料来源：Gartner另外，使用单点登录还是SOA时代的需求之一。在面向服务的架构中，服务 和服务之间，程序和程序之间的通讯大量存在，服务之间的安全认证是SOA应 用的难点之一，应此建立单点登录的系统体系能够大大简化SOA的安全问题， 提高服务之间的合作效率。2单点登陆的技术实现机制随着SSO技术的流行，SSO的产品也是满天飞扬。所有著名的软件厂商都提供 了相应的解决方案。在这里我并不想介绍自己公司（Sun Microsystems）的产 品，而是对SSO技术本身进行解析，并且提供自己开发这一类产品的方法和简 单演示。有

8、关我写这篇文章的目的，请参考我的博客（单点登录的机制其实是比较简单的，用一个现实中的例子做比较。颐和园是北 京著名的旅游景点，也是我常去的地方。在颐和园内部有许多独立的景点，例如 苏州街、佛香阁和德和园，都可以在各个景点门口单独买票。很多游客 需要游玩所有德景点，这种买票方式很不方便，需要在每个景点门口排队买票， 钱包拿进拿出的，容易丢失，很不安全。于是绝大多数游客选择在大门口买一 张通票（也叫套票），就可以玩遍所有的景点而不需要重新再买票。他们只需要 在每个景点门口出示一下刚才买的套票就能够被允许进入每个独立的景点。单点登录的机制也一样，如下图所示，当用户第一次访问应用系统1的时候， 因为还

9、没有登录，会被引导到认证系统中进行登录（1）；根据用户提供的登录 信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据 ticket （2）；用户再访问别的应用的时候（3, 5）就会将这个ticket带上， 作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行 效验，检查ticket的合法性（4, 6）。如果通过效验，用户就可以在不用再次 登录的情况下访问应用系统2和应用系统3 了。4 lleRAt3 ticket8 ticket；ticket1醐砌ri.II 11J III III 1,11 111 11 11J III II匚应用系貌3从上面的视图可

10、以看出，要实现SSO，需要以下主要的功能：所有应用系统共享一个身份认证系统。统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的 登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认 证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证 系统还应该对ticket进行效验，判断其有效性。所有应用系统能够识别和提取ticket信息要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别 已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与 认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录 的功能。上面的功能只是一个非常简单的S

11、SO架构，在现实情况下的SSO有着更加复 杂的结构。有两点需要指出的是：单一的用户信息数据库并不是必须的，有许多系统不能将所有的用户信息 都集中存储，应该允许用户信息放置在不同的存储中，如下图所示。事 实上，只要统一认证系统，统一ticket的产生和效验，无论用户信息存 储在什么地方，都能实现单点登录。统一的认证系统并不是说只有单个的认证服务器，如下图所示，整个系统 可以存在两个以上的认证服务器，这些服务器甚至可以是不同的产品。 认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成 更高级别的单点登录。如下图，当用户在访问应用系统1时，由第一个 认证服务器进行认证后，得到由此服务器产

12、生的ticket。当他访问应用 系统4的时候，认证服务器2能够识别此ticket是由第一个服务器产生 的，通过认证服务器之间标准的通讯协议(例如SAML)来交换认证信 息，仍然能够完成SSO的功能。3 WEB-SSO的实现随着互联网的高速发展，WEB应用几乎统治了绝大部分的软件应用系统，因此 WEB-SSO是SSO应用当中最为流行。WEB-SSO有其自身的特点和优势，实 现起来比较简单易用。很多商业软件和开源软件都有对WEB-SSO的实现。其 中值得一提的是 OpenSSO ()，为用 Java 实现WEB-SSO提供架构指南和服务指南，为用户自己来实现WEB-SSO提供 了理论的依据和实现的

13、方法。为什么说WEB-SSO比较容易实现呢？这是有WEB应用自身的特点决定的。 众所周知，Web协议(也就是HTTP)是一个无状态的协议。一个Web应用由 很多个Web页面组成，每个页面都有唯一的URL来定义。用户在浏览器的地 址栏输入页面的URL，浏览器就会向Web Server去发送请求。如下图，浏览 器向Web服务器发送了两个请求，申请了两个页面。这两个页面的请求是分别 使用了两个单独的HTTP连接。所谓无状态的协议也就是表现在这里，浏览器和 Web服务器会在第一个请求完成以后关闭连接通道，在第二个请求的时候重新 建立连接。Web服务器并不区分哪个请求来自哪个客户端，对所有的请求都一 视

14、同仁，都是单独的连接。这样的方式大大区别于传统的(Client/Server)C/S 结构，在那样的应用中，客户端和服务器端会建立一个长时间的专用的连接通道。 正是因为有了无状态的特性，每个连接资源能够很快被其他客户端所重用，一台 Web服务器才能够同时服务于成千上万的客户端。但是我们通常的应用是有状态的。先不用提不同应用之间的SSO，在同一个应 用中也需要保存用户的登录身份信息。例如用户在访问页面1的时候进行了登 录，但是刚才也提到，客户端的每个请求都是单独的连接，当客户再次访问页面 2的时候，如何才能告诉Web服务器，客户刚才已经登录过了呢？浏览器和服 务器之间有约定：通过使用cookie

15、技术来维护应用的状态。Cookie是可以被 Web服务器设置的字符串，并且可以保存在浏览器中。如下图所示，当浏览器 访问了页面1时，web服务器设置了一个cookie，并将这个cookie和页面1 一起返回给浏览器，浏览器接到cookie之后，就会保存起来，在它访问页面2 的时候会把这个cookie也带上，Web服务器接到请求时也能读出cookie的值， 根据cookie值的内容就可以判断和恢复一些用户的信息状态。Mcz i I lijWebserver申语如fid返回典面，并设爵g海推四页弱12潴黑成密溢密溢密溢密;iHBHiiit甲情真册8并W上此。k祯Web-SSO完全可以利用Cooki

16、e结束来完成用户登录信息的保存，将浏览器中 的Cookie和上文中的Ticket结合起来，完成SSO的功能。为了完成一个简单的SSO的功能，需要两个部分的合作：1统一的身份认证服务。2.修改Web应用，使得每个应用都通过这个统一的认证服务来进行身份效 验。3.1 Web SSO 的样例根据上面的原理，我用J2EE的技术（JSP和Servlet）完成了一个具有Web-SSO 的简单样例。样例包含一个身份认证的服务器和两个简单的Web应用，使得这 两个Web应用通过统一的身份认证服务来完成Web-SSO的功能。此样例所 有的源代码和二进制代码都可以从网站地址 下载。样例下载、安装部署和运行指南:

17、Web-SSO的样例是由三个标准Web应用组成，压缩成三个zip文件， 从 SSOAuth( 是身份认证服务；SSOWebDemo1(1. zip)和 SSOWebDemo2(2. zip)是两个用来演示单点登录的Web应用。这三个Web应用之所 以没有打成war包，是因为它们不能直接部署，根据读者的部署环境需 要作出小小的修改。样例部署和运行的环境有一定的要求，需要符合 Servlet2.3以上标准的J2EE容器才能运行(例如Tomcat5,Sun Application Server 8, Jboss 4等)。另外，身份认证服务需要 JDK1.5 的运行环境。之所以要用JDK1.5是因为笔

18、者使用了一个线程安全的高 性能的Java集合类ConcurrentMap，只有在JDK1.5中才有。这三个Web应用完全可以单独部署，它们可以分别部署在不同的机器， 不同的操作系统和不同的J2EE的产品上，它们完全是标准的和平台无 关的应用。但是有一个限制，那两台部署应用(demo1、demo2)的 机器的域名需要相同，这在后面的章节中会解释到cookie和domain 的关系以及如何制作跨域的WEB-SSO解压缩SSOAuth.zip文件，在/WEB-INF/下的web.xml中请修改 “domainname的属性以反映实际的应用部署情况，domainname需 要设置为两个单点登录的应用(

19、demo1和demo2)所属的域名。这个 domainname和当前SSOAuth服务部署的机器的域名没有关系。我 缺省设置的是“o如果你部署demo1和demo2的机器没有 域名，请输入IP地址或主机名(如localhost)，但是如果使用IP地 址或主机名也就意味着demo1和demo2需要部署到一台机器上了。 设置完后，根据你所选择的J2EE容器，可能需要将SSOAuth这个目 录压缩打包成war文件。用“jar -cvf SSOAuth.war SSOAuth/就可 以完成这个功能。解压缩SSOWebDemo1和SSOWebDemo2文件，分别在它们 /WEB-INF/下找到web.x

20、ml文件，请修改其中的几个初始化参数 SSOServiceURL :8080/SSOAuth/S SOAuth SSOLoginPage :8080/SSOAuth/l ogin.jsp 将其中的 SSOServiceURL 和 SSOLoginPage 修改成部署 SSOAuth应用的机器名、端口号以及根路径（缺省是SSOAuth）以反映实际的 部署情况。设置完后，根据你所选择的J2EE容器，可能需要将 SSOWebDemo1和SSOWebDemo2这两个目录压缩打包成两个 war 文件。用“jar -cvf SSOWebDemol.war SSOWebDemol/以就 可以完成这个功能。.

21、请输入第一个web应用的测试URL（test.jsp），例如 :8080/ SSOWebDemo1/test.jsp， 如果是第一次访问，便会自动跳转到登录界面，如下图；=： X-：: A：: X ：-：: ：-： :m：: R：: Y ：: ：-：: A：: ： A：:：=： H ：=：:V ： : ：-：: ：-： : ：-：: =：:V ：:：=： ：-：使用系统自带的三个帐号之一登录（例如，用户名：wangyu,密码： wangyu），便能成功的看到test.jsp的内容：显示当前用户名和欢迎信息。.请接着在同一个浏览器中输入第二个web应用的测试URL（test.jsp）,例如 :8

22、080/SSOWebDemo2/test.jsp。你会发现，不需要再次登录就能看到 test.jsp的内容，同样是显示当前用户名和欢迎信息，而且欢迎信息中 明确的显示当前的应用名称（demo2）。鞭-Eg寿 噩iiSiBiiiiiffl 可通照在煎煎谗通照氓?夹蔚 死能斐蛇翻聘耍板整知联嗟驻:： ： ： ： ： : : : = ：=：= ：: : ： ：=： ：: :=!： ：= ：: : :=： ：i:ii#:.;!:,:!?i鑫liiniilE 做MgsiIS 空:泛整:逊樗免樗您代:一伊 邕BlilliiiE liililiii 斜淡尊!:!尚帝;落挠麒混 我卖:.:符注.：符以：符诲：

23、符土:;:-:.-.:-:.,.:.:.:3.2 WEB-SSO代码讲解3.2.1身份认证服务代码解析Web-SSO的源代码可以从网站地址 下载。身 份认证服务是一个标准的web应用，包括一个名为SSOAuth的Servlet，一 个login.jsp文件和一个failed.html。身份认证的所有服务几乎都由SSOAuth 的Servlet来实现了； login.jsp用来显示登录的页面（如果发现用户还没有登 录过）；failed.html是用来显示登录失败的信息（如果用户的用户名和密码与 信息数据库中的不一样）。SSOAuth的代码如下面的列表显示，结构非常简单，先看看这个Servlet的

24、主 体部分：package DesktopSSO;import java.io.*;import .*;import java.text.*;import java.util.*;import java.util.concurrent.*;import javax.servlet.*;import javax.servlet.http.*;public class SSOAuth extends HttpServlet static private ConcurrentMap accounts;static private ConcurrentMap SSOIDs;String cookien

25、ame=WangYuDesktopSSOID;String domainname;public void init(ServletConfig config) throws ServletException super.init(config);domainname= config.getInitParameter(domainname);cookiename = config.getInitParameter(cookiename);SSOIDs = new ConcurrentHashMap();accounts=new ConcurrentHashMap();accounts.put(w

26、angyu, wangyu);accounts.put(paul, paul);accounts.put(carol, carol);protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException PrintWriter out = response.getWriter();String action = request.getParameter(action);String result=failed;if

27、(action = = null) handlerFromLogin(request,response); else if (action.equals(authcookie)String myCookie = request.getParameter(cookiename);if (myCookie != null) result = authCookie(myCookie);out.print(result);out.close(); else if (action.equals(authuser) result=authNameAndPasswd(request,response);ou

28、t.print(result);out.close(); else if (action.equals(logout) String myCookie = request.getParameter(cookiename);logout(myCookie);out.close();从代码很容易看出，SSOAuth就是一个简单的Servlet。其中有两个静态成员 变量：accounts和SSOIDs，这两个成员变量都使用了 JDK1.5中线程安全的 MAP类：ConcurrentMap，所以这个样例一定要JDK1.5才能运行Accounts 用来存放用户的用户名和密码，在init()的方法中可以看

29、到我给系统添加了三个 合法的用户。在实际应用中，accounts应该是去数据库中或LDAP中获得，为 了简单起见，在本样例中我使用了 ConcurrentMap在内存中用程序创建了三 个用户。而SSOIDs保存了在用户成功的登录后所产生的cookie和用户名的对 应关系。它的功能显而易见：当用户成功登录以后，再次访问别的系统，为了鉴 别这个用户请求所带的cookie的有效性，需要到SSOIDs中检查这样的映射关 系是否存在。在主要的请求处理方法processRequest()中，可以很清楚的看到SSOAuth的 所有功能1. 如果用户还没有登录过，是第一次登录本系统，会被跳转到login.js

30、p页面(在后面会解释如何跳转)。用户在提供了用户名和密码以后，就会 用handlerFromLogin()这个方法来验证。2. 如果用户已经登录过本系统，再访问别的应用的时候，是不需要再次登录的。因为浏览器会将第一次登录时产生的cookie和请求一起发送。效 验cookie的有效性是SSOAuth的主要功能之一。3. SSOAuth还能直接效验非login.jsp页面过来的用户名和密码的效验请 求。这个功能是用于非web应用的SSO,这在后面的桌面SSO中会用至0。4. SSOAuth 还提供 logout 服务。下面看看几个主要的功能函数：private void handlerFromLo

31、gin(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException String username = request.getParameter(username);String password = request.getParameter(password);String pass = (String)accounts.get(username);if (pass= = null)|(!pass.equals(password)getServletContext

32、().getRequestDispatcher(/failed.html).fo rward(request, response);else String gotoURL = request.getParameter(goto);String newID = createUID();SSOIDs.put(newID, username);Cookie wangyu = new Cookie(cookiename, newID); wangyu.setDomain(domainname); wangyu.setMaxAge(60000);wangyu.setValue(newID);wangyu

33、.setPath(/);response.addCookie(wangyu);System.out.println(login success, goto back url: + gotoURL);if (gotoURL != null) PrintWriter out = response.getWriter();response.sendRedirect(gotoURL);out.close();handlerFromLogin()这个方法是用来处理来自login.jsp的登录请求。它的逻 辑很简单：将用户输入的用户名和密码与预先设定好的用户集合(存放在 accounts中)相比较，如果用

34、户名或密码不匹配的话，则返回登录失败的页面 (failed.html)，如果登录成功的话，需要为用户当前的session创建一个新的ID，并将这个ID和用户名的映射关系存放到SSOIDs中，最后还要将这个 ID设置为浏览器能够保存的cookie值。登录成功后，浏览器会到哪个页面呢？那我们回顾一下我们是如何使用身份认证 服务的。一般来说我们不会直接访问身份服务的任何URL，包括login.jsp。身 份服务是用来保护其他应用服务的，用户一般在访问一个受SSOAuth保护的 Web应用的某个URL时，当前这个应用会发现当前的用户还没有登录，便强制 将也页面转向SSOAuth的login.jsp，让

35、用户登录。如果登录成功后，应该自 动的将用户的浏览器指向用户最初想访问的那个URL。在handlerFromLogin() 这个方法中，我们通过接收“goto这个参数来保存用户最初访问的URL，成功 后便重新定向到这个页面中。另外一个要说明的是，在设置cookie的时候，我使用了一个setMaxAge(6000) 的方法。这个方法是用来设置cookie的有效期，单位是秒。如果不使用这个方 法或者参数为负数的话，当浏览器关闭的时候，这个cookie就失效了。在这里 我给了很大的值(1000分钟)，导致的行为是：当你关闭浏览器(或者关机)， 下次再打开浏览器访问刚才的应用，只要在1000分钟之内，

36、就不需要再登录了。 我这样做是下面要介绍的桌面SSO中所需要的功能。其他的方法更加简单，这里就不多解释了。3.2.2具有SSO功能的web应用源代码解析要实现WEB-SSO的功能，只有身份认证服务是不够的。这点很显然，要想使 多个应用具有单点登录的功能，还需要每个应用本身的配合：将自己的身份认证 的服务交给一个统一的身份认证服务一SSOAuth。SSOAuth服务中提供的各 个方法就是供每个加入SSO的Web应用来调用的。一般来说，Web应用需要SSO的功能，应该通过以下的交互过程来调用身份 认证服务的提供的认证服务： Web应用中每一个需要安全保护的URL在访问以前，都需要进行安全检 查，如

37、果发现没有登录(没有发现认证之后所带的cookie)，就重新定 向到SSOAuth中的login.jsp进行登录。登录成功后，系统会自动给你的浏览器设置cookie，证明你已经登录过 了。当你再访问这个应用的需要保护的URL的时候，系统还是要进行安全检 查的，但是这次系统能够发现相应的co Okie。有了这个cookie，还不能证明你就一定有权限访问。因为有可能你已经 logout，或者cookie已经过期了，或者身份认证服务重起过，这些情况 下，你的cookie都可能无效。应用系统拿到这个cookie，还需要调用 身份认证的服务，来判断cookie时候真的有效，以及当前的cookie对 应的

38、用户是谁。如果cookie效验成功，就允许用户访问当前请求的资源。以上这些功能，可以用很多方法来实现：在每个被访问的资源中（JSP或Servlet）中都加入身份认证的服务，来 获得cookie，并且判断当前用户是否登录过。不过这个笨方法没有人会 用:-）。可以通过一个controller，将所有的功能都写到一个servlet中，然后在 URL映射的时候，映射到所有需要保护的URL集合中（例如*.jsp， /security/*等）。这个方法可以使用，不过，它的缺点是不能重用。在 每个应用中都要部署一个相同的servleto Filter是比较好的方法。符合Servlet2.3以上的J2EE容器

39、就具有部署 filter的功能。（Filter的使用可以参考JavaWolrd的文章 lters.html） Filter是一个具有很好的模块化，可重用的编程API，用 在SSO正合适不过。本样例就是使用一个filter来完成以上的功能。package SSO;import java.io.*;import .*;import java.util.*;import java.text.*;import javax.servlet.*;import javax.servlet.http.*;import javax.servlet.*;import mons.httpclient.*;impor

40、t mons.httpclient.methods.GetMethod;public class SSOFilter implements Filter private FilterConfig filterConfig = null;private String cookieName=WangYuDesktopSSOID;private StringSSOServiceURL= :8080/SSOAuth/SSOA uth;private String SSOLoginPage=:8080/SSOAuth/login.jsp;public void init（FilterConfig fil

41、terConfig） this.filterConfig = filterConfig;if (filterConfig != null) if (debug) log(SSOFilter:Initializing filter);cookieName = filterConfig.getInitParameter(cookieName);SSOServiceURL =filterConfig.getInitParameter(SSOServiceURL);SSOLoginPage =filterConfig.getInitParameter(SSOLoginPage);以上的初始化的源代码有

42、两点需要说明：一是有两个需要配置的参数SSOServiceURL和SSOLoginPage。因为当前的Web应用很可能和身份认 证服务(S SOAuth)不在同一台机器上，所以需要让这个filter知道身份认证 服务部署的URL，这样才能去调用它的服务。另外一点就是由于身份认证的服 务调用是要通过http协议来调用的(在本样例中是这样设计的，读者完全可以 设计自己的身份服务，使用别的调用协议，如RMI或SOAP等等)，所有笔者 引用了 apache的commons工具包(详细信息情访问apache的网站 http:/jakarta.apache.org/commons/index.html)，

43、其中的 “httpclient 可以大大简化http调用的编程。下面看看filter的主体方法doFilter():public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException if (debug) log(SSOFilter:doFilter();HttpServletRequest request = (HttpServletRequest) req;HttpServletResponse response = (Ht

44、tpServletResponse) res;String result=failed;String url = request.getRequestURL().toString();String qstring = request.getQueryString();if (qstring = null) qstring =;检查http请求的head是否有需要的cookieString cookieValue =;javax.servlet.http.Cookie diskCookies = request.getCookies();if (diskCookies != null) for

45、(int i = 0; i 1) /logout 服务 if (debug) log(logout action!); logoutService(cookieValue);response.sendRedirect(SSOLoginPage+?goto=+url); else 效验成功request.setAttribute(SSOUser”,result);Throwable problem = null;try chain.doFilter(req, res); catch(Throwable t) problem = t;t.printStackTrace();if (problem

46、!= null) if (problem instanceof ServletException) throw (ServletException)problem;if (problem instanceof IOException) throw (IOException)problem;sendProcessingError(problem, res);doFilter()方法的逻辑也是非常简单的，在接收到请求的时候，先去查找是否存 在期望的cookie值，如果找到了，就会调用SSOService(cookieValue)去效 验这个cookie的有效性。如果cookie效验不成功或者coo

47、kie根本不存在，就 会直接转到登录界面让用户登录；如果cookie效验成功，就不会做任何阻拦， 让此请求进行下去。在配置文件中，有下面的一个节点表示了此filter的URL 映射关系：只拦截所有的jsp请求。SSOFilter*.jsp下面还有几个主要的函数需要说明：private String SSOService(String cookievalue) throws lOException String authAction = ?action=authcookie&cookiename=;HttpClient httpclient = new HttpClient();GetMetho

48、d httpget = newGetMethod(SSOServiceURL+authAction+cookievalue);try httpclient.executeMethod(httpget);String result = httpget.getResponseBodyAsString();return result; finally httpget.releaseConnection();private void logoutService(String cookievalue) throws IOException String authAction = ?action = lo

49、gout&cookiename=”;HttpClient httpclient = new HttpClient();GetMethod httpget = newGetMethod(SSOServiceURL+authAction+cookievalue);try httpclient.executeMethod(httpget);httpget.getResponseBodyAsString(); finally httpget.releaseConnection();这两个函数主要是利用apache中的httpclient访问SSOAuth提供的认证服 务来完成效验cookie和logo

50、ut的功能。其他的函数都很简单，有很多都是我的IDE(NetBeans)替我自动生成的。4当前方案的安全局限性当前这个WEB-SSO的方案是一个比较简单的雏形，主要是用来演示SSO的概 念和说明SSO技术的实现方式。有很多方面还需要完善，其中安全性是非常重 要的一个方面。我们说过，采用SSO技术的主要目的之一就是加强安全性，降低安全风险。因 为采用了 SSO，在网络上传递密码的次数减少，风险降低是显然的，但是当前 的方案却有其他的安全风险。由于cookie是一个用户登录的唯一凭据，对 cookie的保护措施是系统安全的重要环节：cookie的长度和复杂度在本方案中，cookie是有一个固定的字

51、符串(我的姓名)加上当前的时 间戳。这样的cookie很容易被伪造和猜测。怀有恶意的用户如果猜测 到合法的cookie就可以被当作已经登录的用户，任意访问权限范围内 的资源. cookie的效验和保护在本方案中，虽然密码只要传输一次就够了，可cookie在网络中是经 常传来传去。一些网络探测工具(如sniff, snoop,tcpdump等)可以 很容易捕获到cookie的数值。在本方案中，并没有考虑cookie在传输 时候的保护。另外对cookie的效验也过于简单，并不去检查发送cookie 的来源究竟是不是cookie最初的拥有者，也就是说无法区分正常的用 户和仿造cookie的用户。.当

52、其中一个应用的安全性不好，其他所有的应用都会受到安全威胁 因为有SSO，所以当某个处于SSO的应用被黑客攻破，那么很容易攻 破其他处于同一个SSO保护的应用。这些安全漏洞在商业的SSO解决方案中都会有所考虑，提供相关的安全措施和 保护手段，例如Sun公司的Access Manager，cookie的复杂读和对cookie 的保护都做得非常好。另外在 OpneSSO () 的架构指南中也给出了部分安全措施的解决方案。5当前方案的功能和性能局限性除了安全性，当前方案在功能和性能上都需要很多的改进：.当前所提供的登录认证模式只有一种：用户名和密码，而且为了简单，将 用户名和密码放在内存当中。事实上，

53、用户身份信息的来源应该是多种 多样的，可以是来自数据库中，LDAP中，甚至于来自操作系统自身的 用户列表。还有很多其他的认证模式都是商务应用不可缺少的，因此 SSO的解决方案应该包括各种认证的模式，包括数字证书，Radius， SafeWord，MemberShip，SecurID 等多种方式。最为灵 活的方式应该允许可插入的JAAS框架来扩展身份认证的接口.我们编写的Filter只能用于J2EE的应用，而对于大量非Java的Web 应用，却无法提供SSO服务。.在将Filter应用到Web应用的时候，需要对容器上的每一个应用都要做 相应的修改，重新部署。而更加流行的做法是Agent机制：为每

54、一个应 用服务器安装一个agent，就可以将SSO功能应用到这个应用服务器 中的所有应用。.当前的方案不能支持分别位于不同domain的Web应用进行SSO。这 是因为浏览器在访问Web服务器的时候，仅仅会带上和当前web服务 器具有相同domain名称的那些cookie。要提供跨域的SSO的解决方 案有很多其他的方法，在这里就不多说了。Sun的Access Manager 就具有跨域的SSO的功能。.另外，Filter的性能问题也是需要重视的方面。因为Filter会截获每一个 符合URL映射规则的请求，获得cookie，验证其有效性。这一系列任 务是比较消耗资源的，特别是验证cookie有效

55、性是一个远程的http的 调用，来访问SSOAuth的认证服务，有一定的延时。因此在性能上需 要做进一步的提高。例如在本样例中，如果将URL映射从“.jsp改成/*， 也就是说filter对所有的请求都起作用，整个应用会变得非常慢。这是因为，页面当中包含了各种静态元素如gif图片，css样式文件，和其他 html静态页面，这些页面的访问都要通过filter去验证。而事实上，这 些静态元素没有什么安全上的需求，应该在filter中进行判断，不去效 验这些请求，性能会好很多。另外，如果在filter中加上一定的cache， 而不需要每一个cookie效验请求都去远端的身份认证服务中执行，性 能也能

56、大幅度提高。另外系统还需要很多其他的服务，如在内存中定时删除无用的cookie映 射等等，都是一个严肃的解决方案需要考虑的问题。6桌面SSO的实现从WEB-SSO的概念延伸开，我们可以把SSO的技术拓展到整个桌面的应用， 不仅仅局限在浏览器。SSO的概念和原则都没有改变，只需要再做一点点的工 作，就可以完成桌面SSO的应用。桌面SSO和WEB-SSO 一样，关键的技术也在于如何在用户登录过后保存登录 的凭据。在WEB-SSO中，登录的凭据是靠浏览器的cookie机制来完成的； 在桌面应用中，可以将登录的凭证保存到任何地方，只要所有SSO的桌面应用 都共享这个凭证。从网站可以下载一个简单的桌面S

57、SO的样例(全部源码( p)，虽然简单，但是它具有桌面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.

58、properties包含了三个需要配置的参数：a) SSOServiceURL要指向WebSSO部署的身份认证的URLb) SSOLoginPage要指向WebSSO部署的身份认证的登录页面URLc) cookiefilepath要指向当前用户的mozilla所存放cookie的文件4. 在bin目录下还有一个login.conf是用来配置JAAS登录模块，本样例提供了两个，读者可以任意选择其中一个(也可以都选)，再重新运行 程序，查看登录认证的变化5在bin下的运行脚本可能需要作相应的修改a) 如果是在unix下，各个jar文件需要用、:来隔开，而不是b) java运行程序需要放置在当前运行的路径下，否则需要加上java 的路径全名。6.2桌面样例的运行样例程序包含三个简单的Java控制台程序，这三个程序单独运行都需要登录。 如果运行第一个命叫“GameSystem”的程序，提示需要输入用户名和密码：