SSO单点登录办理方案
副标题#e#
1 什么是单点登岸
单点登录（Single Sign On），简称为 SSO，是今朝较量风行的企业业务 整合的办理方案之一。SSO的界说是在多个应用系统中，用户只需要登录一次就可以会见所有彼此信任的应用系统。
较大的企业内部，一般都有许多的业务支持系统为其提供相应的打点和IT处事。譬喻 财政系统为财政人员提供财政的打点、计较和报表处事；人事系统为人事部分 提供全公司人员的维护服 务；各类业务系统为公司内部差异的业务提供差异的处事等等。这些系统的目标都是让计较机来 举办复 杂繁琐的计较事情，来替代人力的手 工劳动，提高事情效率和质量。这些差异的系统往往是在差异的时 期建树起来的，运行在差异的平台上；也许是由差异厂商开拓，利用了各类差异的技能和尺度。如 果举 例说海内一著名的IT公司（名字隐去），内部共有60多个业务系统，这些系统包罗两个差异版本的SAP的 ERP系统，12个差异范例和版本的数据库系 统，8个差异范例和版本的操纵系统，以及利用了3种差异的 防火墙技能，尚有数十种相互不能兼容的协议和尺度，你相信吗？不要猜疑，这种环境其实很是普遍。 每一个应用系统在运行了数年今后，城市成为不行替换的企业IT架构的一部门，如下图所示。
跟着企业的成长，业务系统的数量在不绝的增加，老的系统却不能等闲的替换，这会带来许多的开销 。其一是打点上的开销，需要维护的系统越来越多。许多系统的 数据是彼此冗余和反复的，数据的纷歧 致性会给打点事情带来很大的压力。业务和业务之间的相关性也越来越大，譬喻公司的计费系统和财政 系统，财政系统和人事 系统之间都不行制止的有着密切的干系。
为了低落打点的耗损，最大限 度的重用已有投资的系统，许多企业都在举办着企业应用集成（EAI）。企业应用集成可以在差异层面上 举办：譬喻在数据存储层面 上的“数据大会合”，在传输层面上的“通用数据互换平 台”，在应用层面上的“业务流程整合”，和用户界面上的“通用企业派别 ”等等。事实上，还用一个层面 上的集成变得越来越重要，那就是“身份认证”的整 合，也就是“单点登录”。
凡是来说，每个单独的系统城市有本身的安详体系和身份 认证系统。整合以前，进入每个系统都需要举办登录，这样的排场不只给打点上带来了很大的坚苦，在 安详方面也埋下了重大的隐患。下面是一些著名的观测公司显示的统计数据：
用户天天平均16分 钟花在身份验证任务上 – 资料来历：IDS
频繁的IT用户平均有21个暗码 – 资料来历：NTA Monitor Password Survey
49%的人写下了其暗码，而67%的人很少改变它们
每79秒呈现一 起身份被窃事件 – 资料来历：National Small Business Travel Assoc
全球欺骗损失每年约12B – 资料来历：Comm Fraud Control Assoc
到2007年，身份打点市场将成倍增长至$4.5B – 资料来 源：IDS
利用“单点登录”整合后，只需要登录一次就可以进入多个系统，而不需要 从头登录，这不只仅带来了更好的用户体验，更重要的是低落了安详的风险和打点的耗损。请看下面的 统计数据：
提高IT效率：对付每1000个受管用户，每用户可节减$70K
辅佐台呼唤淘汰至 少1/3，对付10K员工的公司，每年可以节减每用户$75，可能合计$648K
出产力提高：每个新员工 可节减$1K，每个老员工可节减$350 – 资料来历：Giga
ROI回报：7.5到13个月 – 资料来历： Gartner
别的，利用“单点登录”照旧SOA时代的需求之一。在面向处事的架构中，服 务和处事之间，措施和措施之间的通讯大量存在，处事之间的安详认证是SOA应用的难点之一，应此成立 “单点登录”的系统体系可以或许大大简化SOA的安详问题，提高处事之间的相助效率。
#p#副标题#e#
2 单点登岸的技能实现机制
跟着SSO技能的风行，SSO的产物也是满天飞扬。所有著名的软件厂商都 提供了相应的办理方案。在这里我并不想先容本身公司（Sun Microsystems）的产物，而是对SSO技能本 身举办理会，而且提供本身开拓这一类产物的要领和简朴演示。有关我写这篇文章的目标，请参考我的 博 客（http://yuwang881.blog.sohu.com/3184816.html）。
单点登录的机制其实是较量简朴的 ，用一个现实中的例子做较量。颐和园是北京著名的旅游景点，也是我常去的处所。在颐和园内部有许 多独立的景点，譬喻“苏州 街”、“佛香阁”和“德和园”，都可以 在各个景点门口单独买票。许多旅客需要游玩所有德景点，这种买票方法很不利便，需要在每个景点门 口列队买票，钱包拿 进拿出的，容易丢失，很不安详。于是绝大大都旅客选择在大门口买一张通票（也 叫套票），就可以玩遍所有的景点而不需要从头再买票。他们只需要在每个景点门 口出示一下适才买的 套票就可以或许被答允进入每个独立的景点。
#p#分页标题#e#
单点登录的机制也一样，如下图所示，当用户第一次访 问应用系统1的时候，因为还没有登录，会被引导到认证系统中举办登录（1）；按照用户提供的登录信 息， 认证系统举办身份效验，假如通过效验，应该返回给用户一个认证的根据－－ticket（2）；用户 再会见此外应用的时候（3，5）就会将这个ticket 带上，作为本身认证的根据，应用系统接管到请求之 后会把ticket送到认证系统举办效验，查抄ticket的正当性（4，6）。假如通过效验，用户就可 以在不 用再次登录的环境下会见应用系统2和应用系统3了。
从上面的视图可以看 出，要实现SSO，需要以下主要的成果：
所有应用系统共享一个身份认证系统。
统一的认 证系统是SSO的前提之一。认证系统的主要成果是将用户的登录信息和用户信息库对较量，对用户举办登 录认证；认证乐成后，认证系统应该生成统一的认证符号（ticket），返还给用户。别的，认证系统还 应该对ticket举办效验，判定其有效性。
所有应用系统可以或许识别和提取ticket信息
要实 现SSO的成果，让用户只登录一次，就必需让应用系统可以或许识别已经登录过的用户。应用系统应该能对 ticket举办识别和提取，通过与认证系统的通讯，能自动判定当前用户是否登录过，从而完成单点登录 的成果。
上面的成果只是一个很是简朴的SSO架构，在现实环境下的SSO有着越发巨大的布局。有 两点需要指出的是：
单一的用户信息数据库并不是必需的，有很多系统不能将所有的用户信息都 会合存储，应该答允用户信息安排在差异的存储中，如下图所示。事实上，只要统一认证系统，统一 ticket的发生和效验，无论用户信息存储在什么处所，都能实现单点登录。
统一 的认证系统并不是说只有单个的认证处事器，如下图所示，整个系统可以存在两个以上的认证处事器， 这些处事器甚至可以是不 同的产物。认证处事器 之间要通过尺度的通讯协议，相互互换认证信息，就 能完成更高级此外单点登录。如下图，当用户在会见应用系统1时，由第一个认证处事器举办认证后，得 到由此 处事器发生的ticket。当他会见应用系统4的时候，认证处事器2可以或许识别此ticket是由第一个服 务器发生的，通过认证处事器之间尺度的通讯协议 （譬喻SAML）来互换认证信息，仍然可以或许完成SSO的 成果。
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处事器才气够同时处事于成 千上万的客户端。
#p#分页标题#e#
可是我们凡是的应用是有状态的。先不消提差异应用之间的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/”就可以完成这个成果。
#p#分页标题#e#
请输入第一个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）。
3.2 WEB-SSO代码讲授
3.2.1身份认证处事代码理会
Web-SSO的源代码可以从网站地点 http://gceclub.sun.com.cn/wangyu/web-sso/websso_src.zip下 载。身份认证处事是一个尺度的web应 用，包罗一个名为SSOAuth的Servlet，一个login.jsp文件和一个failed.html。身份 认证的所有处事几 乎都由SSOAuth的Servlet来实现了；login.jsp用来显示登录的页面（假如发明用户还没有登录过）； failed.html是用来显示登录失败的信息（假如用户的用户名和暗码与信息数据库中的纷歧样）。
SSOAuth的代码如下面的列表显示，布局很是简朴，先看看这个Servlet的主体部门：
package DesktopSSO;
import java.io.*;
import java.net.*;
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 cookiename="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("wangyu", "wangyu");
accounts.put("paul", "paul");
accounts.put("carol", "carol");
}
protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
PrintWriter ut = response.getWriter();
String action = request.getParameter ("action");
String result="failed";
if (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);
out.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()的要领中可以看到我 给系统添加了三个正当的用户。在实际应用中，accounts应该是去 数据库中或LDAP中得到，为了简朴起见，在本样例中我利用了 ConcurrentMap在内存顶用措施建设了三 个用户。而SSOIDs生存了在用户乐成的登录后所发生的cookie和用户名的对应干系。它的成果显 而易见 ：当用户乐成登录今后，再次会见此外系统，为了辨别这个用户请求所带的cookie的有效性，需要到 SSOIDs中查抄这样的映射干系是否存在。
在主要的请求处理惩罚要领processRequest()中，可以很清 楚的看到SSOAuth的所有成果。
假如用户还没有登录过，是第一次登录本系统，会被跳转到 login.jsp页面（在后头会表明如何跳转）。用户在提供了用户名和暗码今后，就会用 handlerFromLogin()这个要领来验证。
#p#分页标题#e#
假如用户已经登录过本系统，再会见此外应用的时候，是 不需要再次登录的。因为欣赏器会将第一次登录时发生的cookie和请求一起发送。效验cookie的有效性 是SSOAuth的主要成果之一。
SSOAuth还能直接效验非login.jsp页面过来的用户名和暗码的效验 请求。这个成果是用于非web应用的SSO，这在后头的桌面SSO中会用到。
SSOAuth还提供logout服 务。
下面看看几个主要的成果函数：
private void handlerFromLogin (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().getRequestDispatcher("/failed.html").forward(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.setPath("/");
response.addCookie(wangyu);
System.out.println("login success, goto back url:" + gotoURL);
if (gotoURL != null) {
PrintWriter ut = response.getWriter();
response.sendRedirect(gotoURL);
out.close();
}
}
}
handlerFromLogin()这个要领是用来处理惩罚来自login.jsp的登录请求。它的逻辑 很简朴：将用户输入的用户名和暗码与预先设定好的用 户荟萃（存放在accounts中）对较量，假如用户 名或暗码不匹配的话，则返回登录失败的页面（failed.html），假如登录乐成的话，需要为用 户当前 的session建设一个新的ID，并将这个ID和用户名的映射干系存放到SSOIDs中，最后还要将这个ID配置为 欣赏器可以或许生存的cookie 值。
登录乐成后，欣赏器会到哪个页面呢？那我们回首一下我们是如 何利用身份认证处事的。一般来说我们不会直接会见身份处事的任何URL，包罗 login.jsp。身份处事是 用来掩护其他应用处事的，用户一般在会见一个受SSOAuth掩护的Web应用的某个URL时，当前这个应用会 发明当前的 用户还没有登录，便强制将也页面转向SSOAuth的login.jsp，让用户登录。假如登录乐成后 ，应该自动的将用户的欣赏器指向用户最初想会见的那 个URL。在handlerFromLogin()这个要领中，我 们通过吸收“goto”这个参数来生存用户最初会见的URL，乐成后便从头定向到这个页 面中 。
别的一个要说明的是，在配置cookie的时候，我利用了一个setMaxAge(6000)的要领。这个方 法是用来配置cookie的有效期，单元是 秒。假如不利用这个要领可能参数为负数的话，当欣赏器封锁的 时候，这个cookie就失效了。在这里我给了很大的值（1000分钟），导致的行为是：当你 封锁欣赏器（ 可能关机），下次再打开欣赏器会见适才的应用，只要在1000分钟之内，就不需要再登录了。我这样做 是下面要先容的桌面SSO中所需要的功 能。
其他的要领越发简朴，这里就不多表明白。
3.2.2具有SSO成果的web应用源代码理会
要实现WEB-SSO的成果，只怀孕份认证处事是不足的。这点很显然，要想使多个应用具有单点登录的 成果，还需要每个应用自己的共同：将本身的身份认证的 处事交给一个统一的身份认证处事－SSOAuth 。SSOAuth处事中提供的各个要领就是供每个插手SSO的Web应用来挪用的。
