apisix~authz-keycloak外掛介紹

张占岭發表於2024-05-16
API
  • 參考：https://apisix.apache.org/docs/apisix/plugins/authz-keycloak/

kc外掛原始碼梳理及原理說明

如果只是進行keycloak頒發的token進行校驗（簽名校驗和有效期校驗），那麼我們可以使用jwt-auth這個外掛實現，並且已經對這個外掛進行二次開發，支援jwt內容解析與向下請求頭的傳遞。

作用

主要用到keycloak提供的uma遠端資源授權上面，它對於直接在keycloak後臺配置上游服務的資源許可權，進行代理，不需要上游服務再去直接對接keycloak。

原理

在lua外掛中，實現了與 keycloak服務端的通訊，你可以把這個外掛當成是keycloak的一個客戶端代理，這個客戶端是在keycloak上提前註冊的，它對應一個或者多個應用，應用下面有很多api資源，這些資源可以透過keycloak的uma進行管理。

外掛配置參考

{
  "client_id": "pkulaw",
  "client_secret": "c0b7ab8e-485b-4a10-bff8-7c7d3f472096",
  "discovery": "https://testcas.xxx.com/auth/realms/xx/.well-known/openid-configuration",
  "permissions": [
    "Default Resource"
  ],
  "realm": "fabao",
  "ssl_verify": false,
  "token_endpoint": "https://testcas.xxx.com/auth/realms/xx/protocol/openid-connect/token"
}
  • client_id kc上的客戶端ID
  • client_secret 客戶端的金鑰，本外掛不支援public型別的客戶端
  • discovery kc的開發介面地址，包含認證地址，登出地址，重新整理token地址，公鑰地址等
  • permissions 一組資源，提前在kc的pkulaw這個客戶端上建立的資源，它是一組路由地址
  • realm kc上對應的域，相當於租戶，它下面的組，使用者，客戶端，角色都是隔離的
  • ssl_verify 是否開啟ssl證書驗證，如果是自簽名請關閉本項
  • token_endpoint kc的認證的地址

外掛原始碼功能點

  • 獲取header中的Authorization
  • 判斷是否需要密碼認證方式，如果需要會向kc發起登入請求
  • 獲取jwt_token，從Authorization中擷取Bearer 後面的部分
  • 如果沒有傳token，直接返回401
  • 解析kc中這個客戶端的資源列表，如果配置的資源不存在，直接400
  • 驗證token的有效性，這塊為線上校驗，token無效或者登入出，返回401
  • 評估對配置的permisssion資源是否有許可權，如無許可權，返回403
  • token中包含了資源所需許可權，方可正常訪問

相關文章