用户鉴权方式keycloak

目录

1. SAML、OAuth 2.0和OIDC

1.1 OAuth 2.0

1.2 SAML

 1.3 OIDC

2. Keycloak

3. keycloak实践

3.1 keycloak基本对象

3.1.1 用户

3.1.2 用户角色

3.1.3 客户端（client）

3.1.4 客户端访问范围（client-scopes）

3.2 oauth2.0的用户鉴权

3.2.1 获取用户token（password模式）

3.2.1.1 keycloak设置

3.2.1.2 测试验证

3.2.2 基于角色的数据新增

3.2.2.1 keycloak设置

3.2.2.2 java程序实现

3.2.2.3 测试验证

3.2.3 基于用户的数据查询

3.2.3.1 keycloak设置

3.2.3.1 java程序实现

3.2.3.1 测试验证

3.2.4 基于角色的数据删除

3.2.4.1 keycloak设置

3.1.4.2 java程序实现

3.1.4.3 测试验证

3.1.5 oauth2.0的鉴权（页面跳转code模式）

3.1.5.1 keycloak设置

3.1.5.2 测试验证

3.3 SAML 用户鉴权

3.3.1 基于证书的用户用户鉴权

3.3.1.1 keycloak设置

3.3.1.2 java程序实现

A.1遇到问题

A.1.1. enc报错，需要将enc服务全部关闭

A.1.2. Saml 使用keycloak:18.0.1版本

---

1. SAML、OAuth 2.0和OIDC

