ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11gリリース2 (11.1.2.2) for All Platforms
B69533-09
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

17 Access Managerセッションの維持

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

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

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

この11gR2 PS2リリースのOracle Access Managementでは、Access Managerセッションは、サーバー側からもクライアント側からも管理できます。

  • サーバー側のセッション管理(Coherenceベースのセッション管理とも呼ばれる)は、Access Manager用に開発されたデフォルトのセッション管理オプションです。Coherenceベースのキャッシュを介して、ノード間の高度なセッション管理が可能になります。信頼できるパフォーマンスおよび高度な機能(偽装、セッション・スニッピング、アイデンティティ・コンテキスト伝播など)を提供できるため、サーバー側セッション管理は、ほとんどのデプロイメント(特に、豊富なセッション管理機能が望ましい内部デプロイメント)でお薦めします。次に詳細を示します。

  • クライアント側セッション管理(Cookieベースのセッション管理とも呼ばれる)は、ブラウザCookieを使用してセッションを管理します。これは基本的にステートレスです。クライアント側のセッション管理は、Coherenceベースのセッション管理と比較して、軽量フットプリントで高いパフォーマンスを提供します。サーバー側に情報を保存せずにブラウザCookieにセッションの詳細を格納するため、高度なサーバー側セッション管理機能を必要としない非常に大きなデプロイメントには、こちらの方が適しています。詳細は、「クライアント側セッション管理の理解」を参照してください。


    注意:

    Cookieベースのセッションは、ブラウザ・リクエストのコンテキストからのみアクセス可能であり、サーバーから直接アクセスすることはできません。

セッション管理オプションの構成方法については、「WLSTを使用したセッション管理の構成」を参照してください。

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

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

17.2.1 Access Managerセッションの保護

セッションのセキュリティは、安全なインストールから始まります。インストールの詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。


関連項目:

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

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

  • HTTPSプロトコル

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

  • Oracle Coherence

    メモリー内ではデータは暗号化されませんが、転送時は保護されます。Oracle Coherenceは、様々なサーバーの様々なAccess Managerインスタンス間で通信し、この通信は次のようにして保護されます。

    • Coherenceが前もってID確認されたホスト間の通信だけをサポートします。これは一定のIPアドレス範囲として行うか、特定のホスト名によって行います。Access Manager構成ファイルには、通信に参加する各サーバーのエントリが含まれています。起動時にはこの情報がCoherenceに提供され、認可されたサーバーのみが通信に参加するようにします。

    • Coherenceは、クラスタ内のすべてのサーバー間で相互認証されたSSLを使用します。インストール時に、適用可能なキーおよび証明書を保持するjceksキーストア・ファイルが作成されます。

    詳細は、「Access ManagerセッションおよびOracle Coherenceのロール」およびOracle Coherenceのドキュメントを参照してください。

  • データベースの暗号化

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

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

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

  • セッションの存続期間

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

  • セッションの最大数

  • アクティブ・セッションのデータベース永続性


注意:

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

セッション・ライフタイムの各状態を、表17-1に示します。

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

状態 説明

アクティブ

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

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

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

アイドル

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

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

期限切れ

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

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

詳細な情報は、次のトピックを参照してください:

17.2.2.1 グローバル・セッションの実施チェックについて

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

  • セッションの作成時間

  • 最終アクセス時間

これらの属性値は、表17-2に示すとおり、セッションの実施の際に比較されます。

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

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

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

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

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

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

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

17.2.2.2 セッションの削除について

セッションは、表17-3に示すアクションにより削除できます。

表17-3 セッションの削除

アクション 説明

有効期限

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

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

ユーザー・ログアウト

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

終了

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

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

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

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

17.2.2.4 オプションのアプリケーション固有セッションの実施について

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

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

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

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

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

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

オーバーライド 説明

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

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

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

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

17.2.2.5 複数のエージェント・タイプ(OSSOエージェントおよびOAMエージェント)のタイムアウトについて

