1. Oracle Access Management管理者ガイド
  2. Access Managerの設定とエージェントの管理
  3. Access Managerセッションの維持

16 Access Managerセッションの維持

Access Managerセッションは認証中に作成され、認証したユーザーおよびクライアントにバインドされます。Access Managerセッションは、特定のセッション・ライフサイクルの間維持され、追跡およびポリシー強制を行います(管理者によって手動で、または自動化されたフローを使用して実行されます)。

Access Managerセッションのライフサイクルは、セッションの作成、更新、アイドルおよび期限切れの状態遷移で構成されています。

次の各トピックでは、Access Managerのセッションの概念および手順について説明します。

16.1 Access Managerのセッション管理の概要

Oracle Access Managementのこの12.2.1.3.0リリースでは、Access Managerセッションは、データベースによって支えられたサーバー側で管理されます。

OAM 12.2.1.3.0サーバーは、データベースに支えられたサーバー側セッション・マネージャをサポートして、OAMサーバー・クラスタの複数ノードの全体でセッション状態を同期させます。セッションは、AM_SESSION表に保存されます。

セッション・マネージャは、OAMサーバーによって一意に識別されたアクティブなセッションのデータを処理します。セッションのライフサイクルは、クライアント側にセッションIDを格納することによってサーバー側で管理されます。セッションIDは、OAM 12cサーバーに格納されたユーザー・セッションを一意に識別し、以降のリクエストにおいてサーバー・セッション・ストアからセッションをフェッチし、クライアントの状態を識別するために使用されます。

OAMサーバーはセッションをトークン(セッション・トークン)に変換し、レスポンスに入れて送信します。トークンには、あとでセッションを再構築するために以降のアクセスでデータベースに問い合わせる情報が含まれます。以降のリクエストで、トークンがリクエストから取得されてセッションを識別およびフェッチし、ログインしているユーザーのすべての詳細を取得します。

サーバー側セッションがデータベースに支えられているため、データベースからフェッチされるセッションがアクセス操作時に失敗しないように、データベースが常に使用可能である必要があります。OAM 12.2.1.3.0には、データベースが使用できないときにアクセス操作をサポートするTokenized Session Managementが用意されています。

データベース使用不能シナリオ

OAM 12.2.1.3.0では、次のシナリオのみがセッション・マネージャによりデータベース使用不能状態とみなされます。

  • データベースが停止している

  • 接続プールの枯渇のため、データベースに接続するための空き接続がない

  • ネットワーク遅延の問題のため、データベース接続性およびデータベース操作の遅延が悪化する

ノート:

OAMドメインの管理サーバー、ポリシー・マネージャおよびOAMランタイム・サーバーの起動時に、データベースが使用できる必要があります。

Tokenized Sessionは、データベース使用不能時に次の機能をサポートします。

表16-1 データベースが使用できないときにサポートされる機能

データベースが使用できないときにサポートされる機能とコンポーネント シナリオ
WebGate 11g 認証、認可(セッション制約なし)およびSSOフロー
Webgate 12c 認証、認可(セッション制約なし)およびSSOフロー
Java ASDK ASDK操作

ノート:

セッションに関連したASDK操作はサポートされません。
OAuth 非セッション・リンク・シナリオ

Tokenized Session Managementは、データベース使用不能時に次の機能をサポートしません。

表16-2 データベースが使用できないときにサポートされない機能

DBが使用できないときにサポートされない機能およびコンポーネント(サーバー側セッションに依存しているため) 説明
Java ASDK DB可用性は、ASDKセッション操作が機能するために必須です
セッション・レスポンス DB可用性は、セッション・レスポンスが機能するために必須です。
セッション・スナイプ DB可用性が必須です。DBがセッション・スナイプ後に使用できない場合、すでに確立されたセッションからの認可の動作はセッション・ポリシーに基づいて定義されます
リモート・セッションのキル DB可用性が必須です
OAuth MDCセッション・リンク フローにOAuthトークンとOAM_IDの同期の問題があるためDB可用性が必須。
DCC/NAPトンネリング 未サポート/未認定
LDAPプリフェッチ DBが停止していると、LDAPプリフェッチは機能しません。認可時に、アイデンティティ認可制約を評価するために追加のLDAP問合せが必要になる可能性があります。
oamconsole DBが停止している場合、管理操作はサポートされません

関連項目:

システムおよびポリシー構成のためのポーリング間隔

データベースからセッションおよびプラグインをリストするSQL問合せ

16.2 サーバー側セッション管理の理解

OAM 12.2.1.3.0サーバーは、データベースに支えられたサーバー側セッション・マネージャをサポートして、OAMサーバー・クラスタの複数ノードの全体でセッション状態を同期させます

次の各トピックでは、サーバー側セッション管理の概要について説明します。

16.2.1 Access Managerセッションの保護について

セッションのセキュリティは、安全なインストールから始まります。

インストールの詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』のOracle Access Managementのインストールと構成の準備に関する項を参照してください。

関連項目:

Oracle Fusion Middlewareコンポーネント間のSSLによるセキュア通信の構成の詳細は、『Fusion Middleware管理者ガイド』のOracle Fusion MiddlewareでのSSLの構成に関する項

HTTPSプロトコルおよびデータベース暗号化は、Access Managerがサーバー側セッションのセキュリティをサポートする手段の一部です。次のリストでは、このサポートの仕組みについて説明します。

  • HTTPSプロトコル

    Access Managerは、プロキシによるIPアドレス・チェックを提供することでセッションの固定化防止に役立ちます。セッション固定化の防止効果をさらに高めるために、WebゲートおよびOAMサーバーの間ではセキュアHTTPSプロトコルを使用してください。

  • データベースの暗号化

    このセッション管理エンジンはデータを暗号化しません。セキュリティ上の懸念がある場合は、Oracle Advanced Securityなどを使用してデータベース内を暗号化します。

