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が次のタスクを実行します。
- Access Gatewayセッションを作成する。
- ヘッダーやクッキー属性など、必要なアプリ機能拡張を追加する。
- 必要な書き換えを行う。
- バックエンド保護されたリソースへのリクエストをプロキシする。
- バックエンド保護された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が次のタスクを実行します。
- ヘッダーやクッキー属性など、必要なアプリ機能拡張を追加する。
- 必要な書き換えを行う。
- バックエンド保護されたWebリソースにリダイレクトする。
- バックエンド保護されたWebリソースはリクエストを受信すると、アプリセッションを作成し、応答をAccess Gatewayに返します。
- Access Gatewayが必要な書き換えを行い、応答を返します。
シングルログアウトとUniversal Logout
Okta連携認証では、次の2種類のログアウトフローがサポートされます。
-
シングルログアウト:シングルログアウト(SLO)を使用すると、サービスプロバイダーが開始したフローでアプリとOktaセッションの両方から同時にサインアウトできます。SLOが有効な場合、Access Gatewayはサービスプロバイダーとして機能し、OktaはIDプロバイダーとして機能します。
-
Universal Logout:管理者は、アプリとAccess Gatewayの両方から同時にユーザーをサインアウトするフローを構成できます。Universal LogoutはユーザーをOktaからサインアウトしません。
「アプリ統合でシングルログアウトを構成する」および「アプリケーション動作の定義」を参照してください。