アイドル・タイムアウトは、セッションが切断されている状態で動作している場合でも適切に適用されます。(切断された状態は、Webゲート以外によりmod_ossoリクエストが行われている場合に発生します。この場合、サーバーにはセッションがアイドル・タイムアウトしたように見えます。)OSSOエージェントのグローバル・ログアウトを有効にするには、セッション管理エンジンで、OSSOエージェントでの活動時間に対してOAMエージェントでの休止時間のリコンシリエーションを行います。

mod_ossoエージェントは、(editGITOValues WLSTコマンドを使用して)グローバルな非アクティブ・タイムアウトが有効になっている場合にのみ、粒度の細かいタイムアウトをサポートします。OAMサーバーとともに動作する複数のタイプのエージェント(mod_ossoおよびWebゲート)でタイムアウトをサポートする特別なケースでは、GITO Cookieが必要です。ユーザーがアクティブ・セッション(OAMエージェントによるもの)をそのままにしてOSSOエージェントによるセッションを開始した場合、そのユーザーが最初のセッション(OAMエージェントによるもの、その時点では非アクティブ)に戻ると、セッション管理エンジンはOAMエージェントでの休止時間とOSSOエージェントでの活動時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。

17.2.2.6 OpenSSOエージェントについて

セッション管理上は、OpenSSOエージェントはWebゲートと同じです。OpenSSOエージェントは、mod_ossoと異なり、切断状態では動作しません。

17.2.3 Access ManagerセッションおよびOracle Coherenceのロール

この項では、組込みのOracle Coherenceデータ管理およびキャッシング・サービスがセッション管理の際にどのようにセッション・ストアとやり取りするのかについて説明します。これには、ローカルおよび分散(シリアライズ)メモリー内キャッシュと、オプションのデータベース(セッション管理エンジンのセッション・ストアとして構成され、有効化されている場合)が含まれます。


注意:

一般的には、AdminServerとOAMサーバーの両方がOracle Coherenceクラスタに参加します。ただし、AdminServerは、検索の実行以外には、セッション・データにアクセスしません。

Access Managerは、Coherenceを使用して、分散インストール内でセッション状態をレプリケートします。Coherenceを使用して、OAMサーバー間で状態変更について通信します。クラスタ検出およびハートビートについて、Coherenceはユーザー・データグラム・プロトコル(UDP)に基づきます。一部のコンポーネント間にファイアウォールが存在する場合、Coherenceが使用するUDPポートを開いておく必要があります。それ以外の場合、Access Managerは正常に作動しない可能性があります。


注意:

OAMサーバー間で一貫した共通のセッション状態を維持するには、Coherenceインフラストラクチャのクラスタ・メンバーをネットワーク接続する必要があります。ネットワーク・コンポーネントに障害が発生した時にもOAMセッション・データの共通性を必要とするデプロイメントには、冗長ネットワーキング・インフラストラクチャを使用することをお薦めします。

Oracle Coherenceは、セッション・データを複製してクラスタ内のすべての管理サーバーに分散します。クライアントはセッションの場所を意識せずに処理を行うことができます。セッション管理エンジンは、必要に応じて他のコンポーネントにセッション・オブジェクトを開示します。


注意:

Oracle Coherenceのトラフィックは自動的に暗号化されます。

Oracle Coherenceはフェイルオーバーとリコンシリエーションも行います。たとえば、1つの管理サーバーに障害が発生した場合、Oracle Coherenceは障害発生サーバーのデータを、他の管理サーバーの分散メモリー内キャッシュへ自動的に分散します。

Oracle Access ManagementコンソールがWebLogic AdminServer上に配置されていても、セッションはここには格納されません。図17-1に、組込みのOracle Coherenceによるセッション保存を示します。

図17-1 セッション・データとOracle Coherenceのロール

セッション・データとOracle Coherenceロール
「図17-1 セッション・データとOracle Coherenceのロール」の説明

