【Okta】Org2Org のサインインと再認証を IdP Org に集約する

» Okta » 技術
テクニカルサポート

はじめに

こんにちは、ネクストモード株式会社テクニカルサポート担当です。

Org2Org シリーズでは、複数の Okta テナントを連携する Hub & Spoke 構成について、OIDC による SSO と OAuth 2.0 によるユーザープロビジョニングを紹介してきました。

Org2Org 構成では、認証を担う IdP Org のダッシュボードから SP Org へサインインできます。一方、SP Org からサインインを開始する場合や、利用中に再認証が必要になった場合は、適切な IdP へ遷移するための設定を確認する必要があります。また、両 Org の認証ポリシーによっては、MFA や Authenticator の登録が追加で求められる場合があります。

シリーズ第3回となる本記事では、Group Push で同期したグループを対象に SP Org 側の Authenticator 登録ポリシーを調整し、IdP へのルーティングと再認証を設定します。Claims Sharing についても確認し、セキュリティ要件とユーザーの利便性の両立を目指します。

本シリーズの各記事は以下のとおりです。

それでは、実際の設定方法を見ていきましょう。

 

設定方法

本記事でも、認証を担う Spoke 側のテナントを「IdP Org」、認証を委ねる Hub 側のテナントを「SP Org」と呼びます。

事前準備

前回までに、OIDC による SSO と、IdP Org から SP Org へのユーザープロビジョニングが設定済みであることを前提に進めます。ここでは、後続の Authenticator 登録ポリシーの適用対象となるグループを SP Org に同期し、Claims Sharing に必要な設定を確認します。

IdP Org 側：グループの作成と同期

  1. IdP Org 側の管理画面で Directory > Groups を開き、Add group をクリックします。
  2. 今回は、Authenticator 登録ポリシーの対象を識別するためのグループとして、「Org2Org User」を作成します。
  3. 作成したグループを開き、Assign people から動作確認に使用するテストユーザーを追加します。
  4. IdP Org 側の Org2Org アプリ「SP Org」を開き、Push Groups タブから作成した Okta グループ「Org2Org User」を指定します。
  5. SP Org 側の Directory > Groups でプッシュされたグループを開き、テストユーザーがメンバーとして反映されていることを確認します。

アプリ割り当て用と Group Push 用には別々のグループを使用します。また、プッシュしたグループのメンバーは IdP Org 側で管理します。詳しくは グループプッシュのトラブルシューティング と Group Push の前提条件 を参照してください。

EA 機能の有効化

  1. SP Org の管理画面で Settings > Features を開き、EA 機能「Support for re-authentication with an external IdP」を有効化します。
    Okta SP Org の Settings > Features 画面で、外部 IdP による再認証を有効化する機能を示すスクリーンショットです。

  2. SP Org と IdP Org のそれぞれの管理画面で Settings > Features を開き、EA 機能「Device claims support for Okta-to-Okta Claims Sharing」を両方の Org で有効化します。
    Okta の Settings > Features 画面で、Okta-to-Okta Claims Sharing のデバイスクレーム対応を両 Org で有効にする設定を示します。
     

SP Org の設定

以降の操作は、すべて SP Org 側の管理画面で行います。事前準備で同期したグループを対象に Authenticator 登録ポリシーを設定し、再認証時と SP Org からのサインイン開始時に IdP Org へ遷移するための設定を行います。

