CAS协议学习


=Start=

缘由:

简单记录一下在学习CAS协议时的内容,方便有需要的时候参考。

正文:

参考解答:

CAS协议

CAS协议是一个简单而强大的基于票据的(ticket-based)协议。

它涉及一个或多个客户机(Clients)和一个服务器(Server)。客户端(Clients)嵌入在CASified应用程序(称为“CAS服务”)内,而CAS服务器(Server)是一个独立的组件:

  • CAS Server 负责进行用户认证和授予应用程序的访问权限
  • CAS Clients 用于保护CAS应用程序,并从CAS服务器检索授予用户的身份。

主要概念有:

  • TGT (Ticket Granting Ticket) 存储在TGC cookie中,表示用户的单点登录会话(SSO session)
  • ST (Service Ticket) 在url中作为GET参数传输,代表 CAS Server 为特定用户授予的CASified应用程序的访问权限

CAS浏览器单点登录的时序图

Web flow diagram
第一次访问 APP1
  1. 【用户】通过浏览器访问APP1服务,请求直接发送到APP1服务的后端,后端发现请求里没有包含认证信息,将请求302重定向至 CAS Server 地址。
  2. CAS Server 识别出用户没有没有登录(服务端没有对应的SSO session),返回 CAS 登陆页表单。
  3. 【用户】在 CAS 登陆页输入正确的账号密码并提交。
  4. CAS Server 若校验通过(AUTHENTICATION_SUCCESS),则会为该用户创建并保存认证信息即SSO session,同时在返回头中设置cookie(TGC),包含TGT(可以认为是SSO-session-id)(TICKET_GRANTING_TICKET_CREATED),还包含用于APP1服务认证的ST(service-ticket)(SERVICE_TICKET_CREATED)。
  5. 【浏览器】带着刚才从 CAS Server 返回的 ST-1 再去请求APP1服务的后端。
  6. 【APP1服务的后端】拿着刚传过来的 ST-1 去 CAS Server 验证 ST-1 的合法性和有效性,若认证成功(SERVICE_TICKET_VALIDATED),则 CAS Server 会返回表示成功的响应信息给APP1服务的后端。
  7. APP1服务的后端拿到表示校验成功的响应后,为对应账号添加Session,然后返回给浏览器一个(去掉了 ST-1 信息的)302重定向的响应,并在响应头中设置cookie(JSESSIONID)等信息。
  8. 【浏览器】带着刚才服务端给设置的cookie信息发起和第一次一样的请求。
  9. APP1的服务端提取请求中的cookie信息和之前创建的session信息进行校验。
  10. 校验通过后,返回正确的内容,浏览器对返回的内容进行渲染和展示。
第二次访问 APP1
  1. 【浏览器】带着之前已有的cookie信息向APP1服务发起请求。
  2. APP1的服务端提取请求中的cookie信息和之前创建的session信息进行校验。
  3. 校验通过后,返回正确的内容,浏览器对返回的内容进行渲染和展示。
第一次访问 APP2
  1. 【用户】通过浏览器访问 APP2 服务地址,请求直接发送到APP2服务的后端,后端发现请求里没有包含认证信息(ST-2),返回给浏览器一个302重定向至 CAS Server 的响应。
  2. 浏览器带着之前检验通过后给设置的包含 TGT 的cookie去访问 CAS Server 。
  3. CAS Server 校验请求中的 TGT 有效,因此不需要重新登录,为其创建了一个 ST-2(SERVICE_TICKET_CREATED) 并添加在了响应内容中。
  4. 【浏览器】带着刚才从 CAS Server 返回的 ST-2 再去请求APP2服务的后端。
  5. 【APP2服务的后端】拿着刚传过来的 ST-2 去 CAS Server 验证 ST-2 的合法性和有效性,若认证成功(SERVICE_TICKET_VALIDATED),则 CAS Server 会返回表示成功的响应信息给APP2服务的后端。
  6. APP2服务的后端拿到表示校验成功的响应后,为对应账号添加Session,然后返回给浏览器一个(去掉了 ST-2 信息的)302重定向的响应,并在响应头中设置cookie(MOD_AUTH_CAS_S)等信息。
  7. 【浏览器】带着刚才服务端给设置的cookie信息发起和第一次一样的请求。
  8. APP2的服务端提取请求中的cookie信息和之前创建的session信息进行校验。
  9. 校验通过后,返回正确的内容,浏览器对返回的内容进行渲染和展示。