セッションは2つのホストに格納されます。分散キャッシュに割り当てられたメモリー領域が不足している場合は、最も古いセッションがキャッシュから削除されます。セッション管理エンジンが分散キャッシュのみを使用するように構成されている場合、削除されるセッションは失われないようにフラット・ファイル内に記録されます。次のリストに、認証の成功後にセッション・データがどのように格納されるのかについて概要を示します。

  1. セッションは、分散メモリー内キャッシュに作成されます。リソースをホストするコンピュータ(この例では管理対象サーバー1)のローカルのメモリー内キャッシュには、そのコピーがあります。データベースに対するセッション永続性が有効な場合、セッションはデータベースにも書き込まれます。

  2. セッションが変化するたびに、Oracle Coherenceはセッションを更新し、OAMサーバー(この例では管理対象サーバー2)間で分散キャッシュにセッションをレプリケートして分散します。デフォルトでは、変化するたびに、データベースにも書き込まれます。

  3. 新しくリソースがリクエストされると、リソースをホストしているコンピュータ(この例では管理対象サーバー3)のローカルのメモリー内キャッシュにセッションが読み込まれます。

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

特定のレベルの認証スキームを満たすと、それより低いレベルで保護されているすべてのリソースへのアクセスが可能となります。さらに、特定のレベルのすべての認証スキームが、同等として表示されます。この項では、2つのアプリケーション・ドメインで使用される単一の認証スキームに基づく簡単なセッション実施例と、2つのアプリケーション・ドメインで使用される複数の認証スキームに基づくより複雑な例を示します。

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

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

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

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

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

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

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

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

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

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

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

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

0

D1へのアクセス

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

null

1

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

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

レベル2、認証時間1

21

D2へのアクセス

許可

レベル2、認証時間1

66

D1へのアクセス

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

レベル2、認証時間1

67

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

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

レベル2、認証時間67

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

前のリリースのAccess Managerでは、セッションは、Oracle Identity Management統合のセルフサービス・フロー(強制パスワード・リセットなど)で、その認証レベルを下げることのみ可能でした。このリリースでは、当然セッションがタイムアウトするとステップダウン認証が発生します。これは、セッションで以前保持していた最大のレベルのスキームを満たす新しい資格証明をユーザーが提供するまで継続します。そうしない場合、認証の観点からは、セッションは新規で、さらなるステップアップが必要であるように見えます。次の2つの認証スキーム(ステップアップとステップダウン)のある例を考えます。

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

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

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

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

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

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

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

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

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

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

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

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

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

セッション・ライフサイクルの設定は、Oracle Access Managementコンソールを使用して定義できます。グローバルまたはアプリケーション固有のセッション・ライフサイクル設定を定義する際、タイミング間隔を0に設定すると、対応するチェックが取り消されます。たとえば、アイドル・タイムアウトを0に設定すると、セッションがアイドル・タイムアウトすることはありません。セッションの存続期間を0にすると、セッションは期限切れになりません。すべての場合において、適用可能なデータは、リクエストごとにチェックされるかのように、セッションで追跡され、更新されます。

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

17.4.1 グローバル・セッション・ライフサイクル設定について

Access Managerセッションのライフサイクル設定は、すべてのOAMサーバーが共有する共通設定の一部として定義されます。図17-2は、「共通設定」ページの構成可能なライフサイクル属性を示しています。

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

共通セッション設定ページ
「図17-2 グローバル・セッション詳細: 「共通設定」ページ」の説明

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


関連項目:

Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド

表17-1 グローバル・セッション設定

設定 説明

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

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

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

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

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

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

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

デフォルト=15分

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

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

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

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

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

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

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

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

アクティブ・セッションのデータベース永続性が有効

ローカルおよび分散キャッシュに加えて、構成済データベース・セッション・ストアにアクティブ・セッションを永続化します。すべての管理対象サーバーが停止している場合でも、セッションは保持されます。

デフォルト = 有効(選択)

使用する環境でこの必要がない場合、またはデータベースを考慮したサイズでデプロイメントを実行する場合、チェック・ボックスの選択を解除し、すべてのOAMサーバーを再起動してこの機能を無効にします。

17.4.2 アプリケーション固有セッションのオーバーライドについて

