单点登录（转）

SSO详细介绍

2010-09-19 11:17

3 WEB-SSO的实现 随着互联网的高速发展， WEB 应用几乎统治了绝大部分的软件应用系统，因此 WEB-SSO 是 SSO 应用当中最为流行。 WEB-SSO 有其自身的特点和优势，实现起来比较简单易用。很多商业软件和开源软件都有对 WEB-SSO 的实现。其中值得一提的是 OpenSSO （ https://opensso.dev.java.net ），为用 Java 实现 WEB-SSO 提供架构指南和服务指南，为用户自己来实现 WEB-SSO 提供了理论的依据和实现的方法。 为什么说 WEB-SSO 比较容易实现呢？这是有 WEB 应用自身的特点决定的。 众所周知， Web 协议（也就是 HTTP ）是一个无状态的协议。一个 Web 应用由很多个 Web 页面组成，每个页面都有唯一的 URL 来定义。用户在浏览器的地址栏输入页面的 URL ，浏览器就会向 Web Server 去发送请求。如下图，浏览器向 Web 服务器发送了两个请求，申请了两个页面。这两个页面的请求是分别使用了两个单独的 HTTP 连接。所谓无状态的协议也就是表现在这里，浏览器和 Web 服务器会在第一个请求完成以后关闭连接通道，在第二个请求的时候重新建立连接。 Web 服务器并不区分哪个请求来自哪个客户端，对所有的请求都一视同仁，都是单独的连接。这样的方式大大区别于传统的（ Client/Server ） C/S 结构 , 在那样的应用中，客户端和服务器端会建立一个长时间的专用的连接通道。正是因为有了无状态的特性，每个连接资源能够很快被其他客户端所重用，一台 Web 服务器才能够同时服务于成千上万的客户端。 但是我们通常的应用是有状态的。先不用提不同应用之间的 SSO ，在同一个应用中也需要保存用户的登录身份信息。例如用户在访问页面 1 的时候进行了登录，但是刚才也提到，客户端的每个请求都是单独的连接，当客户再次访问页面 2 的时候，如何才能告诉 Web 服务器，客户刚才已经登录过了呢？浏览器和服务器之间有约定：通过使用 cookie 技术来维护应用的状态。 Cookie 是可以被 Web 服务器设置的字符串，并且可以保存在浏览器中。如下图所示，当浏览器访问了页面 1 时， web 服务器设置了一个 cookie ，并将这个 cookie 和页面 1 一起返回给浏览器，浏览器接到 cookie 之后，就会保存起来，在它访问页面 2 的时候会把这个 cookie 也带上， Web 服务器接到请求时也能读出 cookie 的值，根据 cookie 值的内容就可以判断和恢复一些用户的信息状态。 Web-SSO 完全可以利用 Cookie 结束来完成用户登录信息的保存，将浏览器中的 Cookie 和上文中的 Ticket 结合起来，完成 SSO 的功能。 为了完成一个简单的 SSO 的功能，需要两个部分的合作： 统一的身份认证服务。 修改Web应用，使得每个应用都通过这个统一的认证服务来进行身份效验。 3.1 Web SSO 的样例 根据上面的原理，我用 J2EE 的技术（ JSP 和 Servlet ）完成了一个具有 Web-SSO 的简单样例。样例包含一个身份认证的服务器和两个简单的 Web 应用，使得这两个 Web 应用通过统一的身份认证服务来完成 Web-SSO 的功能。此样例所有的源代码和二进制代码都可以从网站地址 http://gceclub.sun.com.cn/wangyu/ 下载。 样例下载、安装部署和运行指南： Web-SSO的样例是由三个标准Web应用组成，压缩成三个zip文件，从http://gceclub.sun.com.cn/wangyu/web-sso/中下载。其中SSOAuth（http://gceclub.sun.com.cn/wangyu/web-sso/SSOAuth.zip）是身份认证服务；SSOWebDemo1（http://gceclub.sun.com.cn/wangyu/web-sso/SSOWebDemo1.zip）和SSOWebDemo2（http://gceclub.sun.com.cn/wangyu/web-sso/SSOWebDemo2.zip）是两个用来演示单点登录的Web应用。这三个Web应用之所以没有打成war包，是因为它们不能直接部署，根据读者的部署环境需要作出小小的修改。样例部署和运行的环境有一定的要求，需要符合Servlet2.3以上标准的J2EE容器才能运行（例如Tomcat5,Sun Application Server 8, Jboss 4等）。另外，身份认证服务需要JDK1.5的运行环境。之所以要用JDK1.5是因为笔者使用了一个线程安全的高性能的Java集合类“ConcurrentMap”，只有在JDK1.5中才有。 这三个Web应用完全可以单独部署，它们可以分别部署在不同的机器，不同的操作系统和不同的J2EE的产品上，它们完全是标准的和平台无关的应用。但是有一个限制，那两台部署应用（demo1、demo2）的机器的域名需要相同，这在后面的章节中会解释到cookie和domain的关系以及如何制作跨域的WEB-SSO 解压缩SSOAuth.zip文件，在/WEB-INF/下的web.xml中请修改“domainname”的属性以反映实际的应用部署情况，domainname需要设置为两个单点登录的应用（demo1和demo2）所属的域名。这个domainname和当前SSOAuth服务部署的机器的域名没有关系。我缺省设置的是“.sun.com”。如果你部署demo1和demo2的机器没有域名，请输入IP地址或主机名（如localhost），但是如果使用IP地址或主机名也就意味着demo1和demo2需要部署到一台机器上了。设置完后，根据你所选择的J2EE容器，可能需要将SSOAuth这个目录压缩打包成war文件。用“jar -cvf SSOAuth.war SSOAuth/”就可以完成这个功能。 解压缩SSOWebDemo1和SSOWebDemo2文件，分别在它们/WEB-INF/下找到web.xml文件，请修改其中的几个初始化参数 <init-param> <param-name>SSOServiceURL</param-name> <param-value>http://wangyu.prc.sun.com:8080/SSOAuth/SSOAuth</param-value> </init-param> <init-param> <param-name>SSOLoginPage</param-name> <param-value>http://wangyu.prc.sun.com:8080/SSOAuth/login.jsp</param-value> </init-param> 将其中的SSOServiceURL和SSOLoginPage修改成部署SSOAuth应用的机器名、端口号以及根路径（缺省是SSOAuth）以反映实际的部署情况。设置完后，根据你所选择的J2EE容器，可能需要将SSOWebDemo1和SSOWebDemo2这两个目录压缩打包成两个war文件。用“jar -cvf SSOWebDemo1.war SSOWebDemo1/”就可以完成这个功能。 请输入第一个web应用的测试URL（test.jsp）,例如http://wangyu.prc.sun.com:8080/ SSOWebDemo1/test.jsp，如果是第一次访问，便会自动跳转到登录界面，如下图 使用系统自带的三个帐号之一登录（例如，用户名：wangyu,密码：wangyu），便能成功的看到test.jsp的内容：显示当前用户名和欢迎信息。 请接着在同一个浏览器中输入第二个web应用的测试URL（test.jsp）,例如http://wangyu.prc.sun.com:8080/ SSOWebDemo2/test.jsp。你会发现，不需要再次登录就能看到test.jsp的内容，同样是显示当前用户名和欢迎信息，而且欢迎信息中明确的显示当前的应用名称（demo2）。