目录
- 什么是单点登录?
- 非单点登录架构
- 单点登录架构
- 什么是CAS
- 单点登录SSO演进
- 1.同域
- 2.同父域
- 3.跨域CAS
- CAS术语
- CAS场景
- 单点登录优缺点
- 优点
- 缺点
什么是单点登录?
单点登录(SingleSignOn,SSO),就是通过用户的一次性鉴别登录。当用户在身份认证服务器上登录一次以后,即可获得访问单点登录系统中其他关联系统和应用软件的权限,同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的,这意味着在多个应用系统中,用户只需一次登录就可以访问所有相互信任的应用系统。这种方式减少了由登录产生的时间消耗,辅助了用户管理,是比较流行的。摘自百度百科。
简单来说,就是现在随着信息化不断发展建设,在一个公司中会有很多业务系统,比如你需要在OA系统中发起请假流程,又需要去考勤系统中进行当月考勤补卡,这个时候就有个问题,用户需要在OA系统中进行登录,当去考勤系统补卡的时候还需要二次登录验证,这就很麻烦,因此聪明的架构师们,发明了一种帮助用户快捷访问网络中多个站点的安全通信技术,叫做单点登录,也就是一次登录,到处访问。
非单点登录架构
比方说我们以前去游乐场,进去免费,但是每个项目要单独收费,这个时候你想玩🎢过山车的时候,直接走进去,工作人员会检票,发现你没票则会叫你去排队买票,买完了检票通过后直接游玩即可。当你想要去另外一个项目,同样要先买票再检票,最后游玩。我们看个图帮助理解整个流程。那这就是一个传统的多系统登录方式。
单点登录架构
现在去游乐场,比如欢乐谷、迪士尼,为了节省游客的时间,使用的是通票。只需要在售票处购买通票,检票进场后畅玩任意项目。这种通票的方式,大大简化了用户的验票操作,为用户节省了时间,提升了用户体验。这就是单点登录的雏形。
什么是CAS
简单来说,SSO 仅仅是一种架构设计思想,而 CAS 则是实现 SSO 的一种手段。两者是抽象与具体的关系。当然,除了 CAS 之外,实现 SSO 还有其他手段,比如简单的 cookie。
CAS (Central Authentication Service) 是耶鲁 Yale 大学发起的一个java开源项目,旨在为 Web应用系统提供一种可靠的 单点登录 解决方案( Web SSO ), CAS 具有以下特点:
- 开源的企业级单点登录解决方案;
- CAS Server 为需要独立部署的 Web 应用,一个独立的Web应用程序(cas.war)。 ;
- CAS Client 支持非常多的客户端 ( 指单点登录系统中的各个 Web 应用 ) ,包括 Java, .Net, PHP, Perl, 等。
CAS在2004年12月成立Jasig项目,所以也叫JA-SIG CAS。
单点登录SSO演进
1.同域
同域,一般情况下是最简单的一种,一般使用cookie、session的方式就可以解决,这里我们强调一下
cookie是不可以跨域的
。
同域流程如下:
1.用户访问服务器A,验证未登录,返回结果跳转登录页面。
2.用户通过aaaa/login接口登录,成功后服务器写入session信息并共享给B服务器。
3.服务器A为该用户生成一个 cookie,并加入到 response header 中,随着请求返回而写入浏览器。该 cookie 的域设定为 http://xxxx.com。
4.当用户访问同域名的服务器B 时,由于 A和 B 在同一域名下,也是 http://xxxx.com,浏览器会自动带上之前的 cookie。此时后台服务器就可以通过该 cookie 来验证登录状态了。
实际上,这种场景就是最简单最传统的登录操作。虽然是两个server,但由于它们在同域上,就算看成是同一产品的不同类目也未尝不可。我们没有设置独立的 SSO 服务器,因为业务后台服务器本身就足以承担 SSO 的职能。
2.同父域
同父域 SSO 是同域 SSO 的简单升级,唯一的不同在于,服务器在返回cookie的时候,要把cookie的domain设置为其父域。
举个栗子,http://www.xxxx.aaa.com和http://www.xxxx.bbb.com。他们的父域名是http://www.xxxx.com,因此将cookie的domain设置为http://www.xxxx.com即可。
3.跨域CAS
CAS术语
术语:
- Client:用户。
- Server:中心服务器,也是 SSO 中负责单点登录的服务器。
- Service:需要使用单点登录的各个服务,相当于上文中的产品 a/b。
接口:
- /login:登录接口,用于登录到中心服务器。
- /logout:登出接口,用于从中心服务器登出。
- /validate:用于验证用户是否登录中心服务器。
- /serviceValidate:用于让各个 service 验证用户是否登录中心服务器。
票据:
TGT:Ticket Grangting Ticket
TGT 是 CAS 为用户签发的登录票据,拥有了 TGT,用户就可以证明自己在 CAS 成功登录过。TGT 封装了 Cookie 值以及此 Cookie 值对应的用户信息。当 HTTP 请求到来时,CAS 以此 Cookie 值(TGC)为 key 查询缓存中有无 TGT ,如果有的话,则相信用户已登录过。
TGC:Ticket Granting Cookie
CAS Server 生成TGT放入自己的 Session 中,而 TGC 就是这个 Session 的唯一标识(SessionId),以 Cookie 形式放到浏览器端,是 CAS Server 用来明确用户身份的凭证。
ST:Service Ticket
ST 是 CAS 为用户签发的访问某一 service 的票据。用户访问 service 时,service 发现用户没有 ST,则要求用户去 CAS 获取 ST。用户向 CAS 发出获取 ST 的请求,CAS 发现用户有 TGT,则签发一个 ST,返回给用户。用户拿着 ST 去访问 service,service 拿 ST 去 CAS 验证,验证通过后,允许用户访问资源。
CAS场景
我们带入一个实际场景来理解CAS
这其中1~7步 为首次访问服务A的单点登录流程,8~13步为访问A服务单点登录成功后再访问服务B的单点流程。
流程:
1.Client请求A资源
2.Server A校验发现此请求未认证,重定向浏览器到CAS服务端登录地址,其中重定向参数包含A资源地址。
3.用户通过CAS Server登录
4.登录成功,将TGC写入浏览器CAS域名的cookie中,重定向浏览器到ServerA+ServerA的ST
5.重定向后请求A资源地址并且携带Server A的ST
6.Server A向CAS Server发起校验ST请求
7.ST校验成功,Server A知道用户已经在CAS Server登录了,于是Server A构建用户登录session,记为A-session。并将 cookie 写入浏览器,并返回Client请求资源。
8.Client请求A资源
9.重定向浏览器到CAS服务端登录地址,由于CAS地址的Cookie有TGC,重定向时会被携带传递给CAS服务端
10.根据 TGC 去查找 TGT,可以找到,判断Client已经登录,生成新的ST,并且重定向到请求B资源地址携带ST
11.重定向后请求携带服务B的ST
12.Server B获取ST后,发起校验ST请求
13.ST校验成功,B服务器知道用户已经在 sso 登录了,于是B服务器构建用户登录 session,记为 B-session。并将 cookie 写入浏览器,并返回Client请求资源。
单点登录优缺点
优缺点仁者见仁智者见智,我输出一下我简单的理解。
优点
1)提高用户的效率。
用户不再被多次登录困扰,也不需要记住多个 ID 和密码。另外,用户忘记密码并求助于支持人员的情况也会减少。
2)提高开发人员的效率。
SSO 为开发人员提供了一个通用的身份验证框架。实际上,如果 SSO 机制是独立的,那么开发人员就完全不需要为身份验证操心。他们可以假设,只要对应用程序的请求附带一个用户名,身份验证就已经完成了。
3)简化管理。
如果应用程序加入了单点登录协议,管理用户帐号的负担就会减轻。简化的程度取决于应用程序,因为 SSO 只处理身份验证。所以,应用程序可能仍然需要设置用户的属性(比如访问特权)。
缺点
1)不利于重构
因为涉及到的系统很多,要重构必须要兼容所有的系统,可能很耗时。
2) 无人看守桌面
因为只需要登录一次,所有的授权的应用系统都可以访问,可能导致一些很重要的信息泄露。
点赞收藏,富婆包养✋✋