什么是IAM

IAM（Identity and Access Management）是管理和控制用户身份信息及访问权限的系统，确保安全的数字访问。它包括身份管理、访问控制和用户认证，常用模型有RBAC和ABAC。

IAM的定义，英文名称：Identity and Access Management，中文译为身份和访问控制管理。
IAM只做两件事：
1、身份证明和确认。
2、授予权限以访问资源。

IAM的核心安全管理主线是为了保证正确的身份在正确的授权前提下访问正确的企业系统或资源。

Keycloak是一种面向现代应用和服务的开源IAM（身份识别与访问管理）解决方案。Keycloak 支持多种协议和认证方式，能够快速集成到不同的技术栈中。如果基于角色的授权无法满足您的需求，Keycloak 也提供细粒度的授权服务。这使您可以从 Keycloak 管理控制台管理所有服务的权限，并让您有权准确定义所需的策略。

什么是keycloak

Keycloak 是一个云原生计算基金会孵化项目
官方网址：https://keycloak.java.net.cn/

Keycloak is an open-source identity and access management. It adds authentication to applications and secures services with minimum effort. Also, it provides user federation, strong authentication, user management, fine-grained authorization, and more.
Keycloak 是一种开源身份和访问管理。它为应用程序添加了身份验证，并以最少的工作量保护服务。此外，它还提供用户联合、强身份验证、用户管理、精细授权等。

Keycloak提供了单点登录（SSO）功能，支持OpenID Connect、OAuth 2.0、SAML 2.0标准协议，拥有简单易用的管理控制台，并提供对LDAP、Active Directory以及Github、Google等社交账号登录的支持，做到了非常简单的开箱即用。

Keycloak部署及接入简单，轻量的同时功能又不失强大，非常适合企业内部的SSO方案。

登录及身份认证是现代web应用最基本的功能之一，对于企业内部的系统，多个系统往往希望有一套SSO服务对企业用户的登录及身份认证进行统一的管理，提升用户同时使用多个系统的体验，Keycloak正是为此种场景而生。

Keycloak 的功能

1. 单点登录（SSO）

   • 用户登录一次后，即可访问所有已配置的应用，无需再次登录。
   • 支持标准协议（OIDC、OAuth2.0、SAML）实现互通。

2. 用户管理

   • 提供用户注册、账号激活、密码恢复等功能。
   • 用户可以通过 Keycloak 提供的 UI 自助修改个人信息。

3. 身份认证与授权

   • 支持多种认证机制（用户名/密码、OTP、社交登录等）。
   • 提供基于角色和属性的精细化权限控制。

4. 多租户支持

   • 通过 Realm 隔离不同的租户，每个 Realm 拥有独立的配置。

5. 集成支持

   • 内置适配器和 API，可以方便地集成到 Java、Node.js、Spring 等应用中。

核心概念

4个最常用的核心概念：

1. Users: 用户，使用并需要登录系统的对象
2. Roles: 角色，用来对用户的权限进行管理
3. Clients: 客户端，需要接入Keycloak并被Keycloak保护的应用和服务
4. Realms: 领域，领域管理着一批用户、证书、角色、组等，一个用户只能属于并且能登陆到一个域，域之间是互相独立隔离的， 一个域只能管理它下面所属的用户

client

官方文档: https://www.keycloak.org/docs/latest/server_admin/index.html#assembly-managing-clients_server_administration_guide

在 Keycloak 中，Clients 指的是需要与 Keycloak 进行交互的应用程序或服务。它们可能是 Web 应用、移动应用、API 服务或其他需要用户身份验证的系统。

Clients 具有发起用户身份验证流程的能力。也就是说，当用户尝试访问某个受保护的资源时，相关的 Client 会与 Keycloak 进行通信，验证用户的身份。

客户有两种形式。 第一种类型的客户端是希望 以参与单点登录。 这些客户端只是希望 Keycloak 为他们提供安全性。 另一种类型 client 是请求访问令牌的客户端，以便它可以代表经过身份验证的用户调用其他服务。

