SSO是什么
单点登录(Single Sign On),简称为 SSO,是比较流行的企业业务整合的解决方案之一。SSO 的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。
概述
很早期的公司,一家公司可能只有一个 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。
实现方法
server 端
以 server 群如何生成、验证 ID 的方式大致分为两种:
“共享 Cookie”这个就是上面提到的共享 session 的方式,我倒觉得叫“共享 session”来得好一点,本质上 cookie 只是存储 session-id 的介质,session-id 也可以放在每一次请求的 url 里。据说这种方式不安全,我没去细究,哪位大神可以推荐下相关的资料,我后期补上。其实也是,毕竟 session 这项机制一开始就是一个 server 一个 session 的,把 session 拿出来让所有 server 共享确实有点奇怪。
SSO-Token 方式因为共享 session 的方式不安全,所以我们不再以 session-id 作为身份的标识。我们另外生成一种标识,把它取名 SSO-Token(或 Ticket),这种标识是整个 server 群唯一的,并且所有 server 群都能验证这个 token,同时能拿到 token 背后代表的用户的信息。我们要讨论的也是这种方式,一会上具体流程图。
浏览器端
单点登录还有非常关键的一步,这一步跟 server 端验证 token 的方式无关,用最早的“共享 session”的方式还是现在的“token”方式,身份标识到了浏览器端都要面临这样的一个问题:用户登录成功拿到 token(或者是 session-id)后怎么让浏览器存储和分享到其它域名下?同域名很简单,把 token 存在 cookie 里,把 cookie 的路径设置成顶级域名下,这样所有子域都能读取 cookie 中的 token。这就是共享 cookie 的方式(这才叫共享 Cookie 嘛,上面那个应该叫共享 session)。比如:谷歌公司,google.com 是他的顶级域名,邮箱服务的 mail.google.com 和地图服务的 map.google.com 都是它的子域。但是,跨域的时候怎么办?谷歌公司还有一个域名,youtube.com,提供视频服务。
企业应用集成
通常情况下运维内控审计系统、4A 系统都包含此项功能,目的是简化账号登录过程并保护账号和密码安全,对账号进行统一管理。
企业应用集成(EAI, Enterprise Application Integration)。企业应用集成可以在不同层面上进行:例如在数据存储层面上的“数据大集中”,在传输层面上的“通用数据交换平台”,在应用层面上的“业务流程整合”,和用户界面上的“通用企业门户”等等。事实上,还有一个层面上的集成变得越来越重要,那就是“身份认证”的整合,也就是“单点登录”。
在信息安全管理中,访问控制(Access Controls)环绕四个过程:Identification;Authentication;Authorization;Accountability。单点登录(Single Sign On)属于 Authentication 认证系统,除单点登录外还包括:Lightweight Directory Access Protocol 和 Authorization ticket。(Michael E. Whitman (2011) Management Of Information Security Kennesaw University)。
技术实现机制
当用户第一次访问应用系统的时候,因为还没有登录,会被
引导到认证系统中进行登录;根据用户提供的登录信息,认证系统进行身份校验,如果通过校验,应该返回给用户一个认证的凭据--ticket;用户再访问别的应用的时候,就会将这个 ticket 带上,作为自己认证的凭据,应用系统接受到请求之后会把 ticket 送到认证系统进行校验,检查 ticket 的合法性。如果通过校验,用户就可以在不用再次登录的情况下访问应用系统 2 和应用系统 3 了。
要实现 SSO,需要以下主要的功能:
所有应用系统共享一个身份认证系统。 统一的认证系统是 SSO 的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较,对用户进行登录认证;认证成功后,认证系统应该生成统一的认证标志(ticket),返还给用户。另外,认证系统还应该对 ticket 进行效验,判断其有效性。
所有应用系统能够识别和提取 ticket 信息 要实现 SSO 的功能,让用户只登录一次,就必须让应用系统能够识别已经登录过的用户。应用系统应该能对 ticket 进行识别和提取,通过与认证系统的通讯,能自动判断当前用户是否登录过,从而完成单点登录的功能。
优点
1)提高用户的效率。
用户不再被多次登录困扰,也不需要记住多个 ID 和密码。另外,用户忘记密码并求助于支持人员的情况也会减少。
2)提高开发人员的效率。
SSO 为开发人员提供了一个通用的身份验证框架。实际上,如果 SSO 机制是独立的,那么开发人员就完全不需要为身份验证操心。他们可以假设,只要对应用程序的请求附带一个用户名,身份验证就已经完成了。
3)简化管理。
如果应用程序加入了单点登录协议,管理用户帐号的负担就会减轻。简化的程度取决于应用程序,因为 SSO 只处理身份验证。所以,应用程序可能仍然需要设置用户的属性(比如访问特权)。