搜索
支持控制台（Console）开发人员开始试用联系人

8.3. 身份验证流程

download PDF

身份验证 流程是身份验证、屏幕和操作的容器，登录、注册和其他红帽单点登录工作流期间。要查看所有流、操作和检查，每个流程都需要：

流程

  1. 在菜单中，单击 Authentication。
  2. 点 Flows 选项卡。

8.3.1. 内置流

Red Hat Single Sign-On 有几个内置流。您无法修改这些流，但您可以更改流程的需求以满足您的需要。

在下拉列表中，选择 浏览器 以显示 Browser Flow 屏幕。

浏览器流

Browser Flow

将鼠标悬停在下拉列表的 question-mark 工具上，以查看流的描述。有两个部分。

8.3.1.1. auth 类型

要执行的验证或操作的名称。如果验证缩进，则会在子流中。它可能或无法执行，具体取决于其父进程的行为。

  1. cookie

    当用户第一次成功登录时，Red Hat Single Sign-On 会设置一个会话 Cookie。如果已经设置了 cookie，这个验证类型可以成功。由于 Cookie 提供程序返回成功，因此这一级别上的每个执行都是 备选 的，因此 Red Hat Single Sign-On 不会执行任何其他执行。这会导致登录成功。

  2. Kerberos

    这个验证器默认被禁用，并在浏览器流中跳过。

  3. 身份提供程序 Redirector

    此操作通过 Actions > Config 链接进行配置。它重定向到另一个 IdP 的 身份代理。

  4. 表单

    由于此子流标记为 替代，因此如果传递 Cookie 验证类型，则不会执行。此子流包含需要执行的额外验证类型。Red Hat Single Sign-On 加载此子流的执行并处理它们。

第一个执行是 Username Password Form，它是一个呈现用户名和密码页面的身份验证类型。它已被标记为 必需的，因此用户必须输入有效的用户名和密码。

第二个执行是 浏览器 - Conditional OTP 子流。这个子流是 条件，并根据 Condition - User Configured execution 的结果来执行。如果结果正确，Red Hat Single Sign-On 会加载此子流的执行并处理它们。

下一个执行是 Condition - User Configured authentication。此身份验证检查 Red Hat Single Sign-On 是否在用户流中配置了其他执行。Browser - Conditional OTP 子流仅在用户配置了 OTP 凭证时才会执行。

最后的执行是 OTP Form。Red Hat Single Sign-On 会将这个执行标记为 required，但只有用户因为 条件 子流中的设置而设置 OTP 凭证时才会运行。如果没有，用户不会看到 OTP 表单。

8.3.1.2. 要求

一组控制操作执行的单选按钮。

8.3.1.2.1. 必需

流中的 所有必需元素都必须成功执行。如果需要的元素失败，流会终止。

8.3.1.2.2. 替代方案

只有单一元素必须成功执行流程才能成功评估成功。因为 Required 流元素足以将流标记为成功，所以包含 Required 流元素的 Alternative 流元素将无法执行。

8.3.1.2.3. Disabled

该元素不计将流标记为成功。

8.3.1.2.4. 条件

这个要求类型只在子流中设置。

  • Conditional 子流包含执行。这些执行必须评估为逻辑语句。
  • 如果所有执行都评估为 true，则条件 子流充当 必需项。
  • 如果所有执行都评估为 false，Condition al sub-flow 充当 Disabled。
  • 如果没有设置执行，Conditional 子流充当 Disabled。
  • 如果流包含执行，且流没有设置为 Conditional，Red Hat Single Sign-On 不会评估执行，且执行被视为功能 禁用。

8.3.2. 创建流

在设计流程时，应用重要的功能和安全考虑因素。

要创建流，请执行以下操作：

流程

  1. 在菜单中，单击 Authentication。
  2. 单击 New。
注意

您可以复制并修改现有流。选择流，单击 Copy，然后为新流输入一个名称。

创建新流时，您必须首先使用以下选项创建一个顶级流：

Alias
流的名称。
描述
您可以设置为流的描述。
顶级流类型
流的类型。类型 客户端 仅用于客户端的身份验证（应用程序）。对于所有其他情况，请选择 通用。

创建顶级流

Top Level Flow

当 Red Hat Single Sign-On 创建流时，Red Hat Single Sign-On 会显示 Delete、Add execution 和 Add flow 按钮。

空新流

New Flow