管理 OpenID Connect 客户端

OpenID Connect 是保护应用程序的推荐协议。 它是从头开始设计的，对 Web 友好，最适合与 HTML5/JavaScript 应用程序配合使用。

• Client ID
  此 ID 是一个字母数字字符串，用于 OIDC 请求和 Keycloak 数据库，用于标识客户端。

多种身份验证流程

1. Standard Flow

• 定义：
  标准流程是最常用的 OAuth 2.0 和 OpenID Connect（OIDC）认证流程，通常用于 Web 应用程序。
• 工作原理：
  用户在客户端应用中访问受保护的资源时，客户端将用户重定向到 Keycloak 登录页面。
  用户输入凭据（如用户名和密码），Keycloak 进行身份验证。
  验证成功后，用户将被重定向回客户端，并附带一个授权码。
  客户端使用此授权码向 Keycloak 请求访问令牌和 ID 令牌。
• 优势：
  适用于需要用户交互的场景，具有较高的安全性。

2. Direct Access Grants

• 定义：
  直接访问授权流程允许用户直接使用用户名和密码进行身份验证。
• 工作原理：
  客户端发送用户凭据（用户名和密码）到 Keycloak 的 Token Endpoint。
  如果凭据有效，Keycloak 会返回访问令牌和刷新令牌。
• 优势：
  适用于需要快速验证用户的场景，但不适合所有类型的应用，特别是不能暴露用户凭据的情况，如公共客户端。

3. Implicit Flow

• 定义：
  隐式流程主要用于单页应用（SPA），不涉及后端服务器。
• 工作原理：
  当用户访问客户端应用时，应用会直接使用 OAuth 2.0 流程请求访问和 ID 令牌。
  用户在 Keycloak 登录并授权后，Token 被直接返回给浏览器的 URL。
• 优势：
  允许快速获取访问令牌，适合对用户而言交互简单且不需要用户秘密信息的应用。

4. Service Accounts Roles

• 定义：
  服务账户角色用于允许非交互式的服务端应用程序（如微服务）进行身份验证。
• 工作原理：
  客户端可以使用客户端凭证（客户端 ID 和客户端秘密）请求访问令牌，而不需要用户输入凭证。
• 优势：
  适合需要后台服务之间进行安全通信的场景，能够安全地访问受保护的资源。

5. OAuth 2.0 Device Authorization Grant

• 定义：
  设备授权流程允许在设备上进行用户身份验证，而该设备缺乏输入能力（如智能电视、IoT 设备）。
• 工作原理：
  设备首先向授权服务器请求一个设备代码和用户代码。用户通过另一台设备（如手机或计算机）访问授权 URL，并输入用户代码来授权设备访问。
• 优势：
  适合无法直接访问传统输入方式的设备，提供了一种用户友好的身份验证方法。

6. OIDC CIBA Grant (Client Initiated Backchannel Authentication)

• 定义：
  OIDC CIBA 允许应用程序在不直接交互的情况下向用户请求进行身份验证。
• 工作原理：
  客户端初始化一个身份验证请求，可能在用户完全不操作的情况下，Keycloak 将通过电子邮件或短信与用户进行互动，完成身份验证后通知客户端。
• 优势：
  提供了一种灵活的身份验证方法，适用于需要非交互式身份验证和用户身份确认的场景。

通过合理选择身份验证流程，可以有效保障用户信息安全，提升应用的使用体验。

Login Settings

• Root URL：
  Root URL 是一个基础 URL，用于构造相对 URL。当客户端应用程序向 Keycloak 发送请求时，Root URL 会作为这些请求的起始点。
  在用户进行身份验证或访问其他 Keycloak 提供的服务时，如果客户端配置了 Root URL，Keycloak 会将这个 Root URL 作为基准，将相对 URL 连接到此基础 URL 之后。

