联合单点登录总结.docVIP

联合单点登录总结关于联合单点登录的文献比较少，相关文献国内也有只有少数几篇，总结如下：目前针对联合单点登录主要有两种方法：1 基于SAML的联合单点登录2 基于kerberos和SAML的联合单点登录问题1：跨域需要SAML的参与 因为SAML 能为用户提供跨越异种网络和平台的单点登录的认证和授权，尤其是在 Web 服务的系统和流程合作的基础上的，允许多个系统共同分享安全问题和身份验证方面的信息，所以若涉及跨域问题，需要基于SAML才能实现联合单点登录的跨域认证，并且SAML已经被广泛应用和认可，目前我没有找到其他的方法来代替SAML的功能。问题2：模型单一1 基于SAML的联合认证需要建立一个联合认证域，它充当认证域A和认证域B之间的代理，但总体看来类似于传统单点登录中认证服务器的功能，感觉只是简单地实现了跨域的功能，关于改进方面不明显。（参考文献：Web环境下SAML联合认证单点登录的研究_于晓琳）2 基于kerberos和SAML的联合单点登录，该方法所谓的联合其实就是采用了kerberos和SAML两种方法的联合，目前kerberos和SAML是单点登录两种主流的模型，暂时还不容易换成别的方法的联合。（参考文献：Web环境下联盟型图书馆联合单点登录模型研究_焦允）问题3：我根据老师的想法采用在每个域上各个域的服务器之间互通信息，取消联合服务器，采用基于kerberos和SAML的联合通信机制，不需要代理服务器 目前还没有相关文献采用这种方法，但是我总结了其传输过程：假设用户C在域A注册过，并对 A 地和 B 地的资源都有访问权限。各个域的服务器数据库中存储着自己的盟友信息。 用户C传输协议采用kerberos协议跨域认证采用SAML （1）应用1 （2） （4） 应用1应用N （3） 应用n 域A 认证服务器A 认证服务器B 域B1 用户 C 未在 A 地登录，就向认证域 B 的应用服务 1 发出访问请求；2 应用服务 1 截获请求后，将请求发送到认证服务器 B 请求验证；3 认证服务器 B 收到请求，判断用户 C 未登录并且不是本地用户，服务器根据用户C的域名在数据库中查询域名A是否是联盟成员，若不是则直接拒绝，否则则将用户 C 的信息发送至认证服务器 A 请求验证4 认证服务器 A 对用户 C 验证成功后，便生成一个包含认证断言和一个或多个属性断言的 SAML 令牌（SAMLToken）返回给认证服务器B；5 认证服务器 B 完成对外部域用户的授权服务，将授权断言写入 SAML令牌返回给应用服务 1；6 最后由应用服务 1 向用户 C 提供相应的服务。原始的认证过程：假设用户C在域A注册过，并对 A 地和 B 地的资源都有访问权限。盟友信息数据存储在联合服务器中。 （1）用户 C 未在 A 地登录，就向认证域 B 的应用服务 1 发出访问请求；（2）应用服务 1 截获请求后，将请求发送到认证服务器 B 请求验证；（3）认证服务器 B 收到请求，判断用户 C 未登录并且不是本地用户，便向 联合认证域发出联合认证请求；（4）联合认证服务器根据用户 C所属域名，到数据库中查找认证域 A 是否 已注册，如果是注册域成员，便查看域 A 和域 B 是否存在信任关系，若不 存在则拒绝请求；（5）若存在，则将用户 C 的信息发送至认证服务器 A 请求验证；（6）认证服务器 A 对用户 C 验证成功后，便生成一个包含认证断言和一个 或多个属性断言的 SAML 令牌（SAMLToken）返回给联合认证服务器；（7） 联合认证服务器将返回的信息和存储于联合认证域数据库中的两域间的关 系信息、认证域 A 注册的域标识以及域 A 所有用户的身份映射标识一起 发送给认证服务器 B；（8）认证服务器 B 完成对外部域用户的授权服务，将授权断言写入 SAML 令牌返回给应用服务 1；（9） 最后由应用服务 1 向用户 C 提供相应的服务 新的通信方法的优点总结：1 当属于域A的用户去访问域B时，域B可以直接在自己的服务器中去查找域A是否是自己的盟友，而不必再去联盟服务器查询，方便快捷。 缺点：可能会占用服务器的少许内存。（但是在网络发展的2 在认证阶段也不用去把信息转发给认证服务器，盟友双方直接验证，直接传输，传输保护机制采用kerberos协议进行加密。不采用SSL进行加密，