zoukankan      html  css  js  c++  java
  • CAS实现单点登录SSO执行原理及部署

    一、不落俗套的开始

    1、背景介绍

    单点登录:Single Sign On,简称SSO,SSO使得在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。

    CAS框架:CAS(Central Authentication Service)是实现SSO单点登录的框架。

    2、盗一张学习CAS绝大多都看过的图以及执行部分分析

    注:已分不清原创,此处就不给出地址了。

    这里写图片描述

    从结构上看,CAS包含两个部分:CAS Server 和CAS Client需要独立部署,主要负责对用户的认证工作;CAS 
    Client负责处理对客户端受保护资源的访问请求,需要登录时,重定向到CAS Server.图1是CAS最基本的协议过程:

    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 的判断是毋庸置疑的。

    该协议完成了一个很简单的任务,所有与CAS的交互均采用SSL协议,确保ST和TGC的安全性。协议工作过程会有2此重定向过程,但是CAS 
    Client与CAS Server之间进行ticket验证的过程对于用户是透明的。

    总结一下,如下:

    访问服务: SSO 客户端发送请求访问应用系统提供的服务资源。

    定向认证: SSO 客户端会重定向用户请求到 SSO 服务器。

    用户认证:用户身份认证。

    发放票据: SSO 服务器会产生一个随机的 Service Ticket 。

    验证票据: SSO 服务器验证票据 Service Ticket 的合法性,验证通过后,允许客户端访问服务。

    传输用户信息: SSO 服务器验证票据通过后,传输用户认证结果信息给客户端。

    二、在云里雾里进一步搜索、探究

    先给出此部分内容出处: 《SSO CAS单点系列》之 实现一个SSO认证服务器是这样的,以下标红部分为自己的疑问。

    1、登录信息传递

    这里写图片描述 
    用户首次登录时流程如下:

    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)、认证中心通知所有用户登录访问的应用,用户已登出。

    三、拨开云雾见青天

    1、对上面所有标红疑问一一解释

    1)、问:系统A是如何发现该请求需要登录重定向到认证中心的? 
    答:用户通过浏览器地址栏访问系统A,系统A(也可以称为CAS客户端)去Cookie中拿JSESSION,即在Cookie中维护的当前回话session的id,如果拿到了,说明用户已经登录,如果未拿到,说明用户未登录。

    2)、问:系统A重定向到认证中心,发送了什么信息或者地址变成了什么? 
    答:假如系统A的地址为http://a:8080/,CAS认证中心的服务地址为http://cas.server:8080/,那么重点向前后地址变化为:http://a:8080/————>ttp://cas.server:8080/?service=http://a:8080/,由此可知,重点向到认证中心,认证中心拿到了当前访问客户端的地址。

    3)、问:登录成功后,认证中心重定向请求到系统A,认证通过令牌是如何附加发送给系统A的? 
    答:重定向之后的地址栏变成:http://a:8080/?ticket=ST-XXXX-XXX,将票据以ticket为参数名的方式通过地址栏发送给系统A

    4)、问:系统A验证令牌,怎样操作证明用户登录的? 
    答:系统A通过地址栏获取ticket的参数值ST票据,然后从后台将ST发送给CAS server认证中心验证,验证ST有效后,CAS server返回当前用户登录的相关信息,系统A接收到返回的用户信息,并为该用户创建session会话,会话id由cookie维护,来证明其已登录。

    5)、问:登录B系统,认证中心是如何判断用户已经登录的? 
    答:在系统A登录成功后,用户和认证中心之间建立起了全局会话,这个全局会话就是TGT(Ticket Granting Ticket),TGT位于CAS服务器端,TGT并没有放在Session中,也就是说,CAS全局会话的实现并没有直接使用Session机制,而是利用了Cookie自己实现的,这个Cookie叫做TGC(Ticket Granting Cookie),它存放了TGT的id,保存在用户浏览器上。 
    相关内容分析可以查看:《SSO CAS单点系列》之 实操!轻松玩转SSO CAS就这么简单(相识篇)

    用户发送登录系统B的请求,首先会去Cookie中拿JSESSION,因为系统B并未登录过,session会话还未创建,JSESSION的值是拿不到的,然后将请求重定向到CAS认证中心,CAS认证中心先去用户浏览器中拿TGC的值,也就是全局会话id,如果存在则代表用户在认证中心已经登录,附带上认证令牌重定向到系统B。

    上面登录状态判断也是这个逻辑。

    6)、问:登出的过程,各个系统对当前用户都做了什么? 
    答:认证中心清除当前用户的全局会话TGT,同时清掉cookie中TGT的id:TGC; 
    然后是各个客户端系统,比如系统A、系统B,清除局部会话session,同时清掉cookie中session会话id:jsession

    2、对系统A登录流程图添加注释,查看

    这里写图片描述

    不管了,反正我看懂了。

    ps:看到这里的福利,cas系列介绍文章分享:CAS介绍资源页面

    部署目录:

    • 一、概述
    • 二、演示环境
    • 三、JDK安装配置
    • 四、安全证书配置
    • 五、部署CAS-Server相关的Tomcat
    • 六、部署CAS-Client相关的Tomcat
    • 七、 测试验证SSO

    一、概述

    此文的目的就是为了帮助初步接触SSO和CAS 的人员提供一个入门指南,一步一步演示如何实现基于CAS的单点登录。

    CAS的官网:http://www.jasig.org/cas

    二、演示环境

    本文演示过程在同一个机器上的(也可以在三台实体机器或者三个的虚拟机上),环境如下:

    • windows7 64位,主机名称:michael-pc
    • JDK 1.6.0_18
    • Tomcat 6.0.29
    • CAS-server-3.4.11、CAS-client-3.2.1
    根据演示需求,用修改hosts 文件的方法添加域名最简单方便(这个非常重要),在文件 C:WindowsSystem32driversetchosts 文件中添加三条
    • demo.micmiu.com  =>> 对应部署cas server的tomcat,这个虚拟域名还用于证书生成
    • app1.micmiu.com  =>>  对应部署app1 的tomcat
    • app2.micmiu.com   =>> 对应部署app2 的tomcat
     

    三、JDK安装配置

    这个详细过程就不在描述,如果是免安装版的,确保环境变量配置正确。

    本机环境变量:JAVA_HOME=D:jdk,如果看到以下信息则表示安装成功:

    四、安全证书配置

    有关keytool工具的详细运用见:http://www.micmiu.com/lang/java/keytool-start-guide/

    4.1. 生成证书:

    ps:

    • 截图中需要输入的姓名和上面hosts文件中配置的一致;
    • keypass 和 storepass 两个密码要一致,否则下面tomcat 配置https 访问失败;

    4.2.导出证书:

    4.3.客户端导入证书:

    ps:该命令中输入的密码和上面输入的不是同一个密码;如果是多台机器演示,需要在每一台客户端导入该证书。

    五、部署CAS-Server相关的Tomcat

    5.1. 配置HTTPS

    解压apache-tomcat-6.0.29.tar.gz并重命名后的路径为 G:sso omcat-cas,在文件 conf/server.xml文件找到:

    修改成如下:

    参数说明:

    • keystoreFile 就是4.1中创建证书的路径
    • keystorePass 就是4.1中创建证书的密码

    5.2. 验证HTTPS配置
    其他按照默认配置不作修改,双击%TOMCAT_HOME%instartup.bat 启动tomcat-cas 验证https访问配置:


    如果看到上述界面表示https 访问配置成功。

    5.3 部署CAS-Server
    CAS-Server 下载地址:http://www.jasig.org/cas/download
    本文以cas-server-3.4.11-release.zip 为例,解压提取cas-server-3.4.11/modules/cas-server-webapp-3.4.11.war文件,把改文件copy到 G:sso omcat-caswebapps 目下,并重命名为:cas.war.
    启动tomcat-cas,在浏览器地址栏输入:https://demo.micmiu.com:8443/cas/login ,回车

    CAS-server的默认验证规则:只要用户名和密码相同就认证通过(仅仅用于测试,生成环境需要根据实际情况修改),输入admin/admin 点击登录,就可以看到登录成功的页面:

    看到上述页面表示CAS-Server已经部署成功。

    六、部署CAS-Client相关的Tomcat

    6.1Cas-Client 下载

    CAS-Client 下载地址:http://downloads.jasig.org/cas-clients/

    以cas-client-3.2.1-release.zip 为例,解压提取cas-client-3.2.1/modules/cas-client-core-3.2.1.jar

    借以tomcat默认自带的 webappsexamples 作为演示的简单web项目

    6.2 安装配置 tomcat-app1

    解压apache-tomcat-6.0.29.tar.gz并重命名后的路径为 G:sso omcat-app1,修改tomcat的启动端口,在文件 conf/server.xml文件找到如下内容:

    修改成如下:

    启动tomcat-app1,浏览器输入 http://app1.micmiu.com:18080/examples/servlets/ 回车:

    看到上述界面表示tomcat-app1的基本安装配置已经成功。

    接下来复制 client的lib包cas-client-core-3.2.1.jar到 tomcat-app1webappsexamplesWEB-INFlib目录下, 在tomcat-app1webappsexamplesWEB-INFweb.xml 文件中增加如下内容:

    有关cas-client的web.xml修改的详细说明见官网介绍:

    https://wiki.jasig.org/display/CASC/Configuring+the+Jasig+CAS+Client+for+Java+in+the+web.xml

    6.3 安装配置 tomcat-app2

    解压apache-tomcat-6.0.29.tar.gz并重命名后的路径为 G:sso omcat-app2,修改tomcat的启动端口,在文件 conf/server.xml文件找到如下内容:

    修改成如下:

    启动tomcat-app2,浏览器输入 http://app2.micmiu.com:28080/examples/servlets/ 回车,按照上述6.2中的方法验证是否成功。

    同6.2中的复制 client的lib包cas-client-core-3.2.1.jar到 tomcat-app2webappsexamplesWEB-INFlib目录下, 在tomcat-app2webappsexamplesWEB-INFweb.xml 文件中增加如下内容:

    七、 测试验证SSO

    启动之前配置好的三个tomcat分别为:tomcat-cas、tomcat-app1、tomcat-app2.

    7.1  基本的测试

    预期流程: 打开app1 url —-> 跳转cas server 验证 —-> 显示app1的应用 —-> 打开app2 url —-> 显示app2 应用 —-> 注销cas server —-> 打开app1/app2 url —-> 重新跳转到cas server 验证.

    打开浏览器地址栏中输入:http://app1.micmiu.com:18080/examples/servlets/servlet/HelloWorldExample,回车:

    跳转到验证页面:

    验证通过后显示如下:

    此时访问app2就不再需要验证:

    地址栏中输入:https://demo.micmiu.com:8443/cas/logout,回车显示:

    上述表示 认证注销成功,此时如果再访问 : http://app1.micmiu.com:18080/examples/servlets/servlet/HelloWorldExample 或 http://app2.micmiu.com:28080/examples/servlets/servlet/HelloWorldExample 需要重新进行认证。

    7.2  获取登录用户的信息

    修改类:webappsexamplesWEB-INFclassesHelloWorldExample.java 后重新编译并替换 webappsexamplesWEB-INFclassesHelloWorldExample.class文件。

     HelloWorldExample.java 修改后的代码如下:

    再进行上述测试显示结果如下:

    http://app1.micmiu.com:18080/examples/servlets/servlet/HelloWorldExample :

    http://app2.micmiu.com:28080/examples/servlets/servlet/HelloWorldExample

    从上述页面可以看到通过认证的用户名。

    到此已经全部完成了CAS单点登录实例演示。

  • 相关阅读:
    spring学习总结003 --- IOC容器启动源码(BeanFactoryPostProcessor)
    spring学习总结002 --- IOC容器启动源码(BeanFactory)
    ubuntu上安装mysql
    kafka学习总结017 --- consumer配置参数之max.poll.interval.ms
    kafka学习总结016 --- consumer配置参数session.timeout.ms和heartbeat.interval.ms
    kafka学习总结015 --- consumer配置参数之auto.offset.reset
    kafka学习总结014 --- consumer多线程问题
    kafka学习总结013 --- kafka消费者API
    kafka学习总结012 --- 数据消费相关流程
    Java SAX解析
  • 原文地址:https://www.cnblogs.com/barrywxx/p/8591840.html
Copyright © 2011-2022 走看看