• Home URL：
  Home URL 是一个用于重定向用户的地址，通常指向客户端应用的主页或欢迎页面。这个 URL 则可以是用户在成功登录或注销后被引导到的位置。

• Valid Redirect URIs：
  这是一个或多个有效的 URI 模式，指定身份验证服务器（如 Keycloak）在用户成功登录后可以将用户重定向到的地址。这些地址是安全的，确保只有预先定义的 URI 能够接收身份验证结果，增强了系统的安全性。
  定义了哪些 URL 是合法和被允许的，这样可以防止攻击者通过恶意重定向来窃取身份验证信息。
  假设您有一个应用程序，其Home URL 为 http://example.com/home，您希望在用户成功登录后将他们重定向到该页面。您可以在 Valid Redirect URIs 设置中配置如下：
  配置:
  http://example.com/home
  http://example.com/* （允许重定向到该域下的任意页面）

• Valid Post Logout Redirect URIs
  Valid Post Logout Redirect URIs 是 Keycloak 中确保用户在注销后返回到合法、受信任的页面的配置。合理配置这些 URI 模式可以显著提高用户体验，并提供额外的安全保障，防止用户在注销后被重定向到不安全或恶意的网站。

• Web Origins
  在 Keycloak 的客户端配置中，Web Origins 是一个用于指定允许跨源资源共享（CORS）的源列表。

Login theme（登录主题）：

• Consent required（需要同意）：
  这是一个开关选项，当前设置为“开启”（On）。这意味着用户在登录时必须明确同意某些条款或条件，才能继续使用应用程序。

• Display client on screen（在屏幕上显示客户端）：
  另一个开关选项，当前也设置为“开启”（On）。这表示在同意屏幕上将显示客户端的名称或相关信息，帮助用户了解他们正在授权的应用程序。

• Consent screen text（同意屏幕文本）：
  这是一个文本框，用户可以在此输入自定义的同意文本。如果未填写，则默认使用客户端范围的名称。这个文本将显示在用户同意屏幕上，帮助用户理解他们同意的内容。

Client Scope

官方文档https://www.keycloak.org/docs/latest/server_admin/index.html#_client_scopes

Keycloak 的 Client Scope 是一个重要的概念，用于管理和配置客户端（Client，即应用程序）与用户（用户凭据、角色、属性等）之间的交互。

Client Scope 是一组授权的请求，它定义了客户端在与 Keycloak 进行交互时所需的用户信息和权限。例如，您可以创建一个 Client Scope，以便用户在登录时只获取其电子邮件地址和角色，这样可以精简传输的信息。

在用户进行身份验证时，Keycloak 会根据与客户端关联的 Client Scope 来确定返回哪些信息。

您可以为每个客户端指定一个默认的 Client Scope，也可以为每个用户分配特定的 Client Scope，以覆盖默认设置。

• Type
  Type 配置决定了在授予访问权限时，用户是否必须同意或可以选择性地给予同意。下面是有关 None、Optional 和 Default 三个值的详细含义：

1. None
   含义：选择该选项表示该 Client Scope 不需要用户的同意。也就是说，当用户通过认证流程时，不会显示与此 Client Scope 相关的同意屏幕。
   使用场景：适合那些不需要用户明确同意的 Client Scope。例如，某些基本信息可能被视为默许授权，系统可以直接获取。

2. Optional
   含义：选择该选项表示该 Client Scope 是可选的。用户在登录时可以选择是否同意提供相关信息。这将触发同意屏幕，让用户选择是否授予这个 Client Scope 的权限。
   使用场景：适合那些不影响用户基本功能但提供额外服务的 Client Scope。例如，应用程序可能询问用户是否希望共享某些额外信息（如兴趣爱好）以获得更个性化的服务。