アプリケーション固有のアクセスは、最初のアプリケーションのアクセス時から追跡され、そのアプリケーション・ドメインに対してさらにリクエストが行われた場合にのみ更新されます。つまり、ユーザー認証および認証の状態は、Access Managerと管理者により制御されます。特定のアプリケーションの現在のアイドル時間は、Access Managerとアプリケーション間で共有されます。アプリケーションは、セッションごとにユーザー独自の実行時データをプロビジョニングするため、早急にこれを削除して他のユーザーのために領域を空ける必要があります。

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

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

要素 説明

アイドル・タイムアウト

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

デフォルト: 未定義

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

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

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


関連項目:

「グローバル・セッション・ライフサイクル設定について」

グローバル・セッション設定を表示または変更するには:

  1. Oracle Access Managementコンソールで、「共通設定」をクリックします。

  2. 「共通設定」ページで「セッション」セクションを展開します。

  3. 必要に応じて、各リストの横にある矢印キーをクリックしてセッションのライフサイクル設定を増減させます(表17-7)。

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

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

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

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

    • アクティブ・セッションのデータベース永続性が有効

  4. ボックスを選択してアクティブ・セッションのデータベース永続性を有効化します。

  5. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

  6. 終了する際はページを閉じます。

  7. 次のトピックのいずれかに進みます。

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

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


関連項目:

「アプリケーション固有セッションのオーバーライドについて」

オプションのアプリケーション固有セッション設定を表示または変更するには:

  1. Oracle Access Managementコンソールで「アプリケーション・ドメイン」をクリックします。

  2. 目的のドメインを検索して開きます。

  3. 「サマリー」タブで次の情報を入力し、このドメインをセッション・オーバーライドを使用するグループに作成(または追加)します(表17-8)。

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

  4. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

  5. 「アクティブなサーバー側セッションの管理」に進みます。

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

Oracle Access Managementコンソールの「セッション管理」ページには、管理者がフィルタ条件に基づいて問合せを作成し、検索基準を後で使用するために保存し、検索をさらに絞り込むために問合せフォームにフィールドを追加できる検索コントロールが用意されています。

データベース・ストア構成で、セッションがデータベースには存在するがキャッシュには存在しない場合があります。セッション検索はシステム・タイムスタンプに基づきます。データベースに対して、タイムスタンプよりも先に更新されたセッションの問合せが行われます(書込み遅延を差し引いて)。キャッシュに対しては、このタイムスタンプよりも後に更新されたセッションの問合せが行われます。キャッシュおよびデータベースで検出された結果のデータがマージされます。重複した結果が存在する場合、キャッシュ・データが優先されます。検索操作に詳細パフォーマンス・メトリックが生成されます。

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

17.5.1 セッション管理ページについて

図17-3に、「システム構成」タブの「共通構成」セクションにある「セッション管理」ページを示します。詳細は、図の後に説明します。

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

共通構成: 「セッション管理」ページ
「図17-3 共通構成: 「セッション管理」ページ」の説明

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

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

名前 説明

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

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

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

保存済の検索

再使用のために以前保存した検索基準をリストします。検索基準を保存すると次のようなリストが常に使用可能になります。

セッション検索: 保存済

パーソナライズを選択すると、次のウィンドウで新しい選択を行うことによって保存済検索基準の動作を変更できます。

セッション検索: パーソナライズ

一致、すべて、任意

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

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

ユーザーID

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

検索を支援する次のリストが使用可能です。

セッション・コントロール: ユーザーIDおよびクライアントIPアドレス

クライアントIPアドレス

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

検索

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

リセット

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

保存

このボタンをクリックすると、検索基準の再使用を有効にする検索操作が開始されます。次のウィンドウが開きます。

セッション検索: 保存...

  1. 後で選択するときに「保存済の検索」リストに表示する名前を入力します。

  2. この検索をデフォルトとして設定します(またはチェック・ボックスの選択を解除します)。

  3. この検索が自動的に実行されるように設定します(またはチェック・ボックスの選択を解除します)。

  4. 結果のレイアウトを保存します(またはチェック・ボックスの選択を解除します)。

  5. 「OK」をクリックします。

フィールドの追加

検索フォームに別のフィールドを追加できます。支援する次のリストが使用可能です。

セッション検索: 追加

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

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