16.2.2 Access Managerセッションのライフサイクル、状態および実施

セッション・ライフサイクルは、定義されているある状態から別の状態への遷移を含む状態のセットです。この遷移は、ユーザーのアクティビティ(またはその欠如)や手動(または自動)の管理者アクティビティにより異なります。

管理者は、次のグローバル・セッション・ライフサイクル設定を定義できます。

  • セッションのライフタイム

  • アイドル・タイムアウト

    ノート:

    アイドル・タイムアウトは、アプリケーション固有の設定としても実装できます(後述)。

  • セッションの最大数

「グローバル・セッション・ライフサイクル設定」を参照してください。

表16-3に、セッション・ライフサイクルの各状態を示します。

表16-3 セッション・ライフサイクルの状態

状態 説明

アクティブ

新たに作成されたセッションはアクティブです。ユーザーがAccess Managerによって認証されるとセッションが作成されます。

セッションは、この表内の別の状態のいずれかに遷移する必要があるとAccess Managerが判断するまで、アクティブな状態を維持します。

ノート: 管理者が削除できるのは、アクティブなセッションのみです。

アイドル

ユーザーがAccess Managerによって保護されているコンテンツにアクセスしない状態が、管理者により定義された期間継続すると、セッションはアイドルになります。

アクティブ・セッションがアイドルになると、先に進む場合、ユーザーは再認証する必要があります。再認証に成功すると、セッションはアクティブな状態に戻ります。セッションの属性値はこのプロセスを通して保持されます。

期限切れ

セッションの期間が定義されたライフタイムを超えると、アクティブなセッションは期限切れとなります。期限切れのセッションは、完全にアクセス不能で、削除の対象となります。アクティブ・セッションが期限切れになると、先に進む場合、ユーザーは再認証する必要があります。

再認証に成功すると、新しいセッションが作成されます。ただし、(アイドル状態のように)セッション属性値が保持されることはありません。

詳細は、次の各トピックを参照してください。

16.2.2.1 状態変更のためのグローバル・セッションの実施チェック

各Access Managerセッションは、2つの時間属性および適用可能な値を保持します。

2つの時間属性は、次のとおりです。

  • セッションの作成時間

  • 最終アクセス時間

これらの属性値は、表16-4に示すとおり、セッションの実施について比較されます。

表16-4 状態変更のためのセッション・チェック

セッション・チェック 説明

セッションはアイドルか。

最終アクセス時間を構成されているアイドル・タイムアウト値と比較します。構成されている期間を超えている場合、アクティブからアイドルの状態への変更がトリガーされます。

セッションは期限切れか。

セッションの作成時間を構成されているセッションの存続期間と比較します。構成されている期間を超えている場合、アクティブから期限切れの状態への変更がトリガーされます。

アイドル状態への遷移の際、基盤となるセッション属性は保持されます。これは、ユーザーが以前満たしていた認証条件およびデータが信頼できるためです。ただし、そのセッションに基づいて保護されているリソースや、そのセッション内のデータの変更結果に引き続きアクセスすることは、ユーザーが再認証を行い、ロック解除されたコンピュータへのアクセス権を持つ悪意のあるユーザーでないことを証明するまで、許可されません。

16.2.2.2 Access Managerセッションの削除

セッションは、期限切れ、ユーザー・ログアウトおよび終了の3つのアクションによって削除できます。

表16-5で、セッションの削除アクションについて説明します。

表16-5 セッションの削除

アクション 説明

期限切れ

期限切れのセッションは、その作成時間に基づいて、削除の対象となります。実際の削除は、格納メカニズムによって決定されます。セッションは、サーバーで実行されるバックグラウンド・タスクを使用して分散キャッシュから削除され、同様のバックグラウンド・タスク、オプションで有効となるデータベース内のジョブ、または両方の方法を組み合せて使用して、データベースから削除されます。

セッションがすべての層の記憶域(ローカルおよび分散キャッシュ、および有効な場合、データベース)から削除されると、そのセッションは完全に除去されます。

ユーザー・ログアウト

ユーザー・ログアウトにより、現在のデータベース・セッションの書込みおよびパフォーマンスの量に従い、分散キャッシュからの迅速な削除がトリガーされます。

終了

終了は、管理コンソールによりセッションが対話的に終了されるのか、Oracle Identity Managementのユーザー・ロックアウトまたはプロビジョニング解除フローの一部として自動的に行われるのかに関係なく、ユーザー・ログアウトと同じです。

16.2.2.3 認証および資格証明のステップアップおよびステップダウンについて

ステップアップ・フローを完了するために、単一のセッションで複数の認証フォームが必要となり、実行される場合があります。再認証レベルは、セッションからのステップダウンの場合もあります。

ステップアップ・フローでは、ユーザーが保護されたコンテンツにアクセスするために認証した後、同じセッション内で、より機密性の高い別のコンテンツをリクエストすると、それにアクセスするため、より厳しいレベルで再度認証を要求されます。ステップアップ・フローでは、常に、認証レベルが上昇する順に、複数の認証が発生します。各セッションでは、ステップアップ認証実行の認証レベル属性を保持します。

再認証レベルが、前にセッションに含まれていたレベルより低い場合、ユーザーによりステップダウン・プロセスが行われています。正常に再認証すると、セッションは、使用された認証スキームのうち低い方と等しい認証レベルで、アクティブな状態に復元されます。後でユーザーが、より高いレベルで保護されたコンテンツにアクセスを試みると、ステップアップ認証が発生します。

16.2.2.4 オプションのアプリケーション固有セッションの実施

Access Managerは、1セットのグローバル・セッション・タイミング、またはアクセスが単一の認証レベルのみに依存する1セットの認証スキームで可能な方法より粒度の細かい方法で、リソースへのユーザー・アクセスを制限します。特定のデータへのアクセスには、より厳しい要件がありますが、その他すべてのデータへのアクセスは、グローバルに構成されます。

