SSO概述主要实现方式产品相关协议.docx

资源描述

SSO概述主要实现方式产品相关协议.docx

《SSO概述主要实现方式产品相关协议.docx》由会员分享，可在线阅读，更多相关《SSO概述主要实现方式产品相关协议.docx（9页珍藏版）》请在冰豆网上搜索。

SSO概述主要实现方式产品相关协议.docx

SSO概述主要实现方式产品相关协议

单点登录SSO（SingleSignOn）介绍

抛开前人成果，细细想来无非存储信任，验证信任，作用范围和安全性。

粗略想想采用cookie或者单独的管理系统应该都能实现，貌似也不是很遥远的东西，但是真正做好还有很远的路。

一、SSO的两种架构

集中验证：

各系统登录交由专门的信任验证服务器完成登录动作，统一了用户账户密码，但是一旦验证服务器宕机SSO功能将全部丧失；

多点验证：

登录动作由各个系统完成，任何一台服务器宕机都不会影响其他系统，容错性好，各系统账户密码难以统一，用户体验差，技术上存在跨域问题；

二、SSO三种实现技术

代理登录（agent）：

用于无法改造的旧系统；

令牌环（token）：

通过Cookie共享令牌环的方式传递当前用户信息，实现SSO，存在跨域问题；

身份票据（ticket）：

除了增加一台信任验证服务器，完全满足了存储信任，验证信任，作用范围和安全性的问题，也是适用最广的webSSO实现方式（接下来的CAS会具体讲解）

三种实现技术比较

比较项

代理登录

令牌环

身份票据

需求实现程度

无法实现同时切换用户与会话同时过期

全部

对原系统改造

无

小量改造

安全性

低

高

稳定性

偏低

好

性能开销

登录瞬间压力大一点

非常小

较小

适用范围

同域，对用户密码不一致的系统，需在登录服务器的用户凭证库保存用户密码映射

同域，对不同登录名需增加对用户凭证库的访问

所有可改造的系统，对不同登录名需在登录服务器的用户凭证库保存用户映射

独立验证服务器

需要

不需要

需要

登录模式支持

集中验证模式

集中验证模式/多点验证模式

集中验证模式

商业产品

UTrust

国内领先的支持C－S和B-S架构的单点登录实现机制UTrustSSO（Singlesign-on）系统是针对国内企事业信息化发展现状而开发的应用系统管理软件。

面对用户的重复登陆，系统管理员繁琐的账号管理工作和系统设置工作，以及如何控制用户的访问权限等问题，UTrust　SSO提供了一个完善的解决方案，在异构的IT系统中实现应用系统单点登录，简化用户的登录过程，同时提供集中和便捷的身份管理、安全的认证机制、权限管理和审计，以满足企业对信息系统使用的方便性和安全管理的需求。

2.系统功能和特点UTrustSSO单点登录系统提供灵活模块化的解决方案，用户可以将后台应用系统（B/S结构的WEB应用系统和C/S结构的应用系统）和UTrustSSO单点登录系统无缝整合在一起，无须修改原有应用系统

IBM的SSO:

TIM,TAM

部署思考

其实这2个东西作为IBM提供的身份管理基础平台,还是有自身的一些优势的,这个IBM自己会做广告.

我考虑的是如果一个企业要采用这套身份管理解决方案,不仅要看到它的优点,还要看到它的不足.

1国内一般企业并没有一个成熟的IT管理和使用规范,所以及时上了这套系统,一般人也不一定能够按照要求使用好这些软件.考虑到软件本来是作为一种支持工具或者为人提供的特定服务存在的,根本问题还是人的问题.即使工具再高级,如果人的it意识不够合格的话,那么实施更多的IT产品恐怕也是一场噩梦的开始.

2TAM单点还是有限制的,比如对非标准系统的支持不够,页面集成后调试复杂等等.另外一个就是性能的问题,对于动辄上万人访问的门户系统,如果一般企业没有互联网公司的集群经验的话,恐怕仅仅靠2,3台服务器也悬.这方面需要给出具体的数字,如果过w的话应该至少要2台webseal的集群.