参考链接:

CAS Protocol
https://apereo.github.io/cas/6.5.x/protocol/CAS-Protocol.html

How CAS Works
https://calnetweb.berkeley.edu/calnet-technologists/cas/how-cas-works

Single Sign On with CAS (Central Authentication Service)
https://dinika-15.medium.com/single-sign-on-with-cas-central-authentication-service-fd60bae64fa7

=END=


《“CAS协议学习”》 有 4 条评论

  1. Apereo CAS Audits
    https://apereo.github.io/cas/6.5.x/audits/Audits.html
    `
    CAS配置列表(CAS configuration catalog):

    cas.audit.engine.alternate-client-addr-header-name=
    cas.audit.engine.alternate-server-addr-header-name=
    cas.audit.engine.app-code=CAS
    cas.audit.engine.audit-format=DEFAULT/JSON
    cas.audit.engine.enabled=true
    cas.audit.engine.excluded-actions=
    cas.audit.engine.ignore-audit-failures=false
    cas.audit.engine.include-validation-assertion=false
    cas.audit.engine.number-of-days-in-history=30
    cas.audit.engine.supported-actions=
    cas.audit.engine.use-server-host-address=false

    审计日志的存储方式(Audit Log Storage):

    * File
    * Couchbase
    * CouchDb
    * JDBC
    * DynamoDb
    * MongoDb
    * Redis
    * REST

    审计事件(Audit Events):

    Event Action
    TICKET_GRANTING_TICKET CREATED, NOT_CREATED, DESTROYED
    SERVICE_TICKET CREATED, NOT_CREATED
    AUTHENTICATION SUCCESS, FAILED
    AUTHENTICATION_EVENT TRIGGERED

    `

  2. Cas服务端5.3.2之开启审计功能(MySQL8)
    https://blog.csdn.net/zhouzhiwengang/article/details/97892152
    `
    添加Maven/Gradle依赖
    cas-server-support-audit-jdbc

    表记录说明:
    访问登录页,登录事件都会记录到数据库,打开登录页,记录的AUD_USER是audit:unknown,AUD_ACTION是 AUTHENTICATION_EVENT_TRIGGERED
    登录成功会生成一条 AUD_ACTION=AUTHENTICATION_SUCCESS 的记录,失败会是 AUD_ACTION=AUTHENTICATION_FAILED
    如果登录成功,还会生成 AUD_ACTION=TICKET_GRANTING_TICKET_CREATED 的记录,
    注销会生成 AUD_ACTION=TICKET_GRANTING_TICKET_DESTROYED 的记录。
    `

  3. 单点登录cas常见问题(十三) – 几个重要概念怎么理解?
    https://blog.csdn.net/matthewei6/article/details/50769670
    `
    1、TGC:Ticket-granting cookie,存放用户身份认证凭证的cookie,在浏览器和CAS Server间通讯时使用,是CAS Server用来明确用户身份的凭证。TGT封装了TGC值以及此Cookie值对应的用户信息。
    2、TGT:ticket granting ticket,TGT对象的ID就是TGC的值,在服务器端,通过TGC查询TGT。
    3、ST:service ticket,CAS为用户签发的访问某一service的票据,ST是TGT签发的。
    4、PGT:proxy granting ticket,代理模式下的TGT
    5、PT:proxy ticket,代理模式下的ST
    6、service:在cas系统中,接入的各个子系统叫服务。因为对普通用户来说,每一个接入到cas认证中心的子系统都提供特定的服务比如商城、bbs等,大家都听过软件即服务,平台即服务,这样理解service就通顺了
    7、credentials,凭证,即待认证的用户的信息载体,如用户名+密码
    8、Principal,当事人,即认证之后返回的已认证的当事人的信息载体,默认只返回用户ID即用户名。
    9、Authentication表示一个完成的认证请求,当然,结果可能是凭证有效或无效,他有一个method可以获取。
    `

发表评论

您的电子邮箱地址不会被公开。