90 likes | 427 Views
CAS 协议分析. CAS1.0 vs.CAS2.0. CAS1.0 CAS1.0 也称为基础模式 适用场合:参与 SSO 的应用都为 Web 应用,且各应用之间相互独立,没有复杂的集成关系。 CAS2.0 CAS2.0 称为代理模式 适用场合: 参与 SSO 的应用存在非 Web 应用( CAS 使用 Cookie ,故非 Web 应用不宜于直接做 CAS 的客户应用) 应用之间,存在集成关系。. CAS 协议内容.
E N D
CAS1.0 vs.CAS2.0 • CAS1.0 CAS1.0也称为基础模式 适用场合:参与SSO的应用都为Web应用,且各应用之间相互独立,没有复杂的集成关系。 • CAS2.0 CAS2.0称为代理模式 适用场合: • 参与SSO的应用存在非Web应用(CAS使用Cookie,故非Web应用不宜于直接做CAS的客户应用) • 应用之间,存在集成关系。
CAS协议内容 Service Ticket 。ST是CAS为用户签发的访问某一service的票据。用户访问service时,service发现用户没有ST,则要求用户去CAS获取ST。用户向CAS发出获取ST的请求,CAS发现用户有TGT,则签发一个ST,返回给用户。用户拿着ST去访问service,service拿ST去CAS验证,验证通过后,允许用户访问资源。 Proxy TicketGranting Ticket。Proxy Service认证成功后,CAS会生成PGT,并将值回传给Proxy Service 。Proxy Service拿到PGT后,就可以为Target Service做代理,为其申请PT。 Proxy Ticket。PT是用户访问Target Serivce的票据。用户经由Proxy Service去CAS获取到PT后,再访问Target Serivce,Target Serivce去CAS验证PT成功后,才允许用户访问。 Ticket Grangting Ticket 。TGT是CAS为用户签发的登录票据,拥有了TGT,用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。当HTTP请求到来时,CAS以此Cookie值为key查询缓存中有无TGT ,如果有的话,则相信用户已登录过。 Proxy TicketGranting Ticket IOU。PGTIOU是CAS协议中定义的一种附加票据,它增强了传输、获取PGT的安全性。 CAS协议定义了一组术语,一组票据,一组接口。 术语:Client、Server、Service、Proxy、Target。 接口:/login、/logout /validate、/serviceValidate、/proxyValidate /proxy 票据:TGT、ST、PGT、PGTIOU、PT Client、CAS Server、Service三者,是通过各种票据 的传递与验证,来实现单点认证功能的。
CAS1.0协议的动画显示 场景介绍: 在本演示中,用户先访问广告合同管理系统ADM,去投 放广告,之后又去资产系统AMS,查看资产信息。 访问ADM时,用户需要先去CAS登录,之后访问AMS时, 就不需再次登录了。
https://cas.company.com/login?service=http://adm/index.html 早晨第一件事,登录ADM,投放广告! http://adm/index.html?ticket= ST-1-qRPh34B1xhe4dquzz 用户名/密码 电话密保 CAS 写Cookie到浏览器 终端 redirect ST ok,认证成功,我生成Cookie、TGT、ST,TGT我保存,Cookie,ST返回到浏览器,浏览器可以用ST访问ADM了。 没有传cookie过来?那去登录页面登录吧! ST验证成功,返回用户数据 service=http://adm/index.html ticket=ST-5-qRPh34B1xhe4dquzz redirect http://adm/index.html 好,收到ST了,我去CAS验证一下 好,我生成用户对象,你可以到投放页面去了! 哈哈,第一次来,我给你redirect到CAS去! AMS ADM
再登录资产系统,看看资产吧! https://cas.company.com/login?service=http://ams/index.html CASTGC CAS 终端 redirect ST TGC Cookie传过来了,我验证一下是不是我生成的,哦,还真是,那我用TGT签发一个ST,redirect给浏览器吧 redirect http://ams/index.html 哇,只输入了一次用户名/密码,就访问多个系统,比原来强多了! service=http://ams/index.html ticket=ST-2-qRPh78V1xhe4dquzz ST验证成功,返回用户数据 OK,你可以查询资产信息了 http://ams/index.html?ticket= ST-2-qRPh78V1xhe4dquzz 好,我去CAS验证一下ST 哈哈,第一次来,没有ST,去CAS申请一个吧! AMS ADM
CAS2.0协议的动画显示 场景介绍: • Portal:企业用Portal整合了内部所有系统,员工可以直接登录Portal去查看所有内部系统的信息。 • Mail Server:老式C/S结构的邮件服务器。在Portal上线之前,员工只能直接登录Mail Server去管理自己的邮件。 在本演示中,Portal是CAS的Proxy Service, Mail Server是Target Service。Mail Server 需要借助于Portal去登录。 用户登录Portal时,需要去CAS认证,之后在Portal上浏览邮件信息时, Mail Server会请求Portal为其申请PT,然后用PT去CAS验证,验证通过后, 才会返回邮件信息,这个过程,无需用户再次登录。
好,收到ST了,我去CAS验证一下,顺便把pgtUrl传给它,让它生成代理证PGT并传给我,我可是代理啊好,收到ST了,我去CAS验证一下,顺便把pgtUrl传给它,让它生成代理证PGT并传给我,我可是代理啊 https://cas.company.com/login?service=http://portal/ 代理证来了,pgt是我的代理证,pgtIou是我取代理证的钥匙。我要妥善保管! 好,我根据用户数据生成User对象,根据pgtIou取出pgt,放入User对象。我当上代理了! 哈哈,第一次来,我给你redirect到CAS去! 企业Portal CAS http://portal?ticket=ST-1-qRPh34B1xhe4dquzz service=http://portal ticket= ST-1-qRPh34B1xhe4dquzz 没有传cookie过来?那去登录页面登录吧! ok,认证成功,我生成TGC、TGT、ST,TGT我保存,TGC返回到浏览器、ST redirect回Portal pgtIou pgtId 验证ST成功,返回用户数据 pgtIou http://portal/ 输入用户凭证,用户名/密码、电话密保….. 写TGC Cookie到浏览器 早晨第一件事,登录Portal,看看公司动态,顺便看看邮件信息! Mail Server 终端
pgt targetService=mailServer MailServer也归CAS管,所以想访问MailServer,必须得为其申请一个PT,我是代理嘛,交给我了! 把PT传给MailServer,让它拿着去到CAS验证吧 企业Portal CAS PT http://portal/mail PTservice 唉,谁知道,提升用户体验的背后,有这如此繁琐的技术细节。。。。。。 验证一下代理证pgt,还有targetService,都没问题,好,发放PT 验证成功,返回用户数据 PT验证没问题,你可以返回数据给Portal了,呵呵 PT username 返回邮件信息 进去portal了,看下邮件吧 PT验证通过了,我就答应你的请求,把信息传给你吧 看到邮件了,有portal真好,再也不用重新登录Mail服务器去读邮件了。 Mail Server 终端