3. Default
   含义：选择该选项表示该 Client Scope 是默认的，并且在认证过程中强制要求用户同意。用户必须明确授予访问权限，这将显示一个同意屏幕，强制用户确认允许访问该 Client Scope 所代表的信息。
   使用场景：适合那些敏感信息或关键权限的 Client Scope。例如，访问用户的电子邮件、角色或财务信息等，这些通常需要用户的明确同意以遵守隐私保护法规（如 GDPR）。

• Protocol（协议）
  指的是用于客户端和身份提供者（Identity Provider, IdP）之间通信的规则和标准。它定义了如何安全地交换身份验证信息和访问令牌，以便应用程序能够验证用户的身份并进行授权。
  协议规定了用户如何通过身份提供者进行身份验证。例如，用户可能首先被重定向到 IdP 的登录页面，然后输入凭据。成功后，IdP 将用户重定向回应用程序并发送一个包含用户身份的信息（如访问令牌、ID 令牌等）的请求。
  协议还定义了在身份验证和授权过程中使用的数据格式。这可能包括 JSON Web Tokens (JWTs)、OAuth 2.0 令牌等。

• “Consent screen text”
  是 Keycloak 中与用户同意界面相关的一项配置。这个选项的含义是，在用户审批其个人信息访问权限时，您可以为特定的 Client Scope（客户端范围）提供自定义文本，以便在同意屏幕上向用户说明该 Client Scope 所代表的内容和目的。
  “Consent screen text” 配置选项为开发者提供了一种在用户同意其个人信息访问时增强透明度和理解的方式。通过正确设置此文本，您可以确保用户在处理个人数据时感到安全和知情，从而提升用户体验和合规性。
  ${emailScopeConsentText} 的做法是一种动态配置的方式，通常用于在不同环境或根据不同上下文动态获取和显示文本信息。

• Include in token scope
  “Include in token scope” 选项的配置用于控制指定的 Client Scope（客户端范围）是否应该包含在生成的访问令牌（Access Token）中

realm role

官方文档：https://www.keycloak.org/docs/latest/server_admin/index.html#assigning-permissions-using-roles-and-groups

角色通常适用于一种类型的用户。例如，组织可以包括admin，user，manager和employee角色。应用程序可以将访问和权限分配给角色，然后将多个用户分配给该角色，以便用户具有相同的访问和权限。

Assigning role mappings分配角色映射

您可以通过为该用户的角色映射选项卡为用户分配角色映射。

1. Click Users in the menu.
   在菜单中单击用户。

2. Click the user that you want to perform a role mapping on.
   单击要执行角色映射的用户。

3. Click the Role mappings tab.
   单击角色映射选项卡。

4. Click Assign role.
   单击分配角色。

5. Select the role you want to assign to the user from the dialog.
   从对话框中选择要分配给用户的角色。

6. Click Assign.单击分配。
   

Using default roles使用默认角色

1. Click Realm settings in the menu.
   单击菜单中的 REALM设置。

2. Click the User registration tab.
   单击用户注册选项卡。

Role scope mappings角色范围映射

By default, each client gets all the role mappings of the user. You can view the role mappings for a client.
默认情况下，每个客户端获取用户的所有角色映射。 您可以查看客户的角色映射。

Users

官方文档：https://www.keycloak.org/docs/latest/server_admin/index.html#assembly-managing-users_server_administration_guide

您可以在您希望这些用户所需的应用程序所在的领域中创建用户。避免在 master 领域中创建用户，因为 master 领域仅用于创建其他领域。

• Required User Actions：
  这是一个配置选项，用于指定用户在登录时必须执行的特定操作。每当用户成功登录后，系统将强制要求他们完成这些操作，以确保用户的安全性和信息的最新性。

Groups

官方文档：https://www.keycloak.org/docs/latest/server_admin/index.html#proc-managing-groups_server_administration_guide

Keycloak 中的组为每个用户管理一组通用的属性和角色映射。用户可以是任意数量的组的成员，并继承分配给每个组的属性和角色映射。

在 Keycloak 中，一个 Group 是一组用户的集合，这些用户可以共享特定的属性和角色映射。这种设计使得用户管理变得更加简便和一致。

