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中包含了資源所需權限,方可正常訪問