管理者は、アプリケーション・ドメイン設定の一部として定義されたグローバル・セッション・タイムアウト設定を、アプリケーションごとにオーバーライドできます。オプションのアプリケーション固有セッションの設定では、次の機能が提供されます。

  • アプリケーションごとにセッション・アイドルのタイミングを宣言する機能。これは一般的に、デプロイメント全体で定義されているグローバル・アイドルのタイミングより厳しくなります。

  • アプリケーションごとのセッション非アクティブのタイムアウトの後、ユーザーに再認証を要求する機能。

表16-6では、グローバル・セッション設定に対するアプリケーション・ドメイン固有のオーバーライドを定義した場合のセッションの実施について説明します。

表16-6 アプリケーション・ドメイン固有のオーバーライド

オーバーライド 説明

セッションはアイドルか。

最終アクセス時間を、定義したアプリケーション・ドメインのみに対して構成されているアイドル・タイムアウト値と比較します。構成されている期間を超えている場合、アクティブからアイドルの状態への変更がトリガーされます。

セッションは期限切れか。

セッションの作成時間を構成されているセッションの存続期間と比較します。構成されている期間を超えている場合、定義したアプリケーション・ドメイン・グループのみに対して、アクティブから期限切れの状態への変更がトリガーされます。

16.3 サーバー側セッションの実施例

特定のレベルの認証スキームを満たすと、それより低いレベルで保護されているすべてのリソースへのアクセスが可能となります。さらに、特定のレベルのすべての認証スキームが、同等として表示されます。

この項では、2つのアプリケーション・ドメインで使用される単一の認証スキームに基づく簡単なセッション実施例と、2つのアプリケーション・ドメインで使用される複数の認証スキームに基づくより複雑な例を示します。

16.3.1 例1: 単一の認証スキーム

次の構成について考えます。

  • レベル2を使用して定義された単一の認証スキーム(S1)

  • アプリケーション・ドメインD1およびD2

  • 各ドメイン内のすべてのリソースは、S1を使用する単一の認証ポリシーと単一の認可ポリシーにより保護されています。

  • グローバル・セッション構成:

    • セッションの存続期間: 90分

    • アイドル・セッション・タイムアウト: 0 (セッションがアイドル・タイムアウトすることはありません)

    • アプリケーション・ドメイン・タイムアウト: 30分

今度は、表16-7の結果について考えます。

表16-7 セッションの内容: 単一の認証スキーム

時間(デルタ) アクション アクセスの許可または拒否 セッションの内容

0

D1へのアクセス

セッションがないため拒否

null

1

S1による認証とD1へのアクセス

認証スキームが満たされているため許可

レベル2、認証時間1

21

D2へのアクセス

許可

レベル2、認証時間1

66

D1へのアクセス

アプリケーション・ドメイン・タイムアウト(構成されているパラメータに基づく)により拒否

レベル2、認証時間1

67

S1による認証とD1およびD2へのアクセス

認証スキームが満たされているためどちらも許可

レベル2、認証時間67

16.3.2 例2: 複数の認証スキーム

通常、セッションがタイムアウトするとステップダウン認証が発生します。これは、セッションで以前保持していた最大のレベルのスキームを満たす新しい資格証明をユーザーが提供するまで継続します。そうしない場合、認証の観点からは、セッションは新規で、さらなるステップアップが必要であるように見えます。次の2つの認証スキーム(ステップアップとステップダウン)のある例を考えます。

  • 認証スキームS1 (レベル2)およびS2 (レベル3)

  • アプリケーション・ドメインD1およびD2

  • 各ドメイン内のすべてのリソースは、単一の認証ポリシーと単一の認可ポリシーにより保護されています。

  • D1はS1を使用、D2はS2を使用

  • グローバル・セッション構成:

    • セッションの存続時間: 240分

    • アイドル・タイムアウト: 30分

    • Appdomain 2 (D2)タイムアウト: 15分(appdomain設定)

D1のリソースにアクセスすると、タイムアウトは30分後(グローバル・タイムアウト設定)に発生します。D2タイムアウトは、タイムアウト値がグローバル・レベルでオーバーライドされているため、15分後に発生します。表16-8に結果を示します。

表16-8 セッションの結果: 複数の認証スキーム

時間(デルタ) アクション アクセスの許可または拒否 セッションの内容

0

D1リソース(RD1)へのアクセス

ログイン成功後にアクセス許可

D1のタイムアウトは、0+30=30に設定されます(D1はアプリケーション・ドメイン・レベルでタイムアウトをオーバーライドしていないため、30はデフォルトのグローバル・タイムアウトです)。

1 (1分後を意味します)

D2リソース(RD2)へのアクセス

資格証明のチャレンジ後にアクセス許可(D2はより高い認証スキームを使用して保護されているため、ユーザーは資格証明を要求されます)

D2のタイムアウトは、1+15=16に設定されます。

t>16かつt<30 (t=20など)

RD1およびRD2へのアクセス

タイムアウトがD1=30のためRD1へのアクセス許可。タイムアウトがD2=16のため、資格証明の指定後にRD2へのアクセス許可

新しいD2のタイムアウトは16です。

40

RD1へのアクセス

許可: D1リソースはタイムアウトが50のため許可

55

RD1およびRD2へのアクセス

ユーザーが資格証明に対して正常にチャレンジされた後、両方のリソースへのアクセスを許可

D1のタイムアウトは現在85 (55+30)です。

D2のタイムアウトは現在70 (55+15)です。

アクセス順序は結果に影響を及ぼします。たとえば、資格証明の期限が切れた後、まずD2アプリケーションへのアクセスを続けることをユーザーが選択した場合、最後のD1アクセスは許可される可能性があります。たとえば:

  • D2へのアクセスが許可された状態での認証S2: L3スキームは満たされ、現在アクティブなセッションのレベルは(再度)以前と同じになります。セッションの内容: レベル3、認証時間51

  • D1へのアクセス許可: レベル2で保護されたアクセスには、レベル3の資格証明でも十分です。セッションの内容: レベル3、認証時間51