3TIM的性能问题,一般4,5k人用一台即可.还包括组织结构的设计,人员的导入和处理,将来的维护等等.或者做到各组织结构同步,或者按照IBM推荐的方法只是把人员分成逻辑的架构.但是考虑到中国国情,我们还是系统能从TIM里面反映出部门调动的情况,所以必须考虑如何解决转移人员部门的问题.还有tim的密码策略,等等.

在采用一套方案前,一定要明白它的优点和缺点,也算是做决定前的一个风险评估吧.

（IBM）TAMeb

是IBM实现企业单点登录的解决方案产品之一，通过TAMeb能集中进行应用级别的认证和授权，

实现不同类型系统的单点登录。

下面就简单介绍一下

TAMeb实现用户单点登录的几种方式：

1、基于LTPA;2、代填表单;3、数字证书;4、基于HTTP请求头。

1.基于LTPA的单点登录

名词说明：

LTPA（Lightweightthirdpartyauthentication）

是IBM提供的基于cookie的轻量级的认证方式，如果需要实现SSO的环境为IBM提供的各种中间件，那么使用LTPA将是最佳的方式。

Webseal是TAM（TivoliAccessmanager）的关键组件，它相当于一个反向代理器，所有的请求将被它所截获，然后由它进行处理转发。

场景描述：

当用户发出一个URL请求到WAS（WebsphereApplicationServer）等支持LTPA（Domino、WPS）的应用，系统要求输入“用户/密码”，

输入并提交后用户就可以访问这个WAS的应用，接着当用户再访问Domino等其它支持LTPA的应用，此时无需再次输入“用户/密码”

信息即可以访问Domino（等其它支持LTPA）下的web应用了。

过程说明：

首先需要在多个服务器以及TAM的Webseal上配置基于LTPA的信任关系，经过配置后的服务器之间建立了信任，

当其中一个服务器认证通过后，再去访问其它已经建立过信任关系的服务器时，因为它们之间彼此是信任的，所以就无需再次认证了。

下面以WAS、Domino和Webseal来简单说明一下LTPA信任的配置过程：

◆在WASServer上生成LTPAKey，并启用LTPA进行安全认证

◆在DominoServer导入上面生成的LTPAKey，并配置DominoServer使用LTPA进行认证

◆在Webseal上基于上面生成的LTPAKey创建到WAS和Domino的Junction通过上述配置就完成了基于LTPA的单点登录，

下面以图示来详细说明认证过程的流程：

（1）用户发出一个URL请求到WAS，此请求被Webseal拦截，Webseal定向到它内置的一个form表单，要求输入用户/密码进行认证;

（2）Webseal拿着输入的用户/密码到LDAPserver进行用户鉴别

（3）Webseal认证成功后生成一个LTPA的Token，并将请求转发到WAS端，WAS收到请求后，发现此请求含有LTPA的Token，

因为之前已经配置了它和Webseal以及Domino的信任关系，所以WAS不再要求进行认证，直接将请求的响应返回，用户收到所需的页面信息响应;

（4）用户再次访问Domino的Web应用，此请求被Webseal拦截;

（5）因为Webseal之前缓存了LTPA的Token，它快速检查了请求信息是来自它所信任的WAS，所以不需要再与LDAPServer进行用户信息的鉴别，

它把请求直接转给Domino，因为Domino和Webseal是信任的，所以也不需要再次认证，Domino将直接返回Webseal的请求结果。

2.基于代填表单的单点登录

场景描述：

系统A存在帐号usr1/pwd1，系统B存在帐号usr2/pwd2，通过TAMwebseal建立一个新的帐号count1/password1，

并建立与系统A和系统B的帐号对应关系（这种关系被保存到TAM中）。

当用户访问系统A时，要求输入用户和密码，这时输入webseal的帐号信息，

提交后用户可以访问系统A，并在系统A显示当前用户是usr1（而不是count1），当用户接着访问系统B时不需要再次输入帐号信息，单点登录到系统B，