Authenticator 登録ポリシーの追加

  1. Security > Authenticators を開き、Enrollment タブで Add a Policy をクリックします。
  2. Policy name を入力し、Assign to groups に事前準備で同期したグループ「Org2Org User」を指定します。
    Okta SP Org の Authenticator Enrollment Policy 設定画面で、Group Push で同期した対象グループをポリシーに割り当てる操作を示します。
     
  3. 各 Authenticator の登録設定を確認し、Password を Required に設定し、Create policy をクリックします。その他の Authenticator は、このポリシーでは Required にせず、運用に応じて Optional または Disabled を選択します。
    Okta の Authenticator 登録設定画面で、Password を Required にし、ほかの Authenticator の登録要件を選択するポリシー設定を示します。
     
  4. Add Rule 画面が表示されます。Rule name を入力し、その他の設定はデフォルトのままにし、Create rule をクリックします。
    Okta の Authenticator Enrollment Policy に追加する Rule の作成画面で、ルール名と条件を設定してポリシーを適用する流れを示します。
     
  5. 作成後、ポリシー一覧で優先順位を確認し、対象ユーザーに意図したポリシーが適用される位置に配置します。

参考：Authenticator 登録ポリシーを作成する

再認証時のリダイレクト設定

  1. Security > Identity Providers を開き、Identity claims sourcing タブを選択します。
  2. Re-authentication to IdP の Edit をクリックし、Re-authentication routing に Most last active SSO IdP を選択します。
  3. Eligible IdPs for re-authentication で All IdPs that meet the requirements を選択します。要件を満たすすべての IdP が再認証の対象になります。設定を確認し、Save をクリックします。
    Okta SP Org の Identity claims sourcing 設定画面で、再認証時に最後に利用した SSO IdP へ戻すルーティング条件を示します。
     

参考：再認証のためにフェデレーションユーザーを IdP にリダイレクトする

IdP Routing Rule の追加

  1. Security > Identity Providers を開き、Routing Rules タブで Add Routing Rule をクリックします。以下の設定を行い、Create Rule をクリックします。
    • Rule Name：Route to IdP Org（ルール名の例）
    • User matches：Domain list on login を選択し、対象ユーザーのログインドメインを入力します。ここでは例として example.com を指定します。実際の環境では対象ユーザーのドメインに置き換えてください。
    • Use this identity provider：作成済みの「IdP Org」を選択します。
    Okta SP Org の IdP Routing Rule 設定画面で、ログインドメインに一致するユーザーを指定した IdP Org へ誘導する条件を示します。

  2. ルールを有効化後に優先順位を確認し、意図した条件で評価されるよう配置します。

参考：ID プロバイダーのルーティングルールを構成する

 

設定の解説

Authenticator 登録ポリシー

このポリシーでは、SP Org 側での Authenticator の登録要件を設定します。少なくとも1つを Required にする必要があるため、本構成では IdP Org から同期される Password を指定し、ユーザーによる SP Org 側での新たな設定を不要にしています。その他の Authenticator は Optional または Disabled としますが、Optional の場合は登録を省略できるものの、登録を促す画面が表示される場合があります。

再認証と初回サインインのルーティング

「Support for re-authentication with an external IdP」は、再認証が必要になった Org2Org ユーザーを認証元の IdP に戻すための機能です。有効化後、Identity claims sourcing と再認証を要求するポリシーを設定します。

Identity claims sourcing は再認証時の遷移先を指定するもので、初回サインインの遷移先は IdP Routing Rule で設定します。再認証時の動作は Claims Sharing やポリシーの要件にも左右され、IdP に戻った後に追加の認証が求められる場合があります。

今回の Routing Rule は、ログインドメインが example.com のユーザーを IdP Org にルーティングする設定です。同じドメインの複数のユーザーに影響するため、ルールの優先順位と対象範囲を確認してください。対象外のユーザーや管理者・緊急用アカウントについても、想定したサインイン経路が維持されることを確認します。

デバイスクレームの共有

Claims Sharing では、IdP Org で使用した認証要素に関する認証クレームを SP Org のポリシー評価に活用できます。これに対し、デバイスクレームは Registered や Managed などのデバイス状態に関する情報です。

「Device claims support for Okta-to-Okta Claims Sharing」は、IdP Org で Okta Verify による認証を行った際のデバイス状態を SP Org のポリシー評価に利用するための機能です。OIDC による SSO では、デバイス情報が ID トークンの okta_auth に含まれます。

