SSO单点登陆

标签: sso 登陆 | 发表时间:2015-03-27 17:34 | 作者:pitian
出处:http://www.iteye.com
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


已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [sso 登陆] 推荐:

SSO单点登陆

- - 行业应用 - ITeye博客
单点登录(Single Sign On, SSO)是企业应用集成中最常见的需求. 异构系统间往往都有各自的用户管理和身份验证机制,为. 避免用户在进行系统切换时频繁输入用户名和密码,因此必须要实现单点登录. 说到SSO的原理,先得说一般Web应用的身份验证原理. Web身份验证之所以能成为问题主要在于HTTP协议的无状态性,这导.

基于jasig的sso

- - 企业架构 - ITeye博客
整体的结构就是cas+shiro实现单点登录和权限管理. 怎么安装就不说了网上一大堆,在这总结一些问题的处理方法. 未能够识别目标'ST-2-jEo1qANhs9HgZ7VKC5Hf-cas'票根. 原因:是由于客户端应用web.xml配置中的casServerLoginUrl和casServerUrlPrefix两个URL属性的域名与证书中定义的不一致,或者你的地址配置的不对,配置serverUrl就到cas配置serviceUrl就到端口号.

CAS解决单点登录SSO

- - CSDN博客推荐文章
关于CAS很多的原理和基础的配置启动,网上是很多的,我更多是结合我的实践和心得. 需要了解CAS的原理,认证协议,认证流程,可以参考以下文章. 让CAS支持客户端自定义登陆页面——客户端篇. CAS原理与配置-基于CAS的单点登陆的研究(上). 单点登录(SSO)是企业开发的重要问题,在我的毕设项目中,由于要和系统其他开发模块共用用户认证模块,方便共享用户资源,所以需要一个好的SSO解决方案.

自己动手写SSO(单点登录)

- - ITeye博客
SSO在我们的应用中非常常见,例如我们在OA系统登录了,我们就可以直接进入采购系统,不需要再登录了,这样使我们非常方便. 现在网上也有很多实现方法,于是乎我也想写一个看看. 我主要用到的是cookie的机制. 在此,分享给大家, 同时提供源代码下载. SSO的实现一般是会有一个SSO Server,也会叫认证中心,同时也会有被认证的系统,如OA系统、采购系统等,他们就相当于SSO Server的client.

CAS实现SSO单点登录原理

- - 非技术 - ITeye博客
CAS实现SSO单点登录原理. CAS ( Central Authentication Service ) 是 Yale 大学发起的一个企业级的、开源的项目,旨在为 Web 应用系统提供一种可靠的单点登录解决方法(属于 Web SSO ). CAS 开始于 2001 年, 并在 2004 年 12 月正式成为 JA-SIG 的一个项目.

单点登录SSO的实现原理

- - 非技术 - ITeye博客
单点登录SSO(Single Sign On)说得简单点就是在一个多系统共存的环境下,用户在一处登录后,就不用在其他系统中登录,也就是用户的一次登录能得到其他所有系统的信任. 单点登录在大型网站里使用得非常频繁,例如像阿里巴巴这样的网站,在网站的背后是成百上千的子系统,用户一次操作或交易可能涉及到几十个子系统的协作,如果每个子系统都需要用户认证,不仅用户会疯掉,各子系统也会为这种重复认证授权的逻辑搞疯掉.

CAS单点登录(SSO)完整教程

- - 互联网 - ITeye博客
CAS单点登录(SSO)完整教程(2012-02-01更新). 教程目的:从头到尾细细道来单点登录服务器及客户端应用的每个步骤. 单点登录(SSO):请看百科解释. 本教程使用的SSO服务器是Yelu大学研发的CAS(Central Authentication Server),. CAS Server版本:cas-server-3.4.3.1、cas-server-3.4.10.

新浪微博开放平台SSO授权上线

- - 微博之博
作为一名普通微博用户,在手机上使用 新浪微博客户端,已经输入过自己的帐号及密码,是否期待手机上的第三方应用如360安全浏览器、唱吧等,可以识别当前的微博帐号,而不需要重新输入账号密码进行登陆. 近日,新浪微博开放平台 SSO授权的正式上线,帮助用户实现了这一愿望. SSO英文全称Single Sign On(单点登录),意指用户只需登录一次,就可以访问相互信任的其他应用系统.

新浪微博Android客户端SSO授权认证缺陷

- - BlogJava-首页技术区
转载请注明出处:  http://www.blogjava.net/zh-weir/archive/2013/09/08/403829.html. 新浪微博Android客户端SSO授权认证缺陷. 从最近几年开始,做平台的公司都流行起Open API. 这是一个非常好的理念,也受到广大开发者的欢迎.

新浪微博SSO授权以及分享(实战)

- - CSDN博客推荐文章
很多人不会使用第三方应用,特写此篇使用下第三方应用:代码具体如下:. // 应用的key 请到官方申请正式的appkey替换APP_KEY. // 替换为开发者REDIRECT_URL. // 新支持scope:支持传入多个scope权限,用逗号分隔. /** 显示认证后的信息,如AccessToken */.