16.4 サーバー側セッション・ライフサイクルの構成

セッション・ライフサイクルの設定は、Oracle Access Managementコンソールを使用して定義できます。グローバルまたはアプリケーション固有のセッション・ライフサイクル設定を定義する際、タイミング間隔を0に設定すると、対応するチェックが取り消されます。

たとえば、アイドル・タイムアウトを0に設定すると、セッションがアイドル・タイムアウトすることはありません。セッションの存続期間を0にすると、セッションは期限切れになりません。すべての場合において、適用可能なデータは、リクエストごとにチェックされるかのように、セッションで追跡され、更新されます。

この項では次のトピックを記載しています:

16.4.1 グローバル・セッション・ライフサイクル設定

Access Managerセッションのライフサイクル設定は、すべてのOAMサーバーが共有する共通設定の一部として定義されます。

図16-1は、「共通設定」ページの構成可能なライフサイクル属性を示しています。

図16-1 グローバル・セッション詳細: 「共通設定」ページ

図16-1の説明が続きます
「図16-1 グローバル・セッション詳細: 「共通設定」ページ」の説明

表16-9では、グローバル・セッションのライフサイクル設定およびそのデフォルトについて説明します。セッションは、切断モードで動作することができます。したがって、セッション規則を確立する構成の変更は、新しいセッションだけに適用されます。変更をただちに適用する場合は、既存のセッションを終了し、ユーザーには新規則に適合するセッションを新たに作成させることをお薦めします。

関連項目:

パフォーマンスのチューニング

表16-9 グローバル・セッション設定

設定 説明

セッションの存続期間(分)

ユーザーの認証セッションがアクティブな状態に維持される分単位の時間。ライフタイムに達すると、そのセッションは期限切れとなります。

デフォルト = 1440分(整数表現の分数で表した24時間)

ゼロ(0)は、この設定を無効にします。0(ゼロ)から2147483647の任意の値が許可されます。

ノート:

  • 変更が有効になるのは、構成変更に対する後続のポーリングの後です(oracle.oam.EntityRefreshIntervalMillisで構成された間隔に基づきます。デフォルト値は30秒です。)

  • 有効期限が切れたセッションは、メモリー内キャッシュ(またはデータベース)から自動的に削除されます。

アイドル・タイムアウト(分)

ユーザーの認証セッションが、Access Managerで保護されたリソースにアクセスすることなくアクティブな状態に維持される分単位の時間。これよりも長い時間アイドル状態が続くと、ユーザーは再認証を求められます。

デフォルト=15分

ゼロ(0)は、この設定を無効にします。0(ゼロ)から2147483647の任意の値が許可されます。

ノート:

  • 変更が有効になるのは、構成変更に対する後続のポーリングの後です(oracle.oam.EntityRefreshIntervalMillisで構成された間隔に基づきます。デフォルト値は30秒です。)

  • タイムアウトしたセッションは、セッション・マネージャからは削除されません。セッション・データはメモリーからは削除されますが、永続ストア(データベース)では引き続き使用可能です。再認証後、同じセッションが再度アクティブ化されます。

関連項目: 「アプリケーション固有のセッション・オーバーライド」

1ユーザーの最大セッション数

各ユーザーが同時に持つことのできるセッションの数。すべてのユーザーに対する複数セッション制限を構成するには、この設定を使用します。

正の整数が許可されます。

このカウントに"1"を指定すると、特殊モードがアクティブ化されます。ユーザーが別のデバイスを使用してセッションの認証を済ませている(つまり、新しいセッションを作成する)場合、そのユーザーの既存のセッションは削除されます。エラーの報告も、警告の表示もありません。

ノート:

  • 認証時にデータベースが使用不可である場合、1ユーザーの最大セッション数の強制適用は機能しません。

  • 数値を大きくしすぎると、パフォーマンスに影響を及ぼし、セキュリティのリスクを招くことになります。ユーザーごとの適切な制限として20未満の数値をお薦めします。それ以外の場合は、パフォーマンスに影響する可能性があります。チューニングの詳細は、パフォーマンスのチューニングを参照してください

(管理)最大検索結果数

結果セットが大きい場合、セッション問合せに対してデフォルトでフェッチされるセッションの数を示します。

16.4.2 システムおよびポリシー構成のためのポーリング間隔

OAMシステム構成ストアおよびポリシー・ストアは、次のポーリング間隔で変更がポーリングされます。

OAM 12.2.1.3.0では、ポリシーおよびシステム構成は、プルベース・モデルで同期されます。これは、個々のOAMサーバー・ノードが、対応する構成の変更をポーリングすることで動作します。

表16-10 デフォルト・ポーリング間隔

構成 デフォルト・ポーリング間隔(ミリ秒および秒単位)
システム構成ストア 30000ミリ秒ごと(30秒)
ポリシー・ストア 30000ミリ秒ごと(30秒)
OAM Config MBeanは構成ストアから変更をリロードします 30000ミリ秒ごと(30秒)

表16-10にリストされたすべての構成に対して、oracle.oam.EntityRefreshIntervalMillisシステム・プロパティを使用してポーリング間隔を構成できます。

たとえば、ポリシー・ストア・ポーリング間隔を60秒に変更するには、次のように設定します。

-D oracle.oam.EntityRefreshIntervalMillis=60000

16.4.3 アプリケーション固有のセッション・オーバーライド

アプリケーション固有のアクセスは、最初のアプリケーションのアクセス時から追跡され、そのアプリケーション・ドメインに対してさらにリクエストが行われた場合にのみ更新されます。

つまり、ユーザー認証および認証の状態は、Access Managerと管理者により制御されます。特定のアプリケーションの現在のアイドル時間は、Access Managerとアプリケーション間で共有されます。アプリケーションは、セッションごとにユーザー独自の実行時データをプロビジョニングするため、早急にこれを削除して他のユーザーのために領域を空ける必要があります。