三个因素决定了流和子流的行为。

  • 流和子流的结构。
  • 流中的执行
  • 在子流和执行过程中设置的要求。

执行操作有多种，从发送重置电子邮件以验证 OTP。使用 Add execution 按钮添加执行。将鼠标悬停在 提供程序 旁边的问号上，以查看执行的描述。

添加身份验证执行

Adding an Authentication Execution

有两种执行类型，即自动执行 和交互式执行。Automatic executions 与 Cookie 执行类似，并将在流中自动执行操作。交互式执行将暂停流以获取输入。执行操作成功将其状态设置为 success。对于完成流程，至少需要一个执行状态 成功。

您可以使用 Add flow 按钮将子流添加到顶级流中。Add flow 按钮显示 Create Execution Flow 页面。此页面与 Create Top Level Form 页类似。区别在于，Flow Type 可以是 通用 （默认）或 表单。表单 类型构造了为用户生成表单的子流，类似于内置的 注册流程。子流成功取决于它们的执行程度，包括它们的子流。如需了解子流的工作方式，请参阅执行 要求部分。

注意

添加执行后，检查要求具有正确的值。

流中的所有元素在 Actions 菜单中都有一个 Delete 选项。此操作会从流中删除这个元素。执行具有 Config 菜单选项来配置执行。还可以使用 Add execution and Add flow 菜单选项把执行和子流加入到子流。

由于执行顺序非常重要，因此您可以使用名称旁边的上和下个按钮在流内移动和执行和子流。

警告

当您配置身份验证流以确认您的设置中存在安全漏洞时，请确保正确测试您的配置。我们建议您测试各种类型情况。例如，考虑在身份验证前从用户帐户中删除不同凭证时测试用户的验证行为。

例如，当有双因素验证器（如 OTP Form 或 WebAuthn Authenticator）时，作为 REQUIRED 且用户没有特定类型的凭证，用户可以在验证自身期间设置特定的凭证。这种情况意味着，在身份验证过程中，用户不会通过这个凭证进行身份验证。要进行浏览器身份验证，请确保使用一些1因素凭证（如 Password 或 WebAuthnless Authenticator）配置您的身份验证流程。

8.3.3. 创建无密码浏览器登录流程

为了说明流程的创建，本节描述了创建高级浏览器登录流。此流程的目的是允许用户选择使用无密码的 WebAuthn 登录，或使用密码和 OTP 进行双因素身份验证。

流程

  1. 在菜单中，单击 Authentication。
  2. 点 Flows 选项卡。
  3. 单击 New。
  4. 输入浏览器密码 作为别名。
  5. 点 Save。
  6. 单击 Add execution。
  7. 从下拉列表中选择 Cookie。
  8. 点 Save。
  9. 点 Alternative，Cookie 验证类型将它的 requirement 设置为 alternative。
  10. 单击 Add execution。
  11. 从下拉列表中选择 Kerberos。
  12. 单击 Add execution。
  13. 从下拉列表中选择 Identity Provider Redirector。
  14. 点 Save。
  15. 点 Alternative，Identity Provider Redirector 验证类型将它的 requirement 设置为 alternative。
  16. 点 Add flow。
  17. 输入 Forms 作为别名。
  18. 点 Save。

  19. 点 Alternative，Forms 验证类型将它的 requirement 设置为 alternative。

    浏览器流的常用部分

    Passwordless browser login common

  20. 点 Forms execution 的 Actions。
  21. 选择 Add execute。
  22. 从下拉列表中选择 Username Form。
  23. 点 Save。
  24. 单击 Username Form authentication type 所需的 Required，以将其要求设置为 required。

在这个阶段，表单需要用户名，但没有密码。我们必须启用密码验证来避免安全风险。

  1. 点 Forms 子流的 Actions。
  2. 点 Add flow。
  3. 输入 Authentication 作为别名。
  4. 点 Save。
  5. 单击 Authentication 身份验证类型的必需，以设置其要求。
  6. 点 Authentication 子流的 Actions。
  7. 单击 Add execution。
  8. 从下拉列表中选择 Webauthn Passwordless Authenticator。
  9. 点 Save。
  10. 点击 Webauthn Passwordent icator 身份验证类型的替代选择。
  11. 点 Authentication 子流的 Actions。
  12. 点 Add flow。
  13. 输入 Password with OTP 作为一个别名。
  14. 点 Save。
  15. 点击 OTP 身份验证类型 的替代方案，将其要求设置为替代方案。
  16. 点 带有 OTP 子流的密码 的 Actions。
  17. 单击 Add execution。
  18. 从下拉列表中选择 Password Form。
  19. 点 Save。
  20. 单击 Password Form authentication type 所需，以将其要求设置为必填。
  21. 点 带有 OTP 子流的密码 的 Actions。
  22. 单击 Add execution。
  23. 从下拉列表中选择 OTP Form。
  24. 点 Save。
  25. 点击 OTP Form 身份验证类型所需的设置要求。

