ASPIRE

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=

Docker

,
, , , , , ,

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

  2. 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
    …
    `

    回复

  3. 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 的记录。
    `

    回复

  4. 单点登录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可以获取。
    `

    回复

  5. 身份威胁态势分析
    https://www.anquanke.com/post/id/287521
    `
    一、身份成为新战场
    1、全球网络安全事件频发，威胁日益增多
    2、教育行业成2022年网络攻击重灾区
    3、**身份持续增长，身份风险带来无限挑战**

    4、84%的公司遭受身份攻击
    身份定义安全联盟的报告《2022-Trends-in-Securing-Digital-Identities》中，**与身份相关的攻击仍处在不断增加的趋势之中，且影响很大**。84%的人表示他们的组织在过去一年中经历了与身份相关的攻击。其中最多的种类为网络钓鱼攻击（59%）、特权管理不当（36%）、凭证盗取（33%）。

    5、凭据类攻击成为身份攻击的主要方式
    79%的公司在2020年和2021年遭受过与身份相关的攻击活动，这一数字在2022年上升到84%，**基于身份相关的攻击仍在增加。攻击者可能会利用网络钓鱼和使用泄露的证书。因为有了这些凭证，就可以利用已有的访问权限绕过限制，窃取数据，部署勒索软件或采取其他恶意行动**。

    《IBM Security X-Force Threat Intelligence Index 2023》报告显示，2022年影响最大的几类威胁行为，勒索行为以21%的占比暂居第一，数据窃取以19%的占比紧随其后，凭据收集和数据泄漏各占11%。

    《2022-data-breach-investigations-report-dbir》报告也显示，有4类攻击方式通常被用来入侵目标组织的资产：凭据，网络钓鱼，漏洞利用和僵尸网络。值得注意的是，基于凭据的攻击大约占50%，可见攻击者已经开始大量利用身份类攻击进行入侵。

    6、身份验证威胁处于LMS平台的安全威胁四大类之首
    Authentication threats（身份认证威胁）
    Availability threats（可用性威胁）
    Confidentiality threats（保密性威胁）
    Integrity threats（完整性威胁）

    根据国际科学与技术研究杂志的《Cyber Security Threat Analysis in Higher Education lnstitutions As A Result 0f Distance Learning》报告显示，身份认证威胁处于LMS平台的安全威胁四大类之首，其中明确表示身份验证威胁包括：使用不安全应用层协议（如 HTTP）进行不安全通信，允许传输未加密的流量，活动会话管理不当、未经授权的身份验证，凭据窃取、身份认证绕过等。

    7、CC服务的安全威胁五类中，身份认证威胁占据两大类

    shared Technologies Vulnerabilities（共享技术漏洞）
    Data Breach（敏感数据泄露）
    Account or Service Traffic Hijacking（账户或服务流量劫持）
    Denial of service（拒绝服务攻击）
    Malicious Insiders（恶意内部人员威胁）

    同时在《Cyber Security Threat Analysis in Hiher Education lnstitutions As A Result 0f Distance Learning》报告中的CC服务的安全威胁五大类别中，身份认证威胁占据两大类别，包括：
    * 账户或服务流量劫持：基于认证方式的攻击，例如通过劫持对密码的认证，攻击者可能会获得对用户账户的控制。
    * 恶意内部人员威胁：例如提供云服务的公司员工。他们可以获取传统上无法访问的敏感信息。

    从众多报告中的数据可见，基于身份的攻击逐渐被攻击者所重视。随着组织身份的增多，基于身份的攻击将会被应用得越来越多。

    二、身份认证攻击在真实环境中具有致命的威胁

    **基于身份的攻击（Identity-based attacks）指的是攻击者利用受害者身份凭据（如用户名、密码、证书等）进行攻击的方式。攻击者通过获取受害者的身份凭据，可以冒充受害者的身份，从而访问受害者的敏感信息、系统、网络等资源。**

    ## 微软BING源代码泄漏
    2022年3月下旬，据称微软泄露了 Bing、Cortana 和其他项目的源代码，大约 37GB 。微软证实受到 Lapsus$ 黑客组织的敲诈，该组织入侵了微软的某个员工的账户，“有限访问”了项目源代码存储库。

    ## Okta入侵事件
    攻击者在2022 年 1 月入侵了 Okta 第三方支持工程师的终端，并获得了 Okta 客户数据的访问权限。虽然潜在动机和整体损失情况尚不明确，但有两件事是可以确定的：身份入侵在这些事件中占据主导作用，而受害的主流科技公司并不是此类攻击唯一的预期目标。在 Okta 事件中，Lapsus$ 明确表示，其实际目标是 Okta 的客户。

    ## Uber攻击事件
    在2022年9月，一名黑客获得了Uber一位员工的Slack（企业聊天平台）账号，并获取了该公司在亚马逊和谷歌云计算平台的访问权限。位于旧金山的Uber公司目前已经证实了这次黑客攻击。

    ## 英伟达源代码泄漏
    2022年2月底，LAPSU$ 通过入侵英伟达内部服务器，导致超过 1TB 的数据泄露，并公开叫卖 RTX 30 系列显卡的挖矿限制破解算法，还要求NVIDIA 全面解除限制。Nvidia 于 2022年3月1日证实 其网络在上个月遭到破坏，攻击者获得了对员工登录数据和专有信息的访问权限。
    `

    回复

  6. 2022 TRENDS IN SECURING DIGITAL IDENTITIES
    https://www.idsalliance.org/white-paper/2022-trends-in-securing-digital-identities/
    https://assets.beyondtrust.com/assets/documents/2022-Trends-in-Securing-Digital-Identities.pdf

    IBM Security X-Force Threat Intelligence Index 2023
    https://www.ibm.com/reports/threat-intelligence
    https://www.ibm.com/downloads/cas/DB4GL8YM

    2022 Data Breach Investigations Report – Verizon
    https://www.verizon.com/business/resources/reports/dbir/
    https://www.verizon.com/business/en-gb/resources/2022-data-breach-investigations-report-dbir.pdf

    Cyber Security Threat Analysis In Higher Education Institutions As A Result Of Distance Learning
    https://ibn.idsi.md/vizualizare_articol/163773
    https://www.ijstr.org/final-print/mar2021/Cyber-Security-Threat-Analysis-In-Higher-Education-Institutions-As-A-Result-Of-Distance-Learning.pdf

    回复

  8. IAM单点登录之CAS协议分析
    https://www.freebuf.com/articles/network/365909.html
    https://zhuanlan.zhihu.com/p/627920220 #图片更清晰
    `
    一、CAS协议介绍
    集中式认证服务（Central Authentication Service，简称CAS）是一种针对web应用的单点登录协议，旨在为 Web 应用系统提供一种可靠的单点登录方法，**它允许一个用户访问多个应用程序，而只需向认证服务器提供一次凭证（如用户名和密码）。这样用户不仅不需在登陆web应用程序时重复认证，而且这些应用程序也无法获得密码等敏感信息**。“CAS”也指实现了该协议的软件包。

    CAS协议常见概念以及数据的基本介绍

    局部会话：浏览器-客户端之间的会话。

    全局会话：浏览器-认证服务器之间的会话。

    TGT(Ticket Granting Ticke)：建立全局会话的凭证，包含用户信息、票据生命周期等信息。

    TGC(Ticket Granting Cookie)：认证服务器认证成功后返回给浏览器的cookie，与存储在认证服务器上的TGT相对应，TGC和TGT类似于cookie和session的关系。

    ST(Service Ticket)：服务凭证，用于客户端验证用户身份。

    CAS协议介绍
    * 发展历史
    * CAS协议角色介绍
    * CAS协议常见概念以及数据的基本介绍
    * CAS协议认证流程
    * CAS 2.0代理模式认证流程

    CAS攻击面
    * CAS攻击面-XSS
    * CAS攻击面-统一注销错误
    * CAS攻击面-凭据泄漏
    * CAS攻击面-凭据爆破
    * CAS攻击面-其他问题

    CAS漏洞案例
    * 漏洞案例-XSS
    * 漏洞案例-反序列化
    `

    回复

  9. 统一Portal门户和IAM平台（单点登录、统一用户资源和权限管理）实践
    http://blog.zollty.com/b/archive/portal-and-iam-practice.html
    `
    О、背景和目的

    解决如下问题：
    打通所有系统的账户密码，只需要记住一个就行，而且登录一个系统后，打开其他系统不需要再登录。
    不需要记住多个系统的地址，甚至不需要在多个系统页面跳来跳去，通过一个门户网站，串通起常用功能。

    需求如下：
    具备单点登录功能，并且能为第三方应用提供主流的登录认证。
    具备用户的基本信息、角色、资源权限等集中管理和控制。
    提供统一的集中办公Portal门户网站，在里面无缝链接其他系统的页面和功能。

    关键术语：
    IAM（Identity and Access Management），即“身份识别与访问管理”，具有单点登录、强大的认证管理、基于策略的集中式授权和审计、动态授权、企业可管理性等功能。

    本文涉及关键词：
    IAM, SSO, CAS, OpenID, OICD, OAUTH, SAML, Keycloak, LDAP, RSA, RBAC, MFA等。

    如果这些关键词你都熟悉，就不用继续看了。
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注