如有疑问，请看视频：CAS单点登录（第7版）

1. 规划
   1. 架构

1. 1. 1. 系统组件

CAS 服务器和客户端构成了 CAS 系统体系结构的两个物理组件，它们通过各种协议进行通信。

1. 1. 1. 1. CAS 服务器

CAS 服务器是基于 Spring Framework 构建的 Java servlet，其主要职责是通过颁发和验证票证来验证用户并授予对支持 CAS 的服务（通常称为 CAS 客户端）的访问权限。当服务器在成功登录后向用户颁发票证授予票证 （TGT） 时，将创建 SSO 会话。服务票证 （ST） 是应用户请求，通过使用 TGT 作为令牌的浏览器重定向向服务颁发的。随后，ST 通过反向通道通信在 CAS 服务器上进行验证。这些交互在 CAS 协议文档中有非常详细的描述。

1. 1. 1. 1. CAS客户端

术语“CAS 客户端”在其常见用法中有两种不同的含义。CAS 客户端是任何启用了 CAS 的应用程序，它们可以通过支持的协议与服务器通信。CAS 客户端也是一个软件包，可以与各种软件平台和应用程序集成，以便通过某种身份验证协议（例如 CAS、SAML、OAuth）与 CAS 服务器进行通信。已经开发了支持许多软件平台和产品的 CAS 客户端。

平台：

1. Apache httpd 服务器（mod_auth_cas 模块）
2. Java（Java CAS 客户端）
3. .NET（.NET CAS 客户端）
4. PHP （phpCAS）
5. Perl （PerlCAS）
6. Python （pycas）
7. Ruby （rubycas-client）

应用：

1. Canvas
2. Atlassian
3. Drupal
4. Liferay
5. uPortal
6. …

当术语“CAS 客户端”出现在本手册中而不进行进一步限定时，它指的是集成组件，例如 Java CAS 客户端，而不是依赖于 CAS 服务器（客户端）的应用程序。

1. 1. 1. 支持的协议

客户端通过多种受支持的协议中的任何一种与服务器通信。 所有支持的协议在概念上都相似，但有些协议具有使其适用于特定应用程序或用例的功能或特征。例如，CAS 协议支持委托（代理）身份验证，SAML 协议支持属性发布和单点注销。

支持的协议：

1. CAS（版本 1、2 和 3）
2. SAML1
3. SAML2
4. OpenID 连接
5. OAuth 2.0 版本
6. WS 联合
   1. 1. 软件组件

根据三个分层子系统来描述 CAS 服务器会很有帮助：

1. Web （Spring MVC/Spring Webflow）
2. Ticketing票务
3. Authentication认证

几乎所有的部署注意事项和组件配置都涉及这三个子系统。Web 层是与所有外部系统（包括 CAS 客户端）通信的端点。Web 层委托给票证子系统以生成用于 CAS 客户端访问的票证。SSO 会话从身份验证成功时颁发票证授予票证开始，因此票证子系统经常委托给身份验证子系统。

身份验证系统通常仅在 SSO 会话开始时处理请求，尽管在其他情况下可以调用它（例如强制身份验证）。

1. 1. 1. 1. Spring Framework

CAS 使用 Spring 框架的许多方面;最值得注意的是 Spring MVC 和Spring Webflow。Spring 为核心 CAS 代码库以及部署程序提供了一个完整且可扩展的框架;通过挂接 CAS 和 Spring API 扩展点来自定义或扩展 CAS 行为非常简单。Spring 的一般知识有助于理解框架组件之间的相互作用，但并非严格要求。

1. 1. 1. 1. Spring Boot

并自动配置正在运行的应用程序上下文，无需太多人工干预。

1. 1. 入门

首先，我们要感谢您使用 CAS。

本文档提供了有关如何开始 CAS 服务器部署的高级指南。本指南的唯一重点是描述 CAS 部署程序必须遵循和采用的流程，以便获得成功且可持续的架构和部署。

1. 1. 1. 准备工作

首先从本文档开始非常重要。这将帮助您了解 CAS 项目的运行和操作方式。您将学习如何参与项目、如何寻求帮助、如何管理和发布更改、项目对您的期望以及您对 CAS 本身的期望。

1. 1. 1. 寻求帮助

CAS 部署通常被视为任务关键型部署。它的部署成功、健康状况和一般维护对于组织的日常工作和业务至关重要。此外，作为在访问管理领域运行的身份提供商，它在部署的整体安全架构中发挥着重要而敏感的作用。因此，您可能需要专家和专家的额外专家帮助，他们了解软件的全面和外貌，并可以帮助您解决问题、部署最佳实践和实用升级指南。免费支持仅在一定程度上有效，通常最适合个人使用和/或业余爱好者。

为获得最佳效果，请寻求帮助。

1. 1. 1. 收集用例

在部署之前，记录、编目和分析所需的使用案例和要求非常重要。一旦您有一些想法，请与 CAS 社区讨论和分享这些想法，以了解可能已经解决了您今天面临的相同问题的常见趋势、做法和模式。

 KISS

通常，请避免设计和/或采用严重改变 CAS 内部组件、给配置的管理和维护带来沉重负担或重新发明 CAS 软件及其支持的协议的用例和工作流程。所有选项都增加了维护成本和麻烦。

1. 1. 1. 研究架构

了解 CAS 是什么以及可以做什么。这将帮助您打下基础，以实现 CAS 可能已经可以满足您的哪些使用案例和要求。查看 CAS 体系结构的基础知识，了解哪些选项和选项可用于部署和应用程序集成。

同样，研究 CAS 支持的协议和规范列表也同样重要。

1. 1. 1. 评论博客

Apereo 博客上不时会出现博客文章，当您考虑需求和评估功能时，这些文章可能会变得有用。通常建议您关注博客并尽可能多地关注项目新闻和公告，并且在整个 CAS 部署过程中不要回避撰写和贡献自己的博客文章、经验和更新。

1. 1. 1. 准备环境

研究部署环境的安装要求。

1. 1. 1. 部署CAS

建议使用 WAR Overlay 方法在本地构建和部署 CAS。这种方法不需要采用者显式下载任何版本的 CAS，而是利用覆盖机制将 CAS 原始构件和本地自定义组合在一起，以进一步简化将来的升级和维护。

注意：请勿直接克隆或下载 CAS 代码库。只有当您希望为项目的发展做出贡献时，才需要这样做。

在做任何其他事情之前，尝试让功能基线正常工作是非常重要的。避免立即进行临时更改以自定义部署。请坚持使用 CAS 提供的 defaultsand 设置，并逐步进行更改。在进度中跟踪源代码管理和标记更改中的过程和应用的更改。

1. 1. 1. 自定义

这是用例映射到 CAS 功能的地方。浏览文档以查找最接近的匹配项并应用。同样，尽可能坚持 CAS 基线也很重要：

避免对软件内部进行临时更改。

避免对核心配置组件（如 Spring 和 Spring Webflow）进行手动更改。

如果遇到问题，请避免对部署进行一次性错误修复。

如前所述，所有这些策略都会导致令人头疼和成本。

相反，请尝试对以下建议进行预热：

错误修复和小的改进属于核心 CAS 软件。不是您的部署。尽一切努力报告问题，提供修复和补丁，并与 CAS 社区合作，一劳永逸地解决问题。

某些数量的内部 CAS 组件难以扩充和修改。在大多数情况下，这种方法是有意为之的，目的是引导您远离危险和不必要的复杂更改。如果您遇到某个需求，并且心中有一个功能或用例，其配置和实现需要修改软件的核心内部结构，请与 CAS 社区讨论，并尝试将增强功能直接构建到 CAS 软件中，而不是将其视为雪花。