组是分层的。一个组可以有多个子组，但一个组只能有一个父组。子组从其父组继承属性和角色映射。用户也从其父级继承属性和角色映射。

如果您有一个父组和一个子组，并且有一个用户只属于该子组，则该子组中的用户将继承父组和子组的属性和角色映射。

组的层次结构有时使用组路径表示。路径是表示特定组层次结构的名称的完整列表，从上到下，用斜杠 / 分隔（类似于文件系统中的文件）。例如，路径可以是 /top/level1/level2，这意味着 top 是顶级组，并且是 level1 的父级，而 level1 又是 level2 的父级。此路径明确表示组 level2 的层次结构。

由于历史原因，Keycloak 不会转义组名本身的斜杠。
例如，如果有一个组名为 level1/group，它在层级结构中被表示为路径 /top/level1/group。这种表示方式可能会让人误解，因为它看起来像是一个层级结构，而实际上 level1/group 是一个完整的组名。

为了避免这种误导，Keycloak 提供了一个启动选项 --spi-group-jpa-escape-slashes-in-group-path，可以将其设置为 true。启用此选项后，组名中的斜杠会被转义为 ~ 字符。

在启用转义后，原本的路径 /top/level1/group 会变为 /top/level1~/group。这里的 ~ 表示斜杠是组名的一部分，而不是层级结构的分隔符。

bin/kc.[sh|bat] start --spi-group-jpa-escape-slashes-in-group-path=true

sessions

官方文档：https://www.keycloak.org/docs/latest/server_admin/index.html#managing-user-sessions

当用户登录到领域时，Keycloak 会为每个用户维护一个用户会话，并记住用户在会话中访问的每个客户端。Realm 管理员可以对每个用户会话执行多项作：

View login statistics for the realm.
查看领域的登录统计信息。

View active users and where they logged in.
查看活动用户及其登录位置。

Log a user out of their session.
将用户从其会话中注销。

Revoke tokens.撤销令牌。

Set up token timeouts.
设置令牌超时。

Set up session timeouts.
设置会话超时。

Events

官方文档：https://www.keycloak.org/docs/latest/server_admin/index.html#configuring-auditing-to-track-events

在 Keycloak 中，使用 Events 功能的场景主要涉及安全监控、用户行为分析和审计合规等多个方面。

KeyCloak还包括一个侦听器SPI，该SPI聆听事件并可以触发操作。内置侦听器的示例包括日志文件和如果发生事件，则发送电子邮件。

您可以记录并查看影响用户的每个事件。 KeyCloak触发了登录事件，例如成功的用户登录，输入不正确密码或用户帐户更新的操作。默认情况下，KeyCloak不会在管理员控制台中存储或显示事件。仅将错误事件记录到管理控制台和服务器的日志文件。

• Save events（保存事件）
  这个配置的含义是：如果启用此选项，用户事件将被保存到数据库中，这样管理员和账户管理用户界面（UIs）就可以访问和查看这些事件记录。

Keycloak Policy

Policy 是访问控制的核心组成部分，决定了哪些用户可以访问哪些资源。它们可以基于用户的角色、属性、环境条件等进行定义。

策略可以根据业务需求进行自定义，支持复杂的访问控制场景。

Keycloak的权限控制通过所谓的PEP（Policy Enforcement Point）即：策略执行点来操作。

创建策略:

登录到 Keycloak 管理控制台。
选择相应的客户端或资源。
在“授权”部分中，创建新的策略，选择策略类型并配置相关条件。

在 Keycloak 中，默认配置的“Default Policy”通常是一个预定义的策略，用于控制用户对资源的访问。

这是 Keycloak 中的一个默认策略，通常在创建新的客户端或资源时自动生成。
该策略的目的是提供一个基本的访问控制机制，确保只有符合特定条件的用户才能访问资源。

Decision strategy (决策策略):

