Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

8.10. 条件付きフローの条件

実行要件 で述べたように、条件 実行は 条件付き サブフローにのみ含めることができます。すべての 条件 実行が true と評価されると、Conditional サブフローは Required として機能します。Conditional サブフローの次の実行を処理できます。Conditional サブフローに含まれる一部の実行が false と評価されると、サブフロー全体が Disabled と見なされます。

8.10.1. 利用可能な条件
リンクのコピー

Condition - User Role

この実行では、ユーザーに User role フィールドで定義されているロールがあるかどうかを判別できます。ユーザーに必要なロールが割り当てられている場合、実行は true と判断され、その他の実行が評価されます。管理者は以下のフィールドを定義する必要があります。

Alias
認証フローに表示される実行の名前を記述します。
User role
このフローを実行するために必要なユーザーロール。アプリケーションロールを指定する場合、構文は appname.approle(myapp.myrole など) です。
Condition - User Configured
これは、フローの他の実行がユーザーに設定されているかどうかを確認します。実行要件のセクションには、OTP フォームの例が含まれています。
Condition - User Attribute

ユーザーが必須の属性を設定したかチェックします。このチェックでは、オプションでグループ属性も評価できます。出力が否定される可能性があります。この場合、ユーザーに属性を設定することはできません。ユーザー属性 セクションに、カスタム属性を追加する方法が説明されています。以下のフィールドを指定できます。

Alias
認証フローに表示される実行の名前を記述します。
Attribute name
確認する属性の名前。
Expected attribute value
属性の想定される値。
Include group attributes
この条件を On にすると、参加したグループのいずれかに、設定された名前と値に一致する属性が 1 つあるかチェックします。このオプションはパフォーマンスに影響を与える可能性があります。
Negate output
出力を否定することができます。つまり、この属性は存在しません。
条件 - sub-flow executed

この条件は、認証プロセスで前のサブフローが正常に実行されたかどうか (または実行されなかったかどうか) をチェックします。したがって、フローは以前のサブフローの終了に基づいて他のステップをトリガーできます。次の設定フィールドが存在します。

Flow name
実行されたかどうかを確認するサブフロー名。必須。
Check result
条件が true と評価された場合。設定したサブフローが実行され、Success と出力された場合に、executed は true を、それ以外は false を返します。サブフローが実行され、Success と出力された場合に、not-executed は false を、それ以外の場合は true (前のオプションの否定) を返します。
条件 - client scope

認証を要求するクライアントのクライアントスコープとして設定されたクライアントスコープが存在するかどうかを評価する条件。次の設定フィールドが存在します。

Client scope name
認証をリクエストするクライアントのクライアントスコープとして存在する必要があるクライアントスコープの名前。ログインをリクエストしているクライアントにとって、リクエストされたクライアントスコープがデフォルトスコープである場合、この条件は true として評価されます。リクエストされたクライアントスコープが、ログインをリクエストしているクライアントに設定された任意のクライアントスコープである場合、クライアントがログインリクエストの中でそのスコープを指定して送信している場合 (例: OIDC/OAuth2 の scope パラメータなど)、条件は true として評価されます。必須。
Negate output
チェック結果に NOT を適用します。これが true の場合、設定されたクライアントスコープが存在しない場合にのみ、条件は true と評価されます。

8.10.2. 条件付きフローでのアクセスの明示的な拒否/許可
リンクのコピー

条件付きフローのリソースへのアクセスを許可または拒否できます。2 つのオーセンティケーターの Deny Access と Allow Access は、条件でリソースへのアクセスを制御します。

Allow Access
オーセンティケーターは常に認証に成功します。このオーセンティケーターは設定できません。
Deny Access

アクセスは常に拒否されます。ユーザーに表示されるエラーメッセージを定義できます。以下のフィールドを指定できます。

Alias
認証フローに表示される実行の名前を記述します。
エラーメッセージ
ユーザーに表示されるエラーメッセージ。エラーメッセージは、ローカリゼーションで使用するために、特定のメッセージまたはプロパティーとして提供できます。(つまり"You do not have the role 'admin'."、メッセージプロパティーの my-property-deny) プロパティー access-denied として定義されたデフォルトメッセージの場合は空白のままにします。

以下の例は、ロール role1 を持たないすべてのユーザーのアクセスを拒否し、プロパティー deny-role1 で定義されたエラーメッセージを表示する方法を示しています。この例には、Condition - User Role および Deny Access 実行が含まれます。

Browser Flow

Deny access flow

Condition - user role configuration

Deny access role settings

Deny Access の設定は非常に簡単です。以下のように、任意のエイリアスと必要なメッセージを指定できます。

Deny access execution settings

最後に、ログインテーマのエラーメッセージのプロパティー messages_en.properties(英語の場合) を定義します。 

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

8.10.3. 2FA 条件付きワークフローの例
リンクのコピー

このセクションでは、さまざまな方法で二要素認証 (2FA) を統合する条件付きワークフローの例をいくつか紹介します。例では、デフォルトの browser フローをコピーし、forms サブフロー内の設定を変更します。

8.10.3.1. Conditional 2FA サブフロー
リンクのコピー

デフォルトの browser フローは、OTP フォーム (ワンタイムパスワード) を使用した 2FA をすでに提供する Conditional OTP サブフローを使用します。同じように、さまざまな 2FA 方式を Condition - User Configured と統合できます。

2FA all alternative

2FA all alternative

forms サブフローには Condition - user configured のある別の 2FA 条件付きサブフローが含まれています。代わりのステップとして、3 つの 2FA のステップ (OTP、Webauthn、リカバリーコード) が許可されます。ユーザー向けに設定されている場合は、3 つのオプションのいずれかを選択できます。サブフローは条件付きであるため、2FA 認証情報が設定されていない場合でも認証プロセスは正常に完了します。

8.10.3.2. Conditional 2FA サブフローと Deny access
リンクのコピー

2 番目の例は前の例の続きです。2FA サブフローの後、別のフロー Deny access if no 2FA を使用して、前の 2FA が実行されなかったかどうかを確認します。その場合 (ユーザーに 2FA 認証情報が設定されていない場合)、アクセスは拒否されます。

2FA all alternative および Deny access

2FA all alternative and deny access

Condition - sub-flow executed は 2FA サブフローが以前に実行されていないかどうかを検出するように設定されています。

sub-flow executed の設定

Configuration for the sub-flow executed

Deny access のステップは、実行されない場合、認証を拒否します。

8.10.3.3. OTP がデフォルトの Conditional 2FA サブフロー
リンクのコピー

最後の例は前の例と非常に似ています。アクセスを拒否する代わりに、必要に応じて OTP Form のステップが設定されます。

OTP がデフォルトの 2FA all alternative

2FA all alternative with OTP default

このフローでは、ユーザーが 2FA 方式をいずれも設定していない場合は、OTP 設定を有効にし、ログインを続行します。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat