使用 Authelia OpenID Connect 1.0 为 Ansible AWX 与 Ansible Tower 配置单点登录【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/autheliaoutput文章本指南将完整演示如何将Ansible AWX以及同源的Ansible Tower接入Authelia的 OpenID Connect 1.0 Provider实现以 Authelia 为身份源的统一认证。你将掌握 Authelia 侧注册客户端的 YAML 配置要点、AWX 侧 Generic OIDC 设置的完整操作步骤以及授权码流程在client_secret_post认证方式下的底层工作机理可直接照搬到你的实验或生产环境。一、适用版本与前提假设本指南基于以下已实测通过的版本组合对应仓库中的 Ansible AWX 集成文档组件版本Autheliav4.39.24Ansible AWXv24.6.1本指南属于Community社区级别的集成支持文档中同时标注了integration: true与versions: true意味着集成方式与版本信息均有官方跟踪记录。前提假设本示例默认以下配置前提请按你的实际环境替换应用根地址Application Root URLhttps://awx.example.com/Authelia 根地址Authelia Root URLhttps://auth.example.com/同时作为 OpenID Connect 1.0 的 IssuerClient IDawxClient Secretinsecure_secret仅演示用生产环境请务必更换官方文档中的example.com、auth等值属于可被文档变量自动替换的占位符实际部署时应替换为你自己的域名。二、配置前须知Before You Begin在动手配置 OpenID Connect 1.0 注册客户端之前有几条贯穿全篇的重要原则源自 oidc-common 公共提示块client_id必须全局唯一每个客户端的 Client ID 都不得与其他客户端重复且只能包含 RFC3986 Unreserved Characters。client_secret强烈建议以哈希形式存储Authelia 支持将密钥以 PBKDF2 哈希的形式写入配置文件明文存储属于已弃用行为。需要注意的是哈希工作因子过高可能引起客户端请求超时可参考 FAQ调整工作因子 进行调优。Authelia 侧配置只是客户端注册片段你必须同时配置 OpenID Connect 1.0 Provider 配置 中的其余强制项如 issuer 相关设置本指南只展示与 AWX 客户端直接相关的部分同时客户端配置文档 中还包含大量本指南未涉及的选项建议一并通读以理解每个配置项的效果。三、Authelia 侧注册 AWX 客户端在 Authelia 的configuration.yml中于identity_providers.oidc.clients列表下新增如下客户端配置identity_providers: oidc: ## OpenID Connect 1.0 Provider 的其他强制配置项在此处填写。 clients: - client_id: awx client_name: Ansible AWX client_secret: $pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng # The digest of insecure_secret. public: false authorization_policy: two_factor require_pkce: false pkce_challenge_method: redirect_uris: - https://awx.example.com/sso/complete/oidc/ scopes: - openid - email - profile response_types: - code grant_types: - authorization_code access_token_signed_response_alg: none userinfo_signed_response_alg: none token_endpoint_auth_method: client_secret_post四、关键配置项逐项解析以下每个配置项均可在 OpenID Connect 1.0 客户端配置参考 中找到权威定义这里结合 AWX 场景逐一说明4.1client_id与client_nameclient_id必填必须与 AWX 侧配置的OIDC Key完全一致本例为awx。它是令牌、授权请求中识别客户端的核心标识。client_name可选显示在 Authelia 用户界面中的友好名称默认与 ID 相同本例设为Ansible AWX便于用户识别。4.2client_secret哈希存储的共享密钥该密钥必须与 AWX 侧配置的OIDC Secret一致。本示例展示的是insecure_secret的 PBKDF2-SHA512 哈希摘要$pbkdf2-sha512$310000$...而非明文这正是文档推荐的存储方式。在客户端认证过程中Authelia 会对收到的密钥进行同参数哈希比对。配置哈希值时需要注意详见 oidc-common 提示若哈希工作因子本示例为310000次迭代过高可能导致客户端在令牌端点认证时超时生产环境应使用足够强度的随机密钥避免使用示例中的insecure_secret。4.3public: false保密客户端类型public的默认值为false即本客户端属于confidential保密客户端见 RFC6749 Section 2.1。这类客户端有能力安全保存凭据因此必须配置client_secret。AWX 是服务端应用能够在服务端安全持有密钥符合保密客户端的定位。4.4authorization_policy: two_factor该选项默认值即为two_factor指定客户端发起授权请求时所需的认证级别可取值one_factor、two_factor或 Provider 级定义的 authorization_policies 策略名称。注意此策略仅作用于授权请求本身与 Authelia 的访问控制规则Access Control Rules是两套独立的机制不应混淆——应用自身的访问控制仍需在 AWX 侧实现。4.5require_pkce与pkce_challenge_methodrequire_pkce: false不强制要求 AWX 使用 PKCE。pkce_challenge_method: 空字符串表示不针对该客户端强制指定挑战方法有效值包括空串、plain与S256其中S256是强烈推荐的取值。由于 AWX 作为保密客户端会携带client_secret在令牌端点完成认证因此本示例未强制启用 PKCE。若你的 AWX 版本支持仍建议开启以进一步缓解授权码拦截风险。4.6redirect_uris回调 URI 列表必须精确包含AWX 的 OIDC 回调地址https://awx.example.com/sso/complete/oidc/关键约束详见 clients.md#redirect_urisURI区分大小写必须与 AWX 实际发起回调时使用的 URI 逐字符一致未列入列表的回调一律视为不安全授权请求会直接失败必须携带http或https协议头。4.7scopes允许该客户端消费的授权范围。AWX 需要以下三个 scopeopenidOpenID Connect 的核心 scope返回sub等身份标识email提供用户邮箱地址profile提供用户名等基本资料。更完整的 scope 定义与可携带的 claims 清单见 OpenID Connect 1.0 集成指南的 Scope 定义章节。4.8response_types与grant_typesresponse_types: [code]仅允许Authorization Code Flow授权码流程。这是官方安全提示中唯一推荐的响应类型其余如token、id_token安全性较低。grant_types: [authorization_code]限定该客户端只能通过授权码授权获取令牌。两者组合意味着 AWX 与 Authelia 之间走标准的前端授权 后端换码流程。4.9access_token_signed_response_alg与userinfo_signed_response_algnone两者均设为none这也是access_token_signed_response_alg与userinfo_signed_response_alg的默认值含义如下Access Token 以不透明opaque字符串形式签发而非签名的 JWT。Authelia 的 Access Token 默认即为此形态资源服务器需通过 Introspection 端点 校验对应路径为https://auth.example.com/api/oidc/introspectionUserInfo 端点https://auth.example.com/api/oidc/userinfo返回纯 JSON 文档application/json而非 JWT 编码响应。该配置与 AWX 的 Generic OIDC 客户端实现相兼容无需额外签名验证。4.10token_endpoint_auth_method: client_secret_post指定 AWX 在令牌端点https://auth.example.com/api/oidc/token出示客户端凭据的方式。可选值包括client_secret_basic默认、client_secret_post、client_secret_jwt、private_key_jwt与none公开客户端默认。AWX 通过HTTP POST 请求体携带client_secret因此选用client_secret_post。五、Ansible AWX 侧Generic OIDC 设置Ansible AWX 目前只有一种配置入口——Web 图形界面Web GUI。操作步骤如下以管理员身份登录 Ansible AWX点击左侧导航栏的Settings设置在设置窗口左侧点击Generic OIDC settings通用 OIDC 设置点击Edit编辑配置以下选项AWX 选项值OIDC KeyawxOIDC Secretinsecure_secretOIDC Provider URLhttps://auth.example.comVerify OIDC Provider Certificate启用Enable点击Save保存。其中OIDC Provider URL指向 Authelia 的根地址AWX 会依据该地址自动拼接发现文档/.well-known/openid-configuration以获取授权、令牌、UserInfo 等端点。Verify OIDC Provider Certificate保持启用可确保 AWX 对 Authelia 服务端证书做校验防止中间人攻击。六、端到端认证流程解析完成两侧配置后用户的登录链路如下对应的端点路径均可在 集成指南的 Endpoint Implementations 章节 查到用户访问https://awx.example.com/AWX 将用户重定向到 Authelia 授权端点https://auth.example.com/api/oidc/authorization携带client_idawx、response_typecode、redirect_urihttps://awx.example.com/sso/complete/oidc/及openid email profile等 scopeAuthelia 根据authorization_policy: two_factor要求用户完成登录含第二因素如 TOTP / WebAuthn认证通过后Authelia 将授权码经https://awx.example.com/sso/complete/oidc/回传给 AWXAWX 在后端向令牌端点https://auth.example.com/api/oidc/token发起换码请求并以client_secret_post方式在 POST 请求体中携带client_secretAuthelia 校验凭据对哈希后的密钥做比对后签发 Access Token 与 ID TokenAWX 通过 UserInfo 端点https://auth.example.com/api/oidc/userinfo或 ID Token 获取用户邮箱、资料等 claims完成本地会话建立。七、安全加固建议结合 oidc-common 提示 与 客户端配置文档建议在生产环境执行以下加固更换密钥使用 Authelia 提供的随机密钥生成工具生成强随机client_secret并以哈希形式写入配置切勿使用insecure_secret避免凭据中的特殊字符部分 OIDC 客户端包括 AWX 在内的众多第三方实现在client_secret_post/client_secret_basic认证前未按 RFC6749 Appendix B 对 Client ID 与 Secret 做 URL 编码。规避特殊字符或预先 URL 编码是最稳妥的做法按需收紧认证策略若 AWX 面向内部高权限运维人员two_factor是合理选择如需更细粒度的用户分组控制可配置 Provider 级的 authorization_policies 并引用到本客户端关注 claim 稳定性AWX 等应用可能使用email等可变 claim 绑定本地账号而 OpenID Connect 规范要求以稳定的sub、issclaim 绑定身份见 OpenID Connect Core 5.7 Claim Stability集成时应了解这一差异并在账号映射上谨慎设计。八、参考资料Ansible AWX / Ansible Tower 集成文档本指南源文档OpenID Connect 1.0 客户端配置参考OpenID Connect 1.0 Provider 配置OpenID Connect 1.0 集成指南OpenID Connect 1.0 常见问题 FAQoidc-common 公共提示块模板Ansible AWX 官方《Setting up Enterprise Authentication》文档中关于 Generic OIDC Settings 的章节AWX 24.6.1/output文章【免费下载链接】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），仅供参考 使用 Authelia OpenID Connect 1.0 为 Ansible AWX 与 Ansible Tower 配置单点登录
使用 Authelia OpenID Connect 1.0 为 Ansible AWX 与 Ansible Tower 配置单点登录【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/autheliaoutput文章本指南将完整演示如何将Ansible AWX以及同源的Ansible Tower接入Authelia的 OpenID Connect 1.0 Provider实现以 Authelia 为身份源的统一认证。你将掌握 Authelia 侧注册客户端的 YAML 配置要点、AWX 侧 Generic OIDC 设置的完整操作步骤以及授权码流程在client_secret_post认证方式下的底层工作机理可直接照搬到你的实验或生产环境。一、适用版本与前提假设本指南基于以下已实测通过的版本组合对应仓库中的 Ansible AWX 集成文档组件版本Autheliav4.39.24Ansible AWXv24.6.1本指南属于Community社区级别的集成支持文档中同时标注了integration: true与versions: true意味着集成方式与版本信息均有官方跟踪记录。前提假设本示例默认以下配置前提请按你的实际环境替换应用根地址Application Root URLhttps://awx.example.com/Authelia 根地址Authelia Root URLhttps://auth.example.com/同时作为 OpenID Connect 1.0 的 IssuerClient IDawxClient Secretinsecure_secret仅演示用生产环境请务必更换官方文档中的example.com、auth等值属于可被文档变量自动替换的占位符实际部署时应替换为你自己的域名。二、配置前须知Before You Begin在动手配置 OpenID Connect 1.0 注册客户端之前有几条贯穿全篇的重要原则源自 oidc-common 公共提示块client_id必须全局唯一每个客户端的 Client ID 都不得与其他客户端重复且只能包含 RFC3986 Unreserved Characters。client_secret强烈建议以哈希形式存储Authelia 支持将密钥以 PBKDF2 哈希的形式写入配置文件明文存储属于已弃用行为。需要注意的是哈希工作因子过高可能引起客户端请求超时可参考 FAQ调整工作因子 进行调优。Authelia 侧配置只是客户端注册片段你必须同时配置 OpenID Connect 1.0 Provider 配置 中的其余强制项如 issuer 相关设置本指南只展示与 AWX 客户端直接相关的部分同时客户端配置文档 中还包含大量本指南未涉及的选项建议一并通读以理解每个配置项的效果。三、Authelia 侧注册 AWX 客户端在 Authelia 的configuration.yml中于identity_providers.oidc.clients列表下新增如下客户端配置identity_providers: oidc: ## OpenID Connect 1.0 Provider 的其他强制配置项在此处填写。 clients: - client_id: awx client_name: Ansible AWX client_secret: $pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng # The digest of insecure_secret. public: false authorization_policy: two_factor require_pkce: false pkce_challenge_method: redirect_uris: - https://awx.example.com/sso/complete/oidc/ scopes: - openid - email - profile response_types: - code grant_types: - authorization_code access_token_signed_response_alg: none userinfo_signed_response_alg: none token_endpoint_auth_method: client_secret_post四、关键配置项逐项解析以下每个配置项均可在 OpenID Connect 1.0 客户端配置参考 中找到权威定义这里结合 AWX 场景逐一说明4.1client_id与client_nameclient_id必填必须与 AWX 侧配置的OIDC Key完全一致本例为awx。它是令牌、授权请求中识别客户端的核心标识。client_name可选显示在 Authelia 用户界面中的友好名称默认与 ID 相同本例设为Ansible AWX便于用户识别。4.2client_secret哈希存储的共享密钥该密钥必须与 AWX 侧配置的OIDC Secret一致。本示例展示的是insecure_secret的 PBKDF2-SHA512 哈希摘要$pbkdf2-sha512$310000$...而非明文这正是文档推荐的存储方式。在客户端认证过程中Authelia 会对收到的密钥进行同参数哈希比对。配置哈希值时需要注意详见 oidc-common 提示若哈希工作因子本示例为310000次迭代过高可能导致客户端在令牌端点认证时超时生产环境应使用足够强度的随机密钥避免使用示例中的insecure_secret。4.3public: false保密客户端类型public的默认值为false即本客户端属于confidential保密客户端见 RFC6749 Section 2.1。这类客户端有能力安全保存凭据因此必须配置client_secret。AWX 是服务端应用能够在服务端安全持有密钥符合保密客户端的定位。4.4authorization_policy: two_factor该选项默认值即为two_factor指定客户端发起授权请求时所需的认证级别可取值one_factor、two_factor或 Provider 级定义的 authorization_policies 策略名称。注意此策略仅作用于授权请求本身与 Authelia 的访问控制规则Access Control Rules是两套独立的机制不应混淆——应用自身的访问控制仍需在 AWX 侧实现。4.5require_pkce与pkce_challenge_methodrequire_pkce: false不强制要求 AWX 使用 PKCE。pkce_challenge_method: 空字符串表示不针对该客户端强制指定挑战方法有效值包括空串、plain与S256其中S256是强烈推荐的取值。由于 AWX 作为保密客户端会携带client_secret在令牌端点完成认证因此本示例未强制启用 PKCE。若你的 AWX 版本支持仍建议开启以进一步缓解授权码拦截风险。4.6redirect_uris回调 URI 列表必须精确包含AWX 的 OIDC 回调地址https://awx.example.com/sso/complete/oidc/关键约束详见 clients.md#redirect_urisURI区分大小写必须与 AWX 实际发起回调时使用的 URI 逐字符一致未列入列表的回调一律视为不安全授权请求会直接失败必须携带http或https协议头。4.7scopes允许该客户端消费的授权范围。AWX 需要以下三个 scopeopenidOpenID Connect 的核心 scope返回sub等身份标识email提供用户邮箱地址profile提供用户名等基本资料。更完整的 scope 定义与可携带的 claims 清单见 OpenID Connect 1.0 集成指南的 Scope 定义章节。4.8response_types与grant_typesresponse_types: [code]仅允许Authorization Code Flow授权码流程。这是官方安全提示中唯一推荐的响应类型其余如token、id_token安全性较低。grant_types: [authorization_code]限定该客户端只能通过授权码授权获取令牌。两者组合意味着 AWX 与 Authelia 之间走标准的前端授权 后端换码流程。4.9access_token_signed_response_alg与userinfo_signed_response_algnone两者均设为none这也是access_token_signed_response_alg与userinfo_signed_response_alg的默认值含义如下Access Token 以不透明opaque字符串形式签发而非签名的 JWT。Authelia 的 Access Token 默认即为此形态资源服务器需通过 Introspection 端点 校验对应路径为https://auth.example.com/api/oidc/introspectionUserInfo 端点https://auth.example.com/api/oidc/userinfo返回纯 JSON 文档application/json而非 JWT 编码响应。该配置与 AWX 的 Generic OIDC 客户端实现相兼容无需额外签名验证。4.10token_endpoint_auth_method: client_secret_post指定 AWX 在令牌端点https://auth.example.com/api/oidc/token出示客户端凭据的方式。可选值包括client_secret_basic默认、client_secret_post、client_secret_jwt、private_key_jwt与none公开客户端默认。AWX 通过HTTP POST 请求体携带client_secret因此选用client_secret_post。五、Ansible AWX 侧Generic OIDC 设置Ansible AWX 目前只有一种配置入口——Web 图形界面Web GUI。操作步骤如下以管理员身份登录 Ansible AWX点击左侧导航栏的Settings设置在设置窗口左侧点击Generic OIDC settings通用 OIDC 设置点击Edit编辑配置以下选项AWX 选项值OIDC KeyawxOIDC Secretinsecure_secretOIDC Provider URLhttps://auth.example.comVerify OIDC Provider Certificate启用Enable点击Save保存。其中OIDC Provider URL指向 Authelia 的根地址AWX 会依据该地址自动拼接发现文档/.well-known/openid-configuration以获取授权、令牌、UserInfo 等端点。Verify OIDC Provider Certificate保持启用可确保 AWX 对 Authelia 服务端证书做校验防止中间人攻击。六、端到端认证流程解析完成两侧配置后用户的登录链路如下对应的端点路径均可在 集成指南的 Endpoint Implementations 章节 查到用户访问https://awx.example.com/AWX 将用户重定向到 Authelia 授权端点https://auth.example.com/api/oidc/authorization携带client_idawx、response_typecode、redirect_urihttps://awx.example.com/sso/complete/oidc/及openid email profile等 scopeAuthelia 根据authorization_policy: two_factor要求用户完成登录含第二因素如 TOTP / WebAuthn认证通过后Authelia 将授权码经https://awx.example.com/sso/complete/oidc/回传给 AWXAWX 在后端向令牌端点https://auth.example.com/api/oidc/token发起换码请求并以client_secret_post方式在 POST 请求体中携带client_secretAuthelia 校验凭据对哈希后的密钥做比对后签发 Access Token 与 ID TokenAWX 通过 UserInfo 端点https://auth.example.com/api/oidc/userinfo或 ID Token 获取用户邮箱、资料等 claims完成本地会话建立。七、安全加固建议结合 oidc-common 提示 与 客户端配置文档建议在生产环境执行以下加固更换密钥使用 Authelia 提供的随机密钥生成工具生成强随机client_secret并以哈希形式写入配置切勿使用insecure_secret避免凭据中的特殊字符部分 OIDC 客户端包括 AWX 在内的众多第三方实现在client_secret_post/client_secret_basic认证前未按 RFC6749 Appendix B 对 Client ID 与 Secret 做 URL 编码。规避特殊字符或预先 URL 编码是最稳妥的做法按需收紧认证策略若 AWX 面向内部高权限运维人员two_factor是合理选择如需更细粒度的用户分组控制可配置 Provider 级的 authorization_policies 并引用到本客户端关注 claim 稳定性AWX 等应用可能使用email等可变 claim 绑定本地账号而 OpenID Connect 规范要求以稳定的sub、issclaim 绑定身份见 OpenID Connect Core 5.7 Claim Stability集成时应了解这一差异并在账号映射上谨慎设计。八、参考资料Ansible AWX / Ansible Tower 集成文档本指南源文档OpenID Connect 1.0 客户端配置参考OpenID Connect 1.0 Provider 配置OpenID Connect 1.0 集成指南OpenID Connect 1.0 常见问题 FAQoidc-common 公共提示块模板Ansible AWX 官方《Setting up Enterprise Authentication》文档中关于 Generic OIDC Settings 的章节AWX 24.6.1/output文章【免费下载链接】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），仅供参考