- 參考：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中包含了資源所需許可權，方可正常訪問