shrio单点登陆理论

发表时间:2018-03-20 14:39:48 浏览量( 11 ) 留言数( 0 )

学习目标:

1、了解单点登陆基本原理

2、了解Shiro整合单点登陆


学习过程:

    上一节课我们实现了Session共享,如果多个应用程序都是使用相同的配置:SessionDao的实现,Redis的配置等等。这时可以不需要单点登陆,因为在任何一个应用系统登陆了。Session都已经共享了。不需要重复登陆。但是上一节课的Session共享由两个问题:1、每一个系统都有自己的账号信息管理,都需要做登陆认证的判断,如果数据库没有共享的,那么还有可能每个数据库都保存着不同的账号和密码等信息。2、第二个问题就是,如果公司的其他项目并不是使用这个配置,或者是其他第三方的应用系统,那么Session共享就无法实现了。所以这里我们还需要使用单点登陆。统一使用一个应用系统提供这个认证的功能。其他应用系统只需要保存账号名称和权限信息即可(我个人建议还是需要把权限放到各个应用系统自己管理的)  

单点登陆(Single Sign On),简称SSO,很多公司里面由多套应用系统在运行,比如财务系统、OA办公系统等等,如果每一个系统都维护一套账号信息,没登陆一个系统都需要登陆一次,会很烦人的。而且现在很多公司也会把多个不同的系统通过portal门户面版统一起来。为了让用户只需要登录一次就可以访问所有相互信任的应用系统,需要提供一个统一认证的过程,统一维护所有的账号信息。

   简单的 SSO 的体系中,会有下面三种角色:

   客户端User,一般都是由多个。

   应用系统,一般也是由多个,不然也就不需要单点登陆了。

   单点登陆SSO认证中心,有1个。

   应用系统不再处理客户端登录,所有的登录认证都在 SSO 认证中心进行。 SSO 认证中心通过一些方法来告诉应用系统当前访问用户究竟是不是指定的用户。 SSO 认证中心和所有的应用系统建立一种信任关系, SSO 认证中心对用户身份正确性的判断会通过某种方法通知应用系统,而且判断结果必须被应用系统信任。当然授权也可以通过SSO实现,但是一般授权还是由各个应用系统自己维护。

    实现SSO由很多开源系统。其中Java应用系统使用得比较多得就是CAS,Shiro对此的支持也非常好,所以这里我们主要就是讲解CAS的。

一、CAS的简介

官方网站:

   https://www.apereo.org/projects/cas

cas下载

    http://developer.jasig.org/cas/

 CAS(Central Authentication Service) 是 Yale 大学发起的一个开源项目,提供企业级别的单点登陆服务。

从结构体系看, CAS 包含两部分:

 CAS Server

    CAS Server 负责完成对用户的认证工作, CAS Server 需要独立部署,有不止一种 CAS Server 的实现, Yale CAS Server 和 ESUP CAS Server 都是很不错的选择。

CAS Server 会处理用户名 / 密码等凭证 (Credentials) ,它可能会到数据库检索一条用户帐号信息,也可能在 XML 文件中检索用户密码,对这种方式, CAS 均提供一种灵活但同一的接口 / 实现分离的方式, CAS 究竟是用何种认证方式,跟 CAS 协议是分离的,也就是这个认证的实现细节可以自己定制和扩展。

CAS Client

    CAS Client 负责部署在客户端(相对CAS而言,客户端指的就是我们的应用系统),原则上, CAS Client 的部署意味着,当有对本地 Web 应用的受保护资源的访问请求,并且需要对请求方进行身份认证, Web 应用不再接受任何的用户名密码等类似的 Credentials ,而是重定向到 CAS Server 进行认证。

    目前, CAS Client 支持(某些在完善中)非常多的客户端,包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等客户端,几乎可以这样说, CAS 协议能够适合任何语言编写的客户端应用。

attcontent/8f2d71d9-8538-4e5e-acb0-6b1f94679121.png

2、协议

Supported Protocols

Clients communicate with the server by any of several supported protocols. All the supported protocols are conceptually similar, yet some have features or characteristics that make them desirable for particular applications or use cases. For example, the CAS protocol supports delegated (proxy) authentication, and the SAML protocol supports attribute release and single sign-out.

负责处理对客户端受保护资源的访问请求,需要登录时,重定向到CAS Server.图1是CAS最基本的协议过程:

CAS Client 与受保护的客户端应用部署在一起,以Filter方式保护 Web 应用的受保护资源,过滤从客户端过来的每一个 Web 

请求

Supported protocols:


CAS (versions 1, 2, and 3)

SAML 1.1 and 2

OpenID Connect

OpenID

OAuth 2.0

WS Federation



3、认证的过程简介

attcontent/48cc90f2-0fca-4f6a-b9b5-d29e4c624606.png

 CAS Client 以 Filter 方式保护 Web 应用的受保护资源,过滤从客户端过来的每一个 Web 请求,同时, CAS Client 会分析 HTTP 请求中是否包请求 Service Ticket( 上图中的 Ticket) ,如果没有,则说明该用户是没有经过认证的,于是, CAS Client 会重定向用户请求到 CAS Server ( Step 2 )。 Step 3 是用户认证过程,如果用户提供了正确的 Credentials , CAS Server 会产生一个随机的 Service Ticket ,然后,缓存该 Ticket ,并且重定向用户到 CAS Client (附带刚才产生的 Service Ticket ), Service Ticket 是不可以伪造的,最后, Step 5 和 Step6 是 CAS Client 和 CAS Server 之间完成了一个对用户的身份核实,用 Ticket 查到 Username ,因为 Ticket 是 CAS Server 产生的,因此,所以 CAS Server 的判断是毋庸置疑的。



