Access Gatewayとセッション

Access Gatewayはセッションと連携して保護対象リソースを保護します。

Access Gatewayは、Okta orgのプライマリメールアドレスを使ってユーザーセッションを作成、識別します。セキュリティ上の理由から、複数のユーザーアカウントで同じプライマリメールアドレスを使いまわさずに、ユーザーアカウントごとに一意のプライマリメールアドレスを使用することをお勧めします。これにより、ユニバーサルログアウトが有効な場合などに、プロファイルに同じプライマリメールアドレスが指定されたいずれかのユーザーがセッションを終了したときに、同一プライマリメールアドレスのすべてのユーザーのセッションが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つのセッションが付与されます。

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

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

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

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

シングルログアウトとユニバーサルログアウト

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

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