总而言之，仅当部署配置真正完全符合您的需求时，才对部署配置进行更改。否则，请尝试泛化并回馈以降低维护成本。从长远来看，一再不遵守这一策略可能会导致灾难性的结果。

1. 1. 1. 故障排除

故障排除指南可能针对您可能遇到的问题提供了一些答案，它通常尝试描述对故障排除和诊断有用的策略。您也可以向 CAS 社区寻求帮助。

1. 1. 1. 测试

投资于测试自动化。好多。它可能很无聊和冗余，但它会为您带来安心，减少不眠之夜，并以更健康、更敏捷的态度对待升级。此外，不要测试得太晚。许多 CAS 部署项目都在进行，以至于当部署和/或升级及其测试完成时，CAS 软件本身已经停止使用。尽量不要使用已声明为无效以进行维护的版本进行生产。请记住，CAS 项目发布候选版本是希望获得早期反馈，从而使您能够尽早进行测试。

如果你等得太久，那你就等得太久了。所以，不要等太久。

1. 1. 参与其中
      1. 投稿人指南

首先，我们要感谢您使用 CAS 以及所有捕获错误、构建增强功能、确定性能改进和帮助编写文档的人所做的所有工作。每一份贡献都有意义，所以感谢您的参与。以下是我们要求您遵循的一些准则，以便我们能够成功处理您的贡献。

简而言之，本指南的目标是帮助您学习如何捕鱼。

摆脱你对犯错的所有恐惧，作为你对项目贡献的一部分。熟能生巧，我们都会竭尽所能为您提供帮助，以便您最终成为项目的独立贡献者。犯错是可以的，而且确实需要一些时间、精力和精力来改善提案和贡献的状态。所以不要气馁，坚持下去，如果你发现任何不清楚的地方，不要犹豫，提出问题。

本指南的首要主题从以下问题开始：

Apereo CAS 项目关于接受投稿的政策是什么？

一个人如何认真地、循序渐进地开始贡献？

1. 1. 1. 你说的贡献是什么意思？

在 Apereo CAS 项目中，贡献通常意味着通常以拉取请求或补丁的形式将错误修复、适度的功能增强、文档改进、测试用例等回馈给项目。所有这些物品和捐赠在改善项目状态和所有相关人员的软件方面发挥着重要作用。这些贡献是具体的、可操作的和可衡量的，并向更大的社区发出信号，表明您（贡献者）积极参与、参与并关心项目的整体健康状况和未来方向。当然，对于非技术人员来说，贡献并不总是等于编写某种代码。这只是众多可能选项之一。我们希望您将其视为一个好的起点，当所有其他方法都失败时，请考虑支持该项目。

1. 1. 1. 我该做什么？

一定数量的开源项目尝试宣传、标记和标记他们认为可能适合贡献的工作项、问题和任务。这通常不是 Apereo CAS 项目政策。政策比这简单得多。

它是这样的：

一切都是理想的贡献。

换句话说，

没有“我们与您”。

没有“有些人只能解决某些问题，有些人不能”。

没有“人员 X 做出了更改;所以 X 也必须修复它“（又名代码所有权）

没有“我只是一个用户;你们是开发者”。

当然，如果您是该项目的新手，并且刚刚开始了解 CAS 项目代码库的来龙去脉，那么肯定有一些领域您可能会找到更多的舒适感，慢慢地适应。欢迎您提出建议。在大多数情况下，你希望处理的工作项应该是你觉得有趣和愉快且具有一定程度的实用性的东西。

请记住，您正在部署开源软件，这意味着无论您是否意识到，您都已自动成为项目/社区成员和潜在的维护者。保持仅消费模式通常会导致结果不佳。

1. 1. 1. 我可以做什么？

无论形状、大小和颜色如何，所有贡献都受到张开双臂的热烈欢迎。您可能有兴趣帮助修复拼写错误、编写文档、编写测试用例、开发代码、消除错误等。一切都是受欢迎的。

更多的贡献等于更多的信心。

换句话说，如果您碰巧遇到一个令人烦恼的用例和/或您认为是改进和关注的完美候选者，我们绝对会鼓励您花费时间和 DNA 来提高您的 Apereo CAS 生活质量。无声的痛苦是没有意义的。

如果您发现目前无法为项目做出贡献，请不要担心。这里有资源，这里和这里可以提供培训和支持，帮助您开始取得成功。

1. 1. 1. 我应该先打开一个 issue 吗？

不。

如果您已经发现了增强功能或错误，强烈建议您简单地提交拉取请求来解决该问题。无需特别的仪式来创建单独的问题。拉取请求是问题，它将按此方式进行跟踪和标记。请记住，这是开放和协作社区中的开源软件。它不是“有些人报告问题，有些人解决问题”的软件。在大多数情况下，我们鼓励您不惜一切代价提交补丁来修复报告的问题并消除痛苦，而不是等待有人来修复它。按照规定，没有“我们与您”之争。

简单地说：

你就是你一直在等待的人。

请记住，对问题做一些事情并不一定等于你（单个贡献者）编写代码。这只是众多可能选项之一。也就是说，如果您只想报告和编目问题以让其他人从您的发现中受益，那么最好可以通过社区邮件列表、聊天室和 StackOverflow 等在适当的标签下共享用例和手头的问题，以便于发现。

1. 1. 1. 如果我不是开发人员怎么办？

如果您已经诊断出问题或找到了有吸引力的改进和功能的用例，我们强烈建议您直接走下去，让这一切成为现实并做出贡献。如果您发现自己无法这样做，您将需要寻找并购买可以教您操作方法或为您做的资源。与您的机构、公司、组织、主管、老板、导师、架构师、经理、总监、CIO、CTO、CSO 等交谈，让他们为工作采购合适的资源。

报告问题并希望/等待其他人神奇地出现并花费时间、金钱和精力为您提供解决方案，这绝不是一个可以接受的策略。停止等待隧道尽头的曙光，自己点亮它。

如果您坚持要被当作用户对待，那么您需要重新审视并重新调整期望，与可以为您提供所需治疗的人和资源保持一致。开发一个丰富的综合软件平台的所有工作几乎都是自愿完成的。因此，如果您的期望类似于商业支持协议，其中包含包括承诺、保证、SLA 和后续行动的条款，那么您只需要与提供此类功能的实体进行升级。

1. 1. 1. 我有个主意;如果......

那就太好了。不，那将是美妙的、极好的、奇妙的和超级伟大的。请考虑一下，除非它们以具体的形式被执行和实现，否则孤独的想法本身或多或少是毫无意义的。不乏想法;好或坏。缺乏准备好并足够认真地执行和交付这个想法的人。这在很大程度上是一个行动号召，它让你从一个智囊团毕业，成为一个实干家、贡献者、推动者和领导者。如果你认为某件事值得去做，你能做的最好的事情就是具体而严肃地证明，它实际上是值得去做的。对问题或请求执行某些操作并不一定等于您（单个贡献者）编写代码。这只是众多可能选项之一。我们希望您将其视为一个好的起点，当所有其他方法都失败时，请考虑寻求支持。

1. 1. 1. 我发现了一个问题。我应该...？

