Access Gatewayおよびセッション
項目
概要
Access Gatewayを使用した操作では、以下の3つのタイプのセッションが存在します：
- Oktaセッション - エンドユーザーがOkta orgにログインしてアプリケーションにアクセスした、またはAccess GatewayからOkta orgへリクエストがリダイレクトされた時にOktaセッションが作成されます。OktaセッションはOkta orgで管理され、そのorgと関連付けれられた設定に従います。ユーザーがOkta内での認証に成功するとOktaセッションが作成されます。Okta管理者は様々なセッションタイムアウトやその他の詳細を管理できます。
- Access Gateway セッション - ユーザーが保護対象Webリソースへのアクセスを要求すると、Access Gatewayがアプリケーションリクエストのセッションを作成します。タイムアウトおよびその他の動作はアプリケーション固有です。詳しくはアプリケーション詳細設定についてをご覧ください。
Access Gatewayアプリケーション セッションは、Okta org内でユーザー認証が成功した後、基盤にある保護対象リソースへのアクセスが許可された場合に限り作成されます。 - アプリケーション セッション - ユーザーが認証された後にアプリケーション セッションが作成され、Access Gateway内で保護対象リソースへのアクセス権を持ち、基盤にある保護対象Webリソースにリクエストがリダイレクトされます。
セッションを作成する時に以下のユーザー情報が使用されます：
| 実行者 | 内容 | 説明 |
|---|---|---|
| Oktaセッション |
| ユーザーはOkta内で接続と認証を行うことができます。通常はユーザー名／パスワードと、Okta Orgで要求される1つ以上の追加のMFA要素が含まれます。認証されると、アプリケーションへのアクセス要求の結果、Oktaセッションが作成されます。Oktaセッションは、元のOkta org内で定義された設定、ポリシー、およびコントロールに従います。 |
| Access Gatewayアプリケーション固有のセッション |
| ユーザーは、メールアドレスまたはその他の識別子でAccess Gatewayに識別され、要求された保護対象Webリソースに関連付けられたグループのメンバーです。いったん識別されると、Access Gatewayは認証済みユーザーリクエストに関連付けられたアプリケーション固有のセッションを作成します。Access Gatewayアプリケーション設定は、アプリケーション定義と関連付けられた設定とポリシーの適用を受けます。アプリケーション固有の設定および動作の管理については、アプリケーションの動作を管理するをご覧ください。 |
| アプリケーション セッション |
| Access Gatewayが保護対象Webリソースのリクエストを下層にある保護対象リソースにプロキシします。リクエストには、ヘッダーフィールド、Cookie、およびアプリケーションに必要なその他の情報が含まれています。アプリケーション固有のリクエストがアプリケーションに提供され、そこで独自のアプリケーション固有のヘッダーを作成して管理します。アプリケーション セッション固有のライフサイクル、タイムアウト、その他の動作については、保護対象Webアプリケーションの資料をご覧ください。 |
サービスプロバイダーベースのフロー
サービスプロバイダーベースのフロー：
サービスプロバイダーベースのフロー
サービスプロバイダーベースのフローの例では、任意の数のアプリケーションを含めることができます。これらは、手順6(ab)、7(ab) および8(ab) で示されています。
Oktaレベルでは、エンドユーザーは単一セッションを保有します。
Access Gatewayおよびバック アプリケーションレベルでは、アクセスされているアプリケーションの数だけセッションが存在します。
- ユーザーがアプリケーションへのアクセスを要求。
- Access Gatewayがリクエストを傍受し、OktaにリダイレクトしてSAMLアサーションを実行。
- ユーザー（ブラウザー）がSAML認証要求をOktaに送信し、Oktaポリシーに従ってOktaにログイン。
成功すると、OktaがOktaセッションを作成。 - OktaがAccess Gateway向けのSAMLアサーションを生成。
- ユーザー（ブラウザー）がSAMLアサーションをAccess Gatewayに提示。
Access GatewayがAccess GatewayセッションCookieを作成。 - Access GatewayがAccess Gatewayセッションを作成し、必要なアプリケーション強化（ヘッダーまたはCookie属性など）を追加し、必要な上書きを実行し、リクエストをバッキング保護されたリソースにプロキシします。
- バック保護対象Webリソースがリクエストを受信し、アプリケーションセッションを作成し、応答をAccess Gatewayに返します。
- Access Gatewayが必要な上書きを実行し応答を返します。
IDプロバイダー（Okta）ベースのフロー
IDプロバイダーベースのフロー：
IDPフロー
- ユーザーがOktaにログイン。Oktaセッションが作成される。
- ユーザーがOktaダッシュボードからアプリケーションを選択し、Access Gatewayにリダイレクトされる。Access GatewayがAccess Gatewayセッションを作成
- Access Gatewayが必要なアプリケーション強化（ヘッダーまたはCookie属性など）を追加し、
必要な上書きを実行し、リクエストをバック保護されたリソースにプロキシします。 - バッキング保護対象Webリソースがリクエストを受信し、アプリケーションセッションを作成し、応答をAccess Gatewayに返します。
- Access Gatewayが必要な上書きを実行し応答を返します。
セッション ライフサイクルについて
各セッションに独自のライフサイクルがあることを理解することが重要になります。
- 各Okta orgログインが単一セッションを持ち、Okta orgのポリシーで管理され制御されています。これらのポリシーはセッション作成、タイムアウト、ログアウトおよび無効化を定義します。
- 各Access Gatewayアプリケーションには独自のセッションがあり、関連付けられたアプリケーション定義と関連付けられた動作によって管理、制御されます。詳しくはアプリケーションの動作を管理するをご覧ください。
Access Gatewayセッションおよび高可用性
Access Gatewayは高可用性クラスターのインスタンス間でセッション情報を共有しません。ロードバランサーによってフロントエンドにされるクラスターを定義する際は、セッションアフィニティ（「スティッキーセッション」とも呼ばれる）を指定して後続のリクエストが同じAccess Gatewayインスタンスにルートされるようにする必要があります。 - 各アプリケーションセッションはアプリケーションのポリシーで管理されます。詳しくはアプリケーション固有の資料をご覧ください。
アプリケーションのシングルログアウト
Oktaフェデレーション認証は、アプリケーションのシングルログアウト機能、いわゆるSLOをサポートします。SLOを使用すると、サービスプロバイダー開始フローを構成してアプリケーションとOktaセッションを同時にサインアウトできます。SLOを有効にすると、Access Gatewayはサービスプロバイダーとして、OktaはIDプロバイダーとして機能します。
エンドユーザーがAccess Gatewayからログアウトすると、自動的にOktaからもログアウトします。
詳しい説明と構成については、アプリ統合でシングルログアウトを構成するをご覧ください。