在Keycloak中实现授权，首先需要了解与授权相关的一些概念。授权，简单地说就是某个（些）用户或者某个（些）用户组（Policy），是否具有对某个资源（Resource）具有某种操作（Scope）的权限（Permission）。所以，授权是一种权限管理，它建立在认证的基础上：用户首先要完成认证（Authentication），才能谈授权（Authorization）。在讨论认证与授权的文章或论坛里，往往用Authn代表认证（Authentication），而用Authz代表授权（Authorization）。
1. Keycloak中的授权模型
- 在上面这段描述中，我已经将几个重要的概念用黑体字标注了。或许会有这样的疑问：用户/用户组不应该是User/Group吗？在谈授权的时候，至少也应该是角色（Role）吧，比如我们熟悉的基于角色的访问控制（RBAC），里面就是角色，怎么会是策略（Policy）呢？在回答这个问题前，还是先看一下Keycloak中的授权模型：
这个模型中，包含了几个重要的概念：
- 资源（Resource）：资源是应用程序中能够被访问的对象。假设有个有关天气预报的API，它的URL是http://localhost:5678/WeatherForecast，那么，在这台资源服务器上，URI
/WeatherForecast就是一个资源的地址，它表示一个跟天气预报相关的API端点资源 - 操作（Scope）：其实Scope并不翻译为“操作”，这里我使用“操作”来表示Scope，是因为在授权的场景中，Scope就是定义针对资源的一些“操作”。比如：对于上面的天气预报API资源，我们可以有获取资源的操作，也可以有更新资源的操作（比如，让气象员根据其它科学数据来调整某地的天气预报）。于是，在定义Scope的时候，可以用“weather.read”、“weather.update”这样的名字来命名
对于某个资源，它可以声明自己所需要的操作，例如，在RESTful
API中，/WeatherForecast这个API可以有读取（read/HTTP GET）的操作，也可以有更新（update/HTTP
PATCH）的操作，那么，就可以在这个API资源上声明weather.read和weather.update这两个Scope
一个用户组（Group）可以包含多个子组，一个组下可以有多个用户（User），一个用户又可以属于多个用户组。对于一个用户或者一个组而言，它可以扮演多种角色（Role），而一个角色又可以被赋予多个用户或者多个用户组，这些都是耳熟能详的RBAC授权的基本概念，就不多说明了 - 策略（Policy）可以理解为满足某种条件的资源访问者（可以是用户或用户组），所以，Policy定义的是条件：角色就是一种条件，表示“被赋予某种角色”的条件。基于角色的策略实现的访问控制，就是RBAC。当然条件不仅仅只有角色，用户满足某个条件也可以成为一种策略，比如要求某个用户年龄大于18岁。除此之外，策略是可以被聚合的，聚合策略的投票结果（允许还是拒绝），取决于被聚合的策略以及投票的方式（是所有被聚合策略都允许，结果才被允许，还是只要有一个投票为“允许”，整个聚合策略的结果就是“允许”），比如要求用户是年龄大于18岁（User
Policy）的系统管理员（Role
Policy）。上图中只简单列了几个继承于Policy的子类用以示意，Keycloak所支持的策略类型不止这些 - 权限（Permission）是资源（Resource）或者操作（Scope）与策略（Policy）之间的关联关系。在Keycloak中，权限分为两种：基于资源的权限和基于操作的权限。表达的语义是：符合某些策略的访问者对指定的资源或者操作可以访问
理解了这些概念后，在Keycloak中实现授权并不困难。
本文是转载的，原文链接 https://www.cnblogs.com/daxnet/p/18132246
