Keycloak 入门实战(1)--简介

Keycloak 是面向应用和服务的身份认证及访问控制解决方案，本文主要介绍器基本概念。

1、KeyCloak 概述

Keycloak支持细粒度的授权策略，并且能够组合不同的访问控制机制:

  • Attribute-based access control (ABAC): 基于属性的访问控制
  • Role-based access control (RBAC): 基于角色的访问控制
  • User-based access control (UBAC): 基于用户的访问控制
  • Context-based access control (CBAC): 基于上下文的访问控制
  • Rule-based access control: 基于规则的访问控制
    • 使用Javascript
  • Time-based access control: 基于时间的访问控制
  • 通过服务提供接口（SPI）支持自定义访问控制机制（ACMs）

Keycloak 通过管理 UI 和 RESTful API，它提供了必要的方法来为受保护的资源和作用域创建权限，将这些权限与授权策略相关联，并在应用程序和服务中强制实施授权决策。

资源服务器（为受保护资源提供服务的应用程序或服务）通常依赖于某种信息来决定是否应向受保护资源授予访问权限。对于基于 RESTful 的资源服务器，该信息通常从安全令牌中获取；对于依赖会话对用户进行身份验证的 Web 应用程序，该信息通常存储在会话中。

通常，资源服务器会采用基与角色的访问控制策略。当用户试图访问受保护资源时，服务器会检查用户的角色是否允许访问请求的资源。但是这一策略有一些缺点：

  • 资源和角色紧密耦合，对角色的更改（如添加、删除或更改访问上下文）可能会影响多个资源

  • 安全要求变化时可能需要大量修改代码

  • 如果应用程序较大，角色管理可能会变得困难且容易出错

  • 它不是最灵活的访问控制机制。角色不能代表你是谁，并且缺乏上下文信息。如果您被授予了某个角色，则您至少具有一定的访问权限。

考虑到多种多样的场景，用户散布在不用的地区，每个地区都有各自的政策，用户使用不同的设备，并有较高的信息共享的需求。keycloak的服务授权通过以下方法可以帮助我们提升授权的能力：

  • 使用细粒度的授权策略和不同的访问控制机制进行资源保护

  • 集中的资源、权限和策略管理

  • 集中式策略决策点

  • REST 的安全基于一组 REST 的授权服务

  • 授权工作流和用户管理访问

  • 可避免跨项目（和重新部署）的代码复制，并快速适应安全要求的变化

2、KeyCloak 架构

 

 从设计角度来看，授权服务基于一组明确定义的授权模式，可提供以下功能：

  • Policy Administration Point (PAP)--策略管理点

    提供一组基于 Keycloak 管理控制台的 UI，用于管理资源服务器、资源、作用域、权限和策略。其中一部分也是通过使用保护 API 远程完成的。

  • Policy Decision Point (PDP)--策略决策点

    提供可分发的策略决策点，指向何处发送授权请求，并根据所请求的权限相应地评估策略。

  • Policy Enforcement Point (PEP)--策略实施点

    为不同环境提供实现，以便在资源服务器端实施授权决策。Keycloak 提供了一些内置的策略执行器。

  • Policy Information Point (PIP)--策略信息点

    基于 Keycloak 身份验证服务器，您可以在评估授权策略期间从身份和运行时环境中获取属性。

3、KeyCloak 核心概念

