8.10. 条件流中的条件


执行要求 中所述,Condition 执行只能包含在 Conditional 子流中。如果所有条件执行评估为 true,则 Conditional 子流充当 必需您可以在 Conditional 子流中处理下一个执行。如果 Conditional 子流评估中包含的一些执行为 false,则整个子流被视为 Disabled

8.10.1. 可用条件

condition - 用户角色

此执行能够确定用户是否具有由 User role 字段定义的角色。如果用户具有必要的角色,则执行将被视为 true,并且评估其他执行。管理员必须定义以下字段:

Alias
描述执行的名称,它将显示在身份验证流中。
用户角色
用户应该执行此流的角色。要指定应用角色,语法为 appname.approle (如 myapp.myrole)。
condition - 用户配置
这会检查是否为用户配置了流中的其他执行。Execution requirements 部分包含 OTP 表单的示例。
condition - 用户属性

这会检查用户是否设置了 required 属性:可选,检查也可以评估组属性。可以对输出进行求值,这意味着用户不应具有属性。User Attributes 部分演示了如何添加自定义属性。您可以提供以下字段:

Alias
描述执行的名称,它将显示在身份验证流中。
属性名称
要检查的属性的名称。
预期属性值
属性中的预期值。
包含组属性
如果为 On,则条件检查是否有任何加入组是否有与配置的名称和值匹配的属性:此选项可能会影响性能
negate 输出
您可以对输出进行求反。换句话说,属性不应存在。
condition - 执行子流

条件检查之前的子流是否在身份验证过程中成功执行(或未执行)。因此,流可以根据之前的子流终止触发其他步骤。存在这些配置字段:

流名称
用于检查它是否已执行或未执行的子流名称。必需。
检查结果
当条件评估为 true 时。如果在配置的子流 执行时,如果执行为 true,则输出成功,否则为 false。如果 在没有执行 子流时返回 false,则输出成功,否则为 true (上一选项的负数)。
condition - 客户端范围

评估配置的客户端范围是否为请求身份验证的客户端范围的条件。存在这些配置字段:

客户端范围名称
客户端范围的名称,应显示为客户端的客户端范围,后者正在请求身份验证。如果请求的客户端范围是请求登录的客户端的默认客户端范围,则条件将评估为 true。如果请求的客户端范围是请求登录的客户端的可选客户端范围,如果客户端在 OIDC/OAuth2 客户端登录中由客户端 范围 发送,则条件将评估为 true。必需。
negate 输出
将 not 应用到检查结果。为 true 时,只有在配置的客户端范围不存在时,条件才会评估为 true。

8.10.2. 在条件流中明确拒绝/允许访问

您可以允许或拒绝访问条件流中的资源。这两个 验证器 拒绝访问和 允许访问控制 资源访问。

允许访问
身份验证程序将始终成功进行身份验证。此验证器不可配置。
拒绝访问

访问将始终被拒绝。您可以定义错误消息,它将显示给用户。您可以提供以下字段:

Alias
描述执行的名称,它将显示在身份验证流中。
错误消息
错误消息,显示给用户。错误消息可以作为特定消息提供,或者作为属性提供,以便将其与本地化结合使用。(例如"您没有角色 'admin'。", my-property-deny in messages 属性)留空,针对定义为属性 access-denied 的默认消息。

下面是一个示例,如何拒绝对没有 role1 的所有用户的访问,并显示由属性 deny-role1 定义的错误消息。这个示例包括 Condition - 用户角色Deny Access 执行。

浏览器流

Deny access flow

condition - 用户角色配置

Deny access role settings

Deny Access 的配置实际上非常简单。您可以指定一个任意 Alias 和所需信息,如下所示:

Deny access execution settings

最后一个事情是在 login theme messages_en.properties (用于英语)中定义带有错误消息的属性:

deny-role1 = You do not have required role!
Copy to Clipboard Toggle word wrap

8.10.3. 2FA 条件工作流示例

本节提供了一些条件工作流示例,它们以不同方式集成 2nd Factor Authentication (2FA)。示例复制默认 浏览器 流,并在 表单 子流中修改配置。

8.10.3.1. 条件 2FA 子流

默认 浏览器 流使用 Conditional OTP 子流,它已提供 2FA 带有 OTP Form (One Time Password)。遵循相同的理念,不同的 2FA 方法可以与 Condition - User Configured 集成。

2FA 所有替代方案

2FA all alternative

forms 子流包含另一个 2FA 条件子流,Condition - 用户已配置。允许三个 2FA 步骤(OTP, Webauthn and Recovery Codes)作为替代步骤。如果用户配置了三个选项之一,用户可以选择它们之一。因为子流是条件,如果没有配置 2FA 凭证,身份验证过程将成功完成。

8.10.3.2. 条件 2FA 子流和拒绝访问

第二个示例继续上一个示例。在 2FA 子流后,如果没有使用 2FA 检查之前的 2FA,则另一个流 Deny 访问。在这种情况下(用户没有配置 2FA 凭证),该访问将被拒绝。

2FA 所有替代方法和拒绝访问

2FA all alternative and deny access

执行 Condition - 子流配置为检测之前没有执行 2FA 子流。

执行子流的配置

Configuration for the sub-flow executed

如果没有执行,则 Deny 访问 会拒绝身份验证。

8.10.3.3. 带有 OTP 默认的条件 2FA 子流

最后一个示例与上一个示例非常相似。根据需要将 OTP Form 配置为拒绝访问,而不是拒绝访问。

2FA 带有 OTP 默认的替代

2FA all alternative with OTP default

在这个版本中,如果用户没有配置 2FA 方法,则会强制 OTP 设置以继续登录。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat