单点登录

了解单点登录::

可以使用独立的单点登录应用ssoApp来做，这样可扩展性和安全性会更好。
1：用户访问App1的某个URL，App1通过cookie（必须加密）去单点登录服务器验证当前用户是否已经登录，如果没有登录，则跳转到单点登录应用的登录页面，并传递用户访问的URL。
2：用户提交用户名和密码，单点登录应用验证登录成功后跳转回App1,并传递token和sign(用于防止token被篡改)。
3：App1将返回的token和sign通过接口去单点登录应用进行验证，如果验证成功跳转用户访问的URL,并写入登录成功的cookie。
4：用户退出App1，清空登录验证的cookie。

那么即使新增一个app2或app3，照样可以支持单点登录。

 

 

 

====================================

1. SSO需求

单点登录（Single Sign On, SSO）是企业应用集成中最常见的需求。异构系统间往往都有各自的用户管理和身份验证机制，为

避免用户在进行系统切换时频繁输入用户名和密码，因此必须要实现单点登录。

2. SSO原理

说到SSO的原理，先得说一般Web应用的身份验证原理。Web身份验证之所以能成为问题主要在于HTTP协议的无状态性，这导

致了每次HTTP的请求和响应的无关性。而应用的状态保持是大部分应用系统的一般性需求，因此必须借助其他机制，这就是Cookie。

2.1. Cookie的原理

一个Cookie由name、value、domain、path、expires组成。可以给HTTP响应添加Cookie，然后Cookie就作为HTTP响应的

Headers返回给浏览器，例如Domino的登录成功后的Cookie响应头为：

Set-Cookie: DomAuthSessId=1AD479C4D11CD10278A4C523320A6918; path=/

没有设置expires就表示仅在当前浏览器进程生命期内有效，不保存到客户机上；若expires时间大于当前时间，则浏览器在收到

这个 Cookie以后将其写入到客户机文件中，一般是保存在C:\Documents and Settings\Administrator\Cookies\下。

没有设置domain就表示只在当前域内有效。

当客户机再次请求该域内的其他资源时，浏览器会自动将该域内的Cookie附在请求的Headers一起发送给Web服务器，形如：

Cookie: DomAuthSessId=1AD479C4D11CD10278A4C523320A6918

如此Web应用就能够通过读取HTTP请求Headers里面的Cookie值来判断用户身份，这样也就间接实现了HTTP的状态保持需

求。

2.2. SSO原理

了解的Cookie的原理以后就不难理解SSO的原理了。SSO的目的是为了实现两个或多个应用系统间的单点登录，其实现手段无
非是在登录A系统的 同时自动登录到B系统、C系统……，结合Cookie也就是说在SSO登录时同时去A系统、B系统、C系统进行验证，并将来自各系统的Cookie返回给 浏览器，就是这么简单。

一般情况下，做SSO要统一登录界面，这可以通过将各应用系统的登录界面重定向到指定的登录页来实现。

2.3. Cookie的局限

如果仅仅如上所说这么简单，那也就不会创造什么SSO的概念了。问题出在Cookie的domain上。出于浏览器安全的考虑，HTTP响应 Headers中的Cookie的domain只有与HTTP请求域（a.abc.com）一致或为上级域（abc.com）时，Cookie才能生效。

也就是说：

若A、B系统域名分别为a.abc.com和b.abc.com，登录系统A，同时写来自两个系统的Cookie到浏览器，且Cookie的domain设为.abc.com，那么浏览器是可以接受的，SSO成功。

若A、B系统域名分别为a.abc.com和b.xyz.com，登录系统A，同时写来自两个系统的Cookie到浏览器，其中A Cookie的domain设为.abc.com，B Cookie的domain设为.xyz.com，那么浏览器是不可以接受B Cookie的，因为该HTTP请求是来自.abc.com，因此不能写.xyz.com域中的Cookie。

这也就是跨域SSO难题的原因所在。

2.4. 跨域SSO

了解了Cookie的局限和跨域SSO难题所在，也就不难找到解决跨域问题的办法了：由各应用系统中创建各自域的Cookie并返回给浏览器。不要幻想在一个应用中创建所有域的Cookie，这是徒劳的。

至于如何一次性在各应用系统中创建各自域的Cookie并返回给浏览器，这就仁者见仁智者见智了，一般常见的做法是：

在SSO验证成功的返回页中利用JS脚本动态创建隐藏的IFRAME，并将验证信息通过IFRAME的SRC属性的URL参数传递给各应用系统的某 个资源，这些资源可以是动态程序也可以是JS脚本，由各应用系统的动态程序或JS脚本根据传入的参数来完成该应用的验证过程并返回验证通过的 Cookie。

下文说的做法与上略有不同，我的想法是：只在请求哪个应用系统时才进行哪个应用系统的身份验证，而不是一次性全将所有身份都验证完毕。

3. Domino SSO 实现

Domino 的用户信息和身份验证是通过目录（NAMES.NSF ）来实现的；J2EE 系统也往往有自己开发的用户管理和身份验证机制。要实现二者的SSO ，可以通过部署统一的身份认证应用来完成。

要部署唯一的SSO 应用有三个选择：

l 扩展Domino 的身份认证功能，提供SSO 服务；

l 扩展J2EE 系统的身份认证功能，提供SSO 服务；

