
使用 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實現(xiàn)以 Authelia 為身份源的統(tǒng)一認證。你將掌握 Authelia 側(cè)注冊客戶端的 YAML 配置要點、AWX 側(cè) Generic OIDC 設(shè)置的完整操作步驟以及授權(quán)碼流程在client_secret_post認證方式下的底層工作機理可直接照搬到你的實驗或生產(chǎn)環(huán)境。一、適用版本與前提假設(shè)本指南基于以下已實測通過的版本組合對應(yīng)倉庫中的 Ansible AWX 集成文檔組件版本Autheliav4.39.24Ansible AWXv24.6.1本指南屬于Community社區(qū)級別的集成支持文檔中同時標(biāo)注了integration: true與versions: true意味著集成方式與版本信息均有官方跟蹤記錄。前提假設(shè)本示例默認以下配置前提請按你的實際環(huán)境替換應(yīng)用根地址Application Root URLhttps://awx.example.com/Authelia 根地址Authelia Root URLhttps://auth.example.com/同時作為 OpenID Connect 1.0 的 IssuerClient IDawxClient Secretinsecure_secret僅演示用生產(chǎn)環(huán)境請務(wù)必更換官方文檔中的example.com、auth等值屬于可被文檔變量自動替換的占位符實際部署時應(yīng)替換為你自己的域名。二、配置前須知Before You Begin在動手配置 OpenID Connect 1.0 注冊客戶端之前有幾條貫穿全篇的重要原則源自 oidc-common 公共提示塊client_id必須全局唯一每個客戶端的 Client ID 都不得與其他客戶端重復(fù)且只能包含 RFC3986 Unreserved Characters。client_secret強烈建議以哈希形式存儲Authelia 支持將密鑰以 PBKDF2 哈希的形式寫入配置文件明文存儲屬于已棄用行為。需要注意的是哈希工作因子過高可能引起客戶端請求超時可參考 FAQ調(diào)整工作因子 進行調(diào)優(yōu)。Authelia 側(cè)配置只是客戶端注冊片段你必須同時配置 OpenID Connect 1.0 Provider 配置 中的其余強制項如 issuer 相關(guān)設(shè)置本指南只展示與 AWX 客戶端直接相關(guān)的部分同時客戶端配置文檔 中還包含大量本指南未涉及的選項建議一并通讀以理解每個配置項的效果。三、Authelia 側(cè)注冊 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四、關(guān)鍵配置項逐項解析以下每個配置項均可在 OpenID Connect 1.0 客戶端配置參考 中找到權(quán)威定義這里結(jié)合 AWX 場景逐一說明4.1client_id與client_nameclient_id必填必須與 AWX 側(cè)配置的OIDC Key完全一致本例為awx。它是令牌、授權(quán)請求中識別客戶端的核心標(biāo)識。client_name可選顯示在 Authelia 用戶界面中的友好名稱默認與 ID 相同本例設(shè)為Ansible AWX便于用戶識別。4.2client_secret哈希存儲的共享密鑰該密鑰必須與 AWX 側(cè)配置的OIDC Secret一致。本示例展示的是insecure_secret的 PBKDF2-SHA512 哈希摘要$pbkdf2-sha512$310000$...而非明文這正是文檔推薦的存儲方式。在客戶端認證過程中Authelia 會對收到的密鑰進行同參數(shù)哈希比對。配置哈希值時需要注意詳見 oidc-common 提示若哈希工作因子本示例為310000次迭代過高可能導(dǎo)致客戶端在令牌端點認證時超時生產(chǎn)環(huán)境應(yīng)使用足夠強度的隨機密鑰避免使用示例中的insecure_secret。4.3public: false保密客戶端類型public的默認值為false即本客戶端屬于confidential保密客戶端見 RFC6749 Section 2.1。這類客戶端有能力安全保存憑據(jù)因此必須配置client_secret。AWX 是服務(wù)端應(yīng)用能夠在服務(wù)端安全持有密鑰符合保密客戶端的定位。4.4authorization_policy: two_factor該選項默認值即為two_factor指定客戶端發(fā)起授權(quán)請求時所需的認證級別可取值one_factor、two_factor或 Provider 級定義的 authorization_policies 策略名稱。注意此策略僅作用于授權(quán)請求本身與 Authelia 的訪問控制規(guī)則Access Control Rules是兩套獨立的機制不應(yīng)混淆——應(yīng)用自身的訪問控制仍需在 AWX 側(cè)實現(xiàn)。4.5require_pkce與pkce_challenge_methodrequire_pkce: false不強制要求 AWX 使用 PKCE。pkce_challenge_method: 空字符串表示不針對該客戶端強制指定挑戰(zhàn)方法有效值包括空串、plain與S256其中S256是強烈推薦的取值。由于 AWX 作為保密客戶端會攜帶client_secret在令牌端點完成認證因此本示例未強制啟用 PKCE。若你的 AWX 版本支持仍建議開啟以進一步緩解授權(quán)碼攔截風(fēng)險。4.6redirect_uris回調(diào) URI 列表必須精確包含AWX 的 OIDC 回調(diào)地址https://awx.example.com/sso/complete/oidc/關(guān)鍵約束詳見 clients.md#redirect_urisURI區(qū)分大小寫必須與 AWX 實際發(fā)起回調(diào)時使用的 URI 逐字符一致未列入列表的回調(diào)一律視為不安全授權(quán)請求會直接失敗必須攜帶http或https協(xié)議頭。4.7scopes允許該客戶端消費的授權(quán)范圍。AWX 需要以下三個 scopeopenidOpenID Connect 的核心 scope返回sub等身份標(biāo)識email提供用戶郵箱地址profile提供用戶名等基本資料。更完整的 scope 定義與可攜帶的 claims 清單見 OpenID Connect 1.0 集成指南的 Scope 定義章節(jié)。4.8response_types與grant_typesresponse_types: [code]僅允許Authorization Code Flow授權(quán)碼流程。這是官方安全提示中唯一推薦的響應(yīng)類型其余如token、id_token安全性較低。grant_types: [authorization_code]限定該客戶端只能通過授權(quán)碼授權(quán)獲取令牌。兩者組合意味著 AWX 與 Authelia 之間走標(biāo)準(zhǔn)的前端授權(quán) 后端換碼流程。4.9access_token_signed_response_alg與userinfo_signed_response_algnone兩者均設(shè)為none這也是access_token_signed_response_alg與userinfo_signed_response_alg的默認值含義如下Access Token 以不透明opaque字符串形式簽發(fā)而非簽名的 JWT。Authelia 的 Access Token 默認即為此形態(tài)資源服務(wù)器需通過 Introspection 端點 校驗對應(yīng)路徑為https://auth.example.com/api/oidc/introspectionUserInfo 端點https://auth.example.com/api/oidc/userinfo返回純 JSON 文檔application/json而非 JWT 編碼響應(yīng)。該配置與 AWX 的 Generic OIDC 客戶端實現(xiàn)相兼容無需額外簽名驗證。4.10token_endpoint_auth_method: client_secret_post指定 AWX 在令牌端點https://auth.example.com/api/oidc/token出示客戶端憑據(jù)的方式。可選值包括client_secret_basic默認、client_secret_post、client_secret_jwt、private_key_jwt與none公開客戶端默認。AWX 通過HTTP POST 請求體攜帶client_secret因此選用client_secret_post。五、Ansible AWX 側(cè)Generic OIDC 設(shè)置Ansible AWX 目前只有一種配置入口——Web 圖形界面Web GUI。操作步驟如下以管理員身份登錄 Ansible AWX點擊左側(cè)導(dǎo)航欄的Settings設(shè)置在設(shè)置窗口左側(cè)點擊Generic OIDC settings通用 OIDC 設(shè)置點擊Edit編輯配置以下選項AWX 選項值OIDC KeyawxOIDC Secretinsecure_secretOIDC Provider URLhttps://auth.example.comVerify OIDC Provider Certificate啟用Enable點擊Save保存。其中OIDC Provider URL指向 Authelia 的根地址AWX 會依據(jù)該地址自動拼接發(fā)現(xiàn)文檔/.well-known/openid-configuration以獲取授權(quán)、令牌、UserInfo 等端點。Verify OIDC Provider Certificate保持啟用可確保 AWX 對 Authelia 服務(wù)端證書做校驗防止中間人攻擊。六、端到端認證流程解析完成兩側(cè)配置后用戶的登錄鏈路如下對應(yīng)的端點路徑均可在 集成指南的 Endpoint Implementations 章節(jié) 查到用戶訪問https://awx.example.com/AWX 將用戶重定向到 Authelia 授權(quán)端點https://auth.example.com/api/oidc/authorization攜帶client_idawx、response_typecode、redirect_urihttps://awx.example.com/sso/complete/oidc/及openid email profile等 scopeAuthelia 根據(jù)authorization_policy: two_factor要求用戶完成登錄含第二因素如 TOTP / WebAuthn認證通過后Authelia 將授權(quán)碼經(jīng)https://awx.example.com/sso/complete/oidc/回傳給 AWXAWX 在后端向令牌端點https://auth.example.com/api/oidc/token發(fā)起換碼請求并以client_secret_post方式在 POST 請求體中攜帶client_secretAuthelia 校驗憑據(jù)對哈希后的密鑰做比對后簽發(fā) Access Token 與 ID TokenAWX 通過 UserInfo 端點https://auth.example.com/api/oidc/userinfo或 ID Token 獲取用戶郵箱、資料等 claims完成本地會話建立。七、安全加固建議結(jié)合 oidc-common 提示 與 客戶端配置文檔建議在生產(chǎn)環(huán)境執(zhí)行以下加固更換密鑰使用 Authelia 提供的隨機密鑰生成工具生成強隨機client_secret并以哈希形式寫入配置切勿使用insecure_secret避免憑據(jù)中的特殊字符部分 OIDC 客戶端包括 AWX 在內(nèi)的眾多第三方實現(xiàn)在client_secret_post/client_secret_basic認證前未按 RFC6749 Appendix B 對 Client ID 與 Secret 做 URL 編碼。規(guī)避特殊字符或預(yù)先 URL 編碼是最穩(wěn)妥的做法按需收緊認證策略若 AWX 面向內(nèi)部高權(quán)限運維人員two_factor是合理選擇如需更細粒度的用戶分組控制可配置 Provider 級的 authorization_policies 并引用到本客戶端關(guān)注 claim 穩(wěn)定性AWX 等應(yīng)用可能使用email等可變 claim 綁定本地賬號而 OpenID Connect 規(guī)范要求以穩(wěn)定的sub、issclaim 綁定身份見 OpenID Connect Core 5.7 Claim Stability集成時應(yīng)了解這一差異并在賬號映射上謹慎設(shè)計。八、參考資料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》文檔中關(guān)于 Generic OIDC Settings 的章節(jié)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創(chuàng)作聲明:本文部分內(nèi)容由AI輔助生成(AIGC),僅供參考