用户首次登录时流程如下:


1)、用户浏览器访问系统A需登录受限资源,此时进行登录检查,发现未登录,然后进行获取票据操作,发现没有票据。


2)、系统A发现该请求需要登录,将请求重定向到认证中心,获取全局票据操作,没有,进行登录。


3)、认证中心呈现登录页面,用户登录,登录成功后,认证中心重定向请求到系统A,并附上认证通过令牌,此时认证中心同时生成了全局票据。


4)、此时再次进行登录检查,发现未登录,然后再次获取票据操作,此时可以获得票据(令牌),系统A与认证中心通信,验证令牌有效,证明用户已登录。


5)、系统A将受限资源返给用户。


已登录用户首次访问应用群中系统B时:


1)、浏览器访问另一应用B需登录受限资源,此时进行登录检查,发现未登录,然后进行获取票据操作,发现没有票据。


2)、系统B发现该请求需要登录,将请求重定向到认证中心,获取全局票据操作,获取全局票据,可以获得,认证中心发现已经登录。


3)、认证中心发放临时票据(令牌),并携带该令牌重定向到系统B。


4)、此时再次进行登录检查,发现未登录,然后再次获取票据操作,此时可以获得票据(令牌),系统B与认证中心通信,验证令牌有效,证明用户已登录。


5)、系统B将受限资源返回给客户端。


2、登录状态判断


用户到认证中心登录后,用户和认证中心之间建立起了会话,我们把这个会话称为全局会话。当用户后续访问系统应用时,我们不可能每次应用请求都到认证中心去判定是否登录,这样效率非常低下,这也是单Web应用不需要考虑的。


我们可以在系统应用和用户浏览器之间建立起局部会话,局部会话保持了客户端与该系统应用的登录状态,局部会话依附于全局会话存在,全局会话消失,局部会话必须消失。


用户访问应用时,首先判断局部会话是否存在,如存在,即认为是登录状态,无需再到认证中心去判断。如不存在,就重定向到认证中心判断全局会话是否存在,如存在,按1提到的方式通知该应用,该应用与客户端就建立起它们之间局部会话,下次请求该应用,就不去认证中心验证了。


3、登出


用户在一个系统登出了,访问其它子系统,也应该是登出状态。要想做到这一点,应用除结束本地局部会话外,还应该通知认证中心该用户登出。


认证中心接到登出通知,即可结束全局会话,同时需要通知所有已建立局部会话的子系统,将它们的局部会话销毁。这样,用户访问其它应用时,都显示已登出状态。


整个登出流程如下:


1)、客户端向应用A发送登出Logout请求。 

2)、应用A取消本地会话,同时通知认证中心,用户已登出。 

3)、应用A返回客户端登出请求。 

4)、认证中心通知所有用户登录访问的应用,用户已登出。




CAS 的代理模式

       模式 1 已经能够满足大部分简单的 SSO 应用,现在,我们探讨一种更复杂的情况,即用户访问 helloservice , helloservice 又依赖于 helloservice2 来获取一些信息,如同:

User à helloservice à helloservice2

这种情况下,假设 helloservice2 也是需要对 User 进行身份验证才能访问,那么,为了不影响用户体验(过多的重定向导致 User 的 IE 窗口不停地 闪动 ) , CAS 引入了一种 Proxy 认证机制,即 CAS Client 可以代理用户去访问其它 Web 应用。

代理的前提是需要 CAS Client 拥有用户的身份信息 ( 类似凭据 ) 。 与其说之前我们提到的 TGC 是用户持有对自己身份信息的一种凭据,则这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借 TGC , User 可以免去输入密码以获取访问其它服务的 Service Ticket ,所以,这里,凭借 PGT , Web 应用可以代理用户去实现后端的认证,而无需前端用户的参与。

如下面的 CAS Proxy 图所示, CAS Client 在基础协议之上,提供了一个额外的 PGT URL 给 CAS Server, 于是, CAS Server 可以通过 PGT URL 提供一个 PGT 给 CAS Client 。



CAS 安全性

      CAS 的安全性是一个非常重要的 Topic 。 CAS 从 v1 到 v3 ,都很依赖于 SSL ,它假定了这样一个事实,用户在一个非常不安全的网络环境中使用 SSO , Hacker 的 Sniffer 会很容易抓住所有的 Http Traffic ,包括通过 Http 传送的密码甚至 Ticket 票据。

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

    SSO 的安全性问题比普通应用的安全性还要严重,因为 SSO 存在一种门槛效应。以前即使 Hacker 能够截获用户在 Web 应用 A 的密码,它也未必能知道用户在 Web 应用 B 的密码,但 SSO 让 Hacker 只需要截获 TGC( 突破了门槛 ) ,即能访问所有与该用户相关的所有应用系统。

       PGT 跟 TGC 的角色是一样的,如果被 Hacker 获得,后果可想而知。

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

       因此,某些人认为 CAS 可以不使用 SSL 的想法需要更正一下, CAS 的传输安全性仅仅依赖与 SSL

       跟 Kerberos 一样 TGT , TGC 也有自己的存活周期。下面是 CAS 的 web.xml 中,通过 grantingTimeout 来设置 CAS TGC 存活周期的参数,参数默认是 120 分钟,在合适的范围内设置最小值,太短,会影响 SSO 体验,太长,会增加安全性风险。