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中包含了资源所需权限,方可正常访问