最后，更改绑定。

  1. 单击 Bindings 选项卡。
  2. 点击 Browser Flow 下拉列表。
  3. 从下拉列表中选择 Browser Password-less。
  4. 点 Save。

免密码浏览器登录

Passwordless browser login

输入用户名后，流程如下：

如果用户记录了 WebAuthn无密码的凭证，他们可以使用这些凭证直接登录。这是无密码登录。用户还可以使用 OTP 选择 Password，因为 WebAuthn Passwordless execution 和 使用 OTP 流的 Password 设置为 alternatives。如果将其设定为 Required，则用户必须输入 WebAuthn、password 和 OTP。

如果用户选择带有 WebAuthn passwordless 验证的 Try another way 链接，用户可以在 Password 和 Security Key (WebAuthn passwordless) 间进行选择。选择密码时，用户需要继续使用分配的 OTP 登录。如果用户没有 WebAuthn 凭证，用户必须输入密码，然后 OTP。如果用户没有 OTP 凭证，则会要求您记录它。

注意

由于 WebAuthn 免密码执行设定为 替代方案，而不是 必需的，因此这个流不会要求用户注册 WebAuthn 凭据。用户若要具有 Webauthn 凭据，管理员必须向用户添加所需的操作。为此：

  1. 在 realm 中启用 Webauthn Register Passwordless 必需操作（请参阅 WebAuthn 文档）。
  2. 使用用户凭据管理菜单的 Credential Reset 部分设置必要的操作。

创建等高级流可能会产生副作用。例如，如果启用为用户重置密码的功能，可以通过密码表单访问此密码。在默认的 Reset Credentials 流中，用户必须输入其用户名。由于用户已在 浏览器式密码 流中之前输入了用户名，因此这个操作对于 Red Hat Single Sign-On 和 sub-optimal 对用户体验来说是不必要的。要解决这个问题，您可以：

  • 复制 重置凭据 流。将其名称设置为 "重置无密码"的凭据，例如：
  • 在 Choose user 执行的 Actions 菜单中选择 Delete。
  • 在 Bindings 菜单中，将 reset credential 流从 Reset Credentials 更改为 Reset Credentials forless

8.3.4. 使用步骤机制创建浏览器登录流程

这部分论述了如何使用步骤机制创建高级浏览器登录流。步骤身份验证的目的是允许根据用户的特定身份验证级别访问客户端或资源。

流程

  1. 在菜单中，单击 Authentication。
  2. 点 Flows 选项卡。
  3. 单击 New。
  4. 输入 Browser Incl Step up Mechanism 作为别名。
  5. 点 Save。
  6. 单击 Add execution。
  7. 从 item 列表中选择 Cookie。
  8. 点 Save。
  9. 点 Alternative，Cookie 验证类型将它的 requirement 设置为 alternative。
  10. 点 Add flow。
  11. 输入 Auth Flow 作为别名。
  12. 点 Save。
  13. 点 Alternative，Auth Flow 验证类型将它的 requirement 设置为 alternative。

现在，您可以为第一个身份验证级别配置网络流。

  1. 为 Auth Flow 点 Actions。
  2. 点 Add flow。
  3. 输入 1st Condition Flow 作为别名。
  4. 点 Save。
  5. 为 1st Condition Flow 验证类型点击 Conditional，将其要求设置为条件。
  6. 点 1st Condition Flow 的 Actions。
  7. 单击 Add execution。
  8. 从项列表中选择 Conditional - Authentication Level。
  9. 点 Save。
  10. 点 Conditional - Level Of Authentication authentication type 来设置其要求。
  11. 点 Authentication Conditional - Level 的 Actions。
  12. 单击 Config。
  13. 输入 级别 1 作为别名。
  14. 为验证级别(LoA)输入 1。
  15. 将 Max Age 设置为 36000。这个值以秒为单位，相当于 10 小时，这是在 realm 中设置的默认 SSO Session Max 超时。因此，当用户使用此级别进行身份验证时，后续的 SSO 登录可以重新使用此级别，用户不需要通过这个级别进行身份验证，直到用户会话结束前，默认为 10 小时。

  16. 点 Save

    为第一个身份验证级别配置条件

    authentication step up condition 1

  17. 点 1st Condition Flow 的 Actions。
  18. 单击 Add execution。
  19. 从 items 列表中选择 Username Password Form。
  20. 点 Save。
  21. 在 Username Password Form authentication type 中点 Required，以将其要求设置为 required。

