1. 云栖社区>
  2. 博客列表>
  3. 正文

CAS的登录和注销原理

黑白双傻 2016-05-12 13:06:31 浏览3403 评论0

CAS sso 单点登录

摘要: 【原创申明:文章为原创,欢迎非盈利性转载,但转载必须注明来源】 之前写过一篇文章,介绍单点登录的基本原理。这篇文章重点介绍开源单点登录系统CAS的登录和注销的实现方法。并结合实际工作中碰到的问题,探讨在集群环境中应用单点登录可能会面临的问题。

【原创申明:文章为原创,欢迎非盈利性转载,但转载必须注明来源】

之前写过一篇文章,介绍单点登录的基本原理。这篇文章重点介绍开源单点登录系统CAS的登录和注销的实现方法。并结合实际工作中碰到的问题,探讨在集群环境中应用单点登录可能会面临的问题。

1      单点登录的过程

为了描述方便,假设有如下一个单点登录系统。一套CASServer,两套CAS Client系统。为了描述的方便,省略CAS Server调用用户系统完成登录,以及CASClient从用户系统读取用户详细信息的过程。

1.1多应用情况下Session信息

假定有两个CAS Client应用,一个CAS Server。应用的部署,可能在不同的服务器,也可能有不同的访问IP或域名,即使是同一个浏览器,在各个应用中的Session信息也是不相同的。

浏览器中,每个应用有一个独立的JSESSIONIDCookie。某一个应用,不可能读取到浏览器在其他应用中的Cookie信息。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

假定用户首先访问CAS Client 01,系统提醒用户进行一次登录;然后用户访问CAS Client2,不会再提示登录而是直接登录成功。

1.2第一次访问CAS Client 01

用户打开浏览器后第一次访问,重定向到单点登录后,会提示用户输入账号密码登录。登录成功之后,再跳转回CAS Client

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

1.3第一次访问CAS Client 02

当用户浏览器已经登录系统,切换到另一个CASClient时,跟第一次访问有所不同,因为已经登录成功,就不会再提醒输入账号密码登录了。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

1.4再次访问CAS Clients

当用户已经访问过CAS Client后,当用户再次访问,系统不会再跳转到CAS Server做认证。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

1.5CASClient配置

为了实现前述的单点登录过程,以Java WEB项目为例,需要在 web.xml 中进行相应的配置。(为了排版,没有填写Filter的完整class名,请自行查阅补充。)

<filter>

  <filter-name>CAS AuthenticationFilter</filter-name>

  <filter-class>*.AuthenticationFilter</filter-class>

</filter>

<filter>

  <filter-name>CAS Validation Filter</filter-name>

  <filter-class>*.Cas10TicketValidationFilter</filter-class>

</filter>

<filter>

  <filter-name>CAS HttpServletRequest WrapperFilter</filter-name>

  <filter-class>*.HttpServletRequestWrapperFilter</filter-class>

</filter>

