原理介绍

Posted by

CAS 介绍

CAS 是 Yale 大学倡导的二个开源项目,目的在于为 Web
应用体系提供后生可畏种保障的单点登陆方法,CAS 在 二零零三 年 12 月正式成为 JA-SIG
的三个档案的次序。CAS 具备以下特点:

  • 开源的店堂级单点登陆技术方案。
  • CAS Server 为索要独自安排的 Web 应用。
  • CAS Client 扶助特别多的客商端(这里指单点登陆系统中的各样 Web
    应用),包涵 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。

独立气象

  • X. 第4回访谈整套CAS应用系统的某部应用
  • Y. 已探望过某些应用,首回访谈另多少个接收
  • Z. 第三遍访谈同一应用。

(TGC的意义在于证明是或不是访谈过全部web应用,ST是针对性贰个web应用的)

做客受保证能源,AuthenticationFilter首先看央浼是还是不是有ST

  • 不曾ST且session中无新闻
    证实以前从未访谈过此选取,POST到/cas/login接口,CAS
    Server查看央求是否富含TGC,

    • A. 有TGC–Y场景
      表明该客商此前登陆过其余应用但没登陆过此采纳,用TGC在CAS
      Server缓存中查询TGT,查到后则用此TGT签发叁个ST,
      客商用ST访问web应用,web应用访谈cas服务的/serviceValidate
      接口。验证通过,就能够把顾客音讯写入web 应用的session
      里,并允许访谈受保险能源
    • B. 没有TGC–X场景
      重定向到CAS登入分界面,客商输入密码,POST到/cas/login,假使证实通过,则

      1. 生成TGC写入浏览器
      2. 将TGC封装成TGT保存到CAS Server
      3. 用TGT生成ST,保存并传给web应用
      4. web应用客商端的AuthenticationFilter 看见ticket
        参数后,会跳过,由其背后的TicketValidationFilter管理
      5. TicketValidationFilter访谈cas 服务的/serviceValidate 接口,
        将ticket 、service 都传到此接口,因而接口验证ST的得力
      6. TicketValidationFilter倘若拿到注解成功的新闻,就能够把客商消息写入web
        应用的session里,并允许访谈能源
  1. 有ST, 如果session有信息—Z场景
    不去CAS认证。