是的，您应该这样做。如果您发现一些您认为奇怪、错误或不稳定的行为，并找到了消除障碍或交付案例的替代解决方案，请考虑以补丁的形式报告和分享该改进，以便讨论并可能被接受。这没有坏处，因为您具体地与社区成员互动和合作并付诸行动;他们很可能已经找到了更好的解决方案，并且可能能够与您分享以实现更长的繁荣。不要害怕;可能发生的最坏情况是有人站出来帮助您提供更好的选择。

1. 1. 1. 我怎么知道谁在做什么？

遵循 WIP 模式，以 Draft 状态提交早期拉取请求。这是 GitHub 中推荐的策略：

拉取请求是开始功能对话的好方法，因此请尽快开始一个 - 甚至在完成代码之前。您的团队可以随着功能的发展而对其进行评论，而不是在最后提供所有反馈。

或者换一种说法：

您在开始工作时打开拉取请求，而不是在完成工作时打开拉取请求。

当然还有其他选择：询问。

1. 1. 1. 我应该多久取得一次进展？

如果您确实有待处理的拉取请求可用，并且也可能被标记为 WIP，则最欢迎您根据需要继续推送到底层分支。在 WIP 拉取请求上取得进展没有什么垃圾或烦人的事情。没有人会因为你取得进度和推送更改而生气（这就是电子邮件过滤器等的用途），所以永远不要担心你的进度通知的频率会惹恼其他贡献者和/或项目成员。根据需要随时继续处理用例，并确保在取得进展时不断征求反馈。

请注意，在一段时间内保持非活动状态的贡献和拉取请求将被标记为 Pending （待处理），并最终自动关闭。陈旧仅在一定程度上被允许，但不要担心。任何过时的已关闭拉取请求始终可以重新打开并恢复进度，而不会丢失数据。

1. 1. 1. 我可以将更改向后移植到维护分支吗？

是的，一点没错。如果更改符合维护分支的范围及其跟踪版本，并且假设该分支仍在处理中，则非常欢迎你根据需要在代码库的各个分支之间移动更改，以消除痛苦和改进。

请记住，应用于在维护模式下以 CAS 版本为目标的先前分支的更改也必须通过单独的拉取请求转发到 master 分支。

1. 1. 1. 如果更改太大怎么办？

首先查看发布策略。您心目中的更改应适合计划发布的范围。如果需要，请与其他社区成员讨论发布时间表和政策，以寻找替代的交付解决方案和策略。

1. 1. 1. 您知道何时会解决 X 问题吗？

是的，一点没错。我们确切地知道何时会解决缺陷和功能。时间线如下：

当您以拉取请求的形式提议、讨论、赞助和贡献更改和测试时，将解决所有工作项。

或者，在与项目和相关利益相关者进行适当讨论后，您为更改提供资金和赞助，并与某人或商业支持提供商签订合同，以代表您完成工作。

或者，您可以等到互联网上获得资金或资源的同情陌生人可能具有相同的动机和倾向，他们会代表您完成此过程。

正如您所观察到的，时间线非常精确和可预测。简而言之，当你到达它们时，事情就会完成。

1. 1. 1. 值得吗？

CAS 项目通常基于其自己的维护策略运行。在进行更改之前，您需要交叉检查您当前拥有的 CAS 部署，并确保它仍然存在，以及项目认为在多大程度上可行和维护。

1. 1. 1. 如何进入路线图？

只需交付更改并将其合并到代码库相关分支中即可。该项目没有预定义的路线图。工作项的完成取决于社区的可用性、兴趣、时间和金钱。路线图是您打算处理、构建并最终作为拉取请求交付给项目的项。

1. 1. 1. 是否有未来 CAS 版本的愿望清单？

我们欢迎并鼓励您在适当的论坛和聊天室上与 CAS 社区取得联系，与他人分享您的使用案例和想法，并就变体和可能性进行头脑风暴。健康和富有成效的讨论有助于为更好、更客观的解决方案扫清道路。也就是说，如果你专门在寻找一个想法存储库，在那里你会记录一个想法或功能请求，让其他人来审查并为你提供解决方案或增强功能，那么 CAS 项目不存在这个地方。如前所述，如果您希望看到 CAS 的增强功能，您可以自己学习、学习和完成工作，并在与更广泛的开发人员社区进行适当讨论后将其回馈给 CAS 项目，或者您可以为工作提供资金或与某人签订合同，以便他们可以代表您完成工作。没有其他可行的、可持续的选择。

1. 1. 1. 有没有计划...？

不。没有计划。

CAS 项目开发活动主要基于志愿者的时间和贡献。官方规定，没有合同、承诺、时间表、时间表或资金来规划变化。在没有时间承诺、坚实的资金或赞助的情况下，为未来的变化和路线图讨论做规划似乎是不必要的，只会让人感觉像是仪式性的、过早的忙碌工作，特别是因为缺乏工具和资源，这种计划的截止日期不可避免地而且几乎总是被推迟并继续吃尘埃。CAS 开源开发从来都不是在真空中完成的。一般来说，当贡献者提出、讨论和显示拉取请求时，或者当更改的资金和赞助可用时，工作项就完成了。如果您希望看到 CAS 中的更改或功能，非常欢迎您讨论并贡献或资助其他人的时间，让他们花时间为您做这件事是值得的。

CAS Galaxy 漫游指南

只有当你对问题做了一些事情时，问题才是一个问题。否则，根据定义，没有问题。

1. 1. 1. 更改多久发布一次？

您可以查看发布计划。请注意，为每个里程碑指定的日期在某种程度上是试探性的，可能会根据需要和严重性而推迟。

对于一般贡献，只要它们处于良好的状态，则 pull requests 形式的补丁通常会尽快合并。这意味着给定的拉取请求必须通过一系列自动检查，这些检查会检查样式、测试等，然后才能符合合并条件。如果您提议的拉取请求还没有绿色标记，请不要担心。持续推送到包含您的更改的分支，以自动更新拉取请求并再次使生活变得绿色。

如果您发现项目没有按照您认为合理的速度推进，只需 ping拉取请求并温和地提醒某人站出来与您一起审查问题。

1. 1. 1. 测试更改的速度有多快？

通常，SNAPSHOT 版本由自动 CI 过程发布。合并补丁后，您需要跟踪其构建状态，一旦它变为绿色，您应该准备好在构建脚本中 updatesnapshots。实际上，此过程可能需要 50 分钟或更短的时间。请参阅构建脚本的 README文件和项目文档，了解如何更新覆盖以利用此更改。

这实际上涉及分别使用 Apache Maven 和 Gradle 的 -U 或 --refresh-dependencies 命令运行构建。

1. 1. 1. 您本周可以发布版本吗？

不。CAS 项目通常遵循一个固定的发布时间表，并且时间表不能根据客户/客户/项目/用户/供应商的需求随机更改，因为发布一个版本通常需要相当多的管理、调度和协调。请记住，发布日期总是会发生变化，但前提是需要更多时间来修复问题或根据从社区用户和测试人员那里收到的反馈来测试场景。当然，这一切都基于尽力而为，并且取决于有多少资金和精力可用于解决或测试各种场景。如果您计划投入生产，但无法等待 CAS 发布计划，则可以从源构建项目，并将构件发布到您自己的构件存储库，以便自己控制发布计划。有关其他保证，请参阅项目许可证。

1. 1. 1. 我该如何准备接受投稿？

如果您的拉取请求、想法或变更集非常重要，跨越多个 CAS 模块，引入新的或更改 CAS 设计和架构的基本方面，或者提供与外部系统或产品的集成，这可能会给其他人带来沉重的维护负担，那么在冲刺到编码工作之前，您可以提前做一些事情来准备和启动该过程：

