Authelia 4.37 预发布详解Envoy 支持、OIDC 增强、多算法密码哈希与 mTLS 前瞻【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia本篇文章基于 Authelia 官方 4.37 预发布说明系统梳理该版本计划引入的核心能力Envoy/Istio 代理接入、OpenID Connect 1.0 的哈希客户端密钥与全新同意模式、OCI 容器注解、扩展后的密码哈希算法矩阵、YAML 文件认证后端的热重载与邮箱登录、Redis/LDAP/SMTP 的双向 TLS以及访问控制中的查询参数匹配规则。读完本文你将掌握 4.37 每个新特性的设计动机、适用场景与对应的配置形态并能结合仓库源码理解其底层实现位置。注意本文源自 4.37 正式发布前的预告原文日期为 2024-03-14其中描述的功能在发布前仍可能调整但代表了该版本最可能落地的功能集。对照仓库内的 OpenID Connect 1.0 路线图docs/content/roadmap/active/openid-connect-1.0-provider.md可以看到本文预告的 Hashed Client Secrets、JWK 证书链、Per-Client 同意模式均已随 4.37.0 标记为完成状态。Envoy / Istio 支持补齐主流反向代理的最后拼图4.37 版本将正式支持 [Envoy] 与 [Istio] 作为前端代理接入 Authelia。这一支持基本完成了 Authelia 的主流代理兼容矩阵——除 Microsoft IIS 之外所有主流代理均已获得官方支持。从仓库现状看Envoy 相关的集成测试已经就位在 internal/suites/Envoy/ 与 internal/suites/HAProxy/ 等目录中可以看到按代理划分的端到端测试套件每个套件都包含对应的 compose 配置与场景测试文件如 internal/suites/suite_envoy.go、internal/suites/suite_envoy_test.go。这类测试验证的是 Authelia 作为认证网关与各类代理配合时auth_request/ 转发认证等流程的正确性。对于使用 Service Mesh 或 Envoy 作为边缘代理的部署这意味着可以沿用与其他代理一致的接入方式如 forward-auth / ext-authz 模式无需为 Envoy 单独维护认证逻辑。OpenID Connect 1.0 改进多项路线图条目落地4.37 勾销了 OpenID Connect 1.0 路线图对应 Beta 5 阶段中的多项条目主要包括以下三点。哈希客户端密钥Hashed Client Secrets此前 OpenID Connect 客户端的secret只能以明文形式存储在配置中。4.37 起将支持存储哈希后的客户端密钥管理员仍可继续使用明文密钥但官方推荐使用 PBKDF2、Bcrypt 或 SHA512 SHA2CRYPT完整兼容列表见下文密码算法扩展一节。这一改动不会影响依赖方Relying Party侧的交互——OIDC 客户端仍然提交明文 secret 进行认证Authelia 内部使用同样的密码哈希验证机制来比对摘要因此只需修改 Authelia 配置文件即可完成迁移。仓库源码印证了这一设计在 internal/oidc/client.go 中存在ClientSecretDigest类型的摘要处理逻辑测试文件 internal/oidc/client_test.go 中可以看到使用 Argon2id 与 PBKDF2-SHA512 摘要作为客户端密钥的用例如$pbkdf2-sha512$100000$...格式的密钥摘要。配置时只需把secret字段直接写为带$前缀的摘要字符串即可例如identity_providers: oidc: clients: - client_id: my-app secret: $pbkdf2-sha512$310000$... # 哈希后的客户端密钥 authorization_policy: two_factor同意模式Consent Modes此前 Authelia 仅支持显式同意explicit与预先配置pre-configured两种模式其中 pre-configured 仅在设置了预配置时长后才生效。4.37 将引入隐式同意模式implicit——在该模式下Authelia 永远不会向用户询问任何同意授权同时同意模式的配置方式会变得更加显式。三种模式的语义对照 OpenID Connect 1.0 路线图中的 Beta 5 描述模式行为说明explicit始终询问终端用户同意默认模式严格符合规范implicit从不询问终端用户同意不严格符合规范与consentprompt 类型不兼容适合信任度高的内部应用pre-configured在管理员配置的时长内保存同意会话行为与显式模式几乎一致只是同意结果可在一段时间内复用从实现结构看仓库中同意相关的处理已按模式拆分显式同意见 internal/handlers/handler_oauth2_authorization_consent_explicit.go隐式同意见 internal/handlers/handler_oauth2_authorization_consent_implicit.go预配置同意见 internal/handlers/handler_oauth2_authorization_consent_preconfigured.go并配套了对应的测试文件。管理员可以为不同客户端分别指定同意模式。JWKS 证书链JWKS Certificate Chain此前的 JWKSJSON Web Key Set端点只支持暴露私钥对应的公钥不支持证书。4.37 起将支持通过 JWKS 端点发布证书链Certificate Chain从而在理论上允许依赖方校验 JWKS 所关联的信任等级。需要说明的是只有少数应用理论上需要该能力绝大多数依赖方可能完全不支持读取证书链。但这一改动的优雅之处在于向后兼容——对方若不支持证书链直接忽略即可不影响现有流程。尽管此前几乎没有用户主动提出该需求考虑到第三方迟早会要求Authelia 选择提前实现。路线图中也确认了这一条目JWKs backed by X509 Certificate Chains已随 4.37.0 完成其规范依据是 RFC 7517 第 4.7 节。容器注解与标签OCI Annotations / Labels4.37 开始所有发布的镜像将附带 [OCI Image Format Specification] 定义的标准[注解Annotations]。由于注解规范目前的支持度仍相对有限大多数使用方要么直接使用容器标签labels、要么在无法读取注解时回退到标签因此同一份信息会同时以注解和容器标签两种形式提供。这意味着运维人员可以更规范地通过标准 OCI 字段如版本、描述等元数据识别与审计 Authelia 镜像而不必依赖非标准的自定义字段。对于基于镜像元数据做供应链管理、镜像清单生成的团队这一改动降低了元数据获取的成本。密码算法扩展更完整的密码哈希矩阵4.37 引入多个新的密码哈希算法支持列表扩充为Argon2Argon2id此前已支持、Argon2i、Argon2dPBKDF2SHA1、SHA224、SHA256、SHA384、SHA512Scrypt标准 Scrypt 变体、YescryptBcryptSHA2 CRYPTSHA256、SHA512SHA512 此前已支持这些算法不仅用于 YAML 文件后端的用户密码也用于上文提到的 OIDC 客户端密钥哈希二者共享同一套密码摘要解析与验证能力。仓库的配置 Schemainternal/configuration/schema/authentication.go中每种算法都有独立的参数结构与默认值算法配置键关键参数与默认值Argon2algorithm: argon2variant默认argon2id可选argon2i/argon2d、iterations默认 3、memory默认 65536 KiB、parallelism默认 4、key_length默认 32、salt_length默认 16PBKDF2algorithm: pbkdf2variant默认sha512可选sha1/sha224/sha256/sha384、iterations默认 310000下限 100000、salt_length默认 16下限 8SHA2 Cryptalgorithm: sha2cryptvariant默认sha512可选sha256、iterations默认 50000下限 1000、salt_length默认 16Bcryptalgorithm: bcryptvariant默认standard可选sha256、cost默认 12范围 10–31Scryptalgorithm: scryptvariant默认scrypt可选yescrypt、iterations默认 16、block_size默认 8、parallelism默认 1、key_length默认 32、salt_length默认 16值得注意的是PBKDF2 各变体的默认迭代次数并不相同见 internal/configuration/schema/authentication.go 中defaultIterationsPBKDF2SHA512等常量SHA512 为 310000、SHA384 为 280000、SHA256 为 700000、SHA224 为 900000、SHA1 为 1600000——迭代次数随摘要算法强度反向调整以在安全性与性能间取得平衡。算法标识在 internal/authentication/const.go 中统一注册argon2、sha2crypt、pbkdf2、scrypt、bcrypt密码摘要本身采用业界标准的 PHC 字符串格式。仓库自带的用户数据库模板internal/authentication/users_database.template.yml展示了 Argon2id 摘要的形态users: authelia: disabled: true displayname: Test User password: $argon2id$v19$m32768,t1,p8$eUhVT1dQa082YVk2VUhDMQ$E8QI4jHbUBt3EdsU1NFDu4Bq5jObKNx7nBKSn1EYQxk email: autheliaauthelia.com groups: - admins - dev完整的算法配置示例如下对应 internal/configuration/schema/authentication.go 中的结构authentication_backend: file: path: /config/users_database.yml password: algorithm: argon2 argon2: variant: argon2id iterations: 3 memory: 65536 parallelism: 4 key_length: 32 salt_length: 16 search: email: true case_insensitive: false用户 YAML 文件认证后端增强在密码算法扩展之外4.37 还为 YAML 文件认证后端File Authentication Backend增加了两个重要能力。自动重载Automatic Reload管理员可以配置 Authelia 自动监视用户数据库 YAML 文件并在文件被外部修改后动态重载用户数据无需重启进程。该能力只针对用户数据库文件本版本不会扩展到主配置文件的热重载。源码层面internal/authentication/file_user_provider.go 中实现了Reload()方法并带有冷却cooldown与空文件ErrWatcherNoContent等边界处理配置项为authentication_backend.file.watch布尔值默认false见 internal/configuration/schema/authentication.go。开启方式authentication_backend: file: path: /config/users_database.yml watch: true需要留意的是自动重载只负责重新读取用户数据库若 YAML 语法或哈希格式存在问题重载会按错误严重级别处理部分错误可忽略并继续使用旧数据关键错误会被标记为 critical因此生产环境建议先在外部分阶段验证文件内容再覆盖。邮箱登录Email Lookup管理员可以允许用户使用邮箱地址或用户名登录这与 LDAP 后端通过过滤器如(|({username_attribute}{input})({mail_attribute}{input}))同时匹配用户名与邮箱的做法对齐使 YAML 文件后端获得功能对等feature parity。对应的配置项为authentication_backend.file.search见 internal/configuration/schema/authentication.gosearch.email是否允许用邮箱替代用户名登录默认falsesearch.case_insensitive用户名/邮箱匹配是否忽略大小写默认false在代码中这些选项被传入用户数据库的构造过程NewFileUserDatabase(config.Path, config.Search.Email, config.Search.CaseInsensitive, ...)见 internal/authentication/file_user_provider.go说明匹配行为是在数据库加载/查询时生效的。Mutual TLSmTLS支持4.37 将新增对Redis、LDAP 与 SMTP的双向 TLSMutual TLS支持用于在不期望使用密码认证的场景下提升与这些系统的互操作性。启用 mTLS 后Authelia 在建立 TLS 连接时会向对端出示客户端证书由对端校验身份从而替代传统的口令认证方式。这一能力对以下场景尤其有价值通过 mTLS 保护 Redis 会话存储连接例如在 Kubernetes 网络内使用证书而非密码访问 RedisLDAP 目录服务使用客户端证书绑定certificate-based bind而非服务账号密码SMTP 服务器要求客户端证书认证的邮件网关环境。结合仓库中已有的 TLS 配置结构如 internal/configuration/schema/authentication.go 中 LDAP 的tls配置块mTLS 的启用通常仍依托各组件既有的 TLS 配置段tls/certificate/private_key/server_name等只是新增了客户端证书的指定能力。访问控制查询参数授权规则4.37 在访问控制规则中新增了针对查询参数query parameter的专用匹配器。它可以单独定位某个查询参数键key并测试其存在 / 不存在present / absent等于 / 不等于某值equal / not equal匹配 / 不匹配某条正则表达式pattern / not pattern该规则类型相比resources资源路径规则存在一定的性能开销因此官方仍优先推荐使用resources规则但对于查询参数的复杂匹配单纯用正则难以精确表达此特性正好解决了这一痛点。仓库实现位于 internal/authorization/access_control_query.goNewAccessControlQuery将配置转换为匹配器列表AccessControlQueryMatcherPresent/AccessControlQueryMatcherEqual/AccessControlQueryMatcherPattern分别处理上述三类操作符并由 internal/authorization/access_control_query_test.go 覆盖测试。配置 Schemainternal/configuration/schema/access_control.go定义了规则的字段结构operator枚举equal、not equal、present、absent、pattern、not pattern、key必填查询参数键名、value操作符对应的值或正则表达式。配置示例针对/secure路径要求请求必须携带modestrict查询参数access_control: default_policy: deny rules: - domain: secure.example.com resources: - ^/secure query: - operator: equal key: mode value: strict policy: one_factor兼容性特性Compatibility Features兼容性特性是 Authelia 提供的一类开关型功能用于与第三方系统协同工作通常是出于忽略某个第三方未正确实现的规范的目的而引入。4.37 将新增以下两项LDAP 服务器不支持查询 RootDSE 的受支持控制/扩展部分 LDAP 实现无法响应针对 RootDSE 中supportedControl/supportedExtension等属性的查询相关常量定义见 internal/authentication/const.go开启此兼容特性可让 Authelia 跳过这类探测避免健康检查或能力协商失败。SMTP 服务器声明支持 STARTTLS 但实际上并不支持部分邮件服务器在能力声明中通告 STARTTLS却在握手时未真正实现该协议此兼容特性允许 Authelia 忽略这类错误的通告回退到其他可用加密方式。这两项特性均面向真实的互操作痛点前者解决 LDAP 能力探测在部分实现如某些基于 OpenLDAP 的定制发行版上的失败后者解决邮件网关中常见的假 STARTTLS通告问题。管理员在遇到对应第三方故障时可通过这些开关恢复连接而不必修改第三方配置。小结4.37 的定位与升级建议综合来看4.37 是一次广度补齐 纵深加固的版本广度补齐 Envoy/Istio 代理支持、OCI 注解/标签、mTLSRedis/LDAP/SMTP让部署形态更完整纵深密码算法从 Argon2id 单一主力扩展到覆盖 Argon2 全系、PBKDF2 全系、Scrypt/Yescrypt、Bcrypt、SHA2 Crypt 的完整矩阵为从其他系统如passwd/shadow格式、PHP 站点、旧版哈希迁移用户提供了兼容通道OIDC 侧的哈希密钥、隐式同意与证书链则让身份提供方能力更接近生产级要求。升级前建议重点核对authentication_backend.file.password的算法与参数是否与现有用户数据库摘要匹配OIDC 客户端若改用哈希 secret需确保摘要算法在支持列表内且格式正确文件后端启用watch后应确认运维流程支持原子化更新用户文件。所有新配置项均可对照 config.template.yml 与 docs/content/configuration/ 下的官方配置文档进行逐项确认。【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考