Unanimous: 这是决策策略的选择，表示所有相关策略必须一致同意才能授予访问权限。其他选项包括“Affirmative”（只要有一个策略同意即可）和“Consensus”（大多数策略同意即可）。

资源类型是指在访问控制和权限管理中定义的资源的类别或分类。

资源类型是对应用程序中不同资源的分类。每种资源类型可以有不同的访问控制需求和策略。
例如，常见的资源类型包括 API 端点、文档、用户数据、服务等。

每个资源类型通常会有一个唯一的标识符（URN），用于在 Keycloak 中引用和管理该资源类型。例如，urn:myapp:resources:document 可能表示一个文档资源类型。

通过将权限与特定资源类型关联，可以确保只有符合条件的用户才能访问该类型的所有资源。

通过将资源分为不同的类型，可以更轻松地管理和维护权限。例如，如果有多个 API 端点属于同一类型，可以统一管理它们的访问权限，而不必逐个配置。

在多租户环境中，可以根据租户的需求定义不同的资源类型，以便为每个租户提供定制的访问控制。

policy type

1. Aggregated
   描述：重用现有策略以构建更复杂的策略，并使权限与在处理授权请求时评估的策略更加解耦。
   分析：这种策略允许用户将多个简单策略组合成一个更复杂的策略，增强了灵活性和可维护性。适用于需要多层次权限控制的场景。
2. Client
   描述：定义条件以确定一组或多个客户端是否被允许访问某个对象。
   分析：适用于需要根据客户端身份进行权限控制的情况，例如，特定应用程序或服务的访问权限。
3. Client Scope
   描述：定义条件以确定一组或多个客户端范围是否被允许访问某个对象。
   分析：与“Client”策略类似，但更侧重于客户端的作用域（scope），适合需要细化权限的场景，例如，限制某些功能或数据的访问。
4. Group
   描述：定义条件以确定一组或多个组（及其层次结构）是否被允许访问某个对象。
   分析：适用于组织结构中基于用户组的权限管理，便于管理和维护用户权限。
5. Regex
   描述：定义正则表达式条件以控制权限。
   分析：这种策略提供了灵活的条件匹配能力，适合需要基于复杂模式进行权限控制的场景，例如，基于用户输入的格式进行验证。
6. Role
   描述：定义条件以确定一组或多个角色是否被允许访问某个对象。
   分析：角色策略适用于基于用户角色的权限管理，常见于企业应用中，便于根据用户的职责分配权限。
7. Time
   描述：定义时间条件以控制权限。
   分析：适用于需要时间限制的访问控制，例如，某些资源只能在特定时间段内访问。
8. User
   描述：定义条件以确定一组或多个用户是否被允许访问某个对象。
   分析：直接基于用户身份进行权限控制，适合需要个性化权限管理的场景。

逻辑决策的定义
Positive（正向）: 当逻辑设置为“Positive”时，策略评估的结果（允许或拒绝）将直接用于做出最终决策。这意味着，如果策略评估的结果是“允许”，则最终决策也是“允许”；如果结果是“拒绝”，则最终决策也是“拒绝”。

Negative（负向）: 当逻辑设置为“Negative”时，策略评估的结果将被取反。这意味着，如果策略评估的结果是“允许”，最终决策将变为“拒绝”；如果结果是“拒绝”，最终决策将变为“允许”。

这种配置提供了一种灵活的方式来管理策略决策，通过简单的“Positive”或“Negative”设置，管理员可以有效地控制访问权限和策略效果。

安装Keycloak

在裸机上开始使用 Keycloak

官方文档：https://keycloak.java.net.cn/getting-started/getting-started-zip

OpenJDK下载地址：https://jdk.java.net/archive/

docker快速安装使用

Keycloak安装有多种方式，这里使用Docker进行快速安装

运行 Keycloak 容器

docker run -p 8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.0.5 start-dev

KC_BOOTSTRAP_ADMIN_USERNAME 和 KC_BOOTSTRAP_ADMIN_PASSWORD 用于设置管理员账号和密码。
start-dev 是开发模式，适合本地开发和测试。