管理者はアプリケーション・ドメインの「サマリー」タブで、アプリケーション固有のセッション・オーバーライドを追加できます。表16-11に、指定された場合にグローバル・セッション設定をオーバーライドする、アプリケーション固有の設定を示します。

表16-11 アプリケーション固有セッションのタイミング・オーバーライド

要素 説明

アイドル・タイムアウト

Access Managerでは、以前は最終アクセス時間の値をセッション内に格納していました。アプリケーションごとに最大アイドル時間を施行するため、Access Managerには新たにアプリケーション固有の最終アクセス時間フィールドが含まれ、これを保持します。これには、アプリケーションごとのアイドル・タイムアウト・オーバーライドが定義されているセッション中に参照したドメインの各サブセットの最終アクセス時間が入力されます。これは、オーバーライドが定義されていないドメインでは不要です。そのようなデータに対してチェックは行われません。

デフォルト: 未定義

ノート:

  • 変更が有効になるのは、構成変更に対する後続のポーリングの後です(oracle.oam.EntityRefreshIntervalMillisで構成された間隔に基づきます。デフォルト値は30秒です。)

  • アプリケーション・ドメインのタイムアウト値がグローバル・セッションのタイムアウト値より小さく、より制限的である場合は、アプリケーション・ドメインのアイドル・タイムアウトがグローバル・セッションのアイドル・タイムアウトより優先されます。グローバル・セッション・タイムアウトより大きい場合、OAMセッション・タイムアウトはグローバル設定の値に基づきます。

  • DBが停止している場合、アプリケーション・ドメインのセッション・アイドル・タイムアウトはグローバルなセッション・アイドル・タイムアウトを上書きしません。

詳細は、「オプションのアプリケーション固有セッション設定オーバーライドの表示または変更」を参照してください。

16.4.4 グローバル・セッション設定の表示または変更

有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールを使用して共通セッションのライフサイクル設定を変更できます。

詳細は、「グローバル・セッション・ライフサイクル設定」を参照してください。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「構成」をクリックします。
  2. 「構成」コンソールで、「設定」セクションの「表示」メニューから「共通設定」を選択します。
  3. 「共通設定」ページで、「セッション」セクションを開きます。
  4. 必要に応じて、各リストの横にある矢印キーをクリックしてセッションのライフサイクル設定を増減させます(表16-9)。

    • セッションの存続期間(分)

    • アイドル・タイムアウト(分)

    • 1ユーザーの最大セッション数

    • (管理)最大検索結果数 - 結果セットが大きい場合、セッション問合せに対してデフォルトでフェッチされるセッションの数を示します。

  5. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。
  6. 終了する際はページを閉じます。
  7. 次のトピックのいずれかに進みます。

16.4.5 オプションのアプリケーション固有セッション設定オーバーライドの表示または変更

有効な管理者の資格証明を持つユーザーは、指定されたグループの1つ以上のアプリケーション・ドメインに対するオプションのセッション設定を変更できます。

詳細は、「アプリケーション固有のセッション・オーバーライド」を参照してください。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
  2. 「Access Manager」セクションで、「アプリケーション・ドメイン」をクリックします。
  3. 目的のドメインを検索して開きます。
  4. 「サマリー」タブで次の情報を入力し、このドメインをセッション・オーバーライドを使用するグループに作成(または追加)します(表16-11)。

    • アイドル・タイムアウト

  5. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。
  6. 「アクティブなサーバー側セッションの管理」に進みます。

16.5 アクティブなサーバー側セッションの管理

「セッション管理」ページには、管理者がフィルタ条件に基づいて問合せを作成し、後で使用するために検索基準を保存し、検索をさらに絞り込むために問合せフォームにフィールドを追加できる検索コントロールが用意されています。データベース・ストア構成では、セッションがデータベースには存在しても、キャッシュには存在しない場合があります。セッション検索はシステム・タイムスタンプに基づきます。データベースに対して、タイムスタンプよりも先に更新されたセッションの問合せが行われます(書込み遅延を差し引いて)。キャッシュに対しては、このタイムスタンプよりも後に更新されたセッションの問合せが行われます。キャッシュおよびデータベースで検出された結果のデータがマージされます。重複した結果が存在する場合、キャッシュ・データが優先されます。検索操作に詳細パフォーマンス・メトリックが生成されます。

この項では、1ユーザーまたは全ユーザーの1つまたは複数のセッションを特定し、削除する方法を説明します。ここでは、次の情報が提供されます。

16.5.1 セッション管理コントロール

「セッション管理」ページは、Oracle Access Managementコンソールの「構成」セクションからアクセスできます。

図16-2に、「セッション管理」ページを示します。詳細は、図の後に説明します。

図16-2 共通構成: 「セッション管理」ページ

図16-2の説明が続きます
「図16-2 共通構成: 「セッション管理」ページ」の説明

表16-12では、フィルタ条件に基づいて問合せを作成できる「セッション管理」ページおよび検索コントロールについて説明します。

表16-12 セッション管理のコントロールと結果表

名前 説明

すべてのユーザー・セッションを削除

すべてのユーザーのアクティブ・セッションを削除するには、このコマンド・ボタンを選択します。

ノート: 操作を確認または拒否できる「確認」ウィンドウが表示されます。

保存済の検索

再使用のために以前に保存した検索基準がリストされたドロップダウン・メニュー。検索のリストは、検索基準を保存するたびに使用可能になります。

このドロップダウン・メニューには、「保存済の検索」の他に「パーソナライズ...」オプションも含まれています。「パーソナライズ」を選択した場合、「デフォルトとして設定」や「自動的に実行」などを新たに選択して、保存済検索基準の動作を変更できます。

一致、すべて、任意

検索中に、指定した条件のいずれかに一致させるか、またはすべてに一致させることができます。

