CAS 服务器是基于 Spring Framework 构建的 Java servlet，其主要职责是通过颁发和验证票证来对用户进行身份验证并授予对启用 CAS 的服务（通常称为 CAS 客户端）的访问权限。当服务器在成功登录后向用户发出票证授予票证（TGT）时，将创建 SSO 会话。使用 TGT 作为令牌，通过浏览器重定向，根据用户的请求向服务发出服务票据（ST）。随后通过反向信道通信在 CAS 服务器上验证 ST。
CAS 客户端
术语“CAS 客户端”在其通用使用中具有两个不同的含义。 CAS 客户端是任何启用 CAS 的应用程序，可以通过支持的协议与服务器通信。 CAS 客户端也是可以与各种软件平台和应用程序集成的软件包，以便通过某种认证协议（例如 CAS，SAML，OAuth）与 CAS 服务器通信。已经开发了支持许多软件平台和产品的 CAS 客户。
几乎所有部署注意事项和组件配置都涉及这三个子系统。 Web 层是与包括 CAS 客户端在内的所有外部系统进行通信的端点。 Web 层委托票务子系统生成 CAS 客户端访问的票证。 SSO 会话开始于成功验证时发出票证授予票证，因此票务子系统经常委托给验证子系统。
认证系统通常仅在 SSO 会话开始时处理请求，尽管存在可以调用它的其他情况（例如，强制认证）。
Spring 框架
CAS 使用 Spring Framework 的许多方面;最值得注意的是，Spring MVC 和 Spring Webflow。 Spring 为核心 CAS 代码库以及部署者提供了完整且可扩展的框架;通过挂钩 CAS 和 Spring API 扩展点，可以直接定制或扩展 CAS 行为。 Spring 的一般知识有助于理解某些框架组件之间的相互作用，但并不是严格要求的。但是，用于配置 CAS 和 Spring 组件的基于 XML 的配置是安装，定制和扩展的核心问题。通常使用 XML 的能力和特别是 Spring IOC 容器是 CAS 安装的先决条件。
CAS 使用 Maven 构建和创建可部署的软件包，以便安装到 Java servlet 容器中。强烈建议使用 Maven 进行 CAS 安装过程所需的配置管理。 CAS 基本上是一个复杂的软件产品，它嵌入并紧密集成到机构的软件环境中。因此，它倾向于要求定制远远超出交钥匙解决方案，并且集成要求往往会随着时间的推移而变化。像Maven WAR overlay这样的基于源的安装过程为复杂和动态的需求提供了直接而灵活的解决方案。虽然它确实需要高昂的前期学习成本，但从长远来看，它可以获得许多好处
互联网连接
任何基于 Maven 的项目的构建阶段通常都需要 Internet 连接，包括用于安装 CAS 的推荐 Maven WAR 覆盖。 Maven 通过搜索包含本地下载和安装的工件（大多数情况下为 jar 文件）的在线存储库来解析依赖关系。虽然可以通过替换 Maven 配置设置来覆盖此行为，但它被视为高级用法，不受支持。
克服 CAS 服务器上缺少 Internet 连接的常见解决方案是在具有 Internet 连接的专用构建主机上构建 CAS。随后将构建生成的 cas.war 文件复制到 CAS 服务器以进行部署。
安全指南
CAS 是一种安全软件，可为基于 Web 的应用程序提供基于 Web 的安全单点登录。单点登录在安全性和便利性方面提供了双赢：它减少了对单个受信任凭证代理的密码暴露，同时透明地提供对多个服务的访问而无需重复登录。 CAS 的使用通常会改善安全环境，但是应该考虑几种 CAS 配置，策略和部署问题以实现适当的安全性。
系统安全注意事项
安全传输（https）
与 CAS 服务器的所有通信必须通过安全信道（即 TLSv1）进行。此要求有两个主要理由：
身份验证过程需要传输安全凭据。
CAS 票证授予票证是不记名令牌。
由于任一数据的公开都会允许冒充攻击，因此保护 CAS 客户端和 CAS 服务器之间的通信通道至关重要。
实际上，这意味着所有 CAS URL 必须使用 HTTPS，但这也意味着必须使用 HTTPS 完成从 CAS 服务器到应用程序的所有连接：
当生成的服务票据被发送回“服务”URL 上的应用程序时。
当调用代理回调网址时。
与依赖系统的连接
CAS 通常需要连接到其他系统，例如 LDAP 目录，数据库和缓存服务。我们通常建议在可能的情况下对这些系统使用安全传输（SSL / TLS，IPSec），但可能存在补偿性控制，这使得安全传输成为必要。具有严格访问控制的专用网络和企业网络是常见的例外情况，但仍建议使用安全传输。客户端认证验证可以是 LDAP 提供足够安全性的另一个好方案。
如前所述，必须确保与其他系统的连接。但是，如果 CAS 服务器部署在多个节点上，则同样适用于 CAS 服务器本身。如果基于缓存的故障单注册表在单个 CAS 服务器上运行时没有任何安全问题，则在网络未受保护时使用多个节点时，同步可能会成为安全问题。
CAS 支持许多可用于实现各种安全策略的功能。通过 CAS 配置和 CAS 客户端集成提供以下功能。请注意，许多功能都是开箱即用的，而其他功能则需要显式设置。
强制认证
许多 CAS 客户端和支持的协议支持强制身份验证的概念，用户必须重新进行身份验证才能访问特定服务。 CAS 协议通过 renew 参数支持强制认证。强制身份验证为 SSO 会话的主体身份提供了额外的保证，因为用户必须在访问之前验证其凭据。强制认证适用于需要或强制要求更高安全性的服务。通常，强制身份验证是基于每个服务配置的，但是服务管理工具通过集中安全策略为实施强制身份验证提供了一些支持。强制认证可以与多因素认证特征组合以实现任意特定于服务的访问控制策略。
被动认证
某些 CAS 协议支持被动身份验证，其中在请求时匿名授予对受 CAS 保护的服务的访问权限。 CASv2 和 CASv3 协议通过网关功能支持此功能。被动认证补充了强制认证;强制身份验证需要身份验证才能访问服务，被动身份验证允许服务访问，尽管是匿名的，无需身份验证。
代理验证
代理身份验证或委派身份验证提供了 CAS 的强大，重要且可能具有安全性的功能。 CASv2 和 CASv3 协议支持代理身份验证，并由代表用户的服务请求的代理票证调解;因此，服务代理用户的认证。代理身份验证通常用于服务无法直接与用户交互的情况，也可用作将最终用户凭据重放到服务的替代方法。
然而，代理票据存在风险，因为接受代理票据的服务负责验证代理链（最终用户的认证已经被委托到达票证验证服务的服务列表）。通过简单地针对/ serviceValidate 验证端点验证票证，服务可以完全选择不接受代理票证（并避免验证代理链的责任），但是经验表明很容易对此进行混淆并配置为无意中使用/ proxyValidate 端点不仔细检查故障单验证响应中出现的任何代理链。因此，代理身份验证需要仔细配置以进行适当的安如果不需要代理身份验证，建议在 CAS 服务器上禁用代理身份验证组件。
高度可用的 CAS 部署是为了响应各种故障模式而提供弹性的部署，以便尽管出现故障，CAS 仍继续提供 SSO 服务。我们提供推荐的体系结构，为规划和执行符合机构性能和可用性要求的 CAS 部署提供了一个起点。它还提供了一个框架，用于理解由 HA 考虑因素强加的 CAS 软件组件要求。
通过确保有足够的冗余来实现 CAS 的高可用性（HA）配置，以便在面对组件故障时服务是稳健的，并且可以在没有服务停机的情况下完成日常维护。这可以通过多节点实现，在较小程度上可以通过具有高级虚拟机功能的单节点 CAS 实现。本文档将重点介绍实现 HA 所需的 CAS Server 组件。对 HA 配置的更加定量的分析取决于支持基础设施和服务，超出了本文档的范围。
CAS 服务器软件具有非常可靠的良好记录。但是，CAS 服务器只是软件和硬件的一小部分，认证必须遍历才能顺利运行。集群通常使用集群，不仅用于负载处理，还用于故障转移。即使没有发生故障，有时也需要重新启动服务器。例如，如果安装了操作系统级别的严重安全修复程序，则应立即重新启动服务器。在 CAS 服务器集群中，即使在最繁忙的时间，也可以通过滚动重启轻松完成。
传统上操作单个服务器会延迟重启，直到较不繁忙的时间，同时运行已知漏洞。然而，最近随着虚拟机技术的日益接受及其固有的冗余和容错性，单节点 CAS 已经能够实现类似的质量。
