`
desert3
  • 浏览: 2158641 次
  • 性别: Icon_minigender_1
  • 来自: 合肥
社区版块
存档分类
最新评论

CAS 1.0、CAS2.0演示例子(转)

 
阅读更多
CAS1.0 vs.CAS2.0:
  • CAS1.0也称为基础模式。适用场合:参与SSO的应用都为Web应用,且各应用之间相互独立,没有复杂的集成关系。
  • CAS2.0称为代理模式。适用场合:参与SSO的应用存在非Web应用(CAS使用Cookie,故非Web应用不宜于直接做CAS的客户应用),应用之间可以存在集成关系。

CAS协议内容
CAS协议定义了一组术语,一组票据,一组接口。
术语:Client、Server、Service、Proxy、Back-end service(Target service)。
接口:/login、/logout、/validate、/serviceValidate、/proxyValidate、/proxy
票据:TGT、ST、PGT、PGTIOU、PT
  • Ticket Grangting Ticket :TGT是CAS为用户签发的登录票据,拥有了TGT,用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。当HTTP请求到来时,CAS以此Cookie值为key查询缓存中有无TGT ,如果有的话,则相信用户已登录过。
  • Service Ticket :ST是CAS为用户签发的访问某一service的票据。用户访问service时,service发现用户没有ST,则要求用户去CAS获取ST。用户向CAS发出获取ST的请求,CAS发现用户有TGT,则签发一个ST,返回给用户。用户拿着ST去访问service,service拿ST去CAS验证,验证通过后,允许用户访问资源。
  • Proxy Granting Ticket:Proxy Service认证成功后,CAS会生成PGT,并将值回传给Proxy Service 。Proxy Service拿到PGT后,就可以为Target Service做代理,为其申请PT。
  • Proxy Granting Ticket IOU:PGTIOU是CAS协议中定义的一种附加票据,它增强了传输、获取PGT的安全性。
  • Proxy Ticket: PT是用户访问Target Serivce的票据。用户经由Proxy Service去CAS获取到PT后,再访问Target Serivce,Target Serivce去CAS验证PT成功后,才允许用户访问。

Client、CAS Server、Service三者,是通过各种票据的传递与验证,来实现单点认证功能的。

CAS1.0协议的例子
场景介绍:
在本演示中,用户先访问广告合同管理系统ADM,去投放广告,之后又去资产系统AMS,查看资产信息。
访问ADM时,用户需要先去CAS登录,之后访问AMS时,就不需再次登录了。
  • 用户: 早晨第一件事,登录ADM,投放广告!
  • 客户端: 通过浏览器访问ADM网址 http://adm/index.html
  • ADM: 哈哈,第一次来,我给你redirect到CAS去!
  • ADM: 通过浏览器redirect到CAS https://cas.company.com/login?service=http://adm/index.html
  • CAS: 没有传cookie过来?那去登录页面登录吧!
  • CAS: 返回登录页面给客户端
  • 客户端: 输入用户名/密码 电话密保等信息登录CAS系统
  • CAS: ok,认证成功,我生成Cookie、TGT、ST。TGT我保存,Cookie,ST返回到浏览器,浏览器可以用ST访问ADM了。
  • CAS: 写Cookie到浏览器
  • CAS: 通过浏览器redirect到ADM画面(带ADM服务的ST参数) http://adm/index.html?ticket=ST-1-qRPh34B1xhe4dquzz
  • ADM: 好,收到ST了,我去CAS验证一下
  • ADM: 传递参数service=http://adm/index.htmlticket=ST-1-qRPh34B1xhe4dquzz给CAS,请求CAS验证ADM服务的ticket
  • CAS: ST验证成功,返回用户数据
  • ADM: 好,我生成用户对象,你可以到投放页面去了!
  • 用户: 再登录资产系统,看看资产吧!
  • 客户端: 通过浏览器访问AMS网址 http://ams/index.html
  • AMS: 哈哈,第一次来,没有ST,去CAS申请一个吧!
  • AMS: 通过浏览器redirect到CAS https://cas.company.com/login?service=http://ams/index.html
  • CAS: TGC Cookie传过来了,我验证一下是不是我生成的,哦,还真是,那我用TGT签发一个ST,redirect给浏览器吧
  • CAS: 通过浏览器redirect到AMS画面(带AMS服务的ST参数) http://ams/index.html?ticket=ST-2-qRPh78V1xhe4dquzz
  • AMS: 好,我去CAS验证一下ST
  • AMS: 传递参数service=http://ams/index.htmlticket=ST-2-qRPh78V1xhe4dquzz 给CAS,请求CAS验证AMS服务的ticket
  • CAS: ST验证成功,返回用户数据
  • AMS: OK,你可以查询资产信息了
  • 用户: 哇,只输入了一次用户名/密码,就访问多个系统,比原来强多了!

CAS2.0协议的例子
场景介绍:
Portal:企业用Portal整合了内部所有系统,员工可以直接登录Portal去查看所有内部系统的信息。
Mail Server:老式C/S结构的邮件服务器。在Portal上线之前,员工只能直接登录Mail Server去管理自己的邮件。
在本演示中,Portal是CAS的Proxy Service, Mail Server是Back-end service(Target service)。Mail Server 需要借助于Portal去登录。
用户登录Portal时,需要去CAS认证,之后在Portal上浏览邮件信息时,Portal向CAS为MailServer申请PT,Portal把PT传递给MailServer,然后MailServer去CAS验证PT,验证通过后,MailServer返回邮件信息给Portal,这个过程,无需用户再次登录。
  • 用户: 早晨第一件事,登录Portal,看看公司动态,顺便看看邮件信息!
  • 客户端: 通过浏览器访问Portal网址 http://portal/
  • Portal: 哈哈,第一次来,我给你redirect到CAS去!
  • Portal: 通过浏览器redirect到CAS https://cas.company.com/login?service=http://portal/
  • CAS: 没有传cookie过来?那去登录页面登录吧! 
  • CAS: 返回登录页面给客户端
  • 客户端: 输入用户名/密码 电话密保等信息登录CAS系统
  • CAS:  ok,认证成功,我生成TGC、TGT、ST,TGT我保存,TGC返回到浏览器、ST redirect回Portal
  • CAS: 写Cookie到浏览器
  • CAS: 通过浏览器redirect到Portal画面(带Portal服务的ST参数) http://portal?ticket=ST-1-qRPh34B1xhe4dquzz
  • Portal: 好,收到ST了,我去CAS验证一下, 顺便把pgtUrl传给它,让它生成代理证PGT并传给我,我可是代理啊
  • Portal: 传递参数service=http://portal,ticket= ST-1-qRPh34B1xhe4dquzz及pgtUrl给CAS,请求CAS验证Portal服务的ticket并生成PGT
  • CAS: 使用https协议带参数pgtIou和pgt访问Portal上的代理回调接口pgtUrl,Portal网站保存传递过来的pgt和pgtIou参数
  • Portal: 代理证传来了,pgt是我的代理证,pgtIou是我取代理证的钥匙(要和CAS Response返回的pgtIou比较)。我要妥善保管!
  • CAS: 验证ST成功,返回用户数据及pgtIou
  • Portal: 好,我根据用户数据生成User对象,根据pgtIou取出pgt,放入User对象。我当上代理了!
  • 用户: 进去portal了,看下邮件吧
  • 客户端: 通过浏览器访问Mail服务网址 http://portal/mail
  • Portal: MailServer也归CAS管,所以想访问MailServer,必须得为其申请一个PT,我是代理嘛,交给我了!
  • Portal: 传递pgt和targetService=mailServer给CAS,申请代理服务
  • CAS: 验证一下代理证pgt,还有targetService,都没问题,好,发放PT
  • CAS: 传递PT给Portal
  • Portal: 把PT传给MailServer,让它拿着去到CAS验证吧
  • Portal: 传递PT和username给MailServer
  • MailServer: 传递PT和service给CAS,请求CAS验证PT
  • CAS: PT验证成功,你可以返回数据给Portal了,呵呵
  • CAS: 验证成功,返回用户数据
  • MailServer: PT验证通过了,我就答应你的请求,把信息传给Portal吧
  • MailServer: 返回邮件信息给Portal
  • 用户: 在Portal上看到邮件了,有portal真好,再也不用重新登录Mail服务器去读邮件了。

   
转自:
CAS协议分析
分享到:
评论

相关推荐

    CAS 协议 票据、url介绍,包括cas1.0和cas2.0

    CAS 协议 票据、url 介绍,包括 cas1.0 和 cas2.0 CAS 协议是一个基于 HTTP 的协议,分为两部分:票据(Ticket)和 URL。CAS 协议的主要目的是提供单点登录(SSO)功能,实现用户的身份验证和授权。 票据(Ticket...

    cas3.5.0集成oauth2.0协议

    1. **配置OAuth2.0服务**:在CAS服务器端,需要配置OAuth2.0的相关参数,如客户端ID、客户端密钥、授权端点、令牌端点等,以支持OAuth2.0协议。 2. **创建OAuth2.0客户端**:在第三方服务(如微博)上注册应用,...

    cas-client:适用于Node.js的CAS客户端中间件的完整实现,支持CAS 1.0、2.0 +,3.0 +协议

    http-cas-client 用于Node.js的CAS客户端中间件的完整实现,支持CAS 1.0、2.0 +,3.0 +协议。 CAS(中央身份验证服务)是Web的单点登录/单点退出协议。 我们假设您已经熟悉CAS协议,如果不熟悉,请在使用前阅读本。...

    cas 配置client 1.0 &2.0 及proxy DEMO 说明

    【CAS配置client 1.0 & 2.0及proxy DEMO说明】 CAS(Central Authentication Service)是一种基于Web的单点登录(Single Sign-On, SSO)协议,它允许用户通过一个认证入口登录,然后访问多个受保护的应用系统,而...

    CAS协议分析

    CAS1.0,CAS2.0协议分析,有动画显示各个版本的使用原理。

    H3C CAS维护手册V2.0.chm

    H3C CAS维护手册V2.0,可用于H3C CAS系统的管理和维护。为了保证局点CAS系统的稳定运行,需要进行维护工作。主要包括查看告警、查看操作日志、查看集群、查看主机、查看虚拟机、查看License以及查看日志等。

    H3C CAS维护手册V2.0.rar_V2 _cas维护_cloud computing_h3c cas维护要求_云平台

    《H3C CAS维护手册V2.0》是H3C公司推出的针对其云计算平台——Cloud Computing H3C CAS(Cloud Computing H3C Cloud Application System)的维护指南。该手册详细阐述了如何对H3C CAS进行有效的管理和维护,以确保云...

    cas 官方提供的例子改造

    5. **CAS协议**:深入理解CAS协议的各个版本,如CAS 1.0、CAS 2.0、CAS 3.0和CAS 4.0+,以及它们之间的差异。 6. **调试与测试**:如何使用日志、调试工具等进行问题排查,确保CAS服务和客户端的正确运行。 7. **...

    django3-cas-ng-4.0.0.tar.gz

    - Support CAS version 1.0, 2.0, 3.0 - Support Single Sign Out - Configuration of services via the django Admin application - Fine control on which user's attributes are passed to which service - ...

    CAS Protocol 3.0 Specification.docx 官方中文版教程详解

    CAS协议有多个版本,包括1.0、2.0和3.0,其中3.0是较为成熟和功能完善的版本。 **关键术语** - **Client**:指的是终端用户和/或Web浏览器。 - **CAS Client**:是与Web应用程序集成并使用CAS协议与CAS服务器交互...

    cas认证原理

    为了提升扩展性和架构设计,随后发展出了遵循CAS1.0和CAS2.0协议的CAS3.X版本。CAS3.X版本全面拥抱Spring技术栈,包括Spring DI容器、AOP技术、Spring Web MVC、Spring Web Flow和Spring LDAP Template等。 CAS总体...

    cas-overlay-template-5.3

    3. **CAS协议**:CAS支持多种协议,如CAS 1.0、CAS 2.0、CAS 3.0、SAML 1.1等。CAS 5.3可能进一步支持CAS 4.0和CAS 5.0协议,提供更安全的认证和授权机制。 4. **多语言支持**:CAS Server 5.3可能内置了多语言支持...

    cas-client-3.2.1 cas-server-3.4.11

    - 协议实现:CAS使用HTTP和HTTPS进行通信,主要依赖于TCP/TLS协议,包括CAS协议的三种主要版本:CAS 1.0、CAS 2.0和CAS 3.0。 4. **安全性与优势**: 使用CAS的好处在于,用户只需登录一次即可访问所有已集成的...

    sso cas server原始代码

    4. **协议支持**:CAS支持多种协议,如CAS 1.0、CAS 2.0、CAS 3.0以及SAML等,这些协议允许与不同类型的客户端和服务进行交互。 5. **可扩展性**:CAS服务器的设计允许开发者添加自定义认证模块,以适应不同的身份...

    django-cas:通过CAS服务器进行身份验证

    django_cas是Django的CAS 1.0和CAS 2.0身份验证后端。 它允许您在添加对CAS的支持的同时使用Django的内置身份验证机制和用户模型。 它还包括一个中间件,该中间件拦截对原始登录和注销页面的调用,并将其转发到...

    CAS 协议3.0

    在CAS2.0中添加了属性的传递,并在CAS3.0中给出了带有自定义属性的响应示例。 3. /proxyValidate:该接口用于验证代理票据的有效性,它也有自己的参数和响应格式。 4. /proxy:用于代理票据的获取。 5. /logout:...

    cas单点登陆demo包含cas服务器和2个客户端代码

    这个压缩包提供的是一个完整的CAS SSO演示项目,包括一个CAS服务器和两个客户端应用的代码。下面将详细介绍这个项目的关键知识点。 1. **CAS服务器**:CAS服务器是整个SSO系统的核心,它负责用户的身份验证。在这个...

    cas核心流程图

    - **协议支持**:CAS支持多种协议,如CAS 1.0、CAS 2.0、CAS 3.0以及SAML 1.1等,这些协议定义了服务与CAS服务器之间的通信方式。 - **扩展性**:CAS具有高度的可扩展性,可以通过插件或自定义实现来添加新的认证和...

    cas-server-release4.zip

    CAS支持多种协议版本,如CAS 1.0、CAS 2.0、CAS 3.0以及SAML等。 5. **可扩展性**:CAS服务器支持自定义认证和授权策略,可以集成各种身份验证源,如LDAP、Active Directory、数据库等,满足不同环境的需求。 6. *...

Global site tag (gtag.js) - Google Analytics