apisix~authz-keycloak插件先容

• 参考：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进行管理。
插件设置参考

1. {
2.   "client_id": "pkulaw",
3.   "client_secret": "c0b7ab8e-485b-4a10-bff8-7c7d3f472096",
4.   "discovery": "https://testcas.xxx.com/auth/realms/xx/.well-known/openid-configuration",
5.   "permissions": [
6.     "Default Resource"
7.   ],
8.   "realm": "fabao",
9.   "ssl_verify": false,
10.   "token_endpoint": "https://testcas.xxx.com/auth/realms/xx/protocol/openid-connect/token"
11. }

复制代码

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。