apisix~authz-keycloak外掛介紹

张占岭發表於2024-05-16
  • 參考: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中包含了資源所需許可權,方可正常訪問

相關文章