ノート: リソースがbyAnonymousSchemeによって保護されている場合、セッション検索には表示されません。

ユーザーID

特定のユーザーIDをフィールドに入力して「検索」ボタンをクリックすると、そのユーザーのすべてのアクティブ・セッションが表示されます。不完全な文字列およびワイルド・カードを使用できます。ドロップダウン・メニューには、検索に使用できる「次で始まる」、「次と等しい」、「次を含む」などのオプションが含まれています。

クライアントIPアドレス

クライアントIPアドレスを入力して「検索」ボタンをクリックすると、そのユーザーのすべてのアクティブ・セッションが表示されます。不完全な文字列およびワイルド・カードを使用できます。ユーザーID検索およびクライアントIPアドレス検索を支援する同じリストが使用可能です。

検索

このボタンをクリックすると、フォームの基準に基づいて検索が開始されます。

ノート:

検索問合せはまとめてAND化され、結果が戻されます。

リセット

このボタンをクリックすると、フォームのすべての基準がクリアされます。

フィールドの追加

検索フォームに追加する様々なオプションを選択できるドロップダウン・メニューを表示します。これには、「クライアントIPアドレス」、「IDストア」、「偽装」およびその他のオプションが含まれることがあります。

  1. 「フィールドの追加」ボタンをクリックします。

  2. リスト内の項目を選択してフォームに追加し、「保存」をクリックします。

項目を追加した後、検索を支援するリストが使用可能になります。

並替え

検索フィールドを並べ替えることができるポップアップ・ダイアログを表示します。

ビュー

結果表の上にある「表示」メニューからコマンドを選択して、表を構成します。次のコマンドを使用できます。

  • 列: 表内の特定の詳細を表示または非表示にできる次のオプションを含むメニューを表示します。

  • デタッチ: 結果の表を展開してフルスクリーン表示にします。

  • アタッチ: 「セッション管理」ページの表示に戻ります。

  • 列の並替え: 結果表のセッション・データを含む列の新しい配列を指定します。

削除

結果表で削除する項目を選択した後、このコマンド・ボタン(赤いX)を選択します。

ノート: セッション検索基準が一般的なものである場合(たとえば、ワイルドカード(*)のみを使用する場合など)、大きなセッション・リストからセッションを削除する際に制限があります。セッション検索基準を十分に細分化することによって比較的小さな結果セット(理想的には20以下)を取得することをお薦めします。

付記: 操作を確認または拒否できる「確認」ウィンドウが表示されます。

デタッチ

結果の表を展開してフルページ表示にするには、「デタッチ」をクリックします。

ノート: 表がすでにデタッチされてフルページ表示になっている状態で「デタッチ」をクリックすると、「セッション管理」ページに戻ります。

結果表(名前なし)

特定ユーザーのアクティブ・セッションを検索後、表に結果が表示されます。詳細には次の情報が含まれます。

  • セッションID: OAMが作成したセッションのID。

  • ユーザーID:

  • 偽装:

  • 作成時間: セッションが作成された日付と時刻。

  • 最終アクセス: セッションに対する最後のアクセスの日付と時刻。

  • クライアントIP: 指定したユーザーのIPアドレス。

  • IDストア

  • インパーソネータ

ノート:

  • 検索基準で選択されたフィールドに対するオプションisunsetは、対応するフィールド値が設定されていないセッションを戻します。たとえば、検索基準が「クライアントIPアドレス」でオプションがunsetである場合、検索は、クライアントIPアドレスが設定されていないセッションを戻します。

  • 検索基準で選択されたフィールドに対するオプションisnullは、対応するフィールド値がnullに設定されているセッションを戻します。

    たとえば、検索基準が「ユーザーID」でオプションがisnullである場合、検索はUserID値がnullに等しいセッションを戻します。

16.5.2 アクティブ・セッションの検索および管理

有効な管理者の資格証明を持つユーザーは、検索結果表の構成、特定ユーザーのアクティブ・セッションの特定、特定ユーザーの1つ以上のセッションの削除、またはすべてのユーザーのすべてのセッションの削除を実行できます。

リソースがAnonymousSchemeによって保護されている場合、セッション検索には表示されません。

関連項目:

「セッション管理コントロール」

必要のないステップはスキップしてください。OAMサーバーが稼働している必要があります。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

  2. 「アプリケーション・セキュリティ」コンソールで、「セッション管理」をクリックします。

    「ユーザー名」フィールドと結果表を含む「セッション管理」の「検索」ページが表示されます。

  3. フィールドの追加: 「フィールドの追加」リストから、目的のフィールド名を選択します(表16-12)。

  4. 演算子の選択: 選択した検索フィールドの演算子のリストを開き、目的の関数を選択します。

  5. セッションの検索:

    1. 目的の問合せフィールドで、基準を入力します(ワイルド・カード(*)の使用は任意)。

    2. 「検索」ボタンをクリックして、基準のいずれかまたはすべてに一致するセッションを探します。

    3. 結果表を確認します。

    4. 必要に応じて繰り返し、検索を絞り込みます。

  6. 結果表の構成: 「表示」メニューの機能を使用して、目的の結果表を作成します。

  7. セッションの削除:

    1. 結果表で、削除する1つ以上のセッションをクリックします。

    2. 「削除」(x)ボタンをクリックして、選択したセッションを削除します。

    3. 「はい」をクリックして、選択したセッションの削除を確認します(または「いいえ」をクリックして、削除操作を取り消します)。

    4. 必要に応じてユーザーに通知します。

  8. すべてのユーザーのセッションの削除:

    1. 右上隅にあるすべてのセッションを削除ボタンをクリックします。

    2. 確認を求めるメッセージが表示されたら、「はい」をクリックします。

  9. 終了したら「セッション管理」ページを閉じます。

  10. 「サーバー側セッション操作の検証」に進みます。

16.6 サーバー側セッション操作の検証