开始与项目开发人员讨论，看看项目开发人员社区是否可以接受和维护您的变更集。您实际上是在要求互联网上的陌生人承担该功能的维护和管理工作，可能在您对项目、想法、增强甚至您的雇主的兴趣消失很久之后。他们是否同意代表您管理和维护此增强功能？他们是否有时间和兴趣，他们是否认为这个想法对更大的社区有吸引力和有用？

与 CAS 用户社区展开讨论，查找申办者、其他用户和协作者，了解还有谁可能有兴趣参与和使用该功能。除了您的雇主或客户之外，是否有其他人认为此增强功能或更改有用？是否有其他人认真地与您合作构建、优化、测试并最终将此更改部署到生产环境中？是否有其他人可以为您和项目提供未来的贡献和后续 CAS 版本中的维护工作？

如果您访问某人的住所，打算在客厅中间安装一个现成的游泳池，您可能需要先给他们打电话。他们可能完全可以接受，但先确认一下是很实际的。

 停止编码

如果您没有从项目维护者和用户社区获得足够的支持和支持，请不要立即开始编码工作以提交拉取请求。如果你在没有事先通知或讨论的情况下突然出现一个大型变更集，你的拉取请求很可能会长时间保持陈旧和/或最终被关闭。

从 CAS 开发人员和用户社区获得足够的支持后，请首先查看发布策略，以确定预期增强的范围以及更改附带的目标 CAS 版本。如有疑问，请提出问题。

如果增强功能相当实质性或提供与外部系统或产品的集成，则最佳操作方案是：

将增强功能作为外部 CAS 模块在代码库之外公开构建为具有 CAS 兼容许可证的开源软件。

邀请其他人与您合作，以定义、优化、测试、构建变更集并将其部署到生产环境中。

给自己、您的团队和协作者时间来验证更改、展示承诺并建立支持。时间允许你展示超越文字和纸上意图的活动和社区兴趣，这样整个社区就可以看到你的扩展、变更集或想法是有用的、有需求的并且对其他人有吸引力。您可能需要一周、一个月、三年或更长时间。

根据您和其他人所展示的足够的活动、需求、支持和协作，您应该能够顺利地与项目维护者合作，以包含增强功能，可能通过一系列拉取请求和补丁。当然，事实证明，您可能是唯一对这个想法感兴趣的实体，并且您没有从社区获得任何支持或鼓励。这可能表明一个危险信号，因为您将是变更的单亲父母，完全由您自己承担维护负担。如果您确信变更集对您的需求绝对至关重要，我们建议您无论如何都要开始或继续进行公开开发。随着时间的推移，其他人可能会加紧采用、协作和改进功能。你永远不知道。随着时间的推移，它要么变得更好，要么火车工会把它带回机器世界。

1. 1. 1. 为什么我的提案尚未被接受和合并？

以拉取请求的形式提交给代码库的补丁通常会尽快被审查，并且大多数补丁通常会被接受。如果你发现你的贡献需要比平常更长的时间才能合并，则提议的变更集可能违反了以下一项或多项原则：

重要提示：该补丁旨在修复一个假定的问题，但除了轶事、描述性、手动证据之外，没有提供自动化、可重现、可验证的方式来重现和验证问题。

补丁无法通过自动化单元或集成测试。

该补丁不符合项目的样式准则。

该补丁未能为提议的更改提供足够的单元或集成测试。

此补丁未能为提议的更改提供解释或目标。

该补丁已经陈旧了很长一段时间，没有任何贡献者活动的迹象。

该补丁在没有达成共识、集体反馈或作为单元或集成测试的内部验证的情况下修改系统行为。

该补丁修改了大量文件，不止一个几乎可以及时查看。

该补丁提供的功能或行为被认为过于专业或自定义，并带有毫无根据的假设。

该补丁引入了太多与提案目标无关的更改（即格式设置）。

该补丁违反了代码库的一般设计原则，或者引入了难以维护的不一致/矛盾的概念。

如果您需要帮助，请根据需要随时询问并寻求澄清。拉取请求的共同目标不是评判或指责，而是协作和取得进展。保持积极、乐观，对评论和建设性反馈持健康态度。

在此过程中可能会出现意外错误或基础设施事故。非常欢迎您 ping 拉取请求并提供解释和/或评论。在大多数情况下（如果不是全部），补丁会被接受。

1. 1. 1. 功能构建

在执行任何其他操作之前，请确保您有一个功能性构建。

1. 1. 1. 我该怎么做？

要成功完成本练习，您需要：

Git

IntelliJ IDEA

Java （JDK）

1. 1. 1. Fork 仓库

您需要做的第一件事是在您的账户下复刻 CAS 存储库。CAS 存储库托管在 GitHub 上，可在此处获取。

1. 1. 1. 克隆存储库

克隆代码库的方法要快得多，但现在让我们保持简单：

1 2 3 4

git clone --recursive git@github.com:apereo/cas.gitcd cas git remote add github-username git@github.com:github-username/cas.git git checkout master

接下来，如果你只列出远程仓库，你应该会看到：

1 2 3 4

origin  git@github.com:apereo/cas.git (fetch) origin  git@github.com:apereo/cas.git (push) github-username  git@github.com:github-username/cas.git (fetch) github-username  git@github.com:github-username/cas.git (push)

1. 1. 1. 获取子模块

你可以使用 git submodule update --init --recursive 来获取链接到仓库的所有子模块。

1. 1. 1. 工作流

你想将你的更改隔离在单个主题分支中，并且永远不要向 master 分支提交任何内容。工作流或多或少如下：

创建主题分支。

进行更改和测试。

将更改提交到 branch。

返回 #2 直到你满意为止。

您可能希望确保代码库可以从源代码本地构建。按照本指南了解更多信息。

1. 1. 1. 创建分支

要为更改创建主题分支，请执行：

1 2	git status git checkout -b my-topic-branch-which-fixes-something

1. 1. 1. 提交更改

当您准备好在进行更改后提交更改时，请执行：

1	git add --all && git commit -am "This change fixes a problem"

请注意，--all 标志会将所有修改的文件添加到项目目录中。如果你想挑选，你可以通过 git add fileName 命令一次单独添加文件，或者最好只选择一个 GUI 客户端，比如 SourceTree 或 Git Extensions。

1. 1. 1. 推送更改

将更改从本地分支推送到 fork 的远程分支：

1	git push github-username my-topic-branch-which-fixes-something

1. 1. 1. 提交 Pull Request

接下来，根据您的 CAS 项目的分支创建拉取请求。在这种特殊情况下，目标分支是 master 分支，因为您的分支是从 master 分支创建的。

1. 1. 1. 目标分支

CAS 代码库将特定分支专用于软件的功能和主要版本（即 5.3.x、6.0.x 等）。这些分支将继续以维护模式存在，直到版本被宣布为 EOL，并构成后续补丁版本和维护周期的基础。在准备拉取请求时，请务必为补丁选择适当的目标分支，以确保您的更改可以按计划包含在即将到来的维护版本中。

再次提醒您，应用于在维护模式下针对 CAS 版本的先前分支的更改也必须通过单独的拉取请求转发到 master 分支。

1. 1. 安全指南

CAS 是一种安全软件，可为基于 Web 的应用程序提供基于 Web 的安全单点登录。单点登录在安全性和便利性方面提供了双赢：它减少了对单个可信 Credentialbroker 的密码暴露，同时透明地提供对多种服务的访问，而无需重复登录。使用 CAS 通常会改善安全环境，但为了实现适当的安全性，应考虑几个 CAS 配置、策略和部署问题。

 报告问题

