6.3. 認証フロー

認証フローは、ログイン、登録、およびその他の Red Hat Single Sign-On ワークフロー時に発生する必要のあるすべての認証、画面、およびアクションのコンテナーです。管理コンソールの左側のメニュー項目 Authentication に移動し、Flows タブに移動する場合は、システムにある定義されたフローをすべて表示し、各フローに必要なアクションを確認し、チェックすることができます。

6.3.1. 組み込みフロー

Red Hat Single Sign-On には、一定数のビルトインフローが含まれています。これらのフローを変更することはできませんが、ニーズに合わせて要件を変更できます。

本セクションでは、ビルトインのブラウザーログインフローの手順について説明します。左側のドロップダウンリストで、browser を選択し、以下の画面に移動します。

ブラウザーフロー

browser flow

フロー選択リストに右にあるヒント (tiny question mark) にマウスをかざすと、フローの内容を説明することになります。

Auth Type コラムは、実行される認証またはアクションの名前です。認証がインデントされている場合、これはサブフローにあり、親の動作に応じて実行されないことがあります。Requirement 列は、アクションが実行されるかどうかを定義するラジオボタンのセットです。このコンテキストで各ラジオボタンが何をするか説明してください。

6.3.1.1. 実行要件

必須
フローが正常に実行されると評価されるには、フローの必要な要素をすべて成功したものとして評価する必要があります。つまり、要素の 1 つが原因でフローが失敗するのでない限り、フローの Required 要素すべてが上部から順に実行される必要があります。ただし、これは現在のフローに対してのみ当てはまります。サブフロー内の Required 要素は、そのサブフローが入力した場合にのみ処理されます。
代替方法
フローに Alternative 要素のみが含まれる場合、フローが正常に実行されると評価するには、1 つの要素のみを評価する必要があります。フロー内の Required フロー要素はフローを成功としてマークできるため、Required フロー要素が含まれるフロー内の Alternative フロー要素は実行されません。この場合、機能的に Disabled になります。
Disabled
Disabled 要素は評価されず、フローが成功したとマーク付けするためにカウントされません。
条件
この要件タイプは、サブフローでのみ設定できます。Conditional のサブフローには「Condition」実行を含めることができます。これらの「Condition」の実行は論理ステートメントとして評価する必要があります。すべての "Condition" 実行が true と評価すると、Conditional が Required としてサブフローが動作します。そうでない場合は、Conditional サブフローが Disabled として動作します。「Condition」実行が設定されていない場合、Conditional サブフローは Disabled として動作します。フローに「Condition」実行が含まれ、Conditions が Conditional に設定されていない場合は、「Condition」の実行は評価されず、機能的に Disabled とみなすことができます。

これは、例で説明する方が適切です。browser 認証フローを順番に説明します。

  1. 最初の認証タイプは Cookie です。ユーザーが初めてログインすると、セッションクッキーが設定されます。このクッキーがすでに設定されている場合、この認証タイプは成功します。この場合、Cookie プロバイダーによって成功が返され、フローのこのレベルの各実行が代替であるため、他の実行は実行されず、ログインに成功します。
  2. フローの 2 回目の実行は Kerberos の実行を確認します。このオーセンティケーターはデフォルトで無効になっており、スキップされます。
  3. 3 つ目の実行は、Identity Provider Redirector です。これは Actions > Config リンクを使用して設定し、アイデンティティーブローカー化用に別の IdP に自動的にリダイレクトします。
  4. 次回の実行は、Forms と呼ばれるサブフローです。このサブフローは 代替 としてマークされているため、Cookie 認証タイプが渡されると実行されません。このサブフローには、実行する必要がある追加の認証タイプが含まれます。このサブフローの実行がロードされ、同じ処理ロジックが発生します。
  5. Forms サブフローでの最初の実行は、Username Password Form です。この認証タイプにより、ユーザー名とパスワードがレンダリングされます。ユーザーは有効なユーザー名とパスワードに入力する必要があるため、required としてマークされます。
  6. Forms サブフローの 2 番目の実行は、新しいサブフロー (Browser - Conditional OTP サブフロー) です。このサブフローは conditional であるため、どのように実行されるかは Condition - User Configured 実行の評価の結果によって異なります。存在する場合は、このサブフローの実行がロードされ、同じ処理ロジックが発生します。
  7. 次回実行は Condition - User Configured です。これは、フローの他の実行がユーザーに設定されているかどうかを確認します。つまり、Browser - Conditional OTP サブフローは、ユーザーが OTP 認証情報が設定されている場合にのみ実行されることを意味します。
  8. 最終的な実行は OTP Form です。これは required とマークされますが、conditional サブフローの設定により、ユーザーが OTP 認証情報が設定されている場合にのみ実行されます。心当たりがない場合は、OTP フォームが見られません。