apisix~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中包含了資源所需權限,方可正常訪問
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章