创建Realm

创建一个新的realm: demo，后续所有的客户端、用户、角色等都在此realm中创建。

Keycloak 中的领域相当于租户。每个领域允许管理员创建应用程序和用户的隔离组。最初，Keycloak 包含一个名为 master 的单一领域。仅将此领域用于管理 Keycloak，而不要用于管理任何应用程序。

创建client客户端

“客户端” 指的是可以与身份验证系统（如 Keycloak 或 OAuth 2.0 认证服务器）进行交互的应用程序或服务。它们可以是网页应用、移动应用或者其他后端服务。

client是向身份验证服务发起请求的实体。

创建一个新的客户端：vue-demo，Access Type选择public

创建一个新的客户端：spring-boot-demo，Access Type选择bearer-only

关于客户端的访问类型（Access Type）

上面创建的2个客户端的访问类型分别是public、bearer-only，那么为什么分别选择这种类型，实际不同的访问类型有什么区别呢？
事实上，Keycloak目前的访问类型共有3种：
• confidential：适用于服务端应用，且需要浏览器登录以及需要通过密钥获取access token的场景。典型的使用场景就是服务端渲染的web系统。

Confidential Client（机密客户端）表示这个客户端是一个可以安全地存储并管理其凭证的应用程序。
与机密客户端相对应的是 Public Client（公共客户端），它不能安全存储凭据，通常是用户端应用程序，如手机应用或单页 web 应用。公共客户端不会包含敏感信息（如客户端密钥），因为它们的环境不可控，容易受到攻击。

• public：适用于客户端应用，且需要浏览器登录的场景。典型的使用场景就是前端web系统，包括采用vue、react实现的前端项目等。
• bearer-only：适用于服务端应用，不需要浏览器登录，只允许使用bearer token请求的场景。典型的使用场景就是restful api。

创建用户和角色

创建角色
创建2个角色：ROLE_ADMIN、ROLE_CUSTOMER

创建用户
创建2个用户：admin、customer

绑定用户和角色
给admin用户分配角色ROLE_ADMIN

给customer用户分配角色ROLE_CUSTOMER

测试

使用 官方 测试验证地址 可以测试你的配置，如果你的之前的配置可以公网访问的话。

生产环境

配置 TLS

官方文档：https://www.keycloak.org/server/enabletls
[视频]为生产环境的Keycloak完成最基础的配置-证书-数据库
参考URL: https://www.bilibili.com/video/BV1aC4y1Q7v4/

配置 Keycloak 的 https 证书，
传输层安全（简称：TLS）对于通过安全通道交换数据至关重要。对于生产环境，您永远不应该通过 HTTP 公开 Keycloak 端点，因为敏感数据是 Keycloak 与其他应用程序交换的核心。在本指南中，您将学习如何配置 Keycloak 以使用 HTTPS/TLS。

Keycloak 可以配置为使用 PEM 格式的文件或从 Java 密钥库加载所需的证书基础结构。当配置了这两种选择时，PEM 文件优先于 Java 密钥库。

bin/kc.[sh|bat] start --https-certificate-file=/path/to/certfile.pem --https-certificate-key-file=/path/to/keyfile.pem

Keycloak 侦听端口 8443 上的 HTTPS 流量。要更改此端口，请使用以下命令：

bin/kc.[sh|bat] start --https-port=<port>

TODO 证书再验证~

~~docker run -p 8080:8080  -p 8443:8443   -e KC_BOOTSTRAP_ADMIN_USERNAME=admin   -e KC_BOOTSTRAP_ADMIN_PASSWORD=xxx   -v /etc/nginx/httpcat.cn_nginx:/etc/nginx/httpcat.cn_nginx   quay.io/keycloak/keycloak:26.1.1 start-dev   --https-certificate-file=/etc/nginx/httpcat.cn_nginx/httpcat.cn_bundle.pem   --https-certificate-key-file=/etc/nginx/httpcat.cn_nginx/httpcat.cn.key   --https-port=8443~~ 