安全团队要求您不要创建公开可见的问题或帖子来讨论您可能认为的安全漏洞。要正确报告问题并了解如何生成响应，请参阅本指南。

1. 1. 1. 系统安全注意事项

需要考虑的基础设施安全事项可能包括以下内容。

1. 1. 1. 1. 安全传输 （https）

与 CAS 服务器的所有通信都必须通过安全通道（即 TLSv1）进行。此要求有两个主要理由：

身份验证过程需要传输安全凭证。

CAS 票证授予票证是持有者令牌。

由于泄露任一数据都会导致冒充攻击，因此保护 CAS 客户端和 CAS 服务器之间的通信通道至关重要。

实际上，这意味着所有 CAS url 都必须使用 HTTPS，但这也意味着从 CAS 服务器到应用程序的所有连接都必须使用 HTTPS 完成：

当生成的服务工单被发送回 “service” URL 上的应用程序时

当代理回调 URL 被调用时。

CAS 配置目录中提供了以下设置和属性：

自选

笔记

下面列出的配置设置在 CAS 配置元数据中标记为 Optional（可选）。This标志表示在最终用户 CAS 配置中不需要立即存在该设置，因为分配了默认值，或者该功能的激活不受设置值有条件地控制。换句话说，仅当需要修改默认值或需要打开由设置控制的功能时，才应在配置中包含此字段。

Show  entries

搜索：

·  cas.http-client.allow-local-urls=false CAS 是否应接受本地 URL。例如 http(s)://localhost/logout。  org.apereo.cas.configuration.model.core.authentication.HttpClientProperties. 如何配置此属性？

·  cas.http-client.async-timeout=PT5S 指示异步操作的超时。 此设置支持java.time.Duration 语法 [？]。  org.apereo.cas.configuration.model.core.authentication.HttpClientProperties. 如何配置此属性？

·  cas.http-client.authority-validation-reg-ex-case-sensitive=true 使用 #authorityValidationRegex 指定的正则表达式应作为区分大小写 （true） 还是不区分大小写 （false） 处理。如果未设置 #authorityValidationRegex，则此值没有任何影响。  org.apereo.cas.configuration.model.core.authentication.HttpClientProperties. 如何配置此属性？

·  cas.http-client.authority-validation-regex= 如果指定，则正则表达式将用于验证 url 的权威性。 此设置支持正则表达式模式。[?].  org.apereo.cas.configuration.model.core.authentication.HttpClientProperties. 如何配置此属性？

·  cas.http-client.connection-timeout=PT5S 访问 URL 终端节点的所有操作的连接超时。 此设置支持java.time.Duration 语法 [？]。  org.apereo.cas.configuration.model.core.authentication.HttpClientProperties. 如何配置此属性？

显示 1 到 5 个条目，共 14 个条目

上一页123下一页

1. 1. 1. 1. 与依赖系统的连接

CAS 通常需要连接到其他系统，例如 LDAP 目录、数据库和缓存服务。我们通常建议尽可能使用安全传输 （SSL/TLS、IPSec） 到这些系统，但可能会有补偿控制，使安全传输变得不必要。专用网络和具有严格访问控制的公司网络是常见的例外，但仍然建议使用安全传输。客户端认证验证是 LDAP 带来足够安全性的另一种很好的解决方案。

如前所述，必须保护与其他系统的连接。但是，如果 CAS 服务器部署在多个节点上，则 CAS 服务器本身也是如此。如果基于缓存的票据注册表在单个 CAS 服务器上运行时没有任何安全问题，则在网络不受保护的情况下，使用多个节点时，同步可能会成为安全问题。

1. 1. 1. 部署驱动的安全功能

CAS 支持许多可用于实施各种安全策略的功能。以下功能通过 CAS 配置和 CAS 客户端集成提供。请注意，许多功能是开箱即用的，而其他功能则需要明确设置

1. 1. 1. 1. 强制身份验证

许多 CAS 客户端和支持的协议都支持强制身份验证的概念，即用户必须重新进行身份验证才能访问特定服务。CAS 协议支持通过 renew参数进行强制身份验证。强制身份验证为 SSO 会话的委托人的身份提供了额外的保证，因为用户必须在访问之前验证他或她的凭据。强制身份验证适用于需要或强制要求更高安全性的服务。通常，forcedauthentication 是按服务配置的，但服务管理工具为实现强制身份验证提供了一些支持，作为集中式安全策略的问题。强制身份验证可以与多因素身份验证功能相结合，以实施任意特定于服务的访问控制策略。

1. 1. 1. 1. 被动身份验证

某些 CAS 协议支持被动身份验证，在被动身份验证中，在请求时匿名授予对受 CAS 保护的服务的访问权限。CASv2 和 CASv3 协议通过网关功能支持此功能。被动身份验证是对强制身份验证的补充;强制身份验证需要身份验证才能访问服务，而 PassiveAuthentication 允许服务访问，尽管是匿名的，无需身份验证。

1. 1. 1. 1. 代理身份验证

代理身份验证或委托身份验证提供了 CAS 的一个强大、重要且可能提高安全性的功能。CASv2 和 CASv3 协议支持代理身份验证，并由服务代表用户请求的代理票证进行调解;因此，该服务代理用户的身份验证。代理身份验证通常用于服务无法直接与用户交互的情况，并作为将最终用户凭证重播到服务的一种替代方法。

但是，代理票证存在风险，因为接受代理票证的服务负责验证代理链（最终用户的身份验证通过其到达票证验证服务的服务列表）。服务可以通过针对 /serviceValidatevalidation 端点验证票证来选择完全不接受代理票证（并避免验证代理链的责任），但经验表明，很容易对此感到困惑，并配置为无意中使用 /proxyValidate 端点，但不仔细检查票证验证响应中出现的任何代理链。因此，代理身份验证需要仔细配置以进行适当的安全控制;如果不需要代理验证，建议在 CAS 服务器上禁用代理验证组件。

从历史上看，任何服务都可以获取代理授予票证，并从中获取代理票证以访问任何其他服务。换句话说，安全模型是去中心化的，而不是集中的。服务管理工具通过公开可以基于每个服务启用或禁用的代理身份验证标志，提供了对代理身份验证的一些集中控制。默认情况下，不会向已注册的服务授予代理身份验证功能。

1. 1. 1. 1. 凭证缓存和重放

ClearPass 扩展提供了一种机制，用于捕获主身份验证凭据，缓存 （加密） 并根据需要重放以访问旧版服务。虽然建议使用代理身份验证代替密码重播，但可能需要将旧式服务与 CAS 集成。有关详细信息，请参阅ClearPass 文档。

1. 1. 1. 1. 服务管理

服务管理工具提供了许多特定于服务的配置控制，这些控制会影响 securitypolicy，并为集中式安全策略提供一些支持。（请注意，CAS 历来支持分散式安全策略模型。服务管理控制的一些亮点：

授权服务

强制身份验证

属性发布

代理身份验证控制

主题控制

服务授权控制

多因素服务访问策略

服务管理工具由一个服务注册中心组成，其中包含一个或多个已注册的服务，每个服务都指定了上述管理控制。服务注册表可以通过静态配置文件和/或 Web 用户界面进行控制。有关更多信息，请参阅 Service Management 部分。

 授权服务