どちらのクレームも、SP Org の要件を常に満たせるわけではありません。認証方法やデバイス状態がポリシーの条件に合わない場合は、追加認証やアクセス拒否などにつながることがあります。

 

動作確認・検証結果

設定の動作確認

まずはテストユーザーを使い、管理者のセッションと混同しないよう、別のブラウザープロファイルやプライベートウィンドウで確認します。

  1. 初回サインインのルーティング：対象ドメインのテストユーザーで SP Org からサインインを開始すると、IdP Org に遷移し、FastPass で認証した後に、SP Org 側のダッシュボードが表示されました。
  2. Authenticator 登録ポリシー：同期したグループに所属し、SP Org 側で Authenticator が未登録のテストユーザーを使用しました。IdP Org へルーティングされて認証した後、SP Org 側で Okta Verify などの Authenticator 登録が求められないことを確認できました。
  3. 再認証：テスト対象の認証ポリシーで設定した再認証頻度が経過後に対象アプリへアクセスし、意図したとおりに IdP Org へ遷移することが確認できました。
    検証時は、以下の Prompt for authentication で再認証頻度を調整すると、動作を確認しやすくなります。
    Okta SP Org の認証ポリシー画面で、再認証頻度（Prompt for authentication）を調整して再認証の動作を検証しやすくする設定項目を示すスクリーンショットです。
     

デバイスクレームの検証結果

デバイスの条件を変更して検証したところ、次の結果となりました。

  • Registered を指定した場合：SP Org の認証ポリシーで Device state is を Registered に設定し、IdP Org で FastPass による認証を行いました。SP Org 側で追加認証を求められることなくサインインできました。
  • Device Assurance Policies を指定した場合：SP Org にサインインできませんでした。

Okta Knowledge Base 記事 によると、デバイスクレーム共有で扱えるのは Registered や Managed といった大まかなデバイス状態です。OS バージョンやディスク暗号化状態など、詳細な Device Assurance 条件を評価するための情報は共有されません。今回の結果も、この制限に関連している可能性があります。

詳細なデバイス条件が必要な場合は、IdP Org 側の認証ポリシーで評価する構成を検討してください。SP Org 側の条件を変更する際は、他のサインイン経路にも必要なセキュリティ要件が適用されることを確認します。

なお、デバイスクレーム共有と再認証時のリダイレクトは別の機能です。デバイスクレーム共有を有効化しても MFA の重複が必ず解消されるわけではなく、認証クレームの扱いや SP Org 側のポリシー要件に応じて追加認証が求められることがあります。

 

参考リンク

 

まとめ

今回は、Org2Org 構成で IdP Org を中心とした認証フローを整えるために、Group Push によるグループ同期と、SP Org 側の Authenticator 登録ポリシー、初回サインイン・再認証時のルーティングを設定しました。あわせて、デバイスクレーム共有の検証結果と制限事項を紹介しました。

これらの設定により、SP Org 側での Authenticator 登録要件と、認証時の遷移先を調整できます。ただし、追加認証の有無は Claims Sharing の利用状況や各 Org のポリシーによって異なります。まずはテストユーザーで動作を確認し、管理者や緊急用アカウントのサインイン経路にも影響がないことを確かめてから、適用範囲を広げていくとよいでしょう。

本シリーズでは、OIDC による SSO、OAuth 2.0 によるプロビジョニング、認証・Authenticator 登録ポリシーの調整を取り上げました。ユーザーの同期からサインイン、再認証までを一連の流れとして確認し、自社のセキュリティ要件と運用に合った Org2Org 構成に整えていきましょう。

Okta に関するお問い合わせ

「グループ会社ごとの Okta を連携したい」「MFA の重複や再認証を、自社の運用に合わせて調整したい」とお考えの方は、ぜひネクストモードへご相談ください。

SaaSバナー_Okta