項目を追加した後、検索を支援するリストが使用可能になります。たとえば、雇用および時間ベースの選択には、次のリストが用意されています。

セッション検索: 時間

表示

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

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

    「セッション管理」ページの「表示」メニュー

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

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

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

Delete

「削除」ボタン

結果表から選択した項目を削除するには、このコマンド・ボタンを選択します。

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

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

デタッチ

「デタッチ」ボタン

結果の表を展開してフルページ表示にするには、このボタンをクリックします。

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

結果表(名前なし)

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

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

  • ユーザーID:

  • 偽装:

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

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

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

  • IDストア

  • インパーソネータ

17.5.2 アクティブ・セッションの管理

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

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


関連項目:

「セッション管理ページについて」

必要のないステップはスキップしてください。

前提条件

OAMサーバーが実行中でなければなりません。

アクティブ・セッションの特定と管理

  1. Oracle Access Managementコンソールで、「セッション管理」をクリックします。

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

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

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

  4. セッションの検索:

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

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

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

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

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

  6. セッションの削除:

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

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

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

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

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

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

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

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

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

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

次の手順を使用して、構成したセッション・ライフサイクル操作を検証します。

セッション操作を検証するには:

  1. 認証:

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

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

  2. 複数セッション:

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

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

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

  4. 再認証の検証:

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

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

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

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

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

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

      SQL> select * from oam_session

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

      no row selected

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

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

      SQL> select * from oam_session

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

      1 rows selected

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

17.7 クライアント側セッション管理の理解

クライアント側(Cookieベース)のセッション管理は、軽量なセッション管理ソリューションで、サーバー側のオーバーヘッドを軽減し、より優れたスケーラビリティを提供します。ここでは、SSOセッションの永続メカニズムとしてクライアント側のCookieを使用し、サーバーをステートレスにします。クライアント側のセッション管理では、次の機能をサポートします。

  • 認証

  • 認可(セッションの制約およびレスポンスを除く)

  • TAPでのOAMとOIMの統合(属性変更(アカウントのロック/無効化など)でのセッションの削除を除く)

  • ステップアップ認証

  • 単一Webドメインでの非アクティブのタイムアウト

17.8 WLSTを使用したセッション管理の構成

サーバー側(デフォルト)またはクライアント側(Cookieベース)のセッション管理には、次のWLSTコマンドを使用できます。

17.8.1 displaySSOSessionType

セッション管理構成を表示できる、オンラインおよびオフラインのコマンド。

17.8.1.1 説明

セッション・タイプ構成を表示できます。

17.8.1.2 構文

displaySSOSessionType(domainHome="<domainHome>")
引数 定義 
domainHome
WebLogic Serverの場所またはWebSphereのセル・パスを指定します。このパラメータは、WebSphereでは必須です。オフラインの場合、値は必須です。オンラインの場合はオプションです。

17.8.1.3 例

displaySSOSessionType(domainHome="/oracle/product/OAM/domains/oam_domain")

17.8.2 configSSOSessionType

セッション管理をCOOKIE-BASEDまたはDEFAULTに構成できる、オンラインおよびオフラインのコマンド。

17.8.2.1 説明

Access Managerのセッション管理を構成します。

17.8.2.2 構文

configSSOSessionType(type="<ssoSessionType>",
  cookieDomain="<cookieDomain>",domainHome="<domainHome>")
引数 定義 
type
セッション・ストアのタイプを指定します。有効な値は、COOKIE_BASEDまたはDEFAULTです。 
cookieDomain
SSOセッション・タイムアウトCookieドメインの値を指定します。 
domainHome
WebLogic Serverの場所またはWebSphereのセル・パスを指定します。このパラメータは、WebSphereでは必須です。オフラインの場合、値は必須です。オンラインの場合はオプションです。

17.8.2.3 例

configSSOSessionType(type="COOKIE_BASED",cookieDomain-".example.com")

configSSOSessionType(type="COOKIE_BASED",cookieDomain-".example.com",
  domainHome="domainHome1")

configSSOSessionType(type="Default",cookieDomain=".example.com")
  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引