后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载本文聚焦 Apereo CAS 中的全局认证策略Global Authentication Policy它作用于 CAS 发行vend与验证validate票据的全过程决定一次认证事件在何种条件下被判定为满足安全策略。读完本文你将掌握cas.authn.policy.required-handler-authentication-policy-enabled内置策略的开启方式与底层实现原理能够通过定义globalAuthenticationPolicyBean 编写自己的全局认证策略并理解全局策略与服务级认证策略requiredAuthenticationHandlers之间的协作关系。什么是全局认证策略在 CAS 中认证策略Authentication Policy负责回答两个核心问题认证链authentication chain在发生某类失败后是否应该停止当一条认证链中存在多个认证处理器authentication handler时怎样才算一次成功的认证事件而全局认证策略是其中作用范围最广的一类如 Configuring-Authentication-Policy-Global.md 所述它是当 CAS 尝试发行票据vend tickets和验证票据validate tickets时被应用的全局认证策略。从源码上看这一策略被注入到CentralAuthenticationService的运行时上下文中。在 CasCoreConfiguration.java 中globalAuthenticationPolicy这个AuthenticationPolicyBean 被通过Qualifier(globalAuthenticationPolicy)注入centralAuthenticationServiceContext最终成为CentralAuthenticationServiceContext.authenticationPolicy。也就是说所有经CentralAuthenticationService处理的票据发行、服务票据Service Ticket授予等关键路径都会受该策略约束。与全局策略相对应的是服务级认证策略每个注册应用registered service也可以声明自己的认证策略二者可能互补也可能由服务级策略覆盖全局行为。详见 Configuring-Service-AuthN-Policy.md。策略的执行时机与调用链全局认证策略并不是在认证刚发生时立即判定而是在认证链执行完毕、票据将要发行/验证时进行复核。策略执行的核心入口位于 AbstractCentralAuthenticationService.java 的getAuthenticationSatisfiedByPolicy方法protected Nullable Authentication getAuthenticationSatisfiedByPolicy( Nullable final Authentication authentication, Nullable final Service service, Nullable final RegisteredService registeredService) throws AbstractTicketException { val policy configurationContext.getAuthenticationPolicy(); try { val policyContext Map.of(RegisteredService.class.getName(), Objects.requireNonNull(registeredService), Service.class.getName(), Objects.requireNonNull(service)); val executionResult policy.isSatisfiedBy(authentication, configurationContext.getApplicationContext(), policyContext); if (executionResult.isSuccess()) { return authentication; } } catch (final Throwable e) { LoggingUtils.error(LOGGER, e); } throw new UnsatisfiedAuthenticationPolicyException(policy); }这段代码揭示了三个要点策略上下文policyContext中包含当前RegisteredService与Service因此全局策略可以感知本次认证是针对哪个注册应用判定通过时返回原Authentication对象流程继续判定失败时抛出UnsatisfiedAuthenticationPolicyException阻止票据的发行或验证。该入口在 DefaultCentralAuthenticationService.java 中被多处调用授予服务票据L449、创建票据授予票据L218以及代理授予票据路径L131正好印证了文档中应用在 CAS 发行和验证票据时的描述。内置全局策略必需认证处理器策略开启方式CAS 内置的全局认证策略由以下属性控制cas.authn.policy.required-handler-authentication-policy-enabledtrue该属性定义在 AuthenticationPolicyProperties.java 中注释明确说明Global authentication policy that is applied when CAS attempts to vend and validate tickets. Checks to make sure a particular authentication handler has successfully executed and validated credentials. Required handlers are defined per registered service.即启用后CAS 会检查某个特定的认证处理器是否已成功执行并验证了凭证必需处理器是按注册服务per registered service定义的。从配置模型看该布尔开关挂在cas.authn.policy命名空间下由 AuthenticationProperties.java 中的AuthenticationPolicyProperties policy字段承载。底层实现原理当开关打开时CasCoreConfiguration.java 中的globalAuthenticationPolicyBean 会返回一个必需处理器判定的 lambda 实现Bean ConditionalOnMissingBean(name globalAuthenticationPolicy) RefreshScope(proxyMode ScopedProxyMode.DEFAULT) public AuthenticationPolicy globalAuthenticationPolicy(final CasConfigurationProperties casProperties) { if (casProperties.getAuthn().getPolicy().isRequiredHandlerAuthenticationPolicyEnabled()) { LOGGER.trace(Applying configuration for Required Handler Authentication Policy); return (authentication, handlers, applicationContext, context) - { val registeredService (RegisteredService) context.get(RegisteredService.class.getName()); val requiredHandlers registeredService.getAuthenticationPolicy().getRequiredAuthenticationHandlers(); LOGGER.debug(Required authentication handlers for this service [{}] are [{}], registeredService.getName(), requiredHandlers); val success requiredHandlers .stream() .allMatch(required - authentication.getSuccesses().containsKey(required)); return AuthenticationPolicyExecutionResult.success(success); }; } return AuthenticationPolicy.alwaysSatisfied(); }实现逻辑可拆解为从策略上下文取出当前RegisteredService读取该服务定义的requiredAuthenticationHandlers必需认证处理器集合逐一检查当前Authentication的successes集合中是否包含这些必需处理器——successes以认证处理器名称为键只有当全部必需处理器都出现在成功记录中时策略才被满足allMatch否则判定失败。当开关未启用时默认返回AuthenticationPolicy.alwaysSatisfied()即策略恒被满足不产生任何额外约束。必需处理器的来源注册服务定义既然必需处理器按注册服务定义就需要在服务注册表service registry中为对应应用声明。以 JSON 服务定义为例如下详见 Configuring-Service-AuthN-Policy.md{ class : org.apereo.cas.services.CasRegisteredService, serviceId : https://app.example.org/., name : ExampleApp, id : 1, authenticationPolicy : { class : org.apereo.cas.services.DefaultRegisteredServiceAuthenticationPolicy, requiredAuthenticationHandlers : [java.util.TreeSet, [ AuthNHandlerName ]], excludedAuthenticationHandlers : [java.util.TreeSet, [ ]] } }对应的实现类是 DefaultRegisteredServiceAuthenticationPolicy.java其中requiredAuthenticationHandlers一组必需的认证处理器标识/名称强制该服务只接受携带这些名称的认证策略未出现的处理器即使成功也不算数excludedAuthenticationHandlers一组被排除的认证处理器名称用于拉黑某些处理器。注意CAS 中每个认证方法都有默认名称且绝大多数方法可通过 CAS 设置项为其指定自定义名称因此requiredAuthenticationHandlers中填写的名称必须与运行时实际注册的处理器名称精确匹配。这一全局开关 服务级名单的组合非常适合 MFA多因素认证场景例如只允许密码 一次性口令OTP同时成功的高安全服务可以把两个处理器都列入requiredAuthenticationHandlers。测试用例佐证仓库中的集成测试 MultifactorAuthenticationTests.java 通过TestPropertySource同时启用了cas.authn.policy.required-handler-authentication-policy-enabledtrue与cas.authn.policy.any.try-alltrue并验证了如下行为使用单一密码凭证访问普通安全服务放行verifyAllowsAccessToNormalSecurityServiceWithPassword使用单一密码凭证访问高安全服务抛出UnsatisfiedAuthenticationPolicyExceptionverifyDeniesAccessToHighSecurityServiceWithPassword同时提供密码与 OTP 两种凭证访问高安全服务放行且断言authn.getSuccesses()同时包含AcceptUsersAuthenticationHandler与TestOneTimePasswordAuthenticationHandler两个处理器名称verifyAllowsAccessToHighSecurityServiceWithPasswordAndOTPViaRenew。这个测试恰好演示了全局必需处理器策略与多凭证认证multi-credential配合的完整链路策略要求所有必需处理器都成功而高安全服务需要两个处理器全部命中。自定义全局认证策略除了内置开关CAS 允许完全自定义全局认证策略——定义你自己的globalAuthenticationPolicyBean 即可覆盖默认行为。文档给出了最小示例AutoConfiguration public class MyConfiguration { Bean public AuthenticationPolicy globalAuthenticationPolicy() { return new MyAuthenticationPolicy(); } }为了让这个 Bean 真正生效需要理解AuthenticationPolicy接口的契约。该接口定义于 AuthenticationPolicy.java核心方法是FunctionalInterface public interface AuthenticationPolicy extends Ordered, Serializable, NamedObject { AuthenticationPolicyExecutionResult isSatisfiedBy(Nullable Authentication authentication, SetAuthenticationHandler authenticationHandlers, ConfigurableApplicationContext applicationContext, MapString, ? extends Serializable context) throws Throwable; default boolean shouldResumeOnFailure(final Throwable failure) { return failure ! null; } }自定义实现时需要关注isSatisfiedBy判定方法接收当前Authentication、被选中的认证处理器集合、应用上下文与策略上下文含RegisteredService与Service返回AuthenticationPolicyExecutionResult通过success()/failure()构造AuthenticationPolicyExecutionResult.java接口还提供了两个便捷工厂方法AuthenticationPolicy.alwaysSatisfied()恒满足与AuthenticationPolicy.neverSatisfied()恒不满足可作为自定义策略的起点或占位实现shouldResumeOnFailure决定认证链在失败时是否继续执行默认在failure ! null时恢复执行getOrder()默认返回Ordered.LOWEST_PRECEDENCE当存在多个策略时可据此控制判定顺序。如何注册自定义配置到 CAS 运行时AutoConfiguration类需要被 Spring Boot 的自动配置机制发现。按 Configuration-Management-Extensions.md 的指引在项目的src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件中登记你的配置类全限定名org.apereo.cas.custom.config.MyConfiguration如需让 Bean 支持配置热刷新可加RefreshScope(proxyMode ScopedProxyMode.DEFAULT)注解使外部属性变更触发上下文刷新时自动重载可通过Order(...)控制多个配置类的加载顺序。覆盖默认 Bean 的要点CAS 的默认globalAuthenticationPolicy使用了ConditionalOnMissingBean(name globalAuthenticationPolicy)见 CasCoreConfiguration.java。这意味着只要你的自定义 Bean 使用相同的名称globalAuthenticationPolicySpring 就会优先使用你的实现而跳过 CAS 内置定义。这正是用同名 Bean 覆盖内置策略的标准做法无需改动 CAS 源码。如果你的自定义策略需要感知当前注册服务可以从isSatisfiedBy的context参数中取出RegisteredService.class.getName()键对应的对象与内置实现CasCoreConfiguration.java的做法保持一致。全局策略与策略族的其他成员cas.authn.policy命名空间下还提供了多种全局可用的策略族成员AuthenticationPolicyProperties.java它们与必需处理器全局策略共同构成完整的策略矩阵配置属性语义cas.authn.policy.any.*任一认证处理器成功即满足try-all选项可避免短路、尝试全部处理器cas.authn.policy.req.*指定名称的处理器必须成功验证其凭证cas.authn.policy.all.*所有给定凭证都认证成功才满足典型用于多因素场景cas.authn.policy.all-handlers.*所有给定认证处理器都成功才满足cas.authn.policy.not-prevented.*认证事件未被PreventedException阻断即满足cas.authn.policy.unique-principal.*同一主体不允许重复登录需查询票据注册表cas.authn.policy.required-attributes.*认证结果必须包含指定属性才满足cas.authn.policy.groovy.*/cas.authn.policy.rest.*通过 Groovy 脚本或 REST 端点判定策略其中req对应的配置模型是 RequiredAuthenticationHandlerAuthenticationPolicyProperties.java包含handlerName必需处理器名称与tryAll凭证数量须等于成功与失败之和两个字段。各类策略的完整说明可参考 Configuring-Authentication-Policy.md而服务级策略如何映射到这些全局类型Allowed / Excluded / Any / All / Not Prevented / Groovy / REST见 Configuring-Service-AuthN-Policy.md。小结全局认证策略是 CAS 票据生命周期中一道总闸门它由globalAuthenticationPolicyBean 承载在票据发行与验证时通过AbstractCentralAuthenticationService.getAuthenticationSatisfiedByPolicy被调用失败时以UnsatisfiedAuthenticationPolicyException阻止流程。实际落地时有两条路径零代码开启cas.authn.policy.required-handler-authentication-policy-enabledtrue并在服务定义中通过requiredAuthenticationHandlers声明必需处理器即可实现指定认证方式必须全部成功的强制约束完全自定义实现AuthenticationPolicy接口以globalAuthenticationPolicy同名 Bean 注册到AutoConfiguration配置类中从而覆盖内置策略实现任意自定义的判定逻辑。结合仓库中的集成测试 MultifactorAuthenticationTests.java可以快速验证策略行为是否符合预期为多因素认证、高安全服务访问控制等场景提供可复现的参考模板。赞分享后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载相关推荐Apereo CAS 基于 Groovy 脚本的认证策略Authentication Policy配置指南Apereo CAS 基于 Groovy 脚本的认证策略Authentication Policy配置指南 导读 本文围绕 Apereo CAS 的 cas后端认证鉴权单点登录基于 Compose HTML 的四个 Web 示例全解游戏、落地页与 React/JS 互操作实战基于 Compose HTML 的四个 Web 示例全解游戏、落地页与 React/JS 互操作实战 本文围绕 Compose Multiplatform 仓后端认证鉴权单点登录Apereo CAS 认证组件配置指南认证管理器、认证处理器与认证策略体系Apereo CAS 认证组件配置指南认证管理器、认证处理器与认证策略体系 本文围绕 Apereo CAS 认证流程的骨架——认证管理器Authentica后端认证鉴权单点登录创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apereo CAS 全局认证策略（Global Authentication Policy）配置与自定义扩展指南
后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载本文聚焦 Apereo CAS 中的全局认证策略Global Authentication Policy它作用于 CAS 发行vend与验证validate票据的全过程决定一次认证事件在何种条件下被判定为满足安全策略。读完本文你将掌握cas.authn.policy.required-handler-authentication-policy-enabled内置策略的开启方式与底层实现原理能够通过定义globalAuthenticationPolicyBean 编写自己的全局认证策略并理解全局策略与服务级认证策略requiredAuthenticationHandlers之间的协作关系。什么是全局认证策略在 CAS 中认证策略Authentication Policy负责回答两个核心问题认证链authentication chain在发生某类失败后是否应该停止当一条认证链中存在多个认证处理器authentication handler时怎样才算一次成功的认证事件而全局认证策略是其中作用范围最广的一类如 Configuring-Authentication-Policy-Global.md 所述它是当 CAS 尝试发行票据vend tickets和验证票据validate tickets时被应用的全局认证策略。从源码上看这一策略被注入到CentralAuthenticationService的运行时上下文中。在 CasCoreConfiguration.java 中globalAuthenticationPolicy这个AuthenticationPolicyBean 被通过Qualifier(globalAuthenticationPolicy)注入centralAuthenticationServiceContext最终成为CentralAuthenticationServiceContext.authenticationPolicy。也就是说所有经CentralAuthenticationService处理的票据发行、服务票据Service Ticket授予等关键路径都会受该策略约束。与全局策略相对应的是服务级认证策略每个注册应用registered service也可以声明自己的认证策略二者可能互补也可能由服务级策略覆盖全局行为。详见 Configuring-Service-AuthN-Policy.md。策略的执行时机与调用链全局认证策略并不是在认证刚发生时立即判定而是在认证链执行完毕、票据将要发行/验证时进行复核。策略执行的核心入口位于 AbstractCentralAuthenticationService.java 的getAuthenticationSatisfiedByPolicy方法protected Nullable Authentication getAuthenticationSatisfiedByPolicy( Nullable final Authentication authentication, Nullable final Service service, Nullable final RegisteredService registeredService) throws AbstractTicketException { val policy configurationContext.getAuthenticationPolicy(); try { val policyContext Map.of(RegisteredService.class.getName(), Objects.requireNonNull(registeredService), Service.class.getName(), Objects.requireNonNull(service)); val executionResult policy.isSatisfiedBy(authentication, configurationContext.getApplicationContext(), policyContext); if (executionResult.isSuccess()) { return authentication; } } catch (final Throwable e) { LoggingUtils.error(LOGGER, e); } throw new UnsatisfiedAuthenticationPolicyException(policy); }这段代码揭示了三个要点策略上下文policyContext中包含当前RegisteredService与Service因此全局策略可以感知本次认证是针对哪个注册应用判定通过时返回原Authentication对象流程继续判定失败时抛出UnsatisfiedAuthenticationPolicyException阻止票据的发行或验证。该入口在 DefaultCentralAuthenticationService.java 中被多处调用授予服务票据L449、创建票据授予票据L218以及代理授予票据路径L131正好印证了文档中应用在 CAS 发行和验证票据时的描述。内置全局策略必需认证处理器策略开启方式CAS 内置的全局认证策略由以下属性控制cas.authn.policy.required-handler-authentication-policy-enabledtrue该属性定义在 AuthenticationPolicyProperties.java 中注释明确说明Global authentication policy that is applied when CAS attempts to vend and validate tickets. Checks to make sure a particular authentication handler has successfully executed and validated credentials. Required handlers are defined per registered service.即启用后CAS 会检查某个特定的认证处理器是否已成功执行并验证了凭证必需处理器是按注册服务per registered service定义的。从配置模型看该布尔开关挂在cas.authn.policy命名空间下由 AuthenticationProperties.java 中的AuthenticationPolicyProperties policy字段承载。底层实现原理当开关打开时CasCoreConfiguration.java 中的globalAuthenticationPolicyBean 会返回一个必需处理器判定的 lambda 实现Bean ConditionalOnMissingBean(name globalAuthenticationPolicy) RefreshScope(proxyMode ScopedProxyMode.DEFAULT) public AuthenticationPolicy globalAuthenticationPolicy(final CasConfigurationProperties casProperties) { if (casProperties.getAuthn().getPolicy().isRequiredHandlerAuthenticationPolicyEnabled()) { LOGGER.trace(Applying configuration for Required Handler Authentication Policy); return (authentication, handlers, applicationContext, context) - { val registeredService (RegisteredService) context.get(RegisteredService.class.getName()); val requiredHandlers registeredService.getAuthenticationPolicy().getRequiredAuthenticationHandlers(); LOGGER.debug(Required authentication handlers for this service [{}] are [{}], registeredService.getName(), requiredHandlers); val success requiredHandlers .stream() .allMatch(required - authentication.getSuccesses().containsKey(required)); return AuthenticationPolicyExecutionResult.success(success); }; } return AuthenticationPolicy.alwaysSatisfied(); }实现逻辑可拆解为从策略上下文取出当前RegisteredService读取该服务定义的requiredAuthenticationHandlers必需认证处理器集合逐一检查当前Authentication的successes集合中是否包含这些必需处理器——successes以认证处理器名称为键只有当全部必需处理器都出现在成功记录中时策略才被满足allMatch否则判定失败。当开关未启用时默认返回AuthenticationPolicy.alwaysSatisfied()即策略恒被满足不产生任何额外约束。必需处理器的来源注册服务定义既然必需处理器按注册服务定义就需要在服务注册表service registry中为对应应用声明。以 JSON 服务定义为例如下详见 Configuring-Service-AuthN-Policy.md{ class : org.apereo.cas.services.CasRegisteredService, serviceId : https://app.example.org/., name : ExampleApp, id : 1, authenticationPolicy : { class : org.apereo.cas.services.DefaultRegisteredServiceAuthenticationPolicy, requiredAuthenticationHandlers : [java.util.TreeSet, [ AuthNHandlerName ]], excludedAuthenticationHandlers : [java.util.TreeSet, [ ]] } }对应的实现类是 DefaultRegisteredServiceAuthenticationPolicy.java其中requiredAuthenticationHandlers一组必需的认证处理器标识/名称强制该服务只接受携带这些名称的认证策略未出现的处理器即使成功也不算数excludedAuthenticationHandlers一组被排除的认证处理器名称用于拉黑某些处理器。注意CAS 中每个认证方法都有默认名称且绝大多数方法可通过 CAS 设置项为其指定自定义名称因此requiredAuthenticationHandlers中填写的名称必须与运行时实际注册的处理器名称精确匹配。这一全局开关 服务级名单的组合非常适合 MFA多因素认证场景例如只允许密码 一次性口令OTP同时成功的高安全服务可以把两个处理器都列入requiredAuthenticationHandlers。测试用例佐证仓库中的集成测试 MultifactorAuthenticationTests.java 通过TestPropertySource同时启用了cas.authn.policy.required-handler-authentication-policy-enabledtrue与cas.authn.policy.any.try-alltrue并验证了如下行为使用单一密码凭证访问普通安全服务放行verifyAllowsAccessToNormalSecurityServiceWithPassword使用单一密码凭证访问高安全服务抛出UnsatisfiedAuthenticationPolicyExceptionverifyDeniesAccessToHighSecurityServiceWithPassword同时提供密码与 OTP 两种凭证访问高安全服务放行且断言authn.getSuccesses()同时包含AcceptUsersAuthenticationHandler与TestOneTimePasswordAuthenticationHandler两个处理器名称verifyAllowsAccessToHighSecurityServiceWithPasswordAndOTPViaRenew。这个测试恰好演示了全局必需处理器策略与多凭证认证multi-credential配合的完整链路策略要求所有必需处理器都成功而高安全服务需要两个处理器全部命中。自定义全局认证策略除了内置开关CAS 允许完全自定义全局认证策略——定义你自己的globalAuthenticationPolicyBean 即可覆盖默认行为。文档给出了最小示例AutoConfiguration public class MyConfiguration { Bean public AuthenticationPolicy globalAuthenticationPolicy() { return new MyAuthenticationPolicy(); } }为了让这个 Bean 真正生效需要理解AuthenticationPolicy接口的契约。该接口定义于 AuthenticationPolicy.java核心方法是FunctionalInterface public interface AuthenticationPolicy extends Ordered, Serializable, NamedObject { AuthenticationPolicyExecutionResult isSatisfiedBy(Nullable Authentication authentication, SetAuthenticationHandler authenticationHandlers, ConfigurableApplicationContext applicationContext, MapString, ? extends Serializable context) throws Throwable; default boolean shouldResumeOnFailure(final Throwable failure) { return failure ! null; } }自定义实现时需要关注isSatisfiedBy判定方法接收当前Authentication、被选中的认证处理器集合、应用上下文与策略上下文含RegisteredService与Service返回AuthenticationPolicyExecutionResult通过success()/failure()构造AuthenticationPolicyExecutionResult.java接口还提供了两个便捷工厂方法AuthenticationPolicy.alwaysSatisfied()恒满足与AuthenticationPolicy.neverSatisfied()恒不满足可作为自定义策略的起点或占位实现shouldResumeOnFailure决定认证链在失败时是否继续执行默认在failure ! null时恢复执行getOrder()默认返回Ordered.LOWEST_PRECEDENCE当存在多个策略时可据此控制判定顺序。如何注册自定义配置到 CAS 运行时AutoConfiguration类需要被 Spring Boot 的自动配置机制发现。按 Configuration-Management-Extensions.md 的指引在项目的src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件中登记你的配置类全限定名org.apereo.cas.custom.config.MyConfiguration如需让 Bean 支持配置热刷新可加RefreshScope(proxyMode ScopedProxyMode.DEFAULT)注解使外部属性变更触发上下文刷新时自动重载可通过Order(...)控制多个配置类的加载顺序。覆盖默认 Bean 的要点CAS 的默认globalAuthenticationPolicy使用了ConditionalOnMissingBean(name globalAuthenticationPolicy)见 CasCoreConfiguration.java。这意味着只要你的自定义 Bean 使用相同的名称globalAuthenticationPolicySpring 就会优先使用你的实现而跳过 CAS 内置定义。这正是用同名 Bean 覆盖内置策略的标准做法无需改动 CAS 源码。如果你的自定义策略需要感知当前注册服务可以从isSatisfiedBy的context参数中取出RegisteredService.class.getName()键对应的对象与内置实现CasCoreConfiguration.java的做法保持一致。全局策略与策略族的其他成员cas.authn.policy命名空间下还提供了多种全局可用的策略族成员AuthenticationPolicyProperties.java它们与必需处理器全局策略共同构成完整的策略矩阵配置属性语义cas.authn.policy.any.*任一认证处理器成功即满足try-all选项可避免短路、尝试全部处理器cas.authn.policy.req.*指定名称的处理器必须成功验证其凭证cas.authn.policy.all.*所有给定凭证都认证成功才满足典型用于多因素场景cas.authn.policy.all-handlers.*所有给定认证处理器都成功才满足cas.authn.policy.not-prevented.*认证事件未被PreventedException阻断即满足cas.authn.policy.unique-principal.*同一主体不允许重复登录需查询票据注册表cas.authn.policy.required-attributes.*认证结果必须包含指定属性才满足cas.authn.policy.groovy.*/cas.authn.policy.rest.*通过 Groovy 脚本或 REST 端点判定策略其中req对应的配置模型是 RequiredAuthenticationHandlerAuthenticationPolicyProperties.java包含handlerName必需处理器名称与tryAll凭证数量须等于成功与失败之和两个字段。各类策略的完整说明可参考 Configuring-Authentication-Policy.md而服务级策略如何映射到这些全局类型Allowed / Excluded / Any / All / Not Prevented / Groovy / REST见 Configuring-Service-AuthN-Policy.md。小结全局认证策略是 CAS 票据生命周期中一道总闸门它由globalAuthenticationPolicyBean 承载在票据发行与验证时通过AbstractCentralAuthenticationService.getAuthenticationSatisfiedByPolicy被调用失败时以UnsatisfiedAuthenticationPolicyException阻止流程。实际落地时有两条路径零代码开启cas.authn.policy.required-handler-authentication-policy-enabledtrue并在服务定义中通过requiredAuthenticationHandlers声明必需处理器即可实现指定认证方式必须全部成功的强制约束完全自定义实现AuthenticationPolicy接口以globalAuthenticationPolicy同名 Bean 注册到AutoConfiguration配置类中从而覆盖内置策略实现任意自定义的判定逻辑。结合仓库中的集成测试 MultifactorAuthenticationTests.java可以快速验证策略行为是否符合预期为多因素认证、高安全服务访问控制等场景提供可复现的参考模板。赞分享后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载相关推荐Apereo CAS 基于 Groovy 脚本的认证策略Authentication Policy配置指南Apereo CAS 基于 Groovy 脚本的认证策略Authentication Policy配置指南 导读 本文围绕 Apereo CAS 的 cas后端认证鉴权单点登录基于 Compose HTML 的四个 Web 示例全解游戏、落地页与 React/JS 互操作实战基于 Compose HTML 的四个 Web 示例全解游戏、落地页与 React/JS 互操作实战 本文围绕 Compose Multiplatform 仓后端认证鉴权单点登录Apereo CAS 认证组件配置指南认证管理器、认证处理器与认证策略体系Apereo CAS 认证组件配置指南认证管理器、认证处理器与认证策略体系 本文围绕 Apereo CAS 认证流程的骨架——认证管理器Authentica后端认证鉴权单点登录创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考