简介

  • 单点登录:SSO,Single Sign On。
  • 令牌Ticket代替密码访问的技术。
  • 很早期的公司,一家公司可能只有一个Server,慢慢的Server开始变多了。每个Server都要进行注册登录,退出的时候又要一个个退出。用户体验很不好!你可以想象一下,上豆瓣要登录豆瓣FM、豆瓣读书、豆瓣电影、豆瓣日记……真的会让人崩溃的。我们想要另一种登录体验:一家企业下的服务只要一次注册,登录的时候只要一次登录,退出的时候只要一次退出。怎么做?
  • 一次注册。 一次注册不难,想一下是不是只要Server之间同步用户信息就行了?可以,但这样描述不太完整,后续讲用户注册的时候详细说。实际上用户信息的管理才是SSO真正的难点,只是作为初学者,我们的难点在于实现SSO的技术!我们先讨论实现手段。
  • 一次登录与一次退出。 回头看看普通商场的故事,什么东西才是保持登录状态关键的东西?记录器(session)?那种叫做cookie的纸张?写在纸张上的ID?是session里面记录的信息跟那个ID,cookie不只是记录ID的工具而已。客户端持有ID,服务端持有session,两者一起用来保持登录状态
  • 。客户端需要用ID来作为凭证,而服务端需要用session来验证ID的有效性(ID可能过期、可能根本就是伪造的找不到对于的信息、ID下对应的客户端还没有进行登录验证等)。但是session这东西一开始是每个server自己独有的,豆瓣FM有自己的session、豆瓣读书有自己的session,而记录ID的cookie又是不能跨域的。所以,我们要实现一次登录一次退出,只需要想办法让各个server的共用一个session的信息,让客户端在各个域名下都能持有这个ID就好了。再进一步讲,只要各个server拿到同一个ID,都能有办法检验出ID的有效性、并且能得到ID对应的用户信息就行了,也就是能检验ID。
  • 目前单点登录主要基于web的多种应用程序。

CAS

  • Central Authentication Service,中央认证服务,一种独立开放指令协议,是耶鲁大学发起的一个开源项目,旨在为web应用提供一种可开的单点登录方法。
  • jasig CAS:cas在2004年成为jasig的一个项目,因此别名也叫jasig CAS。
  • cas包含两个部分:CAS Server和CAS Client。
  • CAS Server:负责用户认证。
  • CAS Client:权限验证。
  • 原理:比如有一个让web应用系统Biz,其部署在bizserver上,CAS系统搭建在CAS Server上。
  1. CAS Client与受保护的客户端应用部署在一起,以Filter方式保护受保护的资源。当发起请求http://bizserver/index.jsp访问系统主页时,CAS Client会分析该url中是否包含Service Ticket,如果没有,则说明当前用户尚未登录,于是重定向到指定好的CAS Server登录地址,并传递service(即要访问的目的资源地址,以便登录成功后跳转回该地址),url:https://casserver/cas/servlet/login?service=http://bizserver/index.jsp。
  2. 用户在cas的登录页上输入用户名密码登录,CAS Server验证通过后,随机产生一个唯一Service Ticket,并缓存以待将来验证,然后系统重定向到service所在地址,url:http://bizserver/index.jsp?ticket=casticket;并为客户端设置一个Ticket Granted Cookie(TGC),即存放Service Ticket的cookie。
  3. CAS Client在拿到service和新产生的Ticket后,与CAS Server进行身份核实,即再次确认身份,url:https://casserver/cas/servlet/validate?service= http://bizserver/index.jsp&ticket=casticket,确保Service Ticket合法,不合法则再次登录。
  • 所有与CAS的交互均采用ssl协议,确保ST与TGC的安全性。
  • 总结:其实也就只是拿了一个Ticket而已。