配置数据库

官方文档：https://www.keycloak.org/server/db

服务器内置了对不同数据库的支持。您可以通过查看db配置选项的期望值来查询可用的数据库。下表列出了支持的数据库及其测试版本。

默认情况下，服务器使用dev-file数据库。这是服务器将用于持久化数据的默认数据库，只存在于开发用例中。dev-file数据库不适合生产用例，必须在部署到生产环境之前进行替换。

可以在build命令或start命令中设置配置：

1. 使用build命令，然后start命令（推荐）

首先，可以在conf/keycloak.conf中指定连接到数据库所需的最小设置：

# The database vendor.
db=postgres

# The username of the database user.
db-username=keycloak

# The password of the database user.
db-password=change_me

# Sets the hostname of the default JDBC URL of the chosen vendor
db-url-host=keycloak-postgres

然后，以下命令基于配置选项创建一个新的和优化的服务器映像，然后启动服务器。

bin/kc.[sh|bat] build
bin/kc.[sh|bat] start --optimized

2. 仅使用start命令（没有–optimized）

bin/kc.[sh|bat] start --db postgres --db-url-host keycloak-postgres --db-username keycloak --db-password change_me

使用conf/keycloak.conf，上面的示例包括连接到数据库所需的最小设置，但不建议使用数据库密码。如上所示，环境变量或密钥库

默认schema为keycloak，但是您可以使用db-schema配置选项来更改它。

更改集群配置中的数据库锁定超时

集群节点（在网络中协同工作的服务器）可以同时启动。这种并发启动可能导致潜在的冲突，因为多个节点可能会同时尝试执行数据库操作。

例如，引导服务器实例可以执行一些数据库迁移，导入或首次初始化。当群集节点同时启动时，数据库锁定会阻止启动操作相互冲突。

使用了数据库锁。这个锁确保在某一时刻只有一个节点可以执行特定操作，从而避免数据损坏或不一致的状态。

bin/kc.[sh|bat] start --spi-dblock-jpa-lock-wait-timeout 900

用户可以将900替换为其他值，以修改超时期限。

过程问题总结

keycloak 初始化admin后，出现HTTPS required 问题

原因：放到服务器上后,我使用外网IP访问http服务，出现需要ssl

Keycloak can run out of the box without SSL so long as you stick to private IP addresses like localhost, 127.0.0.1, 10.0.x.x, 192.168.x.x, and 172.16.x.x. If you don???t have SSL/HTTPS configured on the server or you try to access Keycloak over HTTP from a non-private IP adress you will get an error.

keycloak如果用私有地址才能不使用ssl登录方式，如果用公网就需要用ssl登录方式。

解决方法：
思路1: 官方文档：https://keycloak.java.net.cn/server/enabletls
思路2: 数据库修改一个字段的内容， 参考stackoverflow链接
update REALM set ssl_required='NONE' where id = 'master';

可以使用如下命令行方式操作：

./kcadm.sh config credentials --server http://x.x.x.x:8080 --realm master --user admin
./kcadm.sh update realms/master -s sslRequired=NONE --server http://localhost:8080

亲测可用，在特殊场景下，你只要http推荐使用方法2。

参考

Keycloak快速上手指南（一）
参考URL: https://developer.aliyun.com/article/1370863
解决登录与SSO的开发痛点：Keycloak快速部署与最简单登录验证教程
参考URL: https://blog.csdn.net/m0_70878103/article/details/144785915
杂记 | 使用keycloak实现SSO单点登录（新手向，概念、原理、逻辑、详细步骤、难点解释）
参考URL: https://blog.csdn.net/xuzhongyi103/article/details/131525379
[推荐，写的很清晰]基于Keycloak的权限控制
参考URL：https://blog.csdn.net/m0_49294242/article/details/134117739