后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载Apereo CAS 内置Inspektr审计框架对认证、票据发放、服务访问等粗粒度执行路径进行非侵入式记录。本文围绕 CAS 官方文档 Audits 展开讲清审计组件如何被自动配置、cas.audit.engine/cas.audit.slf4j等属性如何落到 CasCoreAuditAutoConfiguration 的具体 Bean 上、审计记录如何同时路由到文件、数据库、Redis、Mongo、DynamoDb、AWS Firehose、REST 等多个目的地以及如何通过auditLog/auditeventsActuator 端点在线查询审计事件帮助运维与开发者构建可落地、可溯源的 CAS 审计体系。1. Inspektr 框架CAS 审计的底层机制CAS 使用自己的Inspektr框架完成审计auditing与统计statistics。该框架早期是一个独立项目后来被完整合并进 CAS 代码库其核心组件如今位于 api/cas-server-core-api-audit 与 core/cas-server-core-audit 等模块中。Inspektr 的设计要点是非侵入式通过注解org.apereo.inspektr.audit.annotation.Audit/Audits见 Audit.java标记需要审计的 Spring 托管 Bean 方法通过Aspect风格的切面在方法执行前后织入审计逻辑捕获who谁、what对什么资源、action执行了什么动作、when何时以及客户端/服务端 IP、User-Agent、HTTP 头等信息。CAS 服务器会自动配置所有相关的 Inspektr 组件部署者无需手工编写切面注入到 Inspektr 类中的全部配置项都通过对应的 CAS 属性cas.audit.*开放给部署者。一个关键能力是多目的地路由multiple audit record destinations审计记录可以同时发往数据库、REST 端点以及任意多个基于 Logger 的目的地。从源码结构看这一能力由 FilterAndDelegateAuditTrailManager 实现——它在 CasCoreAuditAutoConfiguration 的CasCoreAuditManagementConfiguration内被装配为filterAndDelegateAuditTrailManagerBean把来自AuditTrailExecutionPlan中的所有AuditTrailManager收集成一个列表进行委托分发并按supportedActions/excludedActions正则表达式列表做动作级过滤val auditManager new FilterAndDelegateAuditTrailManager( auditTrailExecutionPlan.getAuditTrailManagers(), audit.getSupportedActions(), audit.getExcludedActions()); auditManager.setAuditFormat(auditFormat);也就是说你引入多个审计存储模块File/SLF4J、JPA、Redis、Mongo、DynamoDb、Firehose、REST、Groovy 等后同一条审计记录会自动扇出到每一个目的地互不干扰。审计总开关同样在此配置类中定义BeanCondition.on(cas.audit.engine.enabled)当该属性缺失时按true处理isTrue().evenIfMissing()整个自动配置还受ConditionalOnFeatureEnabled(feature FeatureCatalog.Audit)特性开关控制。2. 核心配置参数cas.audit.engine.*官方文档页通过casproperties片段列出了cas.audit.engine.前缀下的全部属性。结合 AuditEngineProperties 的字段注释与默认值逐项说明如下属性默认值说明cas.audit.engine.enabledtrue是否启用审计功能。cas.audit.engine.number-of-days-in-history30从存储中检索审计记录时回溯多少天的历史供auditLog端点等查询使用。cas.audit.engine.include-validation-assertionfalse票据验证事件的审计记录中是否包含被验证断言的信息如 principal id 与已发布的属性。开启后对应ticketValidationResourceResolver会使用TicketValidationResourceResolver而非普通票据资源解析器见 CasCoreAuditAutoConfiguration 中CasCoreAuditResourcesConfiguration。cas.audit.engine.alternate-server-addr-header-name空用于识别服务器地址的请求头名称。cas.audit.engine.alternate-client-addr-header-nameX-Forwarded-For用于识别客户端地址的请求头。当 CAS 位于负载均衡器之后时客户端地址往往是 LB 地址本身若 LB 正确传递该头常见为X-Forwarded-For审计日志即可记录真实客户端 IP。cas.audit.engine.use-server-host-addressfalse是否通过本地 DNS 查询来确定处理请求的 CAS 服务器地址默认为从请求中推导。cas.audit.engine.ignore-audit-failuresfalse审计发生灾难性失败时是仅记录日志true还是把异常抛出false。源码中映射为aspect.setFailOnAuditFailures(!audit.isIgnoreAuditFailures())。cas.audit.engine.http-request-headers[*]需要从请求中提取并由审计引擎/存储跟踪的 HTTP 头集合默认跟踪全部请求头。cas.audit.engine.supported-actions[*]支持可识别、处理并记录的审计动作白名单每项均可作为正则表达式与 CAS 内置动作匹配字段标注了RegularExpressionCapable。cas.audit.engine.excluded-actions[]需要排除、过滤并忽略的审计动作黑名单同样支持正则。cas.audit.engine.audit-formatDEFAULT审计日志的输出格式取值DEFAULT或JSON见 AuditFormatTypes 枚举。JSON 模式便于机器解析。cas.audit.engine.abbreviation-length100审计日志中字段/条目的最大缩写长度典型用于过长的服务 URL0 或负数禁用缩写。客户端地址/服务器地址的解析由ClientInfoResolver完成默认实现是 DefaultClientInfoResolver并以casAuditClientInfoResolverBean 注入到切面AuditTrailManagementAspect中。2.1 SLF4J 审计输出参数cas.audit.slf4j.*基于日志文件的审计File-based audits输出到日志配置中定义的cas_audit.log详见 File-based Audits。对应的属性模型是 AuditSlf4jLogProperties属性默认值说明cas.audit.slf4j.enabledtrue是否启用 SLF4J 审计管理器。开启后casAuditTrailExecutionPlanConfigurer向执行计划注册Slf4jLoggingAuditTrailManager。cas.audit.slf4j.use-single-linefalse是否将审计日志写成单行。默认每条动作/活动独占多行单行模式更紧凑便于采集。cas.audit.slf4j.singleline-separator|单行模式下分隔审计字段的字符。cas.audit.slf4j.auditable-fieldswho,what,when,action,client_ip,server_ip,geo_location控制审计日志可接受的字段可选值包括who、what、action、application、when、user_agent、client_ip、server_ip、geo_location、headers。文件审计的样本输出摘自 Audits-File.mdWHO: org.apereo.cas.support.oauth.authentication.principal.OAuthCredentials6cd7c975 WHAT: supplied credentials: org.apereo.cas.support.oauth.authentication.principal.OAuthCredentials6cd7c975 ACTION: AUTHENTICATION_SUCCESS APPLICATION: CAS WHEN: Mon Aug 26 12:35:59 EDT 2013 CLIENT IP ADDRESS: 172.16.5.181 SERVER IP ADDRESS: 192.168.200.22 WHO: org.apereo.cas.support.oauth.authentication.principal.OAuthCredentials6cd7c975 WHAT: TGT-9-qj2jZKQUmu1gQvXNf7tXQOJPOtROvOuvYAxybhZiVrdZ6pCUwW-cas01.example.org ACTION: TICKET_GRANTING_TICKET_CREATED APPLICATION: CAS WHEN: Mon Aug 26 12:35:59 MST 2013 CLIENT IP ADDRESS: 172.16.5.181 SERVER IP ADDRESS: 192.168.200.222.2 Groovy 脚本化审计cas.audit.groovy.*除文件输出外还可以用 Groovy 脚本接收完整的 auditable context 参数以任意文本格式构造最终审计记录结果通常以INFO级别交给日志框架。配置入口见 Groovy Audits脚本会收到applicationContext、logger、clientIpAddress、serverIpAddress、what、who、when、action、userAgent、application、geoLocation、全部 HTTP 请求头按名称逐一传入以及引擎从各组件收集的 Extra Info 键值。从源码看CasCoreAuditAutoConfiguration 中的casGroovyAuditTrailExecutionPlanConfigurer在cas.audit.groovy.template.location存在时创建 GroovyAuditTrailManager 并注册进执行计划——注意该 Bean 带有ConditionalOnMissingGraalVMNativeImage即在 GraalVM 原生镜像模式下不可用脚本功能本身依赖 Apache Groovy 集成可参考 Apache Groovy Scripting 的说明。3. 审计动作与资源解析一条记录如何被拼出来Inspektr的AuditTrailManagementAspect在织入点被触发后需要通过三类 SPI 把方法调用转成结构化的审计记录AuditActionResolver解析动作、AuditResourceResolver解析资源/what、PrincipalResolver解析 who。CasCoreAuditAutoConfiguration 把这套机制完整装配了出来动作解析器Action Resolvers—— 动作名由方法名加上成功/失败后缀构成后缀常量定义在 AuditTrailConstantsString AUDIT_ACTION_POSTFIX_SUCCESS _SUCCESS; String AUDIT_ACTION_POSTFIX_CREATED _CREATED; String AUDIT_ACTION_POSTFIX_VALIDATED _VALIDATED; String AUDIT_ACTION_POSTFIX_FAILED _FAILED; String AUDIT_ACTION_POSTFIX_TRIGGERED _TRIGGERED;例如认证动作使用DefaultAuditActionResolver(_SUCCESS, _FAILED)所以登录成功记录AUTHENTICATION_SUCCESS、失败记录AUTHENTICATION_FAILED票据创建动作使用(_CREATED, _NOT_CREATED)对应TICKET_GRANTING_TICKET_CREATED这类动作名协议验证动作使用BooleanAuditActionResolver即方法返回true/false直接映射为成功/失败。资源解析器Resource Resolvers—— 与 CAS 业务语义强绑定的解析器包括credentialsAsFirstParameterResourceResolver把方法第一个参数Credentials解析为资源描述用于认证事件ticketResourceResolver/ticketValidationResourceResolver基于票据解析资源验证场景下可按第 2 节所述附带断言信息serviceAuditResourceResolver、serviceAccessEnforcementAuditResourceResolver解析服务service相关资源分别用于发放服务票据与服务访问管控场景messageBundleAwareResourceResolver与nullableReturnValueResourceResolver对解析结果统一经过MessageSanitizer做敏感信息净化sanitization后再写入审计logoutRequestResourceResolver解析注销请求。这些解析器按常量键AuditActionResolvers/AuditResourceResolvers定义于 AuditActionResolvers.java注册进DefaultAuditTrailRecordResolutionPlan各 support 模块如票据、注销、服务可通过实现AuditTrailRecordResolutionPlanConfigurer/AuditTrailExecutionPlanConfigurer扩展计划。Principal 解析—— 默认 BeanauditablePrincipalResolver由 DefaultAuditPrincipalResolver 实现配合CasWebflowCredentialProvider从 Webflow 会话中取凭据auditPrincipalIdProvider是链式结构ChainingAuditPrincipalIdProvider支持按Ordered排序的多个 provider 依次尝试。相关行为有单元测试覆盖如 DefaultAuditPrincipalResolverTests 与 AllAuditActionResolverTests。4. 审计记录的存储策略Storage官方文档列出了以下审计存储策略每个策略对应一篇独立指南Storage说明文档File System基于日志文件cas_audit.log见cas.audit.slf4j属性Audits-FileJPA通过 JPA 持久化到关系数据库Audits-DatabaseMongoDb存储到 MongoDBAudits-MongoDbRedis存储到 RedisAudits-RedisDynamoDb存储到 AWS DynamoDbAudits-DynamoDbAWS Firehose转发到 AWS Kinesis FirehoseAudits-AWS-FirehoseREST推送至 REST 端点Audits-RESTCustom自定义审计管理器Audits-Custom各存储的属性模型分别位于 AuditJdbcProperties、AuditMongoDbProperties、AuditDynamoDbProperties、AuditAmazonFirehoseProperties、AuditRestProperties 与 AuditRedisProperties 等类中对应的 support 模块位于 support/cas-server-support-audit-jdbc、support/cas-server-support-audit-redis、support/cas-server-support-audit-mongo、support/cas-server-support-audit-dynamodb、support/cas-server-support-audit-aws-firehose、support/cas-server-support-audit-rest 等目录。正如官方文档强调的你可以选择把审计记录同时路由到数据库和一个 REST 端点外加任意多个基于 Logger 的目的地它们同时生效——这正是第 1 节中FilterAndDelegateAuditTrailManager多目的地委托的落地场景。5. Actuator 端点CAS 提供两个审计相关的 Actuator 端点需要cas-server-support-reports模块支持装配代码见 CasReportsAutoConfiguration 中的auditLogEndpoint行为可用 AuditLogEndpointTests 验证端点说明auditLog查询审计日志按动作action、principal、日期范围、IP 等条件检索已存储的审计记录依赖AuditTrailExecutionPlan与defaultAuditActionDateProvider。auditeventsSpring Boot Audit 事件端点暴露AuditEventRepository中的审计事件。值得说明的是CAS 的审计体系与 Spring Boot 的AuditEventRepository已打通CasCoreAuditAutoConfiguration 的CasCoreAuditEventsConfiguration在审计启用时提供 DelegatingAuditEventRepository Bean把 Spring 审计事件桥接到 CAS 的CasEventRepository因此auditevents端点输出的事件与 Inspektr 审计记录共享同一套事件基础设施。使用这些端点前请确保已按 Spring Boot Actuator 的常规方式暴露相应端点并配置访问安全。6. 被跟踪的审计事件Audit Events官方文档页中的 Audit Events 表格通过site.data[siteDataVersion][audits]动态渲染当前版本被跟踪的全部审计动作名。这些动作名即第 3 节所述方法名 后缀的产物覆盖认证AUTHENTICATION_SUCCESS/AUTHENTICATION_FAILED、票据生命周期TICKET_GRANTING_TICKET_CREATED、PROXY_GRANTING_TICKET_CREATED、服务票据发放与验证、票据/票据注销DESTROY_*、服务管理保存/删除服务、协议验证、注销logout以及服务访问管控service access enforcement等场景完整清单以文档站该表格随版本生成的内容为准。7. 小结与配置建议默认即开cas.audit.engine.enabled默认为 trueSLF4J 文件审计也默认启用开箱即可在cas_audit.log中看到 WHO/WHAT/ACTION/WHEN/IP 结构的多行记录。多目的地叠加通过引入多个 audit support 模块即可让同一条审计记录同时落盘、入库、推送到 REST 或 Firehose无需改动业务代码。动作白/黑名单supported-actions与excluded-actions均支持正则可用于降低高噪声场景下的审计量。代理环境必配CAS 位于 LB 之后时建议确认alternate-client-addr-header-name默认X-Forwarded-For与 LB 转发配置一致避免审计日志里全是 LB 的 IP。机器可读audit-formatJSON配合use-single-line与字段裁剪auditable-fields更适合接入日志平台。安全净化资源解析结果默认经过MessageSanitizer净化include-validation-assertion会在验证审计中暴露 principal 与已发布属性请结合合规要求决定是否开启。深度定制复杂记录格式用 Groovy 审计脚本注意原生镜像限制完全自定义目的地则参考 Audits-Custom 实现AuditTrailManager并注册进执行计划。赞分享后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载相关推荐KernelSU 架构与实践基于 Linux 内核的 Android Root 方案解析docs/README_ES 技术深读KernelSU 架构与实践基于 Linux 内核的 Android Root 方案解析docs/README_ES 技术深读 本文以 KernelSU后端认证鉴权单点登录Apereo CAS 审计日志存储到 Rediscas-server-support-audit-redis 模块配置与实现深度解析Apereo CAS 审计日志存储到 Rediscas server support audit redis 模块配置与实现深度解析 CASApereo C后端认证鉴权单点登录Apereo CAS 数据库审计Database Audits实战配置 cas-server-support-audit-jdbc、表结构与 Inspektr 底层实现解析Apereo CAS 数据库审计Database Audits实战配置 cas server support audit jdbc、表结构与 Inspek后端认证鉴权单点登录上一篇Floating UI性能指标LCP与FID优化案例下一篇QmaoTai实战经验分享成功抢到茅台的7个关键因素创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
企业数字化 ERP 产品动态
相关推荐
python-for-android 构建选项完全指南:Bootstrap 选择、命令行参数与 APK 体积优化 开发工具构建工具移动开发 【免费下载链接】python-for-android Turn your Python application into an Android APK 项目地址: https://gitcode.com/gh_mirrors/py/python-for-android 点击查看 免费下载 本篇技术指南以 python-for-android(下文简称 … · 2026/9/25 3:08:55
Django Debug Toolbar 面板全解析:内置面板、第三方面板与 Panel 开发 API 后端开发工具调试器 【免费下载链接】django-debug-toolbar A configurable set of panels that display various debug information about the current request/response. 项目地址: https://gitcode.com/gh_mirrors/dj/django-debug-toolbar 点击查看 免费下载 D… · 2026/9/25 3:08:55
网络安全黑马赛道:AI安全、实战化基础设施与防守侧机会解析 1. 为什么“黑马”这个词,在国内安全行业忽然有了意义五年前如果有人问我“网络安全行业哪个细分赛道会跑出黑马”,我大概率会劝他别想太多。当时的逻辑特别简单:头部厂商已经把防火墙、入侵检测、态势感知、SOC这些主赛道占得七七八八&#… · 2026/9/25 3:08:55
从无标题到落地:如何把模糊项目想法变成清晰可交付成果 “无标题”这三个字,在大多数项目复盘里是缺失的一栏,但在我的实际工作中,它往往意味着一个项目最真实的起点。很多朋友拿一个连名字都没有的构想来找我聊,问的第一句话不是“怎么做”,而是“这事到底能不能成”。说实… · 2026/9/25 3:35:20
肖特基二极管AM检波电路设计与ADS仿真验证 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 3:35:14
Claude Code 模板库实战:从提示词到可复用的工作流资产 Claude Code 用久了,最明显的感受不是模型懂多少,而是每一轮新会话里,你都在反复跟它解释同一个“怎么干活”的老问题。我刚开始用的时候,喜欢把完整背景、硬性约束、输出格式全写在 prompt 里,效果好是好,… · 2026/9/25 3:34:55
创维E900V22D刷机全攻略:S905L3SB芯片兼容性解析与救砖实战 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 1:00:31
MQTT协议原理与Broker服务器搭建实战:从Mosquitto到EMQX /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 1:00:37