Access Gatewayとセッション
Access Gatewayはセッションと連携して保護対象リソースを保護します。
Access Gatewayは、Okta orgのプライマリメールアドレスを使ってユーザーセッションを作成、識別します。セキュリティ上の理由から、複数のユーザーアカウントで同じプライマリメールアドレスを使いまわさずに、ユーザーアカウントごとに一意のプライマリメールアドレスを使用することをお勧めします。これにより、Universal Logoutが有効な場合などに、プロファイルに同じプライマリメールアドレスが指定されたいずれかのユーザーがセッションを終了したときに、同一プライマリメールアドレスのすべてのユーザーのセッションがOktaによって終了されるのを防止できます。
セッションのタイプとライフサイクル
Access Gatewayは、ユーザーのアクセス対象に応じて次の3種類のセッションを使用します。
-
Oktaセッション:ユーザーがorgに対して直接認証を行うか、Access Gatewayがリクエストをorgにリダイレクトすると、Oktaはセッションを作成します。管理者は、Okta org内でこれらのセッションの条件を構成できます。
-
Access Gatewayセッション:ユーザーが保護対象アプリへのアクセスをリクエストし、Oktaがそれを認証すると、Access Gatewayはこのセッションを作成します。管理者は、これらのセッションをAccess Gateway管理者UIコンソールで管理します。「高度なアプリケーション設定」および「アプリケーション動作の定義」を参照してください。Access Gatewayは、高可用性クラスターのインスタンス間ではセッション情報を共有しません。クラスターの前にロードバランサーをデプロイするときは、セッションアフィニティ(スティッキーセッションとも呼ばれます)を指定する必要があります。これにより、以降のリクエストは同一のAccess Gatewayインスタンスにルーティングされます。
-
アプリケーションセッション:Oktaがユーザーを認証した後、またはリクエストが保護対象アプリにリダイレクトされたときに、Access Gatewayはこのセッションを作成します。Access Gatewayは、ヘッダーフィールド、cookie、その他の必須情報を使ってウェブリクエストを修正し、それを保護対象アプリに提供します。その後、リソースがそれ自体のアプリケーションヘッダーを作成して管理します。アプリケーションセッションの設定は、アプリケーションのポリシーによって管理されます。
セッションフロー
セッションは、Access GatewayまたはOktaから開始できます。
Access Gatewayまたはサービスプロバイダーベースのセッションフロー
このシナリオでは、エンドユーザーはアプリケーションに直接アクセスします。ユーザーには1つのOktaセッションと、アクセスするアプリケーションごとに1つのセッションが付与されます。
- ユーザーが保護対象アプリケーションに対し、Okta経由ではなく、直接アクセスを試みます。
- Access Gatewayがリクエストを傍受し、SAMLサーションを実行するOktaにリダイレクトします。
- ユーザーのブラウザーがSAML認証リクエストをOktaに送信し、アプリケーションにサインインします。認証に成功すると、OktaがOktaセッションを作成します。
- OktaがAccess Gateway向けのSAMLアサーションを生成します。
- ユーザーのブラウザーがAccess GatewayにSAMLアサーションを提示します。Access GatewayがAccess Gatewayセッションを作成します。
- Access Gatewayが次のタスクを実行します。
- Access Gatewayセッションを作成する。
- ヘッダーやcookie属性など、必要なアプリケーション機能強化を追加する。
- 必要な書き換えを行う。
- バックエンド保護されたリソースへのリクエストをプロキシする。
- バックエンド保護されたWebリソースはリクエストを受信すると、アプリセッションを作成し、応答をAccess Gatewayに返します。
- Access Gatewayが必要な書き換えを行い、応答を返します。
OktaまたはIDプロバイダーベースのセッションフロー
このシナリオでは、エンドユーザーはOktaダッシュボードを介してアプリケーションにアクセスします。ユーザーには1つのOktaセッションと、アクセスするアプリケーションごとに1つのセッションが付与されます。
- ユーザーがOktaにサインインすると、OktaがそのユーザーのOktaセッションを作成します。
- ユーザーがEnd-User Dashboardでアプリタイルをクリックすると、Access Gatewayにリダイレクトされます。
- Access GatewayはAccess Gatewayセッションを作成します。
- Access Gatewayが次のタスクを実行します。
- ヘッダーやcookie属性など、必要なアプリケーション機能強化を追加する。
- 必要な書き換えを行う。
- バックエンド保護されたWebリソースにリダイレクトする。
- バックエンド保護されたWebリソースはリクエストを受信すると、アプリケーションセッションを作成し、応答をAccess Gatewayに返します。
- Access Gatewayが必要な書き換えを行い、応答を返します。
シングルログアウトとUniversal Logout
Okta連携認証では、次の2種類のログアウトフローがサポートされます。
-
シングルログアウト:シングルログアウト(SLO)を使用すると、サービスプロバイダーが開始したフローでアプリケーションとOktaセッションの両方から同時にサインアウトできます。SLOが有効な場合、Access Gatewayはサービスプロバイダーとして機能し、OktaはIDプロバイダーとして機能します。
-
Universal Logout:管理者は、アプリとAccess Gatewayの両方から同時にユーザーをサインアウトするフローを構成できます。Universal LogoutはユーザーをOktaからサインアウトしません。
「アプリ統合でシングルログアウトを構成する」および「アプリケーション動作の定義」を参照してください。