- 后端
- 认证鉴权
- 单点登录
【免费下载链接】cas
Apereo CAS - Identity & Single Sign On for all earthlings and beyond.
导读：本文深入讲解 Apereo CAS 默认的 Standalone（独立）配置模式——该模式让 CAS 无需连接任何外部 Spring Cloud 配置服务器，即可通过预定义的配置目录与配置文件完成全部属性的引导加载与热更新。读完本文，你将掌握 Standalone 配置目录的查找来源、(cas|application).(yml|properties)文件的命名规则、九级加载顺序与覆盖语义、Groovy 脚本配置、独立配置文件注入，以及生产部署中应当遵循的覆盖最佳实践，并结合仓库源码与测试用例理解其底层实现。
Standalone 模式：默认的嵌入式配置形态
Standalone 是 CAS 的默认配置模式。在该模式下，CAS不要求连接外部配置服务器（external configuration server），而是以内嵌的standalone mode独立运行。当此选项开启时，CAS 默认会在预定义的目录和文件中定位配置项，若这些位置均不存在，则回退到以/etc/cas/config作为配置目录。
与 Spring Cloud 外部配置服务器类似，该目录内的内容同样由(cas|application).(yml|properties)两类文件构成，用于控制 CAS 的运行时行为。同时需要注意：该配置目录可被 CAS 持续监控，一旦文件发生变化，CAS 会自动拾取变更并刷新应用上下文，无需重启容器或重新部署。这一机制的细节参见 Configuration-Management-Reload.md 中的 Reload Strategy 小节。
在默认情况下，所有 CAS 设置与配置均由 CAS Web 应用内嵌的application.properties文件控制。此外还存在一个内嵌的application.yml文件，如果你希望把配置直接打进主 CAS Web 应用、而不依赖外部化配置文件，可以用它覆盖全部默认值。如果你更偏好 properties 语法，那么application-standalone.properties同样可以覆盖application.properties。
外部配置文件中设置的优先级高于 CAS 内置默认值，即只要在外部配置目录中声明了同名属性，就能覆盖 CAS 出厂默认值。
配置目录的查找来源
CAS 默认按以下顺序尝试定位配置目录：
/etc/cas/config/opt/cas/config/var/cas/config
从源码看，这一顺序定义在 CasConfigurationPropertiesSourceLocator.java 的DEFAULT_CAS_CONFIG_DIRECTORIES常量中。而getStandaloneProfileConfigurationDirectory方法的实际逻辑是：先检查cas.standalone.configuration-directory属性指定的目录（若存在则直接采用），否则遍历默认目录列表并返回第一个真实存在的目录；如果没有任何目录存在，则返回null（此时仅加载内嵌配置）。
值得注意的两个边界行为：
noneprofile：当激活的 profile 全部为none（源码常量PROFILE_NONE，见 CasConfigurationPropertiesSourceLocator.java）时，CAS 会跳过默认配置目录的处理。这一行为由单元测试verifyNoneProfile验证（见 DefaultCasConfigurationPropertiesSourceLocatorTests.java）。- Docker secrets 支持：在 CasCoreBaseStandaloneConfiguration.java 中，CAS 还会注册一个
casDockerSecretsPropertySourceLocatorBean，用于从 Docker secrets 中引导配置，适合容器化部署场景。
配置文件命名规则
Standalone 配置目录中文件的命名遵循以下规则：
| 规则 | 说明 |
|---|---|
application.(properties\|yml\|yaml) | 只要存在就始终被加载 |
spring.application.name匹配的文件（如cas.properties） | spring.application.name默认值为大写CAS，但小写名称同样会被加载 |
spring.profiles.active匹配的文件（如ldap.properties） | 文件基名与激活 profile 名一致的配置会被加载 |
application-{profile}.(properties\|yml\|yaml) | 位于打包 Web 应用之外的 profile 专属文件，允许把配置拆分到多个文件，再通过激活 profile 列表引用，例如spring.profiles.active=standalone,testldap,stagingMfa |
从源码实现看，DefaultCasConfigurationPropertiesSourceLocator.java 中的getAllPossibleExternalConfigDirFilenames会依次构造以下基名的候选文件：application、spring.application.name的小写形式（如cas）、spring.application.name本身（如CAS）、spring.config.name指定的配置名（默认cas）。每个基名再分别与yml、yaml、properties三种扩展名组合，仅保留真实存在的文件。Profile 专属文件则按PROFILE_PATTERNS = ["application-%s.%s", "%s.%s"]两种模式构造（见同文件 L35 与 L113-L119）。
配置文件加载顺序（九级优先级）
假设spring.profiles.active=standalone,profile1,profile2，配置文件按以下顺序被加载。注意：越靠后加载的文件，其重复属性越能覆盖先前加载的文件。
| 加载顺序 | 配置文件 |
|---|---|
| 1 | application.(properties\|yml\|yaml) |
| 2 | （小写）spring.application.name.(properties\|yml\|yaml) |
| 3 | spring.application.name.(properties\|yml\|yaml) |
| 4 | application-standalone.(properties\|yml\|yaml) |
| 5 | standalone.(properties\|yml\|yaml) |
| 6 | application-profile1.(properties\|yml\|yaml) |
| 7 | profile1.(properties\|yml\|yaml) |
| 8 | application-profile2.(properties\|yml\|yaml) |
| 9 | profile2.(properties\|yml\|yaml) |
同名不同扩展名的处理次序
如果两个配置文件基名相同但扩展名不同，它们按properties、yml、yaml、groovy的顺序依次处理，最后被处理的那个文件在重复属性上胜出。在源码层面，扩展名候选列表定义于 DefaultCasConfigurationPropertiesSourceLocator.java 的EXTENSIONS常量，Groovy 文件则在 L135-L136 被追加到待处理文件列表末尾，从而获得"最后处理、最高优先级"的位置。
外部文件 vs classpath 文件
这些外部配置文件会覆盖位于 classpath 中的文件（例如 CAS overlay 中来自src/main/resources、最终打包进WEB-INF/classes的文件）。但内嵌于 classpath 的文件本身遵循Spring Boot 的加载规则，与 CAS Standalone 的规则存在差异，例如：<profile>.properties不会从 classpath 被加载，而application-<profile>.properties会被加载。
嵌入式配置与外部化配置的关系
CAS 官方文档反复强调的一个设计是：默认设置由内嵌application.properties控制，外部化配置用于覆盖默认值。仓库中 application.properties 就是这套内嵌默认配置的实例，其中可以看到诸如server.port=8443、server.servlet.context-path=/cas、cas.authn.accept.users=casuser::Mellon（静态凭据示例）等出厂默认值。
三种"覆盖入口"的层级关系如下：
- 内嵌
application.properties—— CAS 出厂默认值； - 内嵌
application.yml—— 希望把覆盖配置打进 WAR 内部时使用； application-standalone.properties—— 偏好 properties 语法时的内嵌覆盖文件；- 外部配置目录中的
application.*/cas.*/ profile 文件 —— 优先级最高，覆盖以上全部。
这一覆盖关系在测试 DefaultCasConfigurationPropertiesSourceLocatorTests.java 的verifyPriority中有直接印证：测试断言test.file=file（来自独立配置文件）、test.dir.app=dirAppYml（来自配置目录内的application.yml，测试资源见 directory/application.yml）、test.classpath=classpathAppYml（来自 classpath），证明外部文件优先于 classpath 内嵌文件。同时，verifySystemPropertiesOverrideCasConfiguration（L124-L131）验证了在 Standalone 引导阶段，系统属性/环境变量具有最高优先级——这也与源码 DefaultCasConfigurationPropertiesSourceLocator.java 中loadEnvironmentAndSystemProperties最先被加入 composite 的实现一致。
用 Groovy 脚本组织配置
CAS 还支持通过一个Groovy 文件来加载设置。该文件应位于上述匹配的配置目录中，命名为${cas-application-name}.groovy，例如cas.groovy。脚本能够把"按激活 profile 过滤的条件设置"与"适用于所有环境与 profile 的公共设置"合并到一个文件中，结构类似于：
// 可按单个 profile 过滤设置 profiles { standalone { cas.some.setting="value" } } // 以下设置适用于所有 profile 与环境 cas.common.setting="value"从源码看，Groovy 文件的路径为配置目录/应用名小写.groovy（DefaultCasConfigurationPropertiesSourceLocator.java），并被追加到文件处理列表的末尾，遵循"后处理者胜出"的覆盖语义。测试verifyGroovySlurper（DefaultCasConfigurationPropertiesSourceLocatorTests.java）验证了 Groovy 脚本中的设置（如cas.authn.accept.name=Static、cas.authn.accept.users=test::dev）确实会被加载。
注意：要启用 Apache Groovy 支持，请参考 Apache-Groovy-Scripting.md 完成相应模块与依赖的配置。
直接注入独立配置文件（云部署场景）
除了配置目录，CAS 允许使用一个专门的配置文件直接向 CAS 喂入一组属性，该文件既可以是文件系统路径，也可以是 classpath 资源。这在以下场景尤其有用：裸 CAS 服务器部署在云环境中，既没有配置服务器、也不存在外部配置目录，且部署者希望避免覆盖内嵌配置文件。
对应的配置参数由 StandaloneConfigurationProperties.java 定义：
| 配置项 | 类型 | 说明 |
|---|---|---|
cas.standalone.configuration-directory | File | 指向 CAS 配置所在目录的路径 |
cas.standalone.configuration-file | File | 指向包含 CAS 属性的单个文件的路径 |
cas.standalone.configuration-security.* | 嵌套 | 用于加解密配置值的密钥安全设置（见下文） |
从该类的 Javadoc 可以看出，这些字段在 CAS 中"仅用于让配置绑定逻辑识别设置"，实际取值会在运行时由环境直接读取，用于以 property source locator 的形式引导（bootstrap）CAS 配置。测试 DefaultCasConfigurationPropertiesSourceLocatorTests.java 正是通过System.setProperty("cas.standalone.configuration-directory", ...)与cas.standalone.configuration-file来注入这两个位置的。
配置值加解密（configuration-security）
cas.standalone.configuration-security.*由 StandaloneConfigurationSecurityProperties.java 定义，字段如下：
| 配置项 | 默认值 | 说明 |
|---|---|---|
alg | PBEWithMD5AndTripleDES | 解密设置时使用的算法 |
provider | 空（Java） | 使用的安全提供方；留空使用 Java 内置，BC表示 BouncyCastle |
iterations | Jasypt 默认迭代次数 | 解密设置时的总迭代次数 |
psw | 无 | 解密设置时使用的密钥/口令 |
initializationVector | false | 仅对PBEWithDigestAndAES类算法必需；开启会改变密文长度，并会使未使用 IV 加密的旧密码失效，默认关闭以兼容既有加密密码 |
配置变更自动监测与热重载
Standalone 模式下，CAS 可以对配置目录实施持续监控：一旦检测到文件变更，便自动刷新运行时应用上下文，使设置立即生效，彻底免去容器重启或重新部署。官方文档指出，CAS 绝大多数设置都具备重载资格，整个 CAS Web 应用（含全部模块与相关设置）几乎都可以被完整重载。
在 Standalone profile 生效且 Spring Cloud 配置服务器被禁用时，CAS 会自动开始监视该 profile 指定的配置文件并自动重载运行时上下文。此外，CAS 还提供以下管理端点用于手动触发刷新：
features、refresh、busenv、butshotdown、bus-refresh、busrefresh、serviceregistry
启用配置变更监测与自动重载需要引入依赖模块cas-server-core-events-configuration。
需要特别留意@RefreshScope的适用边界：只有启动时已存在于应用上下文层次结构中的 Bean 才可被刷新；在初始化/启动阶段被排除或按条件跳过创建的 Bean 无法在刷新请求中重建。换言之，刷新机制最适合"已有属性值从 A 变为 B"的场景；如果原本就不存在 A，或 A 被直接删除，重载策略可能无法生效。详细机制与端点清单见 Configuration-Management-Reload.md。
覆盖策略与部署建议（Handling Overrides）
CAS 官方对覆盖行为给出了明确警告与建议：
不要覆盖或修改内置的
application.properties或bootstrap.properties文件——这只会让你的部署变得复杂而脆弱。请尽量遵从 CAS 默认值，通过application.yml、application-standalone.properties或 Configuration-Management.md 中列出的配置策略来完成覆盖；同时尽量引导 CAS 将配置文件定位在自身外部。过早的"优化"只会带来混乱。
落地到实践，推荐的部署姿势是：
- 保持内置文件原样：不改动
application.properties/bootstrap.properties； - 外部化配置优先：在
/etc/cas/config（或其他自定义目录）中放置application.yml/cas.properties/ profile 文件，让外部配置覆盖默认值； - 必要时用 Groovy 或独立配置文件：需要按环境动态组合设置时使用
cas.groovy；云上裸部署时使用cas.standalone.configuration-file； - 善用激活 profile 拆分：通过
spring.profiles.active=standalone,testldap,stagingMfa将多套配置拆分为多个文件并控制其加载次序。
总结
Standalone 配置模式是 Apereo CAS 开箱即用的默认形态，其核心机制可概括为：在预设目录中按application.*→ 应用名 → profile 的既定顺序加载外部配置，后加载者覆盖先加载者，外部文件覆盖 classpath 内嵌文件，并支持目录监控实现热重载。理解这套加载顺序与覆盖语义，是进行 CAS 生产化配置、多环境部署与故障排查的基础。仓库中的 CasConfigurationPropertiesSourceLocator.java、DefaultCasConfigurationPropertiesSourceLocator.java 与 DefaultCasConfigurationPropertiesSourceLocatorTests.java 分别提供了源码级实现与可复现的加载顺序验证，可供深入研读。
- 后端
- 认证鉴权
- 单点登录
【免费下载链接】cas
Apereo CAS - Identity & Single Sign On for all earthlings and beyond.
相关推荐
Apereo CAS 配置服务器管理实战：Standalone 独立模式与 Spring Cloud 外部化双策略详解
Apereo CAS 配置服务器管理实战：Standalone 独立模式与 Spring Cloud 外部化双策略详解 本文聚焦 Apereo CAS 的配置管
后端认证鉴权单点登录Apereo CAS 认证策略配置详解：Any 策略（cas.authn.policy.any）
Apereo CAS 认证策略配置详解：Any 策略（cas.authn.policy.any） 在 Apereo CAS 中，"Any 认证策略"是最常见的一
后端认证鉴权单点登录Apereo CAS 配置管理完全指南：外部化配置、Spring Cloud Config Server 与热重载实战
Apereo CAS 配置管理完全指南：外部化配置、Spring Cloud Config Server 与热重载实战 CAS（Central Authenti
后端认证鉴权单点登录
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
