小编点评

**Keycloak Authz Keycloak Plugin** **原理** 该插件使用 Lua 插件实现了与 Keycloak 服务端的通信。它可以将其视为一个客户端代理，在 Keycloak 上注册的客户端上运行。客户端可以请求资源，并由 Keycloak 进行授权验证和资源管理。 **配置** 插件的配置包含以下关键属性： * **client_id：**授权请求的客户端 ID。 * **client_secret：**客户端密钥。 * **discovery：**用于获取资源配置的 Discovery 接口。 * **permissions：**授权请求所需的所有资源权限。 * **realm：**授权请求的 Realm。 * **ssl_verify：**是否开启 SSL 证书验证。 * **token_endpoint：**用于获取 JWT 的 token endpoint。 **功能** 当用户请求资源时，插件将检查其凭据是否包含所有所需的权限。如果权限验证成功，插件将创建 JWT token 并将其传递给资源请求。如果权限验证失败，插件将返回 401 错误响应。 **示例配置** ```json { "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" } ``` **注意** 该插件仅用于对 Keycloak 提供的授权请求进行验证。它不支持对直接在 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进行管理。

插件配置参考

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