境内私募机构九鼎控制股份构建APP,来就送 20元现金领取地方:
里头约请码:C8E245J (不写诚邀码,未有现金送卡塔尔国
境内私募机构九鼎控制股份营造,九鼎投资是在朝野上下股份转让系统上市的公众公司,期货(Futures卡塔 尔(阿拉伯语:قطر‎物运输代理码为430719,为“中中原人民共和国PE第一股”,市场总值超1000亿元。 

CAS 原理和钻探

从协会上看,CAS 包蕴两个部分: CAS Server 和 CAS Client。CAS Server
须求独自布署,重要担当对客商的证实工作;CAS Client
肩负管理对顾客端受爱护财富的拜候央求,须求登陆时,重定向到 CAS
Server。图1 是 CAS 最宗旨的合计进度:

CAS的连锁接口和拍卖逻辑

 

图 1. CAS 根底合同

图片 1

CAS Client 与受保证的客户端应用安插在合营,以 Filter
格局保障受保险的能源。对于访谈受保障能源的每一个 Web 央求,CAS Client
会深入分析该央浼的 Http 诉求中是还是不是包ServiceTicket,如果未有,则表达当前客户并未有登入,于是将诉求重定向到钦定好的 CAS
Server 登入地址,并传递 Service(也等于要拜候的目标财富地址卡塔 尔(阿拉伯语:قطر‎,以便登入成功现在退回该地点。客户在第 3
步中输入认证消息,如若登陆成功,CAS Server
随机产生叁个一定长度、唯大器晚成、不可伪造的 ServiceTicket,并缓存以待现在验证,之后系统自动重定向到Service所在地方,并为顾客端浏览器设置三个 Ticket Granted Cookie(TGC卡塔 尔(英语:State of Qatar),CAS
Client 在获得 Service 和新发生的 Ticket 过后,在第 5,6 步中与 CAS
Server 进行身份合适,以保证 Service Ticket 的合法性。

在该契约中,全部与 CAS 的交互作用均采纳 SSL 公约,确认保障,ST 和 TGC
的安全性。左券职业进度中会有 2 次重定向的经过,不过 CAS Client 与 CAS
Server 之间进行 Ticket 验证的历程对于客商是晶莹的。

除此以外,CAS 协议中还提供了 Proxy
(代理卡塔尔国情势,以适应越来越高级、复杂的运用项景,具体介绍能够参照他事他说加以考查 CAS
官方网址上的有关文书档案。

Ticket介绍

概念介绍
CAS的主导正是其Ticket,及其在Ticket之上的生机勃勃多种管理操作。CAS的注重票据有TGT、ST、PGT、PGTIOU、PT,此中TGT、ST是CAS1.0商业事务中就有个别单据,PGT、PGTIOU、PT是CAS2.0协商业中学有的单据。


TGT(Ticket Grangting Ticket)

TGT是CAS为客商签发的登陆票据,具备了TGT,客户就能够表明自身在CAS成功登录过。TGT封装了Cookie值以至此Cookie值对应的客商信息。客户在CAS认证成功后,CAS生成cookie,写入浏览器,同一时候生成叁个TGT对象,归入本人的缓存,TGT对象的ID便是cookie的值。当HTTP再一次恳请到来时,即使传过来的有CAS生成的cookie,则CAS以此cookie值为key查询缓存中有无TGT
,假如有的话,则表明客户在此以前登入过,若无,则顾客须要再度登入。

 

意气风发、CAS 原理介绍

 图片 2

探问流程图

 

第意气风发原理:客商率先次访问一个CAS 服务的客户web 应用时(访问U景逸SUVL : 卡塔尔,安排在客商web 应用的cas
AuthenticationFilter ,会收获此倡议,生成service 参数,然后redirect 到CAS 服务的login 接口,url为 ,认证成功后,CAS 服务器会变卦认证cookie ,写入浏览器,同不日常候将cookie 缓存到服务器本地,CAS 服务器还大概会依赖service 参数生成ticket,ticket 会保存到服务器,也会加在url 前边,然后将呼吁redirect 回客户web 应用,url 为 。这时候客商端的AuthenticationFilter 看见ticket 参数后,会跳过,由其背后的TicketValidationFilter 处理,TicketValidationFilter 会利用httpclient 工具访谈cas 服务的/serviceValidate 接口, 将ticket 、service 都传到此接口,由此接口验证ticket 的得力,TicketValidationFilter 假设获得认证成功的音信,就能把顾客音信写入web 应用的session里。至此结束,SSO 会话就确立起来了,以后客商在一直以来浏览器里拜谒此web 应用时,AuthenticationFilter 会在session 里读取到顾客新闻,所以就不会去CAS 认证,倘使在那浏览器里会见别的web 应用时,AuthenticationFilter 在session 里读取不到顾客音信,会去CAS 的login 接口认证,但那时CAS 会读取到浏览器传来的cookie ,所以CAS 不会供给客户去登入页面签到,只是会依据service 参数生成二个ticket ,然后再和web 应用做三个验证ticket 的并行。

 

 

ST(Service Ticket)

ST是CAS为客商签发的采访某黄金时代service的单据。客户访谈service时,service开采纳户并未有ST,则须求客户去CAS获取ST。客户向CAS发出获取ST的呼吁,假设客商的呼吁中包括cookie,则CAS会以此cookie值为key查询缓存中有无TGT,假设存在TGT,则用此TGT签发一个ST,重临给顾客。客户借助ST去访谈service,service拿ST去CAS验证,验证通过后,允许顾客访问财富。

 

二、CAS 服务端的拍卖逻辑

CAS 服务端总共对外定义了9 个接口,顾客端通过拜谒那9 个接口与服务端人机联作,那9个接口为:

接口

说明

备注

/login

认证接口

 

/logout

退出接口,负责销毁认证cookie

 

/validate

验证ticket 用的接口,CAS1.0 定义

 

/serviceValidate

验证ticket 用的接口,CAS2.0 定义,返回xml 格式的数据

 

/proxy

支持代理认证功能的接口

 

/proxyValidate

支持代理认证功能的接口

 

/CentralAuthenticationService

用于和远程的web services 交互

 

/remoteLogin(新增)

认证接口

 

/directLogin(新增)

认证接口

 

 

详见表明:

 /login:

报到流程那有个别要构思到不一致类型顾客凭证的拿到方案,以至客商使用传播的service 、gateway 、renew 参数的两样取值组合,CAS 为了得以达成流程的惊人可配置性,选择了Spring
Web
Flow 能力。通过CAS 发表包里的login-webflow.xml 、cas-servlet.xml 、applicationContext.xml 那3 个文本,搜索 了登陆有关的兼具组件,画出管理流程图。

 图片 3

CAS 默许的报随地理流程

 图片 4

率先次访谈Web 应用的流水生产线走向

 图片 5

生机勃勃度报到web1 后,访问web1 的资源(web1 未有运行session 卡塔尔国,或访谈web2 的能源

 

注:

1 : InitialFlowSetupAction: 是流程的入口。用 request.getContextPath() 的值来安装 cookie 的 Path 值, Cookie 的 path 值是在布局文件里定义的,但以此 Action 担任将 request.getContextPath() 的值设置为 Cookie 的 path 值,那是在 cas 安插意况改观的情事下,灵活地安装 cookie
path 的艺术;把 cookie 的值以至 service 参数的值放入 requestContext 的 flowscope 里。

2 : GenerateServiceTicketAction 此 Action 担任遵照 service 、 GTC
cookie 值生成 ServiceTicket 对象, ServiceTicket 的 ID 就是回到给客户利用的 ticket 参数,借使成功开创 ServiceTicket ,则转向到 WarnAction ,假若创设战败,且 gateway 参数为 true ,则直接redirect 到客户利用, 不不过必要再行认证。

3 : viewLoginForm 那是登陆页面, CAS 在那访问客户凭证。 CAS 提供的暗许完结是 /WEB-INF/view/jsp/simple/ui/casLoginView.jsp 。

4 : bindAndValidate 对应 AuthenticationViaFormAction 的 doBind 方法,该措施肩负搜罗登陆页面上用户录入的凭据音信(客户名、密码等卡塔 尔(阿拉伯语:قطر‎,然后把这个音讯打包到 CAS 内部的 Credentials 对象中。客户在 casLoginView.jsp 页面上点击提交后,会触发此方法。

5:submit   对应 AuthenticationViaFormAction 的 submit 方法 , 假设 doBind 方法成功实践完, 则触发 submit 方法,此办法负担调用centralAuthenticationService 的      grantServiceTicket 方法,实现认证工作,借使证实成功,则转移 TicketGrantingTicket 对象,放在缓存里, TicketGrantingTicket 的 ID 便是 TGC
Cookie 的 value 值。

6 : warn  CAS 提供了一个意义:顾客在二个 web 应用中跳到另叁个 web 应用时, CAS 能够跳转到贰个提示页面,该页面提醒客商要离开多个运用进入另一个运用,能够让客户本人筛选。客商在签到页面 viewLoginForm 上圈套选了 id=”warn” 的复选框,技能张开这一个功用。

WarnAction 就检查客户有未有张开那几个效应,假诺翻开了,则转向到showWarnView, 假设没展开,则直接redirect 到客户使用。

7 :SendTicketGrantingTicketAction 此Action 肩负为response 生成TGC
Cookie ,cookie 的值正是 AuthenticationViaFormAction 的submit 方法生成的 TicketGrantingTicket 对象的 ID 。

8 : viewGenerateLoginSuccess 那是 CAS 的证实成功页面。

 

/logout: ( 对应达成类 org.jasig.cas.web.LogoutController 卡塔尔国

拍卖逻辑:   

        1) removeCookie

       2) 在服务端删除TicketGrantingTicket 对象(此指标封装了cookie 的value 值卡塔 尔(阿拉伯语:قطر‎

       3 卡塔 尔(英语:State of Qatar)redirect 到退出页面,有2 种接收:

          if(LogoutController 的followServiceRedirects 属性为true 值,且url 里的service 参数非空){

                redirect 到 sevice 参数标志的url

             }

          else{

             redirect 到内置的casLogoutView (cas/WEB-INF/view/jsp/default/ui/cas图标utView.jsp 卡塔尔国,假如url 里有url 参数,则此url 参数标记的链接会彰显在casLogoutView 页面上。

           }

 

/serviceValidate: (对应实现类 org.jasig.cas.web.ServiceValidateController 卡塔 尔(阿拉伯语:قطر‎

 处理逻辑:  

  假使service 参数为空或ticket 参数为空,则转向到failureView (/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationFailure.jsp 卡塔尔

    验证ticket 。以ticket 为参数,去缓存里找ServiceTicketImpl 对象,假如能找到,且从未过期,且ServiceTicketImpl 对象对应的service 属性和service 参数对应,则印证通过,验证通过后,央求转载至casServiceSuccessView (cas/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationSuccess.jsp 卡塔尔,验证不通过,则转向到failureView 。

 

PGT(Proxy Granting Ticket)

Proxy Service的代办凭据。顾客通过CAS成功登陆某风姿罗曼蒂克Proxy
Service后,CAS生成三个PGT对象,缓存在CAS本地,同时将PGT的值(一个UUID字符串卡塔 尔(英语:State of Qatar)回传给Proxy
Service,并保留在Proxy Service里。Proxy Service拿到PGT后,就能够为Target
Service(back-end service卡塔 尔(阿拉伯语:قطر‎做代办,为其报名PT。

原来的小说地址: 

三、认证相关的概念及流程

概念

  • Credentials 顾客提供的用于登陆用的凭证新闻,如客商名/ 密码、证书、IP 地址、Cookie 值等。比方 UsernamePasswordCredentials ,封装的是客商名和密码。CAS 实行验证的率先步,正是把从UI 或request 对象里取到的客商凭据封装成Credentials 对象,然后交到认证微处理机去申明。
  • AuthenticationHandler 证明Handler, 种种AuthenticationHandler 只可以管理大器晚成种Credentials ,如AbstractUsernamePasswordAuthenticationHandler 只担任管理 U sernamePasswordCredentials 。
  • Principal 封装顾客标志,比方 SimplePrincipal, 只是包裹了顾客名。认证成功后, credentialsToPrincipalResolvers 担当由Credentials 生成 Principal 对象。
  • CredentialsToPrincipalResolvers 顶住由 Credentials 生成 Principal 对象,各样 CredentialsToPrincipalResolvers 只处理 意气风发种Credentials ,举个例子 UsernamePasswordCredentialsToPrincipalResolver 担当从 U sernamePasswordCredentials 中收取顾客名,然后将其赋给生成的 SimplePrincipal 的 ID 属性。
  • AuthenticationMetaDataPopulators 负担将 Credentials 的局地性质赋值给 Authentication 的 attributes 属性。
  • Authentication  
    Authentication是认证微电脑的末段管理结果, Authentication 封装了 Principal ,认证时间,及其余部分性质(恐怕出自 Credentials 卡塔 尔(阿拉伯语:قطر‎。
  • AuthenticationManager 认证微机获得 Credentials 对象后,负担调治AuthenticationHandler 去做到认证专门的学业,最终回到的结果是 Authentication 对象。
  • CentralAuthenticationService  CAS 的服务类,对 Web 层提供了一些主意。该类还担负调用 AuthenticationManager 落成认证逻辑

 

序列图

 图片 6

 

类图

 图片 7

 

PGTIOU(Proxy Granting Ticket IOU)

PGTIOU是CAS公约中定义的黄金时代种附加票据,它巩固了传输、获取PGT的安全性。
PGT的传导与收获的经过:Proxy
Service调用CAS的serviceValidate接口验证ST成功后,CAS首先会拜谒pgtUrl指向的https
url,将扭转的 PGT及PGTIOU传输给proxy service,proxy
service会以PGTIOU为key,PGT为value,将其积累在Map中;然后CAS会调换验证ST成功的xml音信,重回给Proxy
瑟维斯,xml音讯中蕴藏PGTIOU,proxy
service收到Xml消息后,会从中剖判出PGTIOU的值,然后以其为key,在map中寻觅PGT的值,赋值给代表客商音信的Assertion对象的pgtId,同期在map上将其除去。

CAS的主题正是其Ticket,及其在Ticket之上的意气风发多元管理操作。CAS的主要性票据有TGT、ST、PGT、PGTIOU、PT,在那之中TGT、ST是CAS1.0交涉中就有个别单据,PGT、PGTIOU、PT是CAS2.0商量中有的单据。

四、Ticket介绍

CAS的中坚正是其Ticket,及其在Ticket之上的大器晚成多元管理操作。CAS的要害票据有TGT、ST、PGT、PGTIOU、PT,个中TGT、ST是CAS1.0磋商中就一些单据,PGT、PGTIOU、PT是CAS2.0构和中部分单据。

 

PT(Proxy Ticket)

PT是客商访谈Target Service(back-end
service卡塔 尔(英语:State of Qatar)的票证。固然客户访问的是多少个Web应用,则Web应用会必要浏览器提供ST,浏览器就能够用cookie去CAS获取二个ST,然后就足以访问这么些Web应用了。假如客户访问的不是二个Web应用,而是一个C/S结构的利用,因为C/S结构的利用得不到cookie,所以客户无法友好去CAS获取ST,而是通过访谈proxy
service的接口,依靠proxy
service的PGT去拿到一个PT,然后能力访谈到此采用。

 

大器晚成 名词解释

  • TGT(Ticket Grangting Ticket)

TGT是CAS为顾客签发的记名票据,具备了TGT,顾客就能够印证本身在CAS成功登陆过。TGT封装了Cookie值以致此Cookie值对应的客商新闻。顾客在CAS认证成功后,CAS生成cookie,写入浏览器,同不时候生成一个TGT对象,放入本身的缓存,TGT对象的ID正是cookie的值。当HTTP再度号令到来时,借使传过来的有CAS生成的cookie,则CAS以此cookie值为key查询缓存中有无TGT
,假如有的话,则证实客户以前登录过,若无,则客商须求重新登陆。

 

  • ST(Service Ticket)

ST是CAS为顾客签发的会见某豆蔻年华service的票据。客商访谈service时,service开掘顾客未有ST,则必要客户去CAS获取ST。客户向CAS发出获取ST的哀求,假诺顾客的乞求中富含cookie,则CAS会以此cookie值为key查询缓存中有无TGT,尽管存在TGT,则用此TGT签发四个ST,重临给顾客。顾客依附ST去走访service,service拿ST去CAS验证,验证通过后,允许客户访问财富。

 

  • PGT(Proxy Granting Ticket)

Proxy Service的代理凭据。客户通过CAS成功登入某黄金时代Proxy
Service后,CAS生成二个PGT对象,缓存在CAS本地,同时将PGT的值(三个UUID字符串卡塔 尔(阿拉伯语:قطر‎回传给Proxy
Service,并保存在Proxy Service里。Proxy Service获得PGT后,就足感觉Target
Service(back-end service卡塔尔国做代办,为其申请PT。

 

  • PGTIOU(Proxy Granting Ticket IOU)

PGTIOU是CAS协议中定义的意气风发种附加票据,它加强了传输、获取PGT的安全性。
PGT的传输与收获的进度:Proxy
Service调用CAS的serviceValidate接口验证ST成功后,CAS首先会访谈pgtUrl指向的https
url,将转移的 PGT及PGTIOU传输给proxy service,proxy
service会以PGTIOU为key,PGT为value,将其积攒在Map中;然后CAS会变动验证ST成功的xml音信,重临给Proxy
Service,xml音信中富含PGTIOU,proxy
service收到Xml新闻后,会从当中深入深入分析出PGTIOU的值,然后以其为key,在map中寻找PGT的值,赋值给代表客商音讯的Assertion对象的pgtId,同期在map大校其删除。

 

  • PT(Proxy Ticket)

PT是用户访谈Target Service(back-end
service卡塔 尔(阿拉伯语:قطر‎的票子。假诺客户访问的是三个Web应用,则Web应用会须求浏览器提供ST,浏览器就能够用cookie去CAS获取贰个ST,然后就能够访问这一个Web应用了。假设客户访谈的不是一个Web应用,而是一个C/S结构的利用,因为C/S结构的选拔得不到cookie,所以顾客不可能协调去CAS获取ST,而是通过拜会proxy
service的接口,依附proxy
service的PGT去获得二个PT,然后技术访问到此选取。

 

从浏览器观望到的流水生产线

率先步:GET央浼受敬性格很顽强在艰难困苦或巨大压力面前不屈财富,重临302,重定向到cas登陆页面

寻访受有限扶助财富
http://localhost:8088/cas/index.html

返回302

响应音信中,有多少个header须要关心

Location:https://cas.xxx.com:8443/cas/login?service=http%3A%2F%2Flocalhost%3A8088%2Fcallback%3Fclient\_name%3DCasClient

decode后:https://cas.xxx.com:8443/cas/login?service=http://localhost:8088/callback?client\_name=CasClient

那是GET央浼,显示CAS登入页面,能够输入客商名密码认证。

其次步:cas登录页面输入客商民密码,发送POST央求,重回302,重定向到callback

输入客户密码,点击分明,发送POST央求
请求URL:https://cas.xxx.com:8443/cas/login?service=http://localhost:8088/callback?client\_name=CasClient
供给头中:
Referer:https://cas.xxx.com:8443/cas/login?service=http%3A%2F%2Flocalhost%3A8088%2Fcallback%3Fclient\_name%3DCasClient
表示是从cas的报到分界面登陆

响应:302
Location:
http://localhost:8088/callback?client\_name=CasClient&ticket=ST-3-YQwbCErcdLU2Lf5I1tqH-greenvm-w10857v6
Set-Cookie:”TGC=eyJhbGciOiJIUzUxMiJ9.WlhsS2FHSkhZMmxQYVVwcllWaEphVXhEU214aWJVMXBUMmxLUWsxVVNUUlJNRXBFVEZWb1ZFMXFWVEpKYmpBdUxuRmZhelZCV1RsUFgxSnZUV1UzT1dkd1lXSk9SVkV1TVdRMU9Xc3RURXBOZURCZmFtaGZTRWhsU0UxWE5XVlpjVlZwTm5ob2NGODNVemRqV0hCNmFuQkdlREU0YjFWNE9EWlRiRGcyWlc5Ull6ZFpaR3BpTlRaZlRsaGhha2RJY1Zsd1NuQlRTRkJRVldJMVdqSlhVRTFPUlVkdFRHdzJRMmRFTlRNeU5HNDROakYxTlcxWmMzTlBhR05SYjFCSlRESXlUV0pDUmtwclpWUXdOalZhUldGRWJHdERXVXQ0VlU5V2FsTjVRV3N5UzFSNlZrTXROMmRaVGtGUVNreENSbHBMWVc4eVlpMVpaVFJWYjBjeGJUaGFNVWRTWlVKMFdIQjRTbEpyWWtaS1dtWlNNSGhhUVUxb1JYSjFlRlJrV25Wa09HRmxWVkZyUTFjd1JFWjVlbWRhT0M1TlpsaHNaVEpmU2xCQmJXa3pTM0poYVVJMlFUWlI.wugAxxGRW1VQBVaorBkwv74L-t5idA0SlzNll6T4X4Svd_YpaWlcDjOUhe3d-JstVrtJ95PNECN78k3P4XTaKQ;path=/cas/;Secure”

X-Application-Context:”cas:native:8443″

证实成功后,CAS 服务器会变动认证cookie(TGC)
,写入浏览器,同一时间将cookie封装成TGT缓存到服务器本地.TGC的意义在于标志顾客是或不是已报到
同期依据service 参数生成ST,ST会保存到服务器,也会加在url 前面

其三步:须求callback,带有ST参数,重临302,重定向到财富地址。

http://localhost:8088/callback?client\_name=CasClient&ticket=ST-3-YQwbCErcdLU2Lf5I1tqH-greenvm-w10857v6

当时客商端的AuthenticationFilter 见到ticket
参数后,会跳过,由其背后的TicketValidationFilter 处理
TicketValidationFilter会利用httpclient 工具访谈cas
服务的/serviceValidate 接口, 将ticket 、service
都传到此接口,由此接口验证ticket的可行
TicketValidationFilter 假诺拿到验证成功的音信,就能够把顾客新闻写入web
应用的session 里
客商在长期以来浏览器里拜访此web 应用时,AuthenticationFilter 会在session
里读取到客户消息,所以就不会去CAS 认证

响应:302
Location:http://localhost:8088/cas/index.html

此刻大家访谈另两个接受的受有限支撑能源
http://localhost:8089/cas/index.html

在那浏览器里拜谒其余web 应用时,AuthenticationFilter在session
里读取不到客户消息,会去CAS 的login 接口认证
但那时候CAS 会读取到浏览器传来的cookie
于是CAS 不会需要客商去登入页面签到,只是会依靠service参数生成一个ST
接下来再和web 应用做多个验证ticket 的竞相而已

再次来到302,重定向到
http://localhost:8089/callback?client\_name=CasClient&ticket=ST-4-yQEVtoz5sLAJQsIHrITl-greenvm-w10857v6

能够看出变化了新的ST

BTW 安全相关响应Header

X-Content-Type-Options:”nosniff”
浏览器过于智能化会带给平安问题。如一个响应内容中含有js代码,Content-Type为image/png,但浏览器会预计出是本子并施行。
以此响应告诉浏览器要严加服从响应中的Content-Type来深入分析内容。

X-Frame-Options:”DENY”
幸免点击威胁攻击,告知浏览器不要将响应中的内容在HTML Frame中展现出来。

x-xss-protection:”1; mode=block”

跨站脚本漏洞(Cross-Site Scripting)
最棒方法是对输出的多少开展不易的编码。
除了,今世浏览器也自带了防守XSS的力量。只需在响应中进入x-xss-protection:”1;
mode=block”就可以。
1代表开启浏览器防范XSS效能;mode=block表示发掘XSS攻击时直接屏蔽将在渲染的内容

生龙活虎 名词解释

二 代码解析

 图片 8

CAS Ticket类图

 

  • TicketGrantingTicket 的 grantServiceTicket方法

措施注解:public synchronized ServiceTicket grantServiceTicket(final
String id,final Service service, final ExpirationPolicy
expirationPolicy, final boolean credentialsProvided)

方法描述:

 1:生成SerivceTicketImpl

 2:更新属性:

this.previousLastTimeUsed = this.lastTimeUsed;

   this.lastTimeUsed = System.currentTimeMillis();

   this.countOfUses++;

 3:给service对象的principal属性赋值

 4:将service对象放入map services

 

  • ServiceTicket 的 grantTicketGrantingTicket方法

主意注解:

public TicketGrantingTicket grantTicketGrantingTicket(final String id,
final Authentication authentication,final ExpirationPolicy
expirationPolicy)

方法描述:在CAS3.3对CAS2.0切磋的兑现中,PGT是由ST签发的,调用的就是瑟维斯Ticket的grantTicket格兰特ingTicket方法。方法再次回到的TicketGrantingTicket对象,表征的是一个PGT对象,此中的ticketGrantingTicket属性的值是签发ST的TGT对象。

 

  • TicketGrantingTicket 的 expire方法

办法申明:void expire()

措施描述:

在CAS的logout接口实现中,要调用TGT对象的expire方法,然后会在缓存中消灭此TGT对象。

expire方法的源委:循环遍历 services
中的瑟维斯对象,调用其logoutOfService方法。具体瑟维斯达成类中的logoutOfService方法的落到实处,要公告具体的施用,顾客要抽离。

 

  • TGT(Ticket Grangting Ticket)

三、TGT、ST、PGT、PT关系

1:ST是TGT签发的。顾客在CAS上印证成功后,CAS生成TGT,用TGT签发一个ST,ST的ticketGrantingTicket属性值是TGT对象,然后把ST的值redirect到顾客利用。

 

2:PGT是ST签发的。客户依靠ST去探问Proxy service,Proxy
service去CAS验证ST(同期传递PgtUrl参数给CAS),若是ST验证成功,则CAS用ST签发一个PGT,PGT对象里的ticketGrantingTicket是签发ST的TGT对象。

 

3:PT是PGT签发的。Proxy service代理back-end
service去CAS获取PT的时候,CAS依据传来的pgt参数,获取到PGT对象,然后调用其grant瑟维斯Ticket方法,生成三个PT对象。

 图片 9

TGT、ST、PGT、PT之间的关系关系

 

 

 

 

TGT是CAS为客户签发的报到票据,具备了TGT,顾客就能够证实本身在CAS成功登入过。TGT封装了Cookie值以致此Cookie值对应的顾客音讯。客户在CAS认证成功后,CAS生成cookie,写入浏览器,同期生成三个TGT对象,放入自身的缓存,TGT对象的ID正是cookie的值。当HTTP再一次伸手到来时,要是传过来的有CAS生成的cookie,则CAS以此cookie值为key查询缓存中有无TGT
,假若有的话,则证实客商早先登陆过,若无,则用户必要再度登入。

CAS CLIENT篇

 

CASFilter 参数表达:

 

参数

是否必须

说明

com.olymtech.cas.client.filter.loginUrl

指定 CAS 提供登录页面的 URL

com.olymtech.cas.client.filter.validateUrl

指定 CAS 提供 service ticket 或 proxy ticket 验证服务的 URL

com.olymtech.cas.client.filter.serverName

指定客户端的域名和端口,是指客户端应用所在机器而不是 CAS Server 所在机器,该参数或 serviceUrl 至少有一个必须指定

com.olymtech.cas.client.filter.serviceUrl

该参数指定过后将覆盖 serverName 参数,成为登录成功过后重定向的目的地址

com.olymtech.cas.client.filter.wrapRequest

如果指定为 true,那么 CASFilter 将重新包装 HttpRequest,并且使 getRemoteUser() 方法返回当前登录用户的用户名

com.olymtech.cas.client.filter.noFilter

设置不过滤的路径,语法如下:/name1/,/name2,

com.olymtech.cas.client.filter.proxyCallbackUrl

用于当前应用需要作为其他服务的代理(proxy)时获取 Proxy Granting Ticket 的地址

com.olymtech.cas.client.filter.authorizedProxy

用于允许当前应用从代理处获取 proxy tickets,该参数接受以空格分隔开的多个 proxy URLs,但实际使用只需要一个成功即可。当指定该参数过后,需要修改 validateUrl 到 proxyValidate,而不再是 serviceValidate

com.olymtech.cas.client.filter.renew

如果指定为 true,那么受保护的资源每次被访问时均要求用户重新进行验证,而不管之前是否已经通过

com.olymtech.cas.client.filter.gateway

指定 gateway 属性

  • ST(Service Ticket)

ST是CAS为客商签发的访问某大器晚成service的单子。顾客访问service时,service开选取户并未ST,则须求顾客去CAS获取ST。顾客向CAS发出获取ST的号令,要是顾客的号召中隐含cookie,则CAS会以此cookie值为key查询缓存中有无TGT,要是存在TGT,则用此TGT签发一个ST,再次回到给客商。用户凭仗ST去访谈service,service拿ST去CAS验证,验证通过后,允许客商访谈能源。

 

  • PGT(Proxy Granting Ticket)

Proxy Service的代办凭据。客户通过CAS成功登入某大器晚成Proxy
Service后,CAS生成三个PGT对象,缓存在CAS本地,同期将PGT的值(三个UUID字符串卡塔尔国回传给Proxy
Service,并保留在Proxy 瑟维斯里。Proxy Service得到PGT后,就能够为Target
Service(back-end service卡塔尔国做代办,为其报名PT。

 

  • PGTIOU(Proxy Granting Ticket IOU)

PGTIOU是CAS左券中定义的后生可畏种附加票据,它巩固了传输、获取PGT的安全性。
PGT的传输与收获的经过:Proxy
Service调用CAS的serviceValidate接口验证ST成功后,CAS首先会拜访pgtUrl指向的https
url,将转移的 PGT及PGTIOU传输给proxy service,proxy
service会以PGTIOU为key,PGT为value,将其储存在Map中;然后CAS会变卦验证ST成功的xml音讯,重返给Proxy
Service,xml信息中包涵PGTIOU,proxy
service收到Xml音讯后,会从当中解析出PGTIOU的值,然后以其为key,在map中寻找PGT的值,赋值给代表顾客消息的Assertion对象的pgtId,相同的时间在map中将其除去。

 

  • PT(Proxy Ticket)

PT是客商访谈Target Service(back-end
service卡塔尔的票子。假诺客户访谈的是叁个Web应用,则Web应用会要求浏览器提供ST,浏览器就能用cookie去CAS获取叁个ST,然后就可以访谈这几个Web应用了。倘使客户访谈的不是二个Web应用,而是一个C/S结构的使用,因为C/S结构的应用得不到cookie,所以顾客不能够协调去CAS获取ST,而是通过拜谒proxy
service的接口,依赖proxy
service的PGT去得到三个PT,然后技能访问到此选拔。

 

二 代码深入深入分析

                                                    CAS Ticket类图

  • TicketGrantingTicket 的 grantServiceTicket方法

办法注明:public synchronized ServiceTicket grant瑟维斯Ticket(final
String id,final Service service, final ExpirationPolicy
expirationPolicy, final boolean credentialsProvided)
艺术描述:
 1:生成SerivceTicketImpl
 2:更新属性:
this.previousLastTimeUsed = this.lastTimeUsed;
   this.lastTimeUsed = System.currentTimeMillis();
   this.countOfUses++;
 3:给service对象的principal属性赋值
 4:将service对象放入map services

 

  • ServiceTicket 的 grantTicketGrantingTicket方法

方法表明:
public TicketGrantingTicket grantTicketGrantingTicket(final String id,
final Authentication authentication,final ExpirationPolicy
expirationPolicy)
艺术描述:在CAS3.3对CAS2.0切磋的落到实处中,PGT是由ST签发的,调用的就是ServiceTicket的grantTicket格兰特ingTicket方法。方法重回的TicketGrantingTicket对象,表征的是二个PGT对象,个中的ticketGrantingTicket属性的值是签发ST的TGT对象。

 

  • TicketGrantingTicket 的 expire方法

方式注脚:void expire()
办法描述:
在CAS的logout接口达成中,要调用TGT对象的expire方法,然后会在缓存中消亡此TGT对象。
expire方法的内容:循环遍历 services
中的Service对象,调用其logoutOfService方法。具体Service达成类中的logoutOfService方法的兑现,要公告具体的行使,顾客要退出。

TGT、ST、PGT、PT之间涉及的计算

 

1:ST是TGT签发的。客户在CAS上表达成功后,CAS生成TGT,用TGT签发二个ST,ST的ticketGrantingTicket属性值是TGT对象,然后把ST的值redirect到顾客利用。

 

2:PGT是ST签发的。客户依据ST去拜望Proxy service,Proxy
service去CAS验证ST(同一时常间传递PgtUrl参数给CAS卡塔 尔(英语:State of Qatar),如若ST验证成功,则CAS用ST签发一个PGT,PGT对象里的ticketGrantingTicket是签发ST的TGT对象。

 

3:PT是PGT签发的。Proxy service代理back-end
service去CAS获取PT的时候,CAS依据传来的pgt参数,获取到PGT对象,然后调用其grant瑟维斯Ticket方法,生成三个PT对象。

                                        TGT、ST、PGT、PT之间的涉及关系

 

注:固然本文中介绍的 Ticket 概念不详细,请参照他事他说加以考察本人的另后生可畏篇随笔 CAS 总括之公约深入分析篇,里面包车型地铁卡通片演示比较清楚地球表面述了 Client 、 Service 、 CAS 三者之间的交互作用。

相关文章

Leave a Reply

电子邮件地址不会被公开。 必填项已用*标注