现在，您可以为第二个身份验证级别配置网络流。

  1. 为 Auth Flow 点 Actions。
  2. 点 Add flow。
  3. 输入 2nd Condition Flow 作为一个别名。
  4. 点 Save。
  5. 为 2nd Condition Flow 验证类型点击 Conditional，将其要求设置为条件。
  6. 点击 2nd Condition Flow 的 Actions。
  7. 单击 Add execution。
  8. 从项列表中选择 Conditional - Authentication Level。
  9. 点 Save。
  10. 点 Conditional - Level Of Authentication authentication type 来设置其要求。
  11. 点 Authentication Conditional - Level 的 Actions。
  12. 单击 Config。
  13. 输入 Level 2 作为别名。
  14. 在验证级别(LoA)输入 2。
  15. 将 Max Age 设置为 0。因此，当用户验证时，此级别仅对当前身份验证有效，但不是后续 SSO 身份验证。因此，在请求此级别时，用户总是需要再次通过这个级别进行身份验证。

  16. 点 Save

    配置第二个身份验证级别的条件

    authentication step up condition 2

  17. 点击 2nd Condition Flow 的 Actions。
  18. 单击 Add execution。
  19. 从 item 列表中选择 OTP Form。
  20. 点 Save。
  21. 点击 OTP Form 身份验证类型所需的设置要求。

最后，更改绑定。

  1. 单击 Bindings 选项卡。
  2. 点 Browser Flow 项列表。
  3. 从项目列表中选择 Browser Incl Step up Mechanism。
  4. 点 Save。

使用步骤机制进行浏览器登录

authentication step up flow

请求特定的身份验证级别

要使用步骤机制，请在身份验证请求中指定请求的身份验证级别(LoA)。claim 参数用于此目的： 

https://{DOMAIN}/auth/realms/{REALMNAME}/protocol/openid-connect/auth?client_id={CLIENT-ID}&redirect_uri={REDIRECT-URI}&scope=openid&response_type=code&response_mode=query&nonce=exg16fxdjcu&claims=%7B%22id_token%22%3A%7B%22acr%22%3A%7B%22essential%22%3Atrue%2C%22values%22%3A%5B%22gold%22%5D%7D%7D%7D

claims 参数以 JSON 指定： 

claims= {
            "id_token": {
                "acr": {
                    "essential": true,
                    "values": ["gold"]
                }
            }
        }

Red Hat Single Sign-On javascript 适配器支持轻松构建此 JSON 并在登录请求中发送它。如需了解更多详细信息，请参阅 Javascript 适配器文档。

您还可以使用更简单的参数 acr_values 而不是 claims 参数以请求特定级别作为非意义。这在 OIDC 规格中提到。

您还可以为特定客户端配置默认级别，在参数 acr_values 或带有 acr 声明 的参数声明时使用。如需了解更多详细信息，请参阅 客户端 ACR 配置。

注意

要请求 acr_values 作为文本（如 gold）而不是数值，您可以配置 ACR 和 LoA 之间的映射。可以在 realm 级别（推荐）或客户端级别上配置它。有关配置，请参阅 ACR 到 LoA Mapping。

如需了解更多详细信息，请参阅 官方 OIDC 规格。

流逻辑

上述配置的身份验证流程的逻辑如下：
如果客户端需要高的身份验证级别，即身份验证 2 级别(LoA 2)，用户必须执行完整的双因素身份验证：Username/Password + OTP。但是，如果用户在 Keycloak 中已有一个会话，使用用户名和密码(LoA 1)登录，则用户只会请求第二个身份验证因素(OTP)。

条件中的 Max Age 选项决定了后续验证级别有效的时长（以秒为单位）。此设置有助于决定用户在后续身份验证过程中是否再次显示身份验证因素。如果 声明 或 acr_values 参数请求特定级别 X，并且用户已验证了级别 X，但其已过期（例如，最大期限配置为 310 秒前验证为 300，用户会被要求再次以特定级别重新验证。但是，如果该级别还没有过期，则用户将自动视为具有该级别的身份验证。