構成したセッション・ライフサイクル操作を検証できます。

  1. 認証:

    1. 管理資格証明以外の資格証明を使用して、ブラウザでリソースにアクセスします。

    2. 「アクティブ・セッションの検索および管理」の説明に従って、セッションが存在することを検証します。

  2. 複数のセッション:

    1. (Cookieを削除した)2番目のブラウザで同じリソースにアクセスします。

    2. 2つのセッションが存在することを検証します。

  3. すべてのセッションを削除し(「アクティブ・セッションの検索および管理」のステップ7)、アクティブ・セッションが削除されていることを確認します。

  4. 再認証の検証:

    1. 2番目のブラウザ(ステップ2)で別のリソースにアクセスして、再認証を要求されることを確認します。

    2. そのリソースに必要な資格証明を入力します。

    3. セッションが作成されていることを検証します。

  5. データベースの検証:

    1. すべてのセッションを削除します。

    2. データベースに接続し、次の問合せを実行します。

      SQL> select * from am_session

    3. 次の結果が得られることを確認します。

      no row selected

    4. 2番目のブラウザで別のリソースにアクセスします。

    5. データベースに接続し、次の問合せを実行します。

      SQL> select * from am_session

    6. 次のようなデータが1行表示されることを確認します。

      1 rows selected

    7. OAM_SESSION_ATTRIBUTESから行を選択して、そのユーザーのデータが存在することを確認します。

16.7 セッション上のCRUD操作でのREST APIの使用

Session REST APIは、データ・センター内でセッションを管理します。通常、セッション上のCRUD操作は、セッション層で実行されます。セッション層に新しいAPIや機能を追加することなく、Session REST APIはセッションの作成、読取り、更新およびキャンセルを支援します。Session REST APIユーザー・ロールを持つ管理者は、セッション上のCRUD操作にSession REST APIを使用できます。

管理者がSession REST APIを使用して実行できるタスクを次に示します。

16.7.1 Session REST APIを使用したセッションの検索

Session REST API Userロールを持つ管理者は、searchSessions APIを使用してユーザー・セッションを検索することができます。

特定のユーザーに関連するセッションを検索するには、userIdを使用します。特定のセッションを検索するには、sessionIdを使用します。clientIpがわかる場合、そのクライアント・アドレスに由来するセッションをすべて検索することができます。

ノート:

セッションを検索すると、問合せあたり28セッションのみリストされ、表示された探索結果はページ付けされません。
  1. 特定のユーザーのセッションを検索するには、userIdを指定します。
    
Sample request
curl -H "Content-Type: application/json" -H "Authorization: Basic <Base64 encoded auth header>" -X POST -d '{"userId":"user2"}' http://<HOST>:<PORT>/oam/services/rest/access/api/v1/sessions

Sample response
<?xml version="1.0" encoding="UTF-8"?>
<SessionResults>
<totalRecords>2</totalRecords>
<sessions>
<sessionData>
<sessionId>53f96ca1-e65a-47ee-a758-a1cebb63f4b3|L+h1SktCgMtjnOnmIWL+gnpIstrT9hGuPD0beqGK5Cc=</sessionId>
<createTime>2017-05-31T13:56:19.000-07:00</createTime>
<updateTime>2017-05-31T13:56:19.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:56:19.000-07:00</lastAccessTime>
<userId>user2</userId>
<clientIp>5.6.7.8</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
<sessionData>
<sessionId>a3d62e11-3f22-4336-b76c-e8f8cbd46306|L+h1SktCgMtjnOnmIWL+gnpIstrT9hGuPD0beqGK5Cc=</sessionId>
<createTime>2017-05-31T13:55:43.000-07:00</createTime>
<updateTime>2017-05-31T13:55:43.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:55:43.000-07:00</lastAccessTime>
<userId>user2</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
</sessions>
</SessionResults>
  2. 特定のクライアント・アドレスのセッションを検索するには、clientIpを指定します。
    
Sample request
curl -H "Content-Type: application/json" -H "Authorization: Basic <Base64 encoded auth header>" -X POST -d '{"clientIp":"1.2.3.4"}' http://<HOST>:<PORT>/oam/services/rest/access/api/v1/sessions

Sample response
<?xml version="1.0" encoding="UTF-8"?>
<SessionResults>
<totalRecords>4</totalRecords>
<sessions>
<sessionData>
<sessionId>a9cacf25-18cc-4d72-9237-e32394fa294e|U90idWYSK4hXcdo6LlVD2+JuHBLvbGtCbbhlfmoDvMA=</sessionId>
<createTime>2017-05-31T13:57:32.000-07:00</createTime>
<updateTime>2017-05-31T13:57:32.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:57:32.000-07:00</lastAccessTime>
<userId>user5</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
<sessionData>
<sessionId>32de23f1-9f53-47e7-b4d5-9d0376187241|c+4quN74tM7P6qvbYVqa6BQOg3RYHDsFT3PzPajvEzM=</sessionId>
<createTime>2017-05-31T13:56:35.000-07:00</createTime>
<updateTime>2017-05-31T13:56:35.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:56:35.000-07:00</lastAccessTime>
<userId>user3</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
<sessionData>
<sessionId>a3d62e11-3f22-4336-b76c-e8f8cbd46306|L+h1SktCgMtjnOnmIWL+gnpIstrT9hGuPD0beqGK5Cc=</sessionId>
<createTime>2017-05-31T13:55:43.000-07:00</createTime>
<updateTime>2017-05-31T13:55:43.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:55:43.000-07:00</lastAccessTime>
<userId>user2</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
<sessionData>
<sessionId>c639fb4d-f467-4da3-88c8-0e6754d809a7|hUNJ4YlF30b5ycVlEq7iZ8LwFa8i9G5QhmKdkr3TizU=</sessionId>
<createTime>2017-05-31T13:57:17.000-07:00</createTime>
<updateTime>2017-05-31T13:57:17.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:57:17.000-07:00</lastAccessTime>
<userId>user4</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
</sessions>
</SessionResults>

