后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载CAS 作为 SAML2 服务提供方SP参与委托认证时需要一份描述自身实体 ID、证书与断言消费服务ACS地址的 SP 元数据文档。本指南聚焦于 CAS 默认采用的文件系统FileSystem元数据存储方案元数据文件存放于磁盘、启动时自动生成并支持后续手工维护与再生成。读完本文你将掌握cas.authn.pac4j.saml[].metadata.service-provider.file-system配置树的完整用法、SP 元数据文件的生命周期管理以及如何借助运行时端点快速校验与分发元数据。一、委托认证中的 SP 元数据为什么需要它在 SAML2 委托认证场景下CAS 通过 pac4j 的SAML2Client将认证流程转交给外部身份提供商IdP例如 Azure AD、Okta 或任意第三方 SAML2 IdP。在此过程中CAS 自身是 SP它必须向 IdP 出示一份合法的SP 元数据其中包含SP 的实体 IDentityIDSP 用于签名认证请求AuthnRequest与解密断言的公私钥信息断言消费服务Assertion Consumer Service, ACS的地址与绑定类型单点登出SLO服务的地址SP 请求的属性和 NameID 策略等扩展内容。IdP 依据这份元数据识别 CAS、验证 CAS 发来的签名请求并把 SAML 断言回送到正确的 ACS 端点。因此SP 元数据的正确性直接决定委托认证能否成功握手。二、文件系统存储CAS 的默认方案原文档明确指出SAML2 SP 元数据通常存放在磁盘上并且默认在启动时生成如果元数据文件不存在。这是 CAS 的默认行为无需任何额外存储组件。该方案有两个关键特性启动自动生成若指定的元数据文件在 CAS 启动时不存在CAS 会依据当前配置实体 ID、证书、绑定等自动生成并写入该文件已存在则复用若文件已经存在CAS 会直接加载并复用其内容而不会覆盖或重新生成手工维护后续对元数据文件的任何变更如更换证书、调整 ACS 地址必须手工编辑该文件使其符合你的实际部署需求。适用前提文件系统元数据存储由cas-server-support-pac4j-saml模块提供并在cas.authn.pac4j.saml[].metadata.service-provider配置树的file-system分支下进行设置无需额外引入 MongoDB、JDBC 或 AWS S3 等存储依赖。三、配置详解完整可运行的示例文件系统 SP 元数据对应的配置属性为cas: authn: pac4j: saml: - client-name: MySaml2IdP service-provider-entity-id: https://cas.example.org/samlsp keystore-path: file:/etc/cas/config/samlKeystore.jks keystore-password: changeit private-key-password: changeit metadata: identity-provider-metadata-path: file:/etc/cas/config/idp-metadata.xml service-provider: file-system: location: file:/etc/cas/config/sp-metadata.xml其中核心属性cas.authn.pac4j.saml[].metadata.service-provider.file-system.location指定SP 元数据文件的存放位置。在配置模型源码 Pac4jSamlServiceProviderMetadataFileSystemProperties.java 中该属性被标记为RequiredProperty必填其注释也印证了上述生命周期语义Location of the SP metadata to use and generate on the file system. If the metadata file already exists, it will be ignored and reused.SP 元数据在文件系统上的存放与生成位置。若该元数据文件已存在则忽略生成逻辑并直接复用。3.1 相关必填与常用属性从 Pac4jSamlClientProperties.java 的配置模型可以看到一个完整的 SAML2 委托客户端还涉及以下关键属性均位于cas.authn.pac4j.saml[]之下属性默认值说明client-name—委托客户端的唯一名称用于在 CAS 内区分不同的 IdP 客户端metadata.identity-provider-metadata-path—IdP 元数据的位置file:、classpath:等 Spring 资源前缀service-provider-entity-idhttps://apereo.org/cas/samlspSP 的实体 ID生成 SP 元数据时写入keystore-path—SP 密钥库位置未配置时 CAS 会落到临时目录的samlSpKeystore.jkskeystore-password/private-key-password—密钥库与私钥口令均为必填force-keystore-generationfalse是否强制重新生成密钥库certificate-expiration-days7300365×20 天生成的证书有效期天certificate-signature-algSHA1WithRSA生成证书使用的签名算法sign-service-provider-metadatafalse生成的 SP 元数据是否签名sign-authn-requestfalseAuthnRequest 是否签名sign-service-provider-logout-requestfalseSP 发出的 LogoutRequest 是否签名response-binding-typeHTTP-POST由底层 pac4j 决定元数据中 ACS 的绑定类型wants-assertions-signed/wants-responses-signedfalse是否要求断言/响应必须签名requested-attributes空列表写入 SP 元数据的请求属性列表含name、friendly-name、name-format、required3.2 元数据存储的多后端结构SP 元数据存储并非只有文件系统一种选择。在 Pac4jSamlServiceProviderMetadataProperties.java 中可以看到service-provider下同时定义了四个并列的嵌套配置分支file-system磁盘文件存储默认方案本文主题mongoMongoDB 存储jdbc关系型数据库存储amazonS3AWS S3 存储。配置前缀均为cas.authn.pac4j.saml[].metadata.service-provider.{file-system|mongo|jdbc|amazon-s3}各分支互斥使用。本文只深入讲解默认的文件系统方案其余后端在对应模块如DelegatedAuthenticationSaml2MongoDbConfiguration、DelegatedAuthenticationSaml2JdbcConfiguration等中实现。四、源码级实现元数据位置如何被解析与加载理解了配置项后我们来看 CAS 是如何把file-system.location真正用起来的。核心逻辑位于 DelegatedClientSaml2Builder.java 的buildSaml2IdentityProviders方法中val samlSpMetadata StringUtils.defaultIfBlank(saml.getMetadata().getServiceProvider().getFileSystem().getLocation(), Beans.getTempFilePath(samlSpMetadata, .xml)); FunctionUtils.doIfNotNull(samlSpMetadata, location - { val resource ResourceUtils.getRawResourceFrom(location); LOGGER.debug(Service provider metadata is located at [{}] with entity id [{}], resource, serviceProviderEntityId); configuration.setServiceProviderMetadataResource(resource); });这段代码揭示了三个实现事实取值优先级优先读取metadata.service-provider.file-system.location如果该值为空则回退到Beans.getTempFilePath(samlSpMetadata, .xml)即在系统临时目录生成一个samlSpMetadata.xml。也就是说即使你完全不配置 SP 元数据位置CAS 也能在临时目录中兜底生成一份资源解析位置字符串通过ResourceUtils.getRawResourceFrom(location)解析为 Spring 资源支持file:、classpath:等标准资源前缀注入 pac4j 配置解析得到的资源被设置到 pac4j 的SAML2Configuration#setServiceProviderMetadataResource后续由 pac4j 的SAML2Client在init()阶段完成“不存在则生成、存在则加载”的判定。同一构建器还完成了密钥库路径、实体 ID、签名策略、消息存储工厂EMPTY/SESSION/自定义类名等大量配置的装配最终产出SAML2Client实例。可见 SP 元数据只是整个 SAML2 委托客户端装配流程中的一个环节但它直接决定了 IdP 侧对 CAS 的信任基础。4.1 测试用例验证仓库测试 DelegatedSaml2IdentityProviderTests.java 给出了file-system配置的标准用法例如cas.authn.pac4j.saml[0].keystore-pathfile:/tmp/keystore-${#randomNumber6}.jks cas.authn.pac4j.saml[0].keystore-password1234567890 cas.authn.pac4j.saml[0].private-key-password1234567890 cas.authn.pac4j.saml[0].metadata.identity-provider-metadata-pathclasspath:idp-metadata.xml cas.authn.pac4j.saml[0].metadata.service-provider.file-system.locationfile:/tmp/sp.xml cas.authn.pac4j.saml[0].service-provider-entity-idtest-entityid测试通过DelegatedIdentityProviderFactory.build()构建客户端后断言其解析出的 IdP 实体描述符与元数据均不为空验证了“基于文件系统 SP 元数据 IdP 元数据成功装配 SAML2 客户端”这一完整链路。五、元数据文件的生命周期生成、复用与手工维护5.1 首次启动自动生成当location指向的文件不存在时CAS 启动 / 客户端初始化时会以当前配置为输入自动生成 SP 元数据内容包括entityID来自service-provider-entity-idmd:KeyDescriptor来自自动生成或指定位置的密钥库中的证书可通过certificate-expiration-days、certificate-signature-alg控制md:AssertionConsumerService地址为 CAS 的委托认证回调地址绑定类型受response-binding-type控制md:SingleLogoutService当配置single-logout-service-url时写入md:RequestedAttribute来自requested-attributes列表。5.2 再次启动加载复用文件已存在时CAS 不会重新生成而是直接加载。因此对元数据的修改应当通过编辑该文件完成。手工编辑时需要注意保持 XML 结构合法并确保entityID与service-provider-entity-id保持一致——两者不一致会导致 IdP 无法将 CAS 识别为已注册的 SP。5.3 需要重新生成时的做法如果部署参数发生了根本性变化例如更换了 SP 实体 ID 或证书旧文件已无法复用。此时应当停止 CAS删除或备份后移除旧的 SP 元数据文件重新启动 CAS让其依据新配置重新生成。注意由于仓库为只读环境此处所述“删除文件”指的是在你自己的 CAS 部署环境中维护元数据文件而非修改本仓库。六、运行时校验通过 CAS 端点获取 SP 元数据为了便于向 IdP 注册或排查问题CAS 提供了 HTTP 端点直接输出 SP 元数据XML。相关实现位于 DelegatedSaml2ClientMetadataController.java端点以/sp为基础路径端点说明GET /sp/metadata返回第一个SAML2 委托客户端的 SP 元数据XMLGET /sp/{client}/metadata按客户端名称返回对应 SP 元数据GET /sp/idp/metadata返回第一个客户端的 IdP 元数据GET /sp/{client}/idp/metadata按名称返回 IdP 元数据例如向 IdP 管理员提供https://cas.example.org/cas/sp/metadata即可让对方导入 CAS 的 SP 元数据。这些端点响应Content-Type: application/xml当不存在 SAML2 客户端时返回404。端点由 DelegatedAuthenticationSaml2Configuration.java 中注册的安全配置器纳入忽略认证的端点列表因此可被 IdP 直接匿名访问。七、常见问题与注意事项多 IdP 场景cas.authn.pac4j.saml[]是数组配置每个元素对应一个 IdP 客户端可分别为每个客户端指定独立的file-system.location避免多个客户端共用同一元数据文件文件权限CAS 进程需要对元数据文件所在目录具有读权限如果希望 CAS 自动生成还要求对目录具备写权限生成时机在启动/首次初始化证书与元数据的一致性修改了密钥库更换证书后旧元数据文件中的证书指纹与 IdP 侧缓存不再匹配通常需要重新生成 SP 元数据并在 IdP 侧同步更新临时目录兜底未配置location时元数据落在临时目录重启或清理临时文件后可能重新生成导致 IdP 侧注册的元数据与最新文件不一致。生产环境务必显式配置固定的file-system.location切勿在生产环境开启all-signature-validation-disabled该属性会关闭响应签名校验配置模型中已明确警告仅可用于调试。八、小结文件系统 SP 元数据存储是 CAS SAML2 委托认证的默认且零额外依赖的方案配置一个locationCAS 即可在启动时自动生成或复用磁盘上的元数据文件配合/sp/metadata端点可以快速完成 IdP 侧的 SP 注册。理解生成—复用—手工维护—再生成的生命周期是在生产环境稳定运行 SAML2 委托认证的关键。若你的部署需要共享或集中化管理元数据可进一步参考service-provider下的mongo、jdbc、amazon-s3分支其配置入口均与本文讲解的file-system结构对齐。赞分享后端认证鉴权单点登录【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载相关推荐Apereo CAS SAML2 委托认证实战将服务提供商元数据托管到 Amazon S3Apereo CAS SAML2 委托认证实战将服务提供商元数据托管到 Amazon S3 本文将介绍 Apereo CAS 在配置 SAML2 委托认证D后端认证鉴权单点登录ai-memory 规则晋升设计如何把长期记忆安全地提升为受治理的 AGENTS.md 规则2.1 特性前瞻ai memory 规则晋升设计如何把长期记忆安全地提升为受治理的 AGENTS.md 规则2.1 特性前瞻 本设计文档面向 ai memory 的 re后端认证鉴权单点登录Apereo CAS SAML2 动态元数据的 REST 实现SP 元数据拉取与 IdP 元数据托管完整指南Apereo CAS SAML2 动态元数据的 REST 实现SP 元数据拉取与 IdP 元数据托管完整指南 Apereo CAS 的 SAML 身份提供方后端认证鉴权单点登录上一篇如何永久保存微信聊天记录本地免费工具WeChatMsg完整指南下一篇pnpm 依赖解析修复仅通过 peerDependenciesMeta 声明的可选 peer 依赖现在与显式声明一样参与解析与提升创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考