TAMeb（IBM Tivoli Access Manager for e-business）是IBM实现企业单点登录的解决方案产品之一，通过TAMeb能集中进行应用级别的认证和授权，实现不同类型系统的单点登录。下面就简单介绍一下TAMeb实现用户单点登录的几种方式：1、基于LTPA；2、代填表单；3、数字证书；4、基于HTTP请求头。
1. 基于LTPA的单点登录
名词说明：
LTPA（Lightweight third party）是IBM提供的基于cookie的轻量级的认证方式，如果需要实现SSO的环境为IBM提供的各种中间件，那么使用LTPA将是最佳的方式。
Webseal是TAM（Tivoli Access manager）的关键组件，它相当于一个反向代理器，所有的请求将被它所截获，然后由它进行处理转发。
场景描述：
当用户发出一个URL请求到WAS（Websphere Application Server）等支持LTPA（Domino、WPS）的应用，系统要求输入“用户/密码”，输入并提交后用户就可以访问这个WAS的应用，接着当用户再访问Domino等其它支持LTPA的应用，此时无需再次输入“用户/密码”信息即可以访问Domino（等其它支持LTPA）下的web应用了。
过程说明：
首先需要在多个服务器以及TAM的Webseal上配置基于LTPA的信任关系，经过配置后的服务器之间建立了信任，当其中一个服务器认证通过后，再去访问其它已经建立过信任关系的服务器时，因为它们之间彼此是信任的，所以就无需再次认证了。
下面以WAS、Domino和Webseal来简单说明一下LTPA信任的配置过程：
◆在WAS Server上生成LTPA Key，并启用LTPA进行安全认证
◆在Domino Server导入上面生成的LTPA Key，并配置Domino Server使用LTPA进行认证
◆在Webseal上基于上面生成的LTPA Key创建到WAS和Domino的Junction
通过上述配置就完成了基于LTPA的单点登录，下面以图示来详细说明认证过程的流程：
（1）用户发出一个URL请求到WAS，此请求被Webseal拦截，Webseal定向到它内置的一个form表单，要求输入用户/密码进行认证；
（2） Webseal拿着输入的用户/密码到LDAP server进行用户鉴别；
（3） Webseal认证成功后生成一个LTPA的Token，并将请求转发到WAS 端，WAS收到请求后，发现此请求含有LTPA的Token，因为之前已经配置了它和Webseal以及Domino的信任关系，所以WAS不再要求进行认证，直接将请求的响应返回，用户收到所需的页面信息响应；weight的几种形式
（4）用户再次访问Domino的Web应用，此请求被Webseal拦截；
（5）因为Webseal之前缓存了LTPA的Token，它快速检查了请求信息是来自它所信任的WAS，所以不需要再与LDAP Server进行用户信息的鉴别，它把请求直接转给Domino，因为Domino和Webseal是信任的，所以也不需要再次认证，Domino将直接返回Webseal的请求结果。
2.基于代填表单的单点登录
场景描述：
系统A存在帐号usr1/pwd1，系统B存在帐号usr2/pwd2，通过TAM webseal 建立一个新的帐号count1/pa
ssword1，并建立与系统A和系统B的帐号对应关系（这种关系被保存到TAM中）。当用户访问系统A时，要求输入用户和密码，这时输入webseal的帐号信息，提交后用户可以访问系统A，并在系统A显示当前用户是usr1（而不是count1），当用户接着访问系统B时不需要再次输入帐号信息，单点登录到系统B，同时在系统B显示当前用户是usr2。
这种单点登录的方式对于已有系统例如系统A和系统B不用做过多修改，不过需要维护它们之间帐号的对应关系。
过程说明：
首先要在TAM webseal上创建新用户count1，并创建与系统A的帐号usr1和系统B的帐号usr2的映射关系；
pdadmin sec_master> rsrccred create sysA rsrcuser usr1 rsrcpwd pwd1 rsrctype web user count1
pdadmin sec_master> rsrccred create sysB rsrcuser usr2 rsrcpwd pwd2 rsrctype web user count1
然后，根据模板建立两个SSO的配置文件，并启动代填表单的设置；
pdadmin> server task webseald-cruz create -t tcp -h websvrA -S
/opt/pdweb/f /jctX
[login-page-one]
login-page = /sysA/login.jsp
acOperator/userid = gso:username
acOperator/password = gso:password
pdadmin> server task webseald-cruz create -t tcp -h websvrB -S
/opt/pdweb/f /jctX
[login-page-one]
login-page = /sysB/login.jsp
acOperator/userid = gso:username
acOperator/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。
过程说明：
首先要建立CA center、Webseal、系统A之间的信任关系，步骤如下
（1） CA Center给Webseal颁发服务器证书和根证书，Webseal将这两个证书导入；
（2） CA Center给系统A颁发服务器证书和根证书，系统A也导入这两个证书；
（3）在客户端浏览器导入CA Center颁发的用户证书和根证书；
上述3个步骤完成了CA center与Webseal以及系统A的证书信任过程，它们都有来自CA Center的根证书，此外客户端也拥有了根证书；
然后在Webseal配置“保护对象策略”（Protected Object Policies）是数字证书的方式，并配置到此POP的资源是系统A；
pdadmin sec_master> pop create sysA_pop
pdadmin sec_master> pop modify sysA_pop set ipauth anyothernw 2 pdadmin sec_master> pop attach /WebSEAL/webseald-cruz/sysA sysA_pop （1）当用户请求WAS应用时，Webseal要求输入用户名和密码，完成登录；
（2）当用户接着请求到系统A时，Webseal根据之前设定要求数字证书的验证，浏览器弹出数字证书选择对话框（用户数字证书已在浏览器客户端导入），用户选择自己对应的数字证书后通过认证进入系统A
4.自行的用户认证和授权
Webseal在完成SSO之后通过Http header向其它系统提供帐号信息，其它系统利用此信息分解出帐号，然后自行进行用户授权或者认证和授权场景描述：
用户访问系统A，经过WebSEAL进行验证之后，Webseal通过HTTP Header 向系统A提供用户身份信息，系统A接收到HTTP Header传递的用户信息后自行处理。
过程说明：
（1）创建到系统A的http header；
server task webseald-cruz create -t tcp -h IPaddress -p 8080 -c iv-user -x -f /sysA
（2）用户访问系统A应用时，Webseal拦截用户请求，并要求输入帐号进行认证；
（3）用户完成帐号输入并提交，然后Webseal通过认证后将用户信息放到http header中转发给系统A接收程序接收；

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。