作为安全最佳实践，强烈建议将服务管理工具限制为仅包含有权使用 CAS 的已知应用程序列表。让管理界面对所有应用程序保持开放状态可能会为安全攻击创造机会。

1. 1. 1. 1. SSO Cookie 加密

票证授予 Cookie 是 CAS 在建立单点登录会话时设置的 HTTP Cookie。默认情况下，cookie 值通过 CAS 属性中定义的设置进行加密和签名。虽然为初始部署提供了示例数据，但必须根据您的特定环境重新生成这些密钥。有关更多信息，请参阅本指南。

1. 1. 1. 1. 密码管理安全链接

帐户密码重置请求通过发送到用户注册电子邮件地址的安全链接进行处理。该链接仅在定义的时间窗口内可用，并且请求已由 CAS 正确签名和加密。虽然为初始部署提供了示例数据，但必须根据您的特定环境重新生成这些密钥。

有关更多信息，请参阅本指南。

1. 1. 1. 1. 协议票证加密

由 CAS 颁发并与其他应用程序（如服务票证）共享的协议票证可以选择完成签名/加密过程。尽管 CAS 服务器将始终交叉检查票证的有效性和过期策略，但这可能会作为一项额外的检查强制执行，以确保票证在传输到其他应用程序的过程中不会被篡改并保持真实。虽然为初始部署提供了示例数据，但必须根据您的特定环境重新生成这些密钥。

 注意

根据所使用的加密方法和算法，对生成的票证进行加密和签名将增加生成的票证长度。并非所有 CAS 客户端都能够处理冗长的票证字符串，并且可能会让您感到不安。在启用此功能之前，请评估现有集成，并考虑您的部署是否确实需要此功能。

此 CAS 功能能够接受签名和加密加密密钥。在大多数情况下，如果未提供密钥，CAS 将自动生成密钥。如果您希望手动和事先创建签名密钥和加密密钥，则以下说明适用。

请注意，如果系统要求您为密钥创建一定大小的 JWK，您将使用以下命令集来生成令牌：

1 2	wget https://raw.githubusercontent.com/apereo/cas/master/etc/jwk-gen.jar java -jar jwk-gen.jar -t oct -s [size]

结果将类似于：

1 2 3 4 5

{   "kty": "oct",   "kid": "...",   "k": "..."}

需要将生成的 k 值分配给相关的 CAS 设置。请注意，通过上述算法生成的密钥由 CAS 使用高级加密标准 （AES 算法进行处理，该算法是美国国家标准与技术研究院制定的电子数据加密规范。

---

1. 1. 1. 1. 工单注册表加密

对于群集 CAS 部署，可能需要进行安全票证复制，以确保 CAS 生成的票证在传输过程中不会被篡改。CAS 通过允许对票证进行本机加密和签名来解决此问题。虽然为初始部署提供了示例数据，但必须根据您的特定环境重新生成这些密钥。有关更多信息，请参阅本指南。

1. 1. 1. 1. 票证过期策略

票证过期策略是实施安全策略的主要机制。票证过期策略允许控制 CAS SSO 会话行为的某些重要方面：

SSO 会话持续时间（滑动到期、绝对）

票证重复使用

请参阅 配置票证组件 部分，了解有关各种过期策略和配置说明的详细讨论。

1. 1. 1. 1. 单点注销

单点注销或单点注销 （SLO） 是一项功能，通过该功能，CAS 服务会收到 CASSSO 会话终止的通知，并期望服务终止 SSO 会话所有者的访问。虽然单点注销可以提高安全性，但它从根本上说是一种尽力而为的工具，实际上可能不会终止对 SSO 会话期间使用的所有服务的访问。以下补偿控制可用于改善与单一注销缺陷相关的风险：

要求对敏感服务进行强制身份验证

减少应用程序会话超时

缩短 SSO 会话持续时间

SLO 可以通过两种方式发生：从 CAS 服务器（反向通道注销）和/或从浏览器（前端通道注销）。对于反向通道注销，SLO 进程依赖于具有线程池的 SimpleHttpClient 类：必须定义其大小才能正确处理所有注销请求。其他尚未处理的注销请求在发送之前临时存储在队列中：其大小定义为线程池全局容量的 20%，并且可以调整。这两个大小都是 CAS 系统的关键设置，它们的值不应超过 CAS 服务器的实际容量。

1. 1. 1. 1. 登录限制

CAS 支持策略驱动型功能，以限制连续失败的身份验证尝试，以帮助防止暴力破解和拒绝服务攻击。在后端身份验证存储缺少等效功能的环境中，此功能非常有用。如果底层系统提供此支持，我们鼓励使用它而不是 CAS 功能;理由是，在底层系统中启用支持可在所有 DependentSystem（包括 CAS）中提供该功能。有关更多信息，请参阅登录限制配置部分。

1. 1. 1. 1. 凭证加密

要了解如何通过加密保护敏感 CAS 设置，请查看本指南。

1. 1. 1. 1. CAS 安全筛选器

CAS 项目提供了许多直截了当的安全过滤器，适用于易受某些基于请求参数的 bad-CAS-protocol-input 攻击的就地修补 JavaCAS 服务器和 Java CAS 客户端部署。过滤器配置为清理身份验证请求参数，如果请求不符合 CAS 协议，则拒绝该请求，例如，如果参数重复多次、包含多个值、包含不可接受的值等。

强烈建议评估所有 CAS 部署，并在必要时包括此配置，以防止在 CAS 容器和环境无法阻止恶意和配置错误请求的情况下进行协议攻击。

CORS

CAS 为启用 HTTP 访问控制 （CORS） 提供一流的支持。CORS 的一个应用是，当资源从与第一个资源本身服务的域不同的域请求资源时，它会发出跨域 HTTP 请求。这应该会对通过 XHR/Ajax 请求访问启用 CAS 的应用程序有所帮助。

CAS 配置目录中提供了以下设置和属性：

必填

自选

笔记

下面列出的配置设置在 CAS 配置元数据中标记为 Required。此标志表示可能需要该设置的存在才能激活或影响 CAS 功能的行为，并且通常应进行审查、可能拥有和调整。如果为该设置分配了默认值，则无需严格将该设置放在配置副本中，但仍应对其进行检查以确保它符合您的部署预期。

Show  entries

搜索：

·  cas.http-web-request.cors.enabled=false 是否应为 http 请求启用 CORS。  org.apereo.cas.configuration.model.core.web.security.HttpCorsRequestProperties. 如何配置此属性？

显示 1 到 1 的 1 个条目

上一页1下一页

安全响应标头

作为 CAS 安全过滤器的一部分，CAS 项目会自动提供必要的配置，以将 HTTP 安全报头插入到 Web 响应中，以防止 HSTS、XSS、X-FRAME 和其他攻击。默认情况下，这些设置目前处于打开状态。

CAS 配置目录中提供了以下设置和属性：

必填

自选

笔记

下面列出的配置设置在 CAS 配置元数据中标记为 Required。此标志表示可能需要该设置的存在才能激活或影响 CAS 功能的行为，并且通常应进行审查、可能拥有和调整。如果为该设置分配了默认值，则无需严格将该设置放在配置副本中，但仍应对其进行检查以确保它符合您的部署预期。

Show  entries

搜索：

·  cas.http-web-request.header.enabled=true 允许 CAS 通过 http 过滤器注入和强制实施 http 安全标头，此处概述了缓存、HSTS 等。  org.apereo.cas.configuration.model.core.web.security.HttpHeadersRequestProperties. 如何配置此属性？

显示 1 到 1 的 1 个条目

