单点登录研究

小近 发布于 2014/11/04 09:07
阅读 991
收藏 20

作者:近乎团队

1       单点登录起因和概念

现代企业一般拥有多套业务系统,传统方式下,各业务系统分别维护用户的帐号密码,拥有各自独立的用户信息,这就导致了以下问题:

•       用户使用不便:需要记住各个系统的帐号密码;

•       管理维护复杂:管理员到各个系统的帐号;

•       开发成本高:开发新业务系统,都需要实现一遍用户认证系统;

单点登录Single Sign On),简称为 SSO,是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。

用户中心是将所有业务系统中用户的账号信息集中在一起管理,但是针对各个业务系统中用户的其他资料信息可以在各业务系统中管理;涉及功能:注册,找回密码,邮箱激活,帐号资料修改,后台用户管理等;

两者之间的关系:

–      用户中心是单点登录的基础;

–      用户中心和单点登录是可以分离的

2       技术难点

跨域问题:假设登录票据存在cookie中,各个子系统都有自己独立的域名,如何在各个子系统中记录登录票据?难道要在用户登录时,向各个子系统发送JSONP请求么?

安全问题:怎么样可以确保用户账号的安全?不会被黑客嗅探到账号密码?想想CSDN…… 你懂得

用户信息如何取舍:在各个子系统中都有自己特定的字段,难于统一,每个子系统都冗余用户数据,又涉及到自动同步问题;

3       CAS协议介绍

3.1   结构体系

从结构体系看, CAS 包括两部分: CAS Server  CAS Client 

CAS Server

CAS Server 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 / 密码等凭证(Credentials) 

CAS Client

负责处理对客户端受保护资源的访问请求,需要对请求方进行身份认证时,重定向到 CAS Server 进行认证。(原则上,客户端应用不再接受任何的用户名密码等 Credentials )。

3.2   CAS 协议流程

 

SSO 访问流程主要有以下步骤:

访问服务: SSO 客户端发送请求访问应用系统提供的服务资源。

定向认证: SSO 客户端会重定向用户请求到 SSO 服务器。

用户认证:用户身份认证。

发放票据: SSO 服务器会产生一个随机的 Service Ticket 

验证票据: SSO 服务器验证票据 Service Ticket 的合法性,验证通过后,允许客户端访问服务。

传输用户信息: SSO 服务器验证票据通过后,传输用户认证结果信息给客户端。

如上图:

   CAS Client 与受保护的客户端应用部署在一起,以 Filter 方式保护 Web 应用的受保护资源,过滤从客户端过来的每一个 Web 请求,同时, CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket( ST 上图中的 Ticket) ,如果没有,则说明该用户是没有经过认证的;

于是 CAS Client 会重定向用户请求到 CAS Server  Step 2 ),并传递 Service (要访问的目的资源地址);

Step 3 是用户认证过程,如果用户提供了正确的 Credentials  CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ,并缓存以待将来验证;

重定向用户到 Service 所在地址(附带刚才产生的 Service Ticket  , 并为客户端浏览器设置一个 Ticket Granted Cookie  TGC  

CAS Client 在拿到 Service 和新产生的 Ticket 过后,在 Step 5  Step6 中与 CAS Server 进行身份核实,以确保 Service Ticket 的合法性。


在该协议中,所有与 CAS Server 的交互均采用 SSL 协议,以确保 ST  TGC 的安全性。协议工作过程中会有 次重定向 的过程。但是 CAS Client  CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。

3.3   术语解释

CAS 系统中的两种票据: TGC  ST 

Ticket-granting cookie(TGC) :存放用户身份认证凭证的 cookie ,在浏览器和 CAS Server 间通讯时使用,并且只能基于安全通道传输( Https ),是 CAS Server 用来明确用户身份的凭证;

Service ticket(ST) :服务票据,服务的惟一标识码 ,  CAS Server 发出( Http 传送),通过客户端浏览器到达业务服务器端;一个特定的服务只能有一个惟一的 ST 

3.4    CAS 如何实现 SSO

当用户访问另一个应用的服务再次被重定向到 CAS Server 的时候, CAS Server 会主动获到这个 TGC cookie ,然后做下面的事情:

如果 User 持有 TGC 且其还没失效,那么就走基础协议图的 Step4 ,达到了 SSO 的效果;

如果 TGC 失效,那么用户还是要重新认证 ( 走基础协议图的 Step3) 

3.5   CAS安全性

CAS 的安全性仅仅依赖于 SSL 。使用的是 secure cookie  

TGC安全性

对于一个 CAS 用户来说,最重要是要保护它的 TGC ,如果 TGC 不慎被 CAS Server 以外的实体获得, Hacker 能够找到该 TGC ,然后冒充 CAS 用户访问 所有 授权资源。

从基础模式可以看出, TGC  CAS Server 通过 SSL 方式发送给终端用户,因此,要截取 TGC 难度非常大,从而确保 CAS 的安全性。

ST安全性

•       ST  Service Ticket )是通过 Http 传送的,因此网络中的其他人可以 嗅探到其他人的 Ticket  CAS 通过以下几方面来使 ST 变得更加安全:

•       ST 只能使用一次

•       CAS 协议规定,无论 Service Ticket 验证是否成功, CAS Server 都会清除服务端缓存中的该Ticket ,从而可以确保一个 Service Ticket 不被使用两次。

•       ST 在一段时间内失效

•       CAS 规定 ST 只能存活一定的时间,然后 CAS Server 会让它失效。默认有效时间为 5 分钟。

•       ST 是基于随机数生成的

•       ST 必须足够随机,如果 ST 生成规则被猜出, Hacker 就等于绕过 CAS 认证,直接访问 对应的服务。

4       单点登录实现要求

u  支持不同技术架构实现的子系统,例如:PHPJava等子系统网站;

u  支持子系统跨地理位置部署,例如:一个子系统部署在深圳,另外一个子系统部署在北京;

SSO数据库只存储用户的基本信息,允许子系统扩展其他字段;

u  为了性能考虑,允许子系统冗余存储用户数据,并可以实现自动同步会员中心的用户数据;

5       设计方案

u  基于CAS协议实现单点登录

SSO Server允许各子系统对于用户基本信息做冗余,但必须保证数据同步,具体实现思路如下:

–      用户登录SSO后,从SSO上获取最新的基本信息;

–      比较SSO基本信息中的ModifySalt和本系统的ModifySalt是否一致;

–      若存在变化,则更新本系统;

u  用户登录SSO Server时,通过<script>标签循环调用各个子系统的登录接口,达到批量颁发登录票据的目的;用户注销时同理;

SSO Server需要实现以下接口:

–      检查用户是否登录过SSO Server,若是,则返回登录用户Id,注意仅供SSO Client调用;

SSO Client 需要实现以下接口:

–      检查用户票据:调用SSO Server检查用户是否登录过SSO Server接口,若是,则设置本子系统的登录状态;

–      注销本子系统的登录状态;

u  各个子系统登录、注册、修改密码,必须跳转到SSO Server页面;

更多详情:近乎sns开发分享社区

 

加载中
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部