同时在系统B显示当前用户是usr2。

这种单点登录的方式对于已有系统例如系统A和系统B不用做过多修改，不过需要维护它们之间帐号的对应关系

过程说明：

首先要在TAMwebseal上创建新用户count1，并创建与系统A的帐号usr1和系统B的帐号usr2的映射关系;

pdadminsec_master>rsrccredcreatesysArsrcuserusr1rsrcpwdpwd1rsrctypeweb

usercount1pdadminsec_master>rsrccredcreatesysBrsrcuserusr2rsrcpwdpwd2rsrctypewebusercount1

然后，根据模板建立两个SSO的配置文件，并启动代填表单的设置;

pdadmin>servertaskwebseald-cruzcreate-ttcp-hwebsvrA-S

/opt/pdweb/fSSO/fSSOsysA.conf/jctX

[login-page-one]

acOperator/userid=gso:

username

acOperator/password=gso:

password

pdadmin>servertaskwebseald-cruzcreate-ttcp-hwebsvrB-S/opt/pdweb/fSSO/fSSOsysB.conf/jctX

[login-page-one]login-page=/sysB/login.jspacOperator/userid=gso:

usernameacOperator/password=gso:

password

（1）当用户请求到系统A时，Webseal拦截此请求，并要求输入帐号信息，用户输入Webseal的帐号信息并提交;

（2）Webseal进行认证并通过认证;

（3）Webseal认证完成后根据之前的配置去查找对应的系统A的帐号，并调用login-page=/sysA/login.jsp进行页面提交登录到系统A;

（4）当用户接着请求到系统B时，Webseal拦截此请求;

（5）因为之前已经缓存了Webseal的帐号信息，所以Webseal只需查看当前请求的上下文找到对应的系统B的帐号，

并调用login-page=/sysB/login.jsp进行页面提交登录到系统B

3.通过数字证书实现单点登录

场景描述：

用户访问WAS系统，系统提示输入帐号进行验证，之后当用户再访问系统A时则提示选择数字证书进行认证，用户选择并确定数字证书后即登录系统A。

过程说明：

首先要建立CAcenter、Webseal、系统A之间的信任关系，步骤如下

（1）CACenter给Webseal颁发服务器证书和根证书，Webseal将这两个证书导入;

（2）CACenter给系统A颁发服务器证书和根证书，系统A也导入这两个证书;

（3）在客户端浏览器导入CACenter颁发的用户证书和根证书;

上述3个步骤完成了CAcenter与Webseal以及系统A的证书信任过程，它们都有来自CACenter的根证书，此外客户端也拥有了根证书;

然后在Webseal配置“保护对象策略”（ProtectedObjectPolicies）是数字证书的方式，并配置到此POP的资源是系统A;

pdadminsec_master>popcreatesysA_pop

pdadminsec_master>popmodifysysA_popsetipauthanyothernw2

pdadminsec_master>popattach/WebSEAL/webseald-cruz/sysAsysA_pop

（1）当用户请求WAS应用时，Webseal要求输入用户名和密码，完成登录;

（2）当用户接着请求到系统A时，Webseal根据之前设定要求数字证书的验证，浏览器弹出数字证书选择对话框（用户数字证书已在浏览器客户端导入）

，用户选择自己对应的数字证书后通过认证进入系统A

4.自行的用户认证和授权Webseal在完成SSO之后通过Httpheader向其它系统提供帐号信息，其它系统利用此信息分解出帐号，

然后自行进行用户授权或者认证和授权

场景描述：

用户访问系统A，经过WebSEAL进行验证之后，Webseal通过HTTPHeader向系统A提供用户身份信息，

系统A接收到HTTPHeader传递的用户信息后自行处理。

过程说明：

（1）创建到系统A的httpheader;servertaskwebseald-cruzcreate-ttcp-hIPaddress-p8080-civ-user-x-f/sysA

（2）用户访问系统A应用时，Webseal拦截用户请求，并要求输入帐号进行认证;