<filter-mapping>

  <filter-name>CAS Validation Filter</filter-name>

  <url-pattern>/*</url-pattern>

</filter-mapping>

<filter-mapping>

  <filter-name>CAS AuthenticationFilter</filter-name>

  <url-pattern>/*</url-pattern>

</filter-mapping>

<filter-mapping>

         <filter-name>CAS HttpServletRequest WrapperFilter</filter-name>

         <url-pattern>/*</url-pattern>

</filter-mapping>

仔细看一下配置过滤器可以发现,三个过滤器正好对应流程图中三次访问CAS Client

  • Authentication Filter:负责将未登录用户跳转到登录界面

  • Authentication Filter:负责验证Service Ticket

  • HttpServletRequest WrapperFilter:负责将用户信息封装到request和session中。


2      统一注销的过程

2.1不能实现统一注销会有什么问题

当用户访问系统后从系统注销,如何能够从每个应用中都注销?注意前面1.4部分的描述,如果用户注销时,并没有注销CASClient 02中的会话信息,如果用户在浏览器中直接访问这个应用,因为Session存在,并不会提醒用户重新登录。

这会带来两个潜在的隐患:

1、  用户注销user1后换账号user2重新登录,进入CAS Client 02之后,当前身份其实还是user1,并没有如用户预期一样使用user2身份。

2、  用户user1点击注销后离开,没有关闭浏览器。这时候其他用户直接打开CAS Client 02,能够直接盗用user1的身份进行操作。

2.2基本概念:TGTST

CAS已经考虑到统一注销的问题。

这里有三个重要的概念TGTSTService,需要着重介绍一下,因为它们同后续统一注销的方案息息相关。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

2.2.1         Service

这是用户第一次访问CAS ClientURL。假设一个CAS Client应用部署在域名oa.company.com,使用HTTP协议,应用首页是index.htm。当用户第一次访问这个应用时,对应的URL地址是 http://oa.company.com/index.htm 。这个URL,对CAS Server来说,就是一个service

当用户第一次跳转到CAS Server的时候,可以看到传了一个参数service,就是这个值。当CASServer生成Ticket重定向到CAS Client的时候,实际就是在这个service 中添加了一个参数 ticket

2.2.2         TGTTicket Grangting Ticket

TGTCAS Server为每一个登录用户创建的登录令牌。在CASServer上拥有了TGT,用户就可以证明自己在CASServer成功登录过。TGT封装了SessionCookie值以及此Cookie值对应的用户信息。当HTTP请求到来时,CAS以此Cookie值为key查询缓存中有无TGT ,如果有的话,则相信用户已登录过。

2.2.3         STService Ticket

STCAS Server为用户签发的访问某一service的认证令牌。用户访问service时,service发现用户没有ST,浏览器会跳转到CASServer去获取STCAS Server发现用户有TGT,则签发一个ST,返回给用户。用户使用ST作为ticket参数去访问serviceserviceSTCAS Server验证,验证通过后,得到当前登录用户的登录名。

注意TGTST,是一对多的关系。一个TGT会维护一个 services 列表,每当为用户创建一个ST并认证通过后,会将这个ST添加到TGTservices列表中。这样,在CASServer端,这个services列表实际维护了一个用户登录过的所有CASClient。这就为实现统一注销打下了基础。

2.3CAS Client的统一注销配置

CAS Client,为了实现统一注销,除了第一张介绍的三个登录过程的过滤器之外,还需要添加一个统一注销过滤器。

<filter>

 <filter-name>CAS Single Sign OutFilter</filter-name>

 <filter-class>*.SingleSignOutFilter</filter-class>

</filter>

<filter-mapping>

 <filter-name>CAS Single Sign OutFilter</filter-name>

 <url-pattern>/*</url-pattern>

</filter-mapping>

<listener>

 <listener-class>*.SingleSignOutHttpSessionListener</listener-class>

</listener>

2.4CAS Server注销过程

用户在浏览器中点击“注销”链接,实际浏览器会访问CASServer的注销页面。收到注销请求后,CAS Server会读取到TGT,并检查当前用户登录过的所有service,并依次发送注销请求。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

2.5CAS Client注销过程

CAS Client的注销,核心代码是SingleSignOutFilter,它的关键代码

public voiddoFilter(servletRequest, servletResponse, filterChain){

         HttpServletRequest request =(HttpServletRequest)servletRequest;

         if (handler.isTokenRequest(request)) {

                   handler.recordSession(request);

         } else if (handler.isLogoutRequest(request)) {

                   handler.destroySession(request);

                   return;

         }

         filterChain.doFilter(servletRequest, servletResponse);

}

其中handlerSingleSignOutHandler的实例,这个对象完成用户在CASClient端登录信息的维护和注销工作。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

至此,CAS完整的登录和注销过程就完成。

2.6思考:什么情况统一注销会失败

统一注销的实现,需要CAS Server通过HttpClient访问CAS Clientservice。如果这个访问过程失败,就会导致统一注销失败。列了几种情况,不详述。

1、开发调试阶段,使用localhost访问CAS Client

2CAS Server部署在外网,CAS Client部署在内网。

3、网络安全设置,不允许CASServer访问CAS Client

3      CAS Client集群的影响

前面的论述,一直假定所有的CAS Client都是单点部署,没有集群。如果集群,会有什么影响,应该如何来解决?

3.1Client集群对登录的影响

假设使用nginx做集群前端,后面部署两台CAS Client 01的实例。我们看看对登录过程会有什么影响。

为了描述方便,CAS Client登录过程会有三次请求(对应三个过滤器),我们依次命名为Authentication Request / Validation Request / Wrapper Request

Nginx缺省的分发规则,并不是sticky模式,同一个浏览器的请求,会按照nginx自身某种规则进行分发。我们曾经测试过,在双点集群环境下,Authentication RequestValidationRequest会恰好被分发到两台服务器,这就会导致登录过程死循环。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

出现登录死循环的原因,主要在于nginx分发时,没有使用sticky策略,也就是同一个浏览器的请求,永远分发给同一台CAS Client实例。缺省nginx的分发策略,可以根据用户IP分发,实现的是同一个IP永远分发到同一台Client,这样就能解决死循环的问题。

3.2Client集群对注销的影响

nginx实现了sitcky转发,同一个浏览器的访问会分发到同一个Client1实例,该用户的会话信息也一直保存在Client1实例中。

当用户统一注销时,由CAS ServerClient发送注销请求,这时候nginx无法确保按当前用户进行分发,因此可能会被分发到Client2。这时候,实际效果是注销失败。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

这个问题,在我们当前的环境中真实存在,还没有合理的解决方法。初步分析,大概有几个修改方向。

3.2.1         修改nginx分发策略

问题存在的原因,是因为nginx在分发注销策略时,不能准确分发。如果能在这个环节进行修改,系统代码和环境,基本不用做任何修改。

但这个实现难度很大,而且可能会影响nginx的性能。

3.2.2         集群的节点实现Session同步

如果能实现集群Session的同步:同步创建、同步注销,主要在一个Client上实现了注销,其他Client也就同步注销。

这个会对Tomcat性能有影响。

3.2.3         集群节点使用redis保存会话信息

即使是多个节点,它们的会话信息只有一份。一旦失效,则所有节点都失效。这只是一个设想,没有做技术调研,不知能够实现。

3.2.4         每次请求验证用户是否注销

首先,在CAS Server中实现一个接口,用于判断某一个ST对应的TGT是否还有效。

SingleSignOutFilter中,每次访问都调用CAS Server的这个新接口,判断用户是否已经注销。如果已经注销,则立刻注销本实例中的会话信息。

这个方法是比较安全的解决办法,但每次请求都会调用CASServer接口,会对性能造成巨大影响。完全不建议用这种方案。


版权声明:本文内容由互联网用户自发贡献,本社区不拥有所有权,也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:yqgroup@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

用云栖社区APP,舒服~

【云栖快讯】哪个编程语言最热门?各个专业领域的技术趋势是什么?如何才能更快速的踏上技术进阶之路……云栖社区2017中国开发者大调查火热进行!答卷可抽奖,红轴机械键盘、天猫精灵,丰富好礼大概率抽取  详情请点击

网友评论


在云上签发Symantec、WoSign、CFCA证书,实现网站HTTPS化,使网站可信,防劫持、防篡改、防监听... 更多>

为您提供简单高效、处理能力可弹性伸缩的计算服务,帮助您快速构建更稳定、安全的应用,提升运维效率,降低 IT 成本... 更多>
安全技术百问

安全技术百问