CAS单点登录

Cas单点登录实例
THANK YOU
2018
1、开源的企业级单点登录解决方案，源码拿出来 就能二次开发，DIY比较容易。 2、CAS Server 为需要独立部署的 Web 应用，打 包放到web中间件(比如Tomcat)里面就可以立即开 始工作，方便快捷，配置简单，傻瓜式使用方式， 也可以对一些功能进行扩展，比如用户认证方式。 3、CAS Client 支持非常多的客户端(这里指单点登 录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Ruby 等。
Cas单点登录解析
图解2： 4
CAS Server（认 证中心） 1、浏览器访问另一应用B需登录受限资源，此时进行 登录检查，发现未登录，然后进行获取票据操作，发 现没有票据。 2、系统B发现该请求需要登录，将请求重定向到认证 中心，获取全局票据操作，获取全局票据，可以获得， 认证中心发现已经登录。 3、认证中心发放临时票据(令牌)，并携带该令牌重定 向到系统B。 4、此时再次进行登录检查，发现未登录，然后再次获 取票据操作，此时可以获得票据(令牌)，系统B与认证 中心通信，验证令牌有效,证明用户已登录。 5、系统B将受限资源返回给客户端。
Cas单点登录简介
CAS简单介绍
CAS（Central Authentication Service） 是Yale耶鲁大学发起的一个开源 项目，旨在为 Web 应用系统提 供一种可靠的单点登录方法， CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。
Cas单点登录简介
CAS特点
06
Cas单点登录解析
图解1： 4
CAS Server（认 证中心）
系统A
5 1
2
3
1、用户浏览器访问系统A需登录受限资源，此时进行 登录检查，发现未登录，然后进行获取票据操作，发 现没有票据。 2、系统A发现该请求需要登录，将请求重定向到认证 中心，获取全局票据TGT操作，没有，进行登录。 3、认证中心呈现登录页面，用户登录，登录成功后， 认证中心重定向请求到系统A，并附上认证通过ticket 令牌(即ST)，同时会在Cookie中设置一个GASTGC（C AS Server的Cookie），此时认证中心同时生成了全 局票据。 4、此时再次进行登录检查，发现未登录，然后再次获 取票据操作，此时可以获得票据(令牌)，系统A与认证 中心通信，将Cookie中的TGC携带到CAS Server，C AS Server根据这个TGC查找与之对应的TGT，验证令 牌有效,证明用户已登录。 5、系统A将受限资源返给用户。
存放用户身份认证凭证票据（存放令牌）的 cookie，浏览器关闭即失效（携带到浏览器）
Cas单点登录解析
原理：
01 02 03 04 05
访问服务：SSO客户端发送请求访问应用系 统提供的服务资源。 定向认证：SSO客户端会重定向用户请求到 SSO服务器。
用户认证：用户身份认证。
发放票据：SSO服务器会产生一个随机的 Service Ticket。 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端 访问服务。 传输用户信息：SSO服务器验证票据通过后， 传输用户认证结果信息给客户端。
实 CA S SSO单点登录 战
主讲人:西越
Cas单点登录简介
Cas单点登录解析
Cas单点登录实例
Cas单点登录简介
SSO简单介绍
CAS
单点登录（Single Sign On），简称为 SSO，是目 前比较流行的企业业务整合 的解决方案之一。SSO的定 义是在多个应用系统中，用 户只需要登录一次就可以访 问所有相互信任的应用系统。
Cas单点登录解析
术语：
缩写 全称 解释
SSO
Single Sign On
单点登录
TGT
Ticket Granting Ticket
用户身份认证凭证票据（俗称大令牌，或者说票 根，他可以签发ST）
ST
Service Ticket
服务许可凭证票据（随机参数，每次服务端校验 后作废）
TGC
Ticket Granting Cookie
系统B
5 1
2
3wenku.baidu.com
Cas单点登录解析
Request1 【第一步】终端第一次访问CAS—Client1，AuthenticationFilter会截获此请求：1、首先，检测本地Session没有缓存有用 户信息；2、然后，检测到请求信息中没有ST；3、所以，CAS—Client1将请求重定向到CAS—Server，并传递 Service （也就是要 访问的目的资源地址，以便登录成功过后转回该地址），例：【https://cas:8443/cas/login?service=http0%3A8081%2F】 【第二步】终端第一次访问CAS—Server：1、CAS—Server检测到请求信息中没有TGC，所以跳转到自己的登录页；2、 终端输入用户名、密码登录CAS—Server，认证成功后，CAS—Server会生成登录票据—TGT（集成了用户信息与ST），并随机生成 一个服务票据—ST与CAS会话标识—TGC。TGT实际上就是Session，而TGC就是这标识这个Session存到Cookie中的SessionID； ST即，根据Service生成Ticket。3、然后，CAS—Server会将Ticket加在url 后面，然后将请求redirect 回客户web 应用，例如 URL为【http://192.168.1.90:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZ】 【第三步】这时，终端携带ticket再次请求CAS—Client1：1、这时客户端的AuthenticationFilter看到ticket 参数后，会跳 过，由其后面的TicketValidationFilter 处理；2、TicketValidationFilter 会利用httpclient工具访问cas 服务的/serviceValidate 接口, 将ticket 、service 都传到此接口，由此接口验证ticket 的有效性，即向CAS—Server验证ST的有效性。3、 TicketValidationFilter如果得到验证成功的消息，就会把用户信息写入web 应用的session里。至此为止，SSO 会话就建立起来了。 Request2 上面说了SSO 会话已经建立起来了，这时用户在同一浏览器里第二次访问此web 应用（CAS—Client1）时， AuthenticationFilter会在session 里读取到用户信息，这就代表用户已成功登录，所以就不会去CAS 认证了。 Request3 【第一步】与Request1是完全一样的，如下：终端第一次访问CAS—Client2，AuthenticationFilter会截获此请求：1、首 先，检测本地Session没有缓存有用户信息；2、然后，检测到请求信息中没有ST；3、所以，CAS—Client1将请求重定向到CAS— Server，并传递 Service （也就是要访问的目的资源地址，以便登录成功过后转回该地址），例： 【https://cas:8443/cas/login?service=http0%3A8081%2F】 【第二步】然后，终端第二次访问CAS—Server：此时，Request中会带有上次生成的TGC，然后根据TGC（SessionID） 去查找是否有对应的TGT（Session），如果有，代表此用户已成功登录过，所以此时用户不必再去登录页登录（SSO的体现），而 CAS—Server会直接用找到的TGT签发一个ST，然后重定向到CAS—Client2，剩下的如Request1中的【第三步】就完全一样了。