SOA+LDAP实现SSO单点登录思路

统一身份认证系统模型

用户首先通过客户端应用程序登录用户登录子系统，再通过身份认证接口向统一身份认证平台（LDAP）提出认证请求，统一身份认证平台对请求内容进行解析和实施访问控制，查询LDAP数据库中的用户身份信息和权限信息，进行身份识别和授权访问，将认证结果信息返回至统一身份认证平台和登录系统，对用户的登录请求作出接受或拒绝的响应。

 

统一身份认证服务的实现：

   该系统的功能是建立一个能够服务于所有应用系统的统一的身份认证系统，每个应用系统都通过该认证系统来进行用户的身份认证，而不再需要开发各自独立的用户认证模块。同时，由“统一身份认证服务”来实现统一的用户认证机制，即统一从已建立的LDAP目录服务器中查询用户认证信息，然后按照统一的认证规则进行校验，从而提高了系统的整体安全性。

 

认证过程可分为以下几个步骤：

     第一步：当用户首次登录一个应用系统时，该应用系统应自动将用户浏览器重定向到“统一身份认证服务” 的登录页面。接着， “统一身份认证服务” 根据用户填写的登录信息从LDAP目录服务器中检索该用户的相关认证信息并进行校验。若校验失败，该用户将被拒绝进入应用系统；若校验成功，用户浏览器会自动返回到最初登录的应用系统。

     为了使“统一身份认证服务” 能够自动返回到应用系统，在重定向到“统一身份认证服务”的登录页面时，还需要传递service参数（我觉得用WebService开发，可以直接作为参数传递），service参数值就是用户最初登录的应用系统的链接地址，这样，“统一身份认证服务”在校验成功后就可以按照service参数值返回到应用系统。

 

第二步：若认证成功，“统一身份认证服务”会自动返回到用户最初登录的应用系统，同时会传递ticket参数。ticket参数值是由“统一身份认证服务”自动创建的随机字符串。ticket值是与当前已成功认证的用户名绑定的。例如：用户zhangsh要登录应用系统S，若认证成功，则“统一身份认证服务”会创建一个ticket参数T，T表示只允许用户zhangsh访问应用程序S，而且这个ticket参数使用一次后即作废。

 

第三步：应用系统在收到ticket参数值后还需要校验收到的ticket参数值的真伪， 目的是防止某些用户伪造ticket参数值来非法登录。具体校验方法是向“统一身份认证服务”传递service参数和ticket参数。传递的service参数值与第一步中介绍的完全一样， 目的也是为了让“统一身份认证服务”在校验成功后就可以按照service参数提供的链接地址返回应用系统ticket参数值就是应用系统刚才收到的ticket参数值，原封不动地传递回去即可。但为了提高响应速度，这次参数传递的过程不再使用将用户浏览器重定向到“统一身份认证服务”的方法，而是用Socket(套接字)直接建立http连接。“统一身份认证服务”会将收到的ticket参数值与先前自己创建的ticket参数值进行比较，若不匹配，则说明传递的ticket参数值系伪造，该用户将被拒绝进入应用系统；若匹配，则“统一身份认证服务”返回一个http应答消息，在应答主体中只有一行信息：通过身份验证的用户名。与此同时，统一身份认证服务必须立即销毁先前创建的ticket参数值，以防被重复使用。

 

登录服务器接到验证请求后得到一个session_ID，在LDAP通过验证后，至少应该保存好这个Session_ID和应用系统的ID，这个可以通过数据库，也可以直接通过Session、cookie方式，简单一点：session变量名为应用ID，session值为session_ID,将session_ID+用户ID以某种组合形式发送给应用系统服务器，应用服务器建立本地已成功登录的session，显示页面。考虑到session_ID是以明码方式加在URL中返回给应用服务器的，为了防止伪造的令牌，需要在建立本地成功登录session前，再一次通过登录服务器，验证令牌的真伪，即不需要发送密码，只需要发送应用ID和令牌中分析出来的session_ID，和登录服务器保存的session比较，匹配成功后发挥应答信息