上一页1下一页

1. 1. 1. 1. Spring Webflow 会话

CAS 项目使用 Spring Webflow 来管理和编排身份验证过程。CAS 使用的 webflow 的会话状态由客户端管理，然后在身份验证过程的各种状态中传递和跟踪该会话。必须保护并加密此状态，以防止会话劫持。虽然 CAS 提供了开箱即用的默认加密设置，但强烈建议在生产部署之前评估所有 CAS 部署，并重新生成此配置以防止攻击。

1. 1. 1. 1. 长期认证

在 CAS 登录表单上选择（通常通过复选框）长期验证功能（通常通过复选框），以避免长时间重新验证。长期身份验证允许用户选择额外的便利，但代价是安全性降低。安全性降低的程度是用于建立 CAS SSO 会话的设备特性的函数。从单个用户拥有或操作的设备建立的长期 SSO 会话的安全性略低于标准 CAS SSO 会话。唯一真正令人担忧的是 CAS 票证授予票证的生命周期延长和风险增加。另一方面，从共享设备建立长期 CAS SSO 会话可能会大大降低安全性。先前 SSO 会话中的项目可能会影响其他用户建立的后续 SSO 会话，即使面对单点注销也是如此，这可能会增加模拟的可能性。虽然没有可行的缓解措施来提高共享设备上长期 SSO 会话的安全性，但教育用户了解固有风险可能会提高整体安全性。

请务必注意，强制身份验证取代了长期身份验证，因此，如果将服务配置为强制身份验证，则即使在长期会话的上下文中，服务访问也需要身份验证。

在安装过程中，必须通过配置和 UI 自定义显式启用长期身份验证支持。因此，部署者选择提供长期身份验证支持，并且当可用时，用户可以通过在 CAS 登录表单上选择来选择使用它。

1. 1. 1. 1. 重定向前警告

CAS 支持在已建立的 SSO 会话期间选择服务访问通知。默认情况下，CAS透明地请求服务访问所需的票证，并将其提供给目标服务进行验证，从而在验证成功后允许访问服务。在大多数情况下，这几乎是即时发生的，并且用户不知道访问启用 CAS 的服务所需的 CAS 身份验证过程。了解此过程可能有一些安全优势，并且 CAS 支持用户可在 CAS 登录屏幕上选择警告标志，以提供在访问服务之前显示的插页式通知页面。默认情况下，通知页面为用户提供了一个选项，用于继续进行 CAS 身份验证或通过离开目标服务来中止。

1. 1. 升级指南

通常，建议采用者尝试使其 CAS 部署与可用的最新 CAS 版本保持一致。特别是，应立即应用 PATCH 或 SECURITY 性质的版本，因为它们是相应父版本的直接替代版本。有关详细信息，请参阅 CAS 版本策略。

CAS 升级的一般目标可能是：

升级是否修复了关键的安全漏洞或烦人的问题？我的 CAS 部署是否受到该漏洞和/或 bug 的影响？

升级是否提供可能有助于实现本地用例的功能？

升级是否提供了在我的覆盖中本地传输的功能，以便通过删除这些本地更改，我可以直接从 CAS 实现它们的好处，并最终获得更小、更易于维护的覆盖？

本文档试图在非常高的层次上描述升级给定 CAS 部署所需的范围和工作量。我们没有描述审查和调整所需的所有步骤/更改（这是不可能的），而是描述了一种可以执行升级的策略。

1. 1. 1. 更改日志

在尝试升级之前，请查看 CAS 更改日志，以确定要升级到的版本中包含哪些更改/修复，以及这些更改/修复是否适用于您的环境和 CAS 部署。如果您使用的是较旧的 CAS 版本，并且遇到了疑似错误的情况，则通过查看更改日志，您很可能会找到一个替代覆盖的替代项，该替代项可以解决该问题。

1. 1. 1. 讨论问题

查看更改日志后，如果您没有看到修复/调整您心目中的行为的改进，请在相应的 CAS 邮件列表上讨论该问题。讨论的结果将是范围/工作量评估，以确定解决方案的可行性和将进行修复的目标版本。

1. 1. 1. 选择 CAS 版本

您应该选择哪个 CAS 版本进行升级，以及应该考虑多久升级一次？

这里没有明确的答案，但以下是一些一般准则：

选择最好仍处于有效维护状态的 CAS 版本。

…使用您的可用资源和技能组合交叉检查系统和平台要求。

确保您了解 CAS 部署在切换到安全补丁模式时会发生什么情况。

…并查看安全漏洞响应指南。

请考虑跟上 CAS 补丁版本（X.Y.1 到 X.Y.2），因为它们通常每月发布一次。

拥有自动化和工具，以便在 CAS 升级上运行集成、功能和性能测试。

最后，查看项目许可证以了解有关稳定性、保证和承诺的准则。

1. 1. 1. 范围审查

确定理想的 CAS 升级版本后，在尝试升级之前，请查看 CAS 版本策略。这将使您了解新版本可能会带来哪些变化，以及升级可能需要付出哪些努力。

1. 1. 1. 评估本地覆盖

作为最佳实践，建议您通过 overlay 方法部署 CAS。如果有，此处的任务是确定您的覆盖已触及和修改的文件数量。对应用更改的内容和原因进行编目，并使用 CAS 更改日志交叉检查这些更改。很有可能，由于该升级，您的覆盖中存在的许多本地更改默认通过 CAS 提供，这将使您在本地摆脱许多这些改进。

您的更改通常为：

身份验证方案和策略（即 LDAP、JDBC 等）

控制 CAS 属性文件中 CAS 行为的设置

用户界面更改可能包括 CSS 和 JavaScript

属性解析和发布策略

已注册并授权使用 CAS 的服务

1. 1. 1. 准备开发环境

嗯，没有。

确保您已准备好用于配置和测试的单独开发环境。无论升级有多小，您都希望确保在切换之前在您的环境中对其进行了充分测试。评估新升级的软件依赖关系和平台要求（即 Java 等），并确保在尝试之前已正确安装和配置所有内容。

1. 1. 1. 清理配置

我们建议您首先从针对要升级到的版本的单独干净 CAS 覆盖开始。这样做的好处是可以保证新的 CAS 部署无需任何本地更改即可正常运行。构建并部署干净的 CAS 覆盖一次，以确保您的构建/部署过程正常运行。

1. 1. 1. 应用更改

浏览在本地覆盖中找到的更改目录。将这些文件与其原始版本进行比较和比较。您可以通过以下方式找出两个版本之间的差异：

如果您已构建过一次干净的 CAS 覆盖，则通常将自动获取原始版本，该版本位于 CAS 覆盖的 build/libs 目录中。在正确的路径中找到正确的文件并进行比较。

直接进入项目源仓库，找到合适的分支并比较文件。

不用说，您将需要：

一个不错的 diff 工具，比如 KDiff3、WinDiff、Beyond Compare 等。

一个不错的智能文本编辑器，例如 Sublime、Visual Studio Code 或成熟的 IDE，例如 IntelliJ IDEA。

较新版本的 CAS 覆盖层允许内置升级支持。要了解更多信息，请参阅本指南。

1. 1. 1. 文档更改

请记住记录本地覆盖中存在的其余更改，以便下次执行相同的过程时，您就有了一个线索，了解覆盖为何会变成现在的样子。

1. 1. 发行说明

RC1

RC2 系列

RC3 系列

RC4 系列

RC5 系列

RC6 系列

1. 1. 发布政策

