Keycloak中授权的实现-转载

在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