l 部署单独的SSO 应用，提供SSO 服务；

Domino 的身份认证在names.nsf 中进行，登录界面在domcfg.nsf 中，通过提交包含用户名（username ）和密码（password ）的请求到路径/names.nsf?Login 即可完成验证过程。但Domino 验证是通过其内在机制实现的，没有给开发者提供任何显示的程序代码（如何进行用户名和口令校验的代码），因此无法对Domino 的验证过程直接进行扩展。

J2EE 系统本身的用户管理和身份认证往往都由我们自行设计的，因此可以在此基础上扩展实现单点登录，我们这里采用的即是这种方案。

此外，也可以开发单独的SSO 应用，集成Domino 和J2EE 系统登录过程，本质上与在J2EE 系统基础上扩展没有区别，这里不再赘述。

3.1. Domino Cookie

前面已经提过SSO 的原理就是Cookie ，所以有必要了解Domino 系统的Cookie 。

Domino 系统根据服务器配置的不同有两种Cookie 来进行会话状态的维持。

l 单服务器，服务器返回给浏览器的Cookie 名是：DomAuthSessId 。

l 多个服务器（SSO ），服务器返回给浏览器的Cookie 名是：LtpaToken ，这是IBM 一套轻量级第三方认证标准，自动支持Websphere 和Lotus 之间的SSO 。

3.2. Domino系统设置

1. 配置Domino 的登录页

用Notes 打开domcfg.nsf 数据库，打开”Sign In Form Mapping “配置文档，设置登录页为domcfg.nsf 里的SSOLoginForm 表单。

2. 将Domino 登录页重定向到J2EE

用Designer 打开domcfg.nsf\SSOLoginForm ，通过脚本将其重定向到SSO 登录页：

 

js 代码

<script language=”javascript”>
parent.location.href = “http://www.j2ee.com/loginAction.do?method=login&redirectTo=< 计算文本>”;
</script>

 

其中该计算文本为RedirectTo 值，记录用户原始请求的DominoURL 。

3.3. J2EE系统SSO开发

3.3.1. SSO 登录界面

在SSO登录表单中，除了必要的用户名和口令输入框之外，还应有一个属性redirectTo来记录登录后的重定向路径。当用户访问某个受限资源时，系统自动重定向到该登录界面，同时记录该受限资源的路径，当输入用户名和口令并验证成功以后，系统自动将用户重定向到该受限资源处，而不是简单的返回到缺省首页。

3.3.2. SSO 验证程序

J2EE 系统自身的验证还是才有传统的用户名和口令校验方式。当检查来自客户端的访问请求是去往Domino 系统时，将自动进行Domino 的验证并重定向到相应的Domino 页面。自动Domino 验证分为两个步骤：

1. 程序自动从服务器后台通过Http URLConnection 访问Domino 系统并登录，若验证通过则读取相应的Cookie 值；

单服务器的form-based 方式验证获取Cookie 及重定向URL 代码如下：

java 代码

URL url = new URL(httpHost + “names.nsf?Login”);

HttpURLConnection.setFollowRedirects(false);

HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();

urlConnection.setDoOutput(true);

OutputStreamWriter wr = new OutputStreamWriter(urlConnection.getOutputStream());

wr.write(”username=” + userName + “&password=” + password);

wr.flush();

wr.close();

urlConnection.connect();

Map

for (Iterator<string> it = headerFields.keySet().iterator(); it.hasNext(); ) {  </string>

String key = it.next();

if (key != null && key.equals(”Set-Cookie”)) {

String value = urlConnection.getHeaderField(key);

String[] cookies = value.split(”;\\s*”);

for (int i = 0; i < cookies.length; i++) {

String[] cookie = cookies[i].trim().split(”=”);

if (cookie[0].equals(”DomAuthSessId”)) {

successful = true;

loginURL = httpHost + “domcfg.nsf/SSOLoginAction?OpenAgent”;

loginURL += “&cookeName=DomAuthSessId”;

loginURL += “&cookeValue=” + cookie[1];

break;

}

}

}

}

urlConnection.disconnect();

 

多服务器（SSO ）方式获取Cookie 及重定向URL 代码如下：

java 代码

Session session = NotesFactory.createSession(serverName, userName, password);

if (session != null && session.isValid()) {

successful = true;

loginURL = httpHost + “domcfg.nsf/SSOLoginAction?OpenAgent”;

loginURL += “&cookeName=LtpaToken”;

loginURL += “&cookeValue=” + URLEncoder.encode(session.getSessionToken(), “UTF-8″);

}

 

2. 程序将获取的Cookie 名称、Cookie 值以及目的资源地址通过URL 参数的方式传给一个Domino 的代理（也即上述代码中的变量loginURL ），由Domino 代理写Cookie 并重定到向目的资源地址。Domino 代理SSOLoginAction 也非常简单，代码示意如下：

Domino 代码

cookieName$ = request.GetParameter(”cookeName”)

cookieValue$ = request.GetParameter(”cookeValue”)

redirectTo$ = request.GetParameter(”redirectTo”)

Print {Set-Cookie:} + cookieName$ + {=} + cookieValue$ + {; path=/}

Print {Location: } + redirectTo$ + {}

 

其中request.GetParameter 是自定义类方法，用以获取URL 中的参数值。

如此，J2EE 与Domino 系统间的跨域SSO 就顺利实现J