CAS 在确定不同版本可以容纳的更改类型以及如何管理开发路线时遵循以下发布策略。CAS 采用者还可以针对每种版本类型期待以下内容。所有新的改进、修复、增强和更改都将根据发布策略进行权衡，以便在将来的版本中考虑。

 停止编码

尽量避免更改 CAS 软件的内部结构，以使将来的升级相对容易和轻松，这符合您的最大利益。您为实施和交付自定义用例而修改 CAS 的内部工作原理的次数越多，后续部署的麻烦就越大，因为您将面临配置和 API 更改。作为单亲父母很艰难，因此请避免独自承担赡养费。考虑与社区讨论和共享用例，并将更改贡献回去，以便您的部署在未来成为此类更改的使用者，而不是所有者。

1. 1. 1. 附表

项目发布时间表可在此处获得。维护政策也可用。

1. 1. 1. 安全

安全版本是对版本的关键最小更改，用于解决严重的 confirmed安全问题。也就是说，2.5.0.1 将是 2.5.0，只需进行最小更改即可修补漏洞。强烈建议所有采用者尽快升级到 SECURITY 版本。CAS 覆盖应无需更改即可构建，除非需要并在发行说明中突出显示。

安全版本中不会进行第三方库更新，除非有确凿的证据证明并要求升级软件包的必要性和努力。有关更多信息，请参阅本指南。

1. 1. 1. 补丁

一个保守的增量改进，包括错误修复、增强和新功能，并且与 sameMINOR 版本的先前 PATCH 版本绝对向后兼容。（即 2.4.15 是 2.4.14、2.4.13、2.4.12 等的替代品）。采用者可以预期主要 API、集成点、默认行为和常规配置基本相同。CAS 覆盖应该在构建时几乎不需要更改，除非需要并在发行说明和更改日志中突出显示。

补丁版本中不会进行第三方库更新，除非有确凿的证据证明并要求升级软件包的必要性和努力。有关更多信息，请参阅本指南。

1. 1. 1. 特征

一种渐进的增量改进，包括所有 PATCH 版本改进以及无法轻松适应的修复和增强功能：爆发向后兼容性或更改默认行为。（即从 3.4.x 过渡到 3.5.x 等）采用者可以预期一般性改进，这些改进需要对 API、集成点、默认行为和一般配置进行适度的更改。总体而言，MINORdevelopment 沿线的 CAS 服务器代码在不同版本之间看起来几乎相同，但有明显的适度演变变化。FEATURE 版本可能具有有助于协调开发的主题或重点。CAS 覆盖可能需要进行轻微到适度的更改，某些 API 可能已更改或已被弃用，默认行为和配置可能已更改。虽然实现 API 可能会更改，但 CAS API在 FEATURE 发行版之间将保持不变。

功能版本可以使用第三方库更新。但是，导致平台要求更改的库更新（即 Java、OS、Server Container）将被忽略。

1. 1. 1. 主要

一场革命性的变革，适应了全面的架构、方法和实施变化。（即从 3.5.x 过渡到 4.0.x 等）API 、默认行为和配置可能会发生重大变化。覆盖可能需要进行重大更改，并且可能需要完全返工。总体而言，CAS 服务器代码行可能看起来明显不同，集成点可能需要返工。

功能版本可以使用第三方库更新，包括可能导致平台要求升级（即 Java、操作系统、服务器容器）的更改。

1. 1. 发布时间表

https://github.com/apereo/cas/milestones

1. 1. 维护政策

本文档介绍了有关维护和管理已发布的 CAS 服务器版本的官方 CAS 策略。

具体而言，解决了以下问题：

CAS 版本应保留多长时间？

版本停用后，版本维护的适当范围是什么？

1. 1. 1. 附表

项目发布时间表可在此处获得。

 哪个版本更稳定？

CAS 版本是严格基于时间的版本;它们不是根据特定的基准、统计数据或功能完成情况或错误修复来安排的。为了对版本充满信心，您应该尽早开始尝试候选版本和/或后续快照。在稳定性方面，Apereo CAS 软件的所有版本都松散地基于薛定谔的 Cat 理论：在您打开盒子之前，没有任何保证。根据项目许可分发的软件按“原样”分发，不附带任何明示或暗示的保证或条件。有关特定语言，请参阅项目许可证文件。

1. 1. 1. 政策

CAS 采用者可能希望 CAS 版本从原始发布日期开始保留六个月。

在此期间的维护包括错误修复、安全补丁和版本的一般维护。根据发布计划，在此期间可能会发布补丁版本。

之后，该版本的维护严格限于安全补丁和另外六个月的漏洞修复（即 SPM 模式）。

版本的有效期可以延长到一年以上，由 CAS PMC 和整个机构群体在合理的情况下决定，前提是有足够的可用性、资源和资金。

“CAS 版本”是指任何 CAS 功能版本。（即 5.0.x、5.1.x 等）。

 呃。。。保养？

在这种情况下，维护严格意味着 CAS 代码库中的发布行和目标分支保持开放状态，以接受来自社区的补丁和贡献，并且在指定日期之前将有后续的二进制版本。

1. 1. 1. 时间线

在好日子里，CAS 项目会同时维护三个活动的分支/版本：领导项目开发工作的 main 分支，以及另外两个维护版本，本文档将介绍其维护周期。该政策和相关的维护周期时间表是根据当前项目成员和志愿者的可用性、时间和兴趣决定的，并以实际和现实的方式反映项目的资金、资源和承诺。如果情况发生变化，缩短或延长维护周期的政策也可能发生变化。

1. 1. 1. 什么是 EOL？

“生命周期结束”（“EOL”）是一个术语，用于描述给定的 CAS 版本行（即 6.1.x、6.2.x、7.0.0 等）已结束其实际生命周期（从项目的角度来看），并且项目在达到指定日期后停止接受、添加和/或发布任何类型的补丁。EOL 版本被视为已失效，无论问题影响或严重性如何，都不会受到任何关注，除非 CAS PMC 绝对合理，但前提是人们的可用性、项目兴趣、资源和足够的资金。

 文档

一段时间后，EOL 版本的文档维护和托管工作将不复存在。如果您确实需要访问 EOL 版本的文档，您始终可以在 CAS 代码库中找到原始页面，您可以在其中根据需要获取页面并渲染和托管它们，并自行承担维护和托管负担。

1. 1. 1. EOL 时间表

以下 CAS 版本将仅转换为安全补丁模式 （SPM），并将在指定日期停产。

释放	SPM 开始日期	完全 EOL
7.1.x	3月 31st， 2025	9月 30th， 2025
7.0.x	10月 31st， 2024	4月 30th， 2025

上表中不存在的所有先前版本都被视为已停产。

1. 1. 1. 安全补丁模式 （SPM）

一旦 CAS 版本过渡到 SPM 阶段，发布行和相关里程碑将公开关闭。补丁和贡献必须通过专为安全相关问题和报告而设计的渠道进行沟通和报告。此类报告将根据安全漏洞响应进行审查和分析。请确保您的报告包含足够的信息和详细信息，以便可以根据具体用例或在实践中真正影响 Apereo CAS 软件内部工作的用例来重现问题。

1. 1. 1. 长期支持 （LTS）

根据现有项目成员和志愿者的可用性、资金状况和兴趣，CAS 项目无法提供实用和可持续意义上的 LTS 版本，并且无法根据志愿者的努力和空闲时间长期遵守承诺的时间表。如果您和/或您的组织对 LTS 版本和长期承诺感兴趣，请联系项目讨论详细信息。