使用 Max Age 及值 0 意味着该特定级别仅对这个单一身份验证有效。因此，请求该级别的每个验证都需要再次通过该级别进行身份验证。这可用于应用程序中需要更高安全性的操作（例如发送付款），并且始终需要使用特定级别进行身份验证。

警告

请注意，当从客户端发送到 Red Hat Single Sign-On 时，在从客户端发送到 Red Hat Single Sign-On 时，可能会更改 声明 或 acr_values 等参数。如果客户端使用 PAR （推送授权请求）、请求对象或其他机制（阻止用户在 URL 中重写参数），则可以缓解这种情况。因此，在身份验证后，建议客户端检查 ID 令牌来再次检查令牌中的 acr 对应于预期的级别。

如果没有参数明确要求，Red Hat Single Sign-On 将要求身份验证在身份验证流中找到的第一个 LoA 条件，如上例中的 Username/Password。当用户已经通过该级别验证并且该级别已过期时，用户不需要重新验证，但令牌中的 acr 将具有值 0。因此，根据 OIDC Core 1.0 规格第 2 部分所述，这只 基于长期浏览器 Cookie 被视为身份验证。

注意

当管理员指定了多个流时，可能会发生冲突情况，将不同的 LoA 级别设置为不同的客户端，并为不同的客户端分配流。但是，该规则始终相同：如果用户具有特定级别，则只需要将该级别连接到客户端。它是管理员，确保 LoA 一致。

示例情境

  1. 最大期限的 1 条件配置为 300 秒。
  2. 发送登录请求，但不请求任何cr。将使用 1 级别，用户需要使用用户名和密码进行身份验证。令牌将具有 acr=1。
  3. 在 100 秒后发送另一个登录请求。由于 SSO 到期，用户会自动进行身份验证，令牌将返回 acr=1。
  4. 另一登录请求在 201 秒后发出（自 2 中的身份验证后计算为 301 秒）由于 SSO 的关系，用户会自动进行身份验证，但令牌将在级别 1 被视为过期时返回 acr=0。
  5. 发送另一个登录请求，但现在，它将在 声明 参数中明确请求为级别 1 的 ACR。用户需要使用用户名/密码重新进行身份验证，然后在令牌中返回 acr=1。

令牌中的 ACR 声明

ACR 声明通过在 acr 客户端范围中定义的 acr loa level 协议映射程序添加到令牌中。此客户端范围是 realm 默认客户端范围，因此将添加到 realm 中所有新创建的客户端。

如果您不希望令牌内部的 acr 声明或需要一些自定义逻辑来添加它，您可以从客户端中删除客户端范围。

请注意，当登录请求使用请求作为 基本 声明的 claim 参数发起请求 时，Red Hat Sign-On 将始终返回其中一个指定级别。如果无法返回指定级别之一（例如，如果请求的级别未知或大于身份验证流程中的配置条件），则 Red Hat Single Sign-On 将抛出错误。

8.3.5. 配置用户会话限制

对用户可以配置的会话数量限制。每个域或每个客户端都可以限制会话。

要向流添加会话限制，请执行以下步骤：

  1. 单击 流的 Add execute。
  2. 从项目列表中选择 User Session Count Limiter。
  3. 点 Save。
  4. 为 User Session Count Limiter 验证类型点 Required，将它的 requirement 设置为 required。
  5. 单击 User Session Count Limiter 的 Actions。
  6. 单击 Config。
  7. 输入此配置的别名。
  8. 输入用户可在此域中具有的最大会话数。如果使用 0，则禁用此检查。
  9. 输入用户可为客户端拥有的最大会话数。如果使用 0，则禁用此检查。

  10. 选择在达到限制后尝试创建会话时所需的行为。可用的 bahaviors 是： 

    Deny new session - when a new session is requested and the session limit is reached, no new sessions can be created.
Terminate oldest session - when a new session is requested and the session limit has been reached, the oldest session will be removed and the new session created.
  11. 另外，还可在达到限制时添加自定义错误消息。

请注意，用户会话限制应添加到绑定 浏览器流、Direct Grant Flow、Reset Credentials 以及任何配置的身份提供程序上的任何 post Login Flow 中。目前，管理员负责在不同配置之间保持一致性。

另外，CIBA 不提供用户会话限制功能。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.