（3）用户完成帐号输入并提交，然后Webseal通过认证后将用户信息放到httpheader中转发给系统A、接收程序接收;

（4）系统A接收到Webseal的请求后，进行分析取出用户信息，示例代码如下：

Stringusername=request.getHeader（"iv-user"）;

WebLogic的SSO

bea后来被oracle公司收购。

现在已经都由oracle公司进行服务。

bea的weblogic只出到9.x的版本。

基本现在的10.x以及更高都换成oracle的。

其实两个是一样的。

在WebLogic 8.1最新的SP4版本中，最引人注目的要算是在安全方面，提供了用于和MicrosoftWindows客户端进行SingleSign-On的SinglePassNegotiateIdentityAssertionProvider。

通过该Provider可以轻松完成从前认为技术难度很高的和Windows客户端的SingleSign-On。

　　这个简单，低成本的SSO解决方案相信对大多数的企业应用来说更具吸引力：

1.用户只需要开机时登录Windows域，就可以以登录用户的身份访问全部的基于WebLogicServer，IIS等的应用系统；

2.在后续的访问中，用户将不需要重新输入口令，这样使得口令不会以明文形式在内网传递，来自内网的安全威胁被降低了（企业的主要网络安全威胁来自内网），如果在内网启用SSL则成本太高；

3.只需要一次验证，因此不论是AD还是其他的存储用户信息的关系数据库，LDAP等，验证的开销降低了；

4.极大改善用户体验，提高了IT服务品质，也提高了用户的工作效率

　　在成本方面，对比一些SSO产品，简单的说：

1.不需要添置新的硬件，不需要购买新的软件License，并且可以充分利用大多数企业中非常成熟的MSAD资源；

*而一些SSO产品，不仅需要添加新硬件，购买License，而且成熟的部署往往涉及到LoadBalance，Failover等，成本骤然升高

2.不需要专门的运营维护人员，不需要专门的技术支持人员对服务器进行管理，现有的IT团队即可胜任，成本被进一步降低；

3.安装配置简单，不需要安装独立的软件，操作人员不需要专门的知识背景；

*对比一些SSO产品超厚的文档手册，以及一次又一次的培训等

　　因此这使得大多数的SSO产品厂商面临了更大的挑战。

在应用安全技术突飞猛进，SSO市场竞争激烈的今天，用户将有越来越多的自由去选择适合自己的SSO解决方案，用户将最终获益。

所以我们要感谢那些为今天这些技术的发展做出贡献的人们。

开源产品

Cas架构实现SSO

首先，cas是一个独立的项目。

就是一个war包，部署在tomcat上面启动就ok。

然后我们要实现单点登陆，无疑是访问系统1，如果没有登录，就跳转到cas服务器上面，然后进行登陆，登陆ok之后，又从cas服务跳转到系统1的界面，然后访问系统2的时候，直接就可以访问了，不用再次登陆。

你要问如何实现各种跳转呢？

那就需要我们在cas服务上和我们的子系统上面做出相应的配置的就ok。

不用写代码。

很爽有木有。

CAS默认使用的是HTTPS协议，如果使用HTTPS协议需要SSL安全证书（需向特定的机构申请和购买）。

如果对安全要求不高或是在开发测试阶段，可使用HTTP协议。

我们这里讲解通过修改配置，让CAS使用HTTP协议。

OpenSSO

OpenAM简介:

OpenAM是一个开源的访问管理、授权服务平台。

由ForegeRock公司发起。

OpenAM前身为OpenSSO，由SUN公司创建，现在属于Oracle。

OpenAM是一个领先的开源认证、授权的产品，可用于替换即将被取消的 OpenSSO。

OpenAM提供核心的标识服务用来简化实现在一个网络架构中的透明单点登录，包括集中式或者分布式的单点登录。

主要的特性有：

完全符合开源AAA产品；

AAA协议：

计算机安全领域的协议，AAA指：

鉴权，授权，计费（Authentication,Authorization,Accounting）

简单易用、易配置；

纯Java开发；

可轻松配置联合认证系统，并集成到已有项目中。