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はヘッダーフィールド、クッキー、その他の必須情報を使ってWebリクエストを編集し、保護対象アプリに提供します。その後、リソースがそれ自体のアプリヘッダーを作成して管理します。アプリセッションの設定は、アプリのポリシーによって管理されます。

セッションフロー

セッションは、Access GatewayまたはOktaから開始できます。

Access Gatewayまたはサービスプロバイダーベースのセッションフロー

このシナリオでは、エンドユーザーがアプリに直接アクセスします。ユーザーには1つのOktaセッションと、アクセスするアプリごとに1つのセッションが付与されます。

ユーザーが保護対象アプリに対して、Okta経由ではなく、直接アクセスを試みます。
Access Gatewayがリクエストを傍受してOktaにリダイレクトし、OktaがSecurity Assertion Markup Language（SAML）アサーションを実行します。
ユーザーのブラウザーがOktaにSAML認証リクエストを送信し、アプリにサインインします。認証に成功すると、OktaがOktaセッションを作成します。
OktaがAccess Gateway向けのSAMLアサーションを生成します。
ユーザーのブラウザーがAccess GatewayにSAMLアサーションを提示します。Access GatewayがAccess Gatewayセッションを作成します。
Access Gatewayが次のタスクを実行します。
1. Access Gatewayセッションを作成する。
2. ヘッダーやクッキー属性など、必要なアプリ機能拡張を追加する。
3. 必要な書き換えを行う。
4. バックエンド保護されたリソースへのリクエストをプロキシする。
バックエンド保護されたWebリソースはリクエストを受信すると、アプリセッションを作成し、応答をAccess Gatewayに返します。
Access Gatewayが必要な書き換えを行い、応答を返します。

OktaまたはIDプロバイダーベースのセッションフロー

このシナリオでは、エンドユーザーがOkta Dashboardを介してアプリにアクセスします。ユーザーには1つのOktaセッションと、アクセスするアプリごとに1つのセッションが付与されます。

ユーザーがOktaにサインインすると、OktaがそのユーザーのOktaセッションを作成します。
ユーザーがEnd-User Dashboardでアプリタイルをクリックすると、Access Gatewayにリダイレクトされます。
Access GatewayはAccess Gatewayセッションを作成します。
Access Gatewayが次のタスクを実行します。
1. ヘッダーやクッキー属性など、必要なアプリ機能拡張を追加する。
2. 必要な書き換えを行う。
3. バックエンド保護されたWebリソースにリダイレクトする。
バックエンド保護されたWebリソースはリクエストを受信すると、アプリセッションを作成し、応答をAccess Gatewayに返します。
Access Gatewayが必要な書き換えを行い、応答を返します。

シングルログアウトとUniversal Logout

Okta連携認証では、次の2種類のログアウトフローがサポートされます。

シングルログアウト：シングルログアウト（SLO）を使用すると、サービスプロバイダーが開始したフローでアプリとOktaセッションの両方から同時にサインアウトできます。SLOが有効な場合、Access Gatewayはサービスプロバイダーとして機能し、OktaはIDプロバイダーとして機能します。
Universal Logout：管理者は、アプリとAccess Gatewayの両方から同時にユーザーをサインアウトするフローを構成できます。Universal LogoutはユーザーをOktaからサインアウトしません。