身份认证会碰到几种常见协议，它们分别是SAML(Security Assertion Markup Language、OAuth(Open Authorization)2.0和 OIDC(OpenID Connect)。

SAML:一种基于XML的开放标准，用于在身份提供者和服务提供商之间交换认证和授权信 息。它主要用于企业间的单点登录(SSO)和身份提供者(Identity Provider,IdP) 与服务提供商(Service Provider,SP)之间信任关系的建立。SAML解决了企业间身份集成和信任关系建立的问题。

OAuth 2.0:一种开放标准，用于授权第三方应用访问受保护资源的框架。OAuth提供了安全且可扩展的身份认证和授权机制。它允许用户授权第三方应用访问它们在其他应用中存储的资源， 而无须共享它们的凭据。OAuth 2.0广泛应用于Web和移动应用的身份验证和授权场景。

OIDC:建立在OAuth2.0之上的身份认证协议，提供了基于令牌的身份验证和用户信息交换的能力，由OpenID基金会开发。

在身份认证领域，以上几个标准和协议被广泛应用于认证和授权的流程。，下面分别详细介绍OAuth 2.0、SAML和OIDC。

1.1 OAuth 2.0

对于OAuth 2.0来说，“第三方”是一个关键字，也就是说，如果你的应用既不准备使用任何第三方能力，也不准备为任何第三方赋能，不会被任何第三方来调用，那么这样的孤立应用程序 (Soiled Application)是完全不需要使用OAuth开放标准的用型。

OAuth允许用户不共享凭据的情况下授权第三方应用访问它们在其他应用中的资源，这是通用共享访问令牌替代共享凭据(比如密码)来实现的，产生这个访问今牌的方式涉及不同的许可类型(或者称为授权模式)。在后文中，将举例逐一介绍不同的许可类型。首先，了解一下OAuth 2.0的授权流程，如图所示。

在图中，提到了如下几个参与方，它们也是常见术语的一部分。

 ●第三方应用(Third-Party Application):需要得到资源持有者授权访问其资源的那个应用。也经常被称为客户端或者请求方，它从授权服务器请求访问令牌，并且可以携带访问令牌从资源服务器访问用户的资源。

 ●资源持有者(Resource Owner):拥有授权权限的人，是第三方应用的用户，拥有资源并可以 授权他人访问其拥有的资源。

 ●授权服务器(Authorization Server):能够根据资源持有者的意愿提供授权(授权前进行了必要 的认证过程)的服务器。

 ●资源服务器(Resource Server):能够提供第三方应用所需资源的服务器，它与认证服务器可 以是相同的服务器，也可以是不同的服务器。它接收令牌，并且在令牌验证有效时返回资源。

 ●用户代理(User Agent):资源持有者用来访问服务器的工具。对于人类用户来说，这通常是浏览器，或者原生应用。对于机器用户，即在微服务的互相调用的认证场景中，一个服务经常会作为另一个服务的用户，此时的用户代理就是HttpClient、RPCClient等。

1.2 SAML

SAML(Security Assertion Markup Language，安全声明标记语言)是一种基于 XML 的开放数据格式，允许计算机在网络间共享安全令牌。SAML2.0可以基于跨域网络实现单点登录，从而减少向单个用户发放多个身份令牌的开销。

 它包含两个实体：

 ●服务提供商。（IDP）

 ●身份提供者。（SP）

 授权过程大致如下：

 (1)服务提供商向身份提供者发送SAML请求，请求用户身份验证。

 (2)身份提供者要求用户输入用户名和密码，并对其进行验证。

 (3)如果验证成功，身份提供者将SAML响应返回给服务提供商，其中包含额外的信息以确 保响应未被篡改。

 其具体时序图如图所示。

 1.3 OIDC

OIDC是一个基于OAuth 2.0的身份验证协议，它提供了在Web应用中验证和获取用户身份信 息的机制，是OAuth 2.0的超集，即OIDC=授权协议+身份认证。OIDC在OAuth 2.0的基础上添加了标准化的身份验证流程和用户信息交换。它被广泛应用于Web应用程序中的用户身份验证和授权， 并且可以提供单点登录的能力，使用和OAuth 2.0相同的授权流程。

 OIDC是OAuth 2.0的一个扩展，为OAuth 2.0协议提供了一个标准的身份验证流程。通过OIDC, 客户端可以通过OAuth 2.0的授权流程获取用户的身份令牌，并使用该令牌验证用户的身份和获取 用户的身份信息。它利用了OAuth 2.0提供的基础，所以它和OAuth 2.0一样，是一种基于REST JSON和API的系统。

 如果说OAuth 2.0是一层非常厚的基于令牌的授权协议，那么 OIDC是一层非常薄的基于令牌 的身份认证协议，它们之间的关系如图所示。

图 OIDC和OAuth2.0的关系

 OIDC定义了三种主要角色，分别说明如下：

 ● EU(End User),即最终用户，也就是使用我们的应用的用户.

 ● RP(Relying Party),即依赖认证服务的第三方，也就是我们的应用。

 ● OP(OpenID Provider),即OIDC服务提供者，也就是我们的认证服务器。

 OIDC基于授权服务器执行的验证 用户的过程简化了确认用户身份的方式，并提供了类RESTful接口的互操作方式，用于获取用户资料。这种开放互联的设计使得不同的系统能够轻松集成，使数字化系统的搭建变得像搭建积木一样 简单高效。OIDC为应用和网站开发者赋能，使他们能够启用登录流程并在基于网页、移动端和JavaSeript 的客户端之间验证用户身份,此外,OIDC支持诸如身份数据加密、身份提供者发现以及会话注销等扩展功能。对于开发者来说,OIDC 安全可靠地回答了一个问题:“正在使用当前浏览器或者移动应用的个体的数字身份是什么?”。OIDC的优势在于，它使开发者不再需要负责设置、存储和管理密码，而这些任务非常困难，凭据泄露事件频繁发生就是最好的证明。因此，将这些烦琐的任务交给 OIDC,开发者可以更加专注于业务逻辑。如图展示了 OIDC连接协议套件的示意图，其中的最小核心组件已足以实现系绕之间的开放互联。而将整个套件全部包含进来，则形成了一个非常理想的身份认证平台。

可以简单地认为，OAuth 2.0提供访问令牌(Access Token), 而OIDC的最小核心组件额外提供身份令牌(ID Token)。

 ●访问令牌：表示用户身份和访问权限的令牌，用于向资源服务器请求受保护资源的访问。

 ●身份令牌：在OIDC中使用的令牌类型，包含有关用户身份的信息，用于进行身份验证和用户 信息交换。

 OIDC致力于为授权过程中的主体(或者说用户)提供更多的保证。身份令牌，正如名称所暗 示的，它聚焦于提供身份相关的信息，它也是JWT格式的。

 除客户端凭据许可类型外，其他的许可类型会同时提供访问令牌和身份令牌。我们后面会详细 介绍在OIDC中的许可类型，不同许可类型对访问令牌和身份令牌的支持情况表如表所示。

许可类型	访问令牌	身份令牌
授权码许可	支持	支持
隐式许可	支持	支持
密码许可	支持	支持
客户端凭据许可	支持	不支持
设备许可	支持	支持

访问令牌不需要被使用方解析，可以使用不透明令牌，而身份令牌是一个JSON Web Token(JWT),属于结构化令牌，需要使用方对令牌进行解析，从中获取用户的身份信息，处理用户的登录状态等逻辑。尽管一个结构化令牌的载荷可以自定义，但是OIDC规范中定义了一些标准的字 段，用于表示用户的身份信息，以及身份令牌的有效期等信息。如果要颁发一个身份令牌，则以下 5个JWT声明参考是必需的：

 (1)iss,全称issuer,是令牌的颁发者，其值就是OpenID提供者(OpenID Provider,OP)的

 URL,这个身份认证服务，在OpenID规范里，也被称为OpenID身份提供者。

 (2)sub,全称subject,是令牌的主题，其值就是终端用户(End User,EU)的唯一标识，比 如用户的ID。

 (3)aud,全称audience,是令牌的受众，其值就是依赖认证服务的第三方应用(Relying Party RP)的app_id。

 (4)exp,全称expiration time,是令牌的过期时间，其值就是一个时间戳，表示令牌的过期时 间。

 (5)iat,全称issuedat,是令牌的颁发时间，其值就是一个时间戳，表示令牌的颁发时间。

2. Keycloak

Keycloak 是一个开源的身份认证和访问管理解决方案，由 Red Hat 公司开发和维护，如今已是 CNCF 的孵化项目。它提供了强大的身份验证、授权和用户管理功能。Keycloak 支持多种身份验证协议，如 OAuth、OpenID Connect、SAML 等,并且可以与各种应用程序和服务进行集成。Keycloak提供了一套完整的身份认证和授权功能，可以用于保护应用程序、API和服务的安全性。下面介绍 Keycloak 的一些关键组件:

1. 认证服务器

认证服务器(AuthenticationServer)是Keycloak的核心组件,负责处理用户的身份认证和授构它支持多种身份验证协议，如OAuth、OpenIDConnect和SAML。认证服务器维护用户的身份信和凭据，并验证用户的身份以颁发访问令牌。

2. 客户端

Keycloak 的客户端(Client)是与认证服务器进行交互的应用程序或服务。客户端使用认证务器颁发的访问令牌来访问受保护的资源。Keycloak支持各种类型的客户端，如Web 应用、移动用和后端服务。客户端是指代表应用程序或服务的实体，它可以是Web 应用程序、移动应用程后端 API或其他与Keycloak进行身份认证和授权交互的实体。

每个客户端都与一个特定的 Realm 相关联,它使用 Realm 中定义的用户和角色来进行身份认和授权。通过客户端,应用程序可以与Keycloak进行安全通信,获取访问令牌并使用它来保护资源Keycloak 提供了不同类型的 Clients，包括:

• Confdential Clients(机密客户端):这种类型的客户端可以安全地保持其凭据，例如客户端密钥。它们通常在服务器端执行，并且可以直接与Keycloak进行交互。
• Public Clients(公开客户端):这种类型的客户端无法安全地保持其凭据。它们通常在客户设备上执行，例如 Web 浏览器、移动应用程序等。公共客户端依赖于重定向和浏览器交互来行身份认证和授权。
• Bearer-only Clients(仅承载令牌客户端):这种类型的客户端只接受 Bearer 令牌，不会主动起身份认证请求。它们通常用于保护后端 API，接收并验证传入的令牌，确保请求的合法性即这类客户端的认证目标对象是机器，使用在面向 API的认证场景中。

 每个客户端都有自己的配置和安全策略,例如访问令牌的有效期、访问权限的范围等。Keycloak通过客户端的定义来控制应用程序的访问和权限，并为每个客户端颁发相应的访问令牌。总之，客户端是 Keycloak 中的一个重要概念，代表着与 Keycloak 进行身份认证和授权交耳应用程序或服务实体。不同类型的客户端具有不同的特性和安全策略，可以根据应用程序的需求。行选择和配置。

3. 令牌

在 Keycloak 中,令牌(Tokens)是身份认证和授权的核心概念。它分为访问令牌(Access Token)和身份令牌(ID Token)。访问令牌用于访问受保护的资源，身份令牌包含有关用户身份的信息。

4.身份提供者

身份提供者(IdentityProvider)是Keycloak 与外部身份源集成的组件。Keycloak 支持与各种身份提供者集成，如 LDAP、Active Directory和社交登录提供者(如Google、Facebook)。通过身份提供者，Keycloak可以实现跨域身份认证和用户数据的同步。

身份提供者是指在身份认证过程中负责验证用户身份的第三方服务提供商。它可以是一个独立的系统或服务，也可以是一个集成在Keycloak 中的模块。

在Keycloak 中，可以配置多个身份提供者来支持不同的身份验证方式，例如社交媒体登录(如Google、Facebook)、企业身份提供者(如Active Directory)等。

每个身份提供者都有自己的身份验证机制和用户存储，它负责验证用户提供的凭据(如用户名和密码)并返回认证结果给Keycloak。当用户尝试登录应用程序时，Keycloak会将用户重定向到适当的身份提供者进行身份验证。-日身份提供者成功验证用户身份,它将生成一个身份令牌或其他形式的证明,并将其返回给 KeycloakKeycloak 接收到身份令牌后，会对其进行验证，并为用户生成访问令牌，用于后续的资源访问和授权。身份提供者在身份认证过程中起到了关键的作用，可以帮助应用程序实现跨平台、跨域的身份认证和用户管理。

总之，身份提供者是Keycloak中的一个重要概念，用于验证用户身份并生成身份令牌。它可以是独立的第三方服务提供商，也可以是集成在 Keycloak 中的模块。通过配置不同的身份提供者，应用程序可以支持多种身份验证方式，提供更灵活和多样化的身份认证体验。

5.安全领域

安全领域(Realm)是 Keycloak 中的一个独立安全域，用于管理用户、客户端和策略。每个领域具有独立的用户存储和身份认证配置。Keycloak 支持创建多个安全领域，用于隔离不同的应用程序或组织。

Realm 是 Keycloak 中的核心概念之一，它提供了一种逻辑上的分区方式，用于划分和管理不同的安全域。在每个 Realm 中，你可以定义自己的用户、角色、客户端和策略。

一个 Realm 可以被看作一个独立的身份认证和授权空间，具有自己的用户数据库和身份验证配置。它提供了一套独立的用户管理功能，可以定义自己的用户属性和访问控制策略。

Keycloak 支持创建多个 Realm，每个 Realm 都是相互隔离的，不共享用户和其他配置信息。这使得 Keycloak 非常适合多租户场景，可以在同一个 Keycloak 实例中为不同的应用程序或组织创建

通过使用 Realm，你可以根据应用程序或组织的需求来划分和管理用户、角色和客户端。每个独立的安全域。Realm 都具有自己的配置和安全策略，可以满足不同应用程序的特定需求。

总之，Realm 是 Keycloak 中的一个关键概念，它提供了一种逻辑上的分区方式，用于划分和管理不同的安全域，以实现用户管理和身份认证的隔离与定制。

以上是 Keycloak 的关键组件，它们共同构成了一个完整的身份认证和访问管理解决方案。通过使用 Keycloak，开发人员可以快速集成身份认证功能，提高应用程序的安全性和用户体验。在实际应用上，使用 Keycloak 打通公司生态是很合适的，因为Keycloak 内置了以下功能:

(1)单点登录，这个一般公司都是需要的。

(2)身份代理和社交登录，适合对接第三方登录。举例来说，对公司的消费者端有微信等，而对公司的员工这种内部使用场景有企业微信登录、钉钉登录等。当然，由于 Keycloak 的主开发者在国外，因此它内置的社交登录是针对国外的社交平台的，如果需要对接国内的社交平台需要自己开发或者使用第三方的插件。

(3)用户联邦，适合打通公司的 LDAP 服务，如果需要此功能，采用 Keycloak 也很适合。

3. keycloak实践

3.1 keycloak基本对象

3.1.1 用户

在Keycloak中，"User"（用户）是指系统中的一个账户实体，代表一个可以登录并访问受保护资源的个体。Keycloak是一个身份和访问管理解决方案，提供了一套丰富的功能来管理用户账户。

• 添加用户

在users界面，点击add user进行添加用户。

3.1.2 用户角色

在Keycloak中，"Role"（角色）是一个核心概念，用于实现基于角色的访问控制（RBAC）。角色定义了一组权限，这些权限可以被分配给用户或客户端以控制对资源的访问。

• 角色添加

3.1.3 客户端（client）

客户端是Keycloak 对用户进行身份验证的实体。 大多数情况下，客户端是希望使用Keycloak 来保护自己并提供单点登录解决方案的应用程序和服务。 客户端也可以是只想请求身份信息或访问令牌的实体，以便他们可以安全地调用网络上由Keycloak 保护的其他服务。

用户点击create client进行创建客户端（client）。

输入client ID 进行创建，client ID为客户端的唯一关键字进行对客户端进行标识。以下是对各个关键字的解释：

Client type ：有两种模式：“OpenID连接”允许客户端根据授权服务器执行的身份验证来验证最终用户的身份。“SAML”支持基于web的身份验证和授权场景，包括跨域单点登录（SSO），并使用包含断言的安全令牌来传递信息。

Client ID：客户端标识符号

Name ：指定客户端的显示名称。例如，“我的客户端”。也支持针对本地化值的键。对应的本地化键值例如：${我的客户端}

Always display in UI：即使没有一个活动的会话（session），也要在帐户UI中列出此客户端。

3.1.4 客户端访问范围（client-scopes）

"client scope"是一个功能，用于定义一组权限，这些权限可以被客户端（即应用程序或服务）请求。用户可以创建和管理client scope，并将它们分配给客户端。客户端在请求访问令牌时，可以指定它需要哪些client scope的权限。Keycloak会根据这些请求和用户的权限来发放相应的访问令牌。

client scope对象界面分为三个部分组成，设置（setting）、映射（mapper）、范围（scope）。

1. "Client Scopes"的"Mapper"功能是用于定义如何将用户属性或声明映射到令牌（如访问令牌或ID令牌）中的机制。Mapper允许你自定义令牌的内容，使其包含特定的用户信息或声明。
2. "Scope mappings"允许你限制哪些用户角色映射（user role mappings）被包含在客户端请求的访问令牌（access token）中。

举例：

创建一个demo-client ，填写名称作为标识。

创建映射mapper映射，在mapper映射中可以创建多种映射方式。例如图中的User Property、User Realm Role。

1. User Realm Role:创建映射器来将角色添加到令牌。将在令牌中添加带有authoritites键的角色。
2. User Property：定义一个映射器，将用户名添加到令牌中。

配置完成后需要在客户端中进行绑定，将刚刚创建的”demo-client“的client-scope对象与客户端（client进行关联）。将demo-client添加到assigned Default Client Scope列表中，使客户端（client）服从client-scopes设定的访问规则。

3.2 oauth2.0的用户鉴权

3.2.1 获取用户token（password模式）

3.2.1.1 keycloak设置

配置流程：添加用户-》创建clients(客户端)

• 添加用户

添加用户user1用于后续获取token访问。

• 创建clients(客户端)

创建客户端demo-client，demo-client是Keycloak 对用户进行身份验证的实体对象。

3.2.1.2 测试验证

配置完成keycloak后，使用password模式向keycloak服务器请求token。下面提供curl和postman两种方式：

curl --request POST ^

  --url http://127.0.0.1:18080/realms/demo/protocol/openid-connect/token ^

  --header 'Content-Type: application/x-www-form-urlencoded'^

  --data grant_type=password ^

  --data client_id=demo-client ^

  --data username=user1 ^

  --data password=123456 ^

使用postman进行测试：

返回结果：

{

    "access_token": "eyJhbGciOiJSUzI1NiIsIn....",

    "expires_in": 300,

    "refresh_expires_in": 1800,

    "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5...",

    "token_type": "Bearer",

    "not-before-policy": 0,

    "session_state": "7f1cc026-230f-4999-8a71-333316b5c40f",

    "scope": "email profile"

}

3.2.2 基于角色的数据新增

3.2.2.1 keycloak设置

Keycloak配置操作流程如下：

添加用户-》配置用户角色-》新增client-scopes-》配置client-scopes的映射模式-》在client中关联client-scopes。

• 添加用户

新增一个管理员角色demo-admin和普通用户角色demo-user

• 新增client-scopes

新增demo-client客户端访问范围对象,client scope 决定客户端的访问方式。

• 配置client-scopes的映射模式

在demo-client客户端访问范围对象配置映射，如下图所示。

创建User Realm Role映射关系，用于角色映射。

• 在client中关联client-scopes

3.2.2.2 java程序实现

在WorkoutService.java 对象中配置访问类型，关键代码如下所示：

1. 访问的对象名与worker中user对象的内容一致，即访问对象只能修改自己的内容。
2. keycloak的客户端的访问访问范围规则是“demo-client”对象所配置的。

3.2.2.3 测试验证

首先需要向keycloak的客户端获取访问token，如下图所示。

curl --request POST ^

  --url http://127.0.0.1:18080/realms/demo/protocol/openid-connect/token ^

  --header 'Content-Type: application/x-www-form-urlencoded'^

  --data grant_type=password ^

  --data client_id=demo-client ^

  --data username=user1 ^

  --data password=123456 ^

返回结果：

{

    "access_token": "eyJhbGciOiJSUzI1NiIsIn....",

    "expires_in": 300,

    "refresh_expires_in": 1800,

    "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5...",

    "token_type": "Bearer",

    "not-before-policy": 0,

    "session_state": "7f1cc026-230f-4999-8a71-333316b5c40f",

    "scope": "email profile"

}

进行如下三种测试：

1. 本人有权限并新增本人数据，即user2 向获取token，并对user2的数据进行新增。
2. 本人有权限并修非本人数据，即user2 向获取token，并对user1的数据进行新增。
3. 权限过期或者无权限，即无权限，并调用数据新增接口。

（1）添加成功-本人

（2）添加失败-非本人

（3）添加失败-token过期

3.2.3 基于用户的数据查询

3.2.3.1 keycloak设置

创建用户-》新增client-scopes-》配置client-scopes的映射模式-》在client中关联client-scopes。

• 新增client-scopes

新增demo-client客户端访问范围对象,client scope 决定客户端的访问方式。

• 配置client-scopes的映射模式

在demo-client客户端访问范围对象配置映射，如下图所示。

创建User Property映射关系，用于用户名映射。

• 在client中关联client-scopes

3.2.3.1 java程序实现

3.2.3.1 测试验证

3.2.4 基于角色的数据删除

3.2.4.1 keycloak设置

添加用户-》配置用户角色-》新增client-scopes-》配置client-scopes的映射模式-》在client中关联client-scopes。

• 添加用户

新增一个管理员角色demo-admin和普通用户角色demo-user

• 新增client-scopes

新增demo-client客户端访问范围对象,client scope 决定客户端的访问方式。

• 配置client-scopes的映射模式

在demo-client客户端访问范围对象配置映射，如下图所示。

创建User Realm Role映射关系，用于角色映射。

• 在client中关联client-scopes

3.1.4.2 java程序实现

3.1.4.3 测试验证

• 管理员用户（成功）

 

• 普通用户测试（失败）

3.1.5 oauth2.0的鉴权（页面跳转code模式）

3.1.5.1 keycloak设置

Keycloak设置流程：用户新增-》客户端（client）创建-》客户端配置

• 用户新增

• 客户端配置

3.1.5.2 测试验证

url中的code内容即为请求权限，这个是页面跳转后生成的权限凭证。

3.3 SAML 用户鉴权

3.3.1 基于证书的用户用户鉴权

3.3.1.1 keycloak设置

Keycloak配置过程：

创建REALM-》创建客户端-》导出密钥-》创建用户

需要进行对以下类目进行配置：

Client ID: spring-boot-keycloak

Client Protocol: saml

Signature Algorithm: RSA_SHA256

SAML Signature Key Name: KEY_ID

Canonicalization Method: EXCLUSIVE

Name ID Format : username

Root URL: http://localhost:8081

Valid Redirect URIs: /saml/*

Base URL: /

**Fine Grain SAML Endpoint Configuration***

Assertion Consumer Service POST Binding URL: /saml/SSO

Logout Service POST Binding URL: /saml/logout

点击export输出key文件并用浏览器下载。

3.3.1.2 java程序实现

Java程序实现有几个关键步骤：配置用户信息、配置本地密钥、解析用户信息。

• 配置用户信息

配置用户信息在samlUserDetailsServiceImpl中进行具体实现。

从请求返回用户信息，包括用户名称、权限、角色等。封装用户信息返回并存储到spring security context中。

解析当前登录用户

• 配置本地密钥

配置saml生成的密钥，配置到工程中。

• 跳转配置

用户验证成功跳转：

SavedRequestAwareAuthenticationSuccessHandler 是 Spring Security 中的一个 AuthenticationSuccessHandler 接口的实现类。这个类用于处理用户认证成功后的逻辑，特别是它能够恢复用户在认证之前请求的URL，并重定向用户到该URL。

验证失败：

SimpleUrlAuthenticationFailureHandler 是 Spring Security 的一个组件，实现了 AuthenticationFailureHandler 接口。当用户认证失败时，这个处理器会被调用，通常用于将用户重定向到一个错误页面。

• 用户注销

SimpleUrlLogoutSuccessHandler：注销成功后转发到一个URL地址。

SecurityContextLogoutHandler：SecurityContext作为SpringSecurity的核心类，保存了认证信息和用户信息，是至关重要的，所以说需要在登出的时候有一个类负责清空SecurityContext。

下面是SecurityContextLogoutHandler的源码解析：

public class SecurityContextLogoutHandler implements LogoutHandler {

   /**

    * 是否应该在登出时 使Session无效

    */

   private boolean invalidateHttpSession = true;

   /**

    * 是否应该在登出时 清除认证对象

    */

   private boolean clearAuthentication = true;

   /**

    * 清空当前用户的安全上下文

    * @param request the HTTP request

    * @param response the HTTP response

    * @param authentication the current principal details

    */

   @Override

   public void logout(HttpServletRequest request, HttpServletResponse response, Authentication authentication) {

      Assert.notNull(request, "HttpServletRequest required");

      //是否使Session无效

      if (this.invalidateHttpSession) {

         HttpSession session = request.getSession(false);

         if (session != null) {

            session.invalidate();

            if (this.logger.isDebugEnabled()) {

               this.logger.debug(LogMessage.format("Invalidated session %s", session.getId()));

            }

         }

      }

      //清空当前用户的 线程级别的安全上下文

      //HttpSession级别的在SecurityContextPersistenceFilter中会被清除

      SecurityContext context = SecurityContextHolder.getContext();

      SecurityContextHolder.clearContext();

      //清空认证对象

      if (this.clearAuthentication) {

         context.setAuthentication(null);

      }

   }

}

3.1.7.2 测试验证

A.1遇到问题

A.1.1. enc报错，需要将enc服务全部关闭

A.1.2. Saml 使用keycloak:18.0.1版本