16.7.2 Session REST APIを使用したセッションの更新

Session REST API Userロールを持つ管理者は、updateSessions APIを使用してセッションを更新することができます。

特定のIPに由来する特定のユーザー・セッションのセッション妥当性を延長または短縮するために(expiryTime)、管理者はupdateSessions APIを使用できます。
  1. userIdおよびclientIpを使用してユーザーのセッションを検索します。「Session REST APIを使用したセッションの検索」を参照してください。
  2. セッション期限切れ時にsessionIdおよびexpiryTimeを入力します。
    
Sample request
curl -H "Content-Type: application/json" -H "Authorization: Basic <Base64 encoded auth header>" -X PUT -d '{ "sessionId": "da9c1056-9216-4bb2-8946-d15da0574c6f|U90idWYSK4hXcdo6LlVD2+JuHBLvbGtCbbhlfmoDvMA=", "expiryTime": "2017-06-01T22:26:40.425-07:00", "userId": "user5" }’ http://<HOST>:<PORT>/oam/services/rest/access/api/v1/session

Sample response
<?xml version="1.0" encoding="UTF-8"?>
<SessionData>
<sessionId>da9c1056-9216-4bb2-8946-d15da0574c6f|U90idWYSK4hXcdo6LlVD2+JuHBLvbGtCbbhlfmoDvMA=</sessionId>
<createTime>2017-05-31T14:26:40.425-07:00</createTime>
<updateTime>2017-05-31T14:42:14.502-07:00</updateTime>
<lastAccessTime>2017-05-31T14:42:14.502-07:00</lastAccessTime>
<expiryTime>2017-05-31T22:26:40.425-07:00</expiryTime>
<userId>user5</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</SessionData>
    セッションは、updateSessions APIを使用して更新されます。

16.7.3 Session REST APIを使用したセッションの削除

Session REST API Userロールを持つ管理者は、deleteSession REST APIを使用して1つ以上のユーザー・セッションを削除できます。

  1. 単一のセッションを削除するには、次のように、deleteSession REST APIでsessionIdを使用します。
    
Sample request
curl -H "Content-Type: application/json" -H "Authorization: Basic <Base64 encoded auth header>" -X "DELETE" “http://<HOST>:<PORT>/oam/services/rest/access/api/v1/session?sessionId= 3b844e4d-9019-4928-9dca-3ba2ebbf475d%7CU90idWYSK4hXcdo6LlVD2%2BJuHBLvbGtCbbhlfmoDvMA%3D”

Sample response
<?xml version="1.0" encoding="UTF-8"?>
<SessionResults>
<totalRecords>1</totalRecords>
<sessions>
<sessionData>
<sessionId>3b844e4d-9019-4928-9dca-3ba2ebbf475d|U90idWYSK4hXcdo6LlVD2+JuHBLvbGtCbbhlfmoDvMA=</sessionId>
<createTime>2017-05-31T13:57:59.545-07:00</createTime>
<updateTime>2017-05-31T13:57:59.545-07:00</updateTime>
<lastAccessTime>2017-05-31T13:57:59.545-07:00</lastAccessTime>
<expiryTime>2017-05-31T21:57:59.545-07:00</expiryTime>
<userId>user5</userId>
<clientIp>5.6.7.8</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
</sessions>
</SessionResults>

    ノート:

    sessionIdは、特殊文字を含んでいるためエンコードされます。
  2. ユーザーが終了させられると、管理者はuserIdを使用して(またはオプションでid-storeを使用)、次のようにして、すべてのユーザーのセッションを検索し、すべてのセッションを削除できます。
    
Sample request
curl -H "Content-Type: application/json" -H "Authorization: Basic <Base64 encoded auth header>" -X "DELETE" "http://<HOST>:<PORT>/oam/services/rest/access/api/v1/session?userId=user3"

Sample response
<?xml version="1.0" encoding="UTF-8"?>
<SessionResults>
<totalRecords>2</totalRecords>
<sessions>
<sessionData>
<sessionId>32de23f1-9f53-47e7-b4d5-9d0376187241|c+4quN74tM7P6qvbYVqa6BQOg3RYHDsFT3PzPajvEzM=</sessionId>
<createTime>2017-05-31T13:56:35.426-07:00</createTime>
<updateTime>2017-05-31T13:56:35.426-07:00</updateTime>
<lastAccessTime>2017-05-31T13:56:35.426-07:00</lastAccessTime>
<expiryTime>2017-05-31T21:56:35.426-07:00</expiryTime>
<userId>user3</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
<sessionData>
<sessionId>3e8fd79e-03b8-4c90-bf4d-964119460a0a|c+4quN74tM7P6qvbYVqa6BQOg3RYHDsFT3PzPajvEzM=</sessionId>
<createTime>2017-05-31T13:56:52.918-07:00</createTime>
<updateTime>2017-05-31T13:56:52.918-07:00</updateTime>
<lastAccessTime>2017-05-31T13:56:52.918-07:00</lastAccessTime>
<expiryTime>2017-05-31T21:56:52.918-07:00</expiryTime>
<userId>user3</userId>
<clientIp>5.6.7.8</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
</sessions>
</SessionResults>

    ノート:

    管理者は、searchSessions APIをclientIPパラメータとともに使用して、すべてのセッションをリストし、特定のクライアント・アドレスからセッションを削除できます。

16.7.4 委任管理者の割当て

LDAPで定義されている指定されたユーザーに、Session-REST API Userロールを付与してから、ユーザー・セッションを管理する管理者のグループに追加します。

ウェブログ管理者またはSession-REST API User ロールを持つユーザーだけが、OAMランタイム・サーバー上でSession REST API機能を実行できます。委任された管理ページを介して、/oamconsoleから、ユーザーを追加して、特定のユーザーにユーザー・ロールを割り当てます。