users：系统用户。
authentication：认证。
authorization：授权。
credentials：Keycloak 用来验证用户身份的凭证。例如密码、一次性密码、数字证书甚至指纹。
roles：角色，管理员、用户、经理和员工都是组织中可能存在的典型角色。应用程序通常将访问和权限分配给特定的角色，而不是单个用户，因为与用户打交道可能过于细粒度且难以管理。
user role mapping：角色和用户之间的映射。用户可以与零个或多个角色关联。
composite roles：组合角色，与其他角色相关联的角色。例如，superuser组合角色与sales-admin和order-entry-admin角色相关联。如果一个用户被映射到superuser角色，那么他们也会继承sales-admin和order-entry-admin角色。
groups：组，可以为一个组定义属性，您也可以将角色映射到一个组，成为组成员的用户继承该组定义的属性和角色映射。
realms：域管理一组用户、凭据、角色和组。用户属于并登录到一个域。域彼此隔离，并且只能管理和验证它们所控制的用户。
clients：客户端是可以请求keycloak对用户进行身份验证的实体。通常，客户端是希望使用Keycloak来保护自己并提供单点登录解决方案的应用程序和服务。客户端还可以是只想请求身份信息或访问令牌的实体，以便安全地调用由Keycloak保护的网络上的其他服务。
client adapters：客户端适配器是一种插件，您可以将其安装到应用程序环境中，以便能够进行通信并通过Keycloak进行保护。Keycloak有许多针对不同平台的适配器可以下载。您还可以获取第三方适配器，应用到我们这里没有提到到的环境中。
consent：同意是指作为管理员，您希望用户在客户端可以参与身份验证过程之前向该客户端提供权限。在用户提供了他们的凭证之后，Keycloak将弹出一个屏幕，识别请求登录的客户端以及用户需要的身份信息。用户可以决定是否授权请求。
client scopes：客户端注册以后，必须为该客户端定义协议映射器和角色范围映射。存储客户端作用域通常很有用，通过共享一些公共设置来简化创建新客户端。这对于根据scope参数的值有条件地请求一些声明或角色也很有用。Keycloak提供了一个客户端作用域的概念。
client role：客户端可以定义特定于他们的角色。这基本上是一个客户端专有的角色命名空间。
identity token：提供有关用户身份信息的令牌，是OpenID Connect规范的一部分。
access token：提供允许调用服务的令牌。是OpenID Connect 和 OAuth 2.0规范的一部分。
assertion：关于用户的信息。这通常与SAML身份验证响应中包含的XML blob有关，SAML身份验证响应提供经过身份验证的用户身份元数据。
service account：每个客户端都有一个内置的服务帐户，允许它获得访问令牌。
direct grant：客户端通过REST方式获取用户访问令牌。
protocol mappers：协议映射器，确定客户端使用的协议。
session：会话包含诸如用户何时登录以及在会话期间中有哪些应用程序参与单点登录等信息。管理员和用户都可以查看会话信息。
user federation provider：keycloak可以存储和管理用户。通常，公司已经拥有存储用户和凭据信息的LDAP或Active Directory服务。您可以使用Keycloak来验证这些外部存储的凭证，并获取身份信息。
identity provider：身份提供者(IDP)是一种可以对用户进行身份验证的服务。在这里，keycloak就是身份验证者。
identity provider federation：可以将keycloak配置为将身份验证委托给一个或多个IDP。通过Facebook或谷歌+进行社交登录是身份提供者联合的一个例子。Keycloak可以将身份验证委托给任何其他OpenID Connect或SAML 2.0 IDP。
identity provider mappers：在进行联合身份验证时，可以将传入的令牌和断言映射到用户和会话属性。这有助于您将身份信息从外部IDP传播到请求身份验证的客户端。
required actions：必需的操作是用户在身份验证过程中必须执行的操作。在这些操作完成之前，用户将无法完成身份验证过程。例如，管理员可以安排用户每月重置密码。将为所有这些用户设置一个更新密码必需的操作。
authentication flows：身份验证流是用户在与系统的某些方面进行交互时必须执行的工作流。登录流可以定义所需的凭据类型。注册流定义用户必须输入什么配置文件信息，以及是否必须使用诸如reCAPTCHA之类的东西来过滤机器人。凭据重置流定义了用户在重置密码之前必须执行的操作。
events：事件，管理员可以查看事件信息。
themes：主题，Keycloak提供默认主题，可以自定义主题。

4、Keycloak 部署模式

4.1、standalone mode--独立模式

独立操作模式仅在您希望运行一个且只有一个 Keycloak 服务器实例时才有用。它不能用于群集部署，并且所有缓存都是非分布式的，并且仅本地缓存。不建议在生产中使用独立模式，因为您将遇到单点故障。如果您的独立模式服务器出现故障，用户将无法登录。此模式实际上仅对试用 Keycloak 的功能有用。

此模式对应的配置文件为：standalone/configuration/standalone.xml，对应的启动脚本为：bin/standalone.sh。

4.2、standalone clustered mode--独立集群模式

此模式要求您在要运行服务器实例的每台计算机上都有 Keycloak 分发的副本。此模式最初可能非常容易部署，但可能会变得非常麻烦。若要进行配置更改，请修改每台计算机上的每个分发。对于大型群集，此模式可能变得耗时且容易出错。

此模式对应的配置文件为：standalone/configuration/standalone-ha.xml，对应的启动脚本为：bin/standalone.sh。

4.3、domain clustered mode--域集群模式

域模式是一种集中管理和发布服务器配置的方法。

在标准模式下运行群集可能会随着群集大小的增长而迅速恶化。每次需要进行配置更改时，都要在群集中的每个节点上执行该更改。域模式通过提供用于存储和发布配置的中心位置来解决此问题。设置起来可能相当复杂，但最终是值得的。此功能内置于Keycloak派生自的WildFly应用程序服务器中。

下面是域模式的一些基本概念：

process controller--进程控制器

控制其他进程的进程。

domain controller--域控制器

域控制器是一个进程，负责存储、管理和发布群集中每个节点的常规配置。它是群集中节点获取其配置的中心点。

host controller--主机控制器

主机控制器负责管理特定计算机上的服务器实例。将其配置为运行一个或多个服务器实例。域控制器还可以与每台计算机上的主控制器交互以管理群集。为了减少正在运行的进程的数量，域控制器还充当其运行在其上的计算机上的主机控制器。

domain profile--域配置

域配置是一组命名的配置信息，服务器可以使用它从中进行引导。域控制器可以定义由不同服务器使用的多个域配置。

server group--服务器组

服务器组是服务器的集合。它们作为一个整体进行管理和配置。您可以将域配置文件分配给服务器组，该组中的每个服务都将使用该域配置文件作为其配置。

此模式对应的配置文件为：domain/configuration/domain.xml、domain/configuration/host-master.xml、domain/configuration/host-slave.xml，对应的启动脚本为：bin/domain.sh。

4.4、cross-site replication mode--跨站点复制模式

使用跨站点复制模式在多个数据中心的群集中运行 Keycloak；通常使用的是位于不同地理区域的数据中心站点。使用此模式时，每个数据中心将拥有自己的 Keycloak 服务器集群。

目前跨站点复制模式为技术预览版，还不完全支持。

posted @ 2022-03-26 15:39  且行且码  阅读(2572)  评论(0)  编辑  收藏  举报