この章では、セッション管理の概念とOracle Access Manager 11gでの手順について説明します。この章の内容は次のとおりです。
この章のタスクを行なうには以下のことを確認または理解する必要があります。
一般的に、ユーザーがWebサイトにアクセスすることをセッションと呼びます。Oracle Access Manager 11gでは、ユーザーはOracle Access Managerの認証サービスを通じて認証を受け、Oracle Access Managerに保護されたリソースにアクセスしなければなりません。
Oracle Access Manager 11gのセッション管理とはユーザー・セッションのライフサイクル要件を管理し、セッション・イベントを通知してグローバル・ログアウトを有効にするプロセスを言い、
Oracle Access Manager 11gのセッション管理エンジン(Session Management Engine: SME)は、セッション・イベントと通知のコントローラとして動作するSSOエンジンとのインタフェースを取ります。SMEサービスはユーザー・セッション・データの自動生成、更新、および管理を可能にし、管理者によるセッション・ライフサイクルの構成、および特定アクティブ・セッションの検索と削除を可能にします。
注意: ユーザーは、同じセッションの間、登録されたOAMエージェントとOSSOエージェントの両方に保護されたリソースにアクセスできます。 |
Oracle Access Managerのインストールと構成の際には、セッション・データ・ストレージを選択する必要があります。クラスタ内のすべてのサーバーには同じストレージ・メカニズムが適用されますが、これはインストール後に変更できます。
セッション・データは、待機時間、可用性、およびリソース消費のバランスを取るために複数の層に保存されます。これには以下のものが含まれます:
管理されている各Oracle Access Managerサーバーのローカルのメモリー内キャッシュ
このキャッシュには、アクティブ・サーバー・リクエストに使用するセッション・データが格納されます。現在使われていないデータを迅速に排除するために短いTTLが使われます。
管理されているすべてのOracle Access Managerサーバーによって共有される分散メモリー内キャッシュ
このキャッシュには、Oracle Coherenceによる管理のためにシリアル化されたセッション・データが格納されます。Coherenceを使用すれば、エージェントがコンタクトしてセッション関連のアクセス・リクエストを行なうことのできるすべての管理サーバーで、セッション・データを使用することができます。また、Coherenceは実行中のサーバー間でこのデータを複製して、フォールトトレランス性を提供します。分散キャッシュ内のエントリは、TTLではなく、マシンごとに適用される全体的なキャッシュ・メモリ・サイズに基づいて排除されます。
最大キャッシュ・メモリ・サイズに達すると、次のどちらのアクションが取られます:
セッション・ストアが有効になると、スペースを確保するために分散キャッシュからエントリが排除されます。これらのエントリはデータベース内には存在しており、必要な場合は分散キャッシュに呼び戻すことができます。
セッション・ストアが有効になっていない場合は、フォールバック・メカニズムとしてローカル・マシン上のフラット・ファイルにエントリが書き込まれます。このファイル内のエントリ数がそのアクティブ・セッション合計数のパーセンテージとともに増えるに従い、パフォーマンスは低下していきます。
注意: ユーザーがログアウトした時、またはセッションが期限切れとなった時は、メモリ内ストアからセッション・データが自動的に削除されます。詳細については「ユーザー・セッションのライフサイクルについて」を参照してください。 |
OAM 11gでは、OAMポリシー・データと(オプションで)OAMユーザー・セッション・データを保存するためのデータベースが必要です。このデータベースは、(何十万という同時ログインが行なわれるような)非常に大きなデプロイメントにフォールトトレランス性とスケーラビリティを提供します。
セッション・ストアには、セッション変更ごとに最新のデータが書き込まれます(ステップアップ認証はセッション変更の一例です)。これは非同期で行なわれるので、セッションの作成や更新を伴うリクエストの待機時間に影響しません。セッション・データは不意の電源異常時にも使用できます。
OAMセッション・データを保存するには、OAM固有のスキーマによってデータベース・セッション・ストアを開く必要があります。
OAMの固有スキーマによってRCUを使用し、ポリシー・ストアまたはセッション・データ・ストアとしてデータベースを設定します。
データベース・ポリシー・ストア構成テンプレートとともにOracle Access Managerを使用してOAMを有効にし、ポリシー・ストアおよびセッション・データ・ストアとしてデータベースを使用します。
Oracle Access Manager 11gはOracle Coherenceを使用して分散キャッシュのデータ・アクセス待機時間を短縮し、分散キャッシュ間で(およびセッション・ストアへ)データを透過的に移動します。セッション・データは、これらの層の間で冗長性を有しています。たとえば、セッションが作成されると、そのセッションを作成したサーバー上のローカル・キャッシュ内、分散キャッシュ、および(有効になっている場合は)セッション・ストア・データベース上にも同じものが複製されます。詳細については、「Oracle Coherenceとセッション管理」を参照してください。
管理者はユーザー・セッション・ライフサイクルを構成して、ユーザー・セッションの最大持続時間、ユーザーが再認証を必要とするまでの非活動時間、各ユーザーの持つアクティブ・セッションの最大数を定義することができます。セッションの期限切れを設定すれば、ユーザーのログイン時とログアウト時にのみサーバーから認識できるOSSOエージェント(mod_osso)との相互運用性を有効にすることができます。詳細については、「ユーザー・セッションのライフサイクル設定の構成」を参照してください。
各セッションは固有のものであり、同じユーザーの別のセッションと区別するために、ユーザーIDとセッションIDによって識別されます。管理者は、特定のユーザーもしくはすべてのユーザーの1つまたは複数のアクティブ・セッションを特定して、削除することができます。たとえば、開いているセッションの数が多過ぎるユーザーは、改めてセッションを開始できるように、管理者に連絡してそのセッションの一部または全てを削除するよう求めることができます。詳細については、「アクティブ・ユーザー・セッションの管理」を参照してください。
ユーザー・セッションのライフサイクル設定は、OAM管理コンソールを使用して定義することができます。WebLogic Scripting Toolには、セッション管理ためのオプションは含まれていません。
ユーザー・セッションのライフサイクルとは、ユーザー・セッションの開始から終了までのユーザー・アクティビティの時間を言います。セッション・ライフサイクルの状態には以下のものがあります。
アクティブ: ユーザーがOracle Access Managerによって認証されるとセッションが開始されます。ユーザーがOracle Access Managerに保護されたコンテンツをリクエストし、なおかつセッションの期限が切れない限り、セッションはアクティブ状態に維持されます。
非アクティブ: セッション・ライフサイクル構成の「アイドル・タイムアウト」属性によって定義された時間にわたってユーザーがOAM保護コンテンツにアクセスしないと、そのセッションは非アクティブになります。
期限切れ: セッション持続時間が、「セッションの存続期間」属性によって定義された時間を超えました。
定められた「アイドル・タイムアウト」時間にわたってユーザーが何もしないと、アクティブ・セッションは非アクティブになります。セッション継続時間が定められた「セッションの存続期間」を超えると、そのセッションは期限切れとなります。
セッション管理エンジンは、非アクティブ・セッションのリストを維持します。アクティブ・セッションが非アクティブになるか期限切れになると、ユーザーは再認証をしなければなりません。期限切れとなったセッションのデータは自動的にメモリー内キャッシュ(またはオプションのSMEデータベース)から削除されます。管理者が削除できるのはアクティブ・ユーザー・セッションのデータだけです。
OSSO GITOのサポート: 特別な場合には、OAM 11gサーバーで使用する複数タイプのエージェント(mod_ossoとWebGate)が関係するタイムアウトをサポートするためのGITO Cookieが必要です。これが有効になっている時に(editGITOValues
WLSTコマンドを使用)ユーザーがアクティブ・セッション(OAMエージェントによるもの)をそのままにしてOSSOエージェントによるセッションを開始した場合、そのユーザーが最初のセッション(OAMエージェントによるもの−その時点では非アクティブ)に戻ると、セッション管理エンジンはOAMエージェントでの休止時間とOSSOエージェントでの活動時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。切断された状態でセッションが稼動しているとしても、アイドル・タイムアウトは適切な形で適用されます(mod_ossoリクエストが実行されてもWebGateによって行なわれることはなく、サーバーから見るとそのセッションはアイドル・アウトしているように見えます)。
注意: セッション管理エンジンは、OSSOエージェントでの活動時間に対してOAMエージェントでの休止時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。詳細については「mod_osso Cookie」を参照してください。 |
OAMエージェントに対するユーザー・セッションのライフサイクル設定は、OAM管理コンソールを使用して定義することができます。WebLogic Scripting Toolには、セッション管理ためのオプションは含まれていません。
この項では、メモリー内キャッシュとSMEセッション・データ・ストアとして構成されたデータベースによるセッション管理において、組み込みのOracle Coherenceデータ管理およびキャッシング・サービスを使用する方法を説明します。
注意: OAMサーバー間で共通のセッション状態を維持するには、Coherenceインフラストラクチャのクラスタ・メンバーをネットワーク接続する必要があります。ネットワーク・コンポーネントに障害が発生した時にもOAMセッション・データの共通性を必要とするデプロイメントには、冗長ネットワーキング・インフラストラクチャを使用することをお薦めします。 |
Oracle Coherenceは、セッション・データを複製してクラスタ内のすべての管理サーバーに分散します。クライアントはセッション・データの場所を意識せずに処理を行なうことができます。Oracle Coherenceのトラフィックは自動的に暗号化されます。セッション管理エンジンは、必要に応じて他のOracle Access Managerコンポーネントにセッション・オブジェクトを開示します。データ待機時間を補正してオブジェクトのシリアル化とネットワーク転送を考慮に入れるために、キャッシュは、短命のセッション・オブジェクトを使用時に保持しておくためのニア・キャッシュとして構成されています。
注意: Oracle Coherenceのトラフィックは自動的に暗号化されます。 |
Oracle Coherenceはフェイルオーバーとリコンシリエーションも行ないます。たとえば、1つの管理サーバーに障害が発生した場合、Oracle Coherenceは障害発生サーバーのデータを、他の管理サーバー・ホストの分散メモリー内キャッシュへ自動的に分散します。
組み込みのOracle Coherenceによるセッション・データの保存を図12-1に示します。説明は図の下のリンクをクリックしてください。
注意: OAM管理コンソールは、WebLogic AdminServer上に置かれるアプリケーションです。セッション・データはAdminServerには保存されません。管理コンソールのシステム・ユーティリティ・ノードからセッション管理操作を行なうには、OAMサーバーが実行中でなければなりません。 |
プロセス概要: 認証成功後のSSOセッション・データの保存
セッションが作成されてセッションIDが割り当てられ、分散メモリー内キャッシュにセッション・データが保存されます。リソースをホストするコンピュータ(この例では管理サーバー1)上に、ローカルのメモリー内キャッシュにコピーを短期間保持しておくことができます。
間もなく、ローカルのメモリー内キャッシュはセッション・データを同じホスト上の分散メモリ内キャッシュへ転送します。
注意: 分散メモリー内キャッシュの割り当てメモリ・スペースが足りない場合は最も古いセッションがキャッシュから排除され、データベースが構成されている場合はそこに保存されます。セッション管理エンジンが分散セッション・ストアだけを使用するように構成されている場合、セッションはフラット・ファイル内に置かれます。 |
セッションが変わると、Oracle CoherenceはOAMサーバー(この例では管理サーバー2)の分散キャッシュ内にあるセッションデータを更新して複製し、分散します
注意: 同じセッション・データは2つのホスト(オリジナル・ホストと他の1つ)にだけ保存されます。 |
オプションのデータベース・ストアを使用している場合、Oracle Coherenceはそのデータベース・ストアにもオリジナル・ホストのセッション・データを分散します。
注意: データベース・ストアにはオリジナル・ホストのセッション・データだけが書き込まれます。 |
新しいリソース・リクエストが行なわれて、リソースをホストしているコンピュータ(この例では管理サーバー3)のローカルのメモリー内キャッシュにセッション・データが保存されます。
間もなく、ローカルのメモリー内キャッシュはセッション・データを同じホスト(この例では管理サーバー3)上の分散メモリー内キャッシュへ転送します。
セッションが変わると、Oracle CoherenceはOAMサーバー(管理サーバー2とオプションのSMEデータ・ストア)の分散キャッシュ内にあるセッションデータを更新して複製し、分散します
注意: 同じセッション・データは2つのホスト(オリジナル・ホストと他の1つ)にだけ保存されます。データベース・ストアにはオリジナル・ホストのセッション・データだけが書き込まれます。 |
OSSOに保護されたリソースをリクエストするユーザーが存在するのは、OAMエージェントが使用する同一アクティブ・セッション内です。ただし、OAMサーバーが認識するのはOSSOユーザーのログインとログアウトだけです。複数エージェントの共存を有効にすることができます。
注意: ユーザーは、OAMに保護されたリソースで作業をしながら、OSSOに保護されたリソースにアクセスすることができます。OAMに保護されたリソースを放置すると、アイドル・セッション・タイムアウトとなることがあります。しかし、ユーザーがOAM保護されたリソースに戻ると、Oracle CoherenceはOSSOエージェントでの作業時間に対してOAMエージェント・セッションの休止時間のリコンシリエーションを行い、グローバル・ログアウトができるようにします。 |
この項の内容は次のとおりです。
ユーザー・セッションのライフサイクル設定は、すべてのOAMサーバーが共有するOAMサーバー共通プロパティの一部です。構成可能なライフサイクル属性を図12-2に示します。
共通セッションのライフサイクルセットとそのデフォルトを表12-1 に示します。セッションは切断モードで動作させることができます(たとえばmod_osso)。したがって、セッション規則を確立する構成の変更は、新しいセッションだけに適用されます。変更を直ちに適用する必要がある場合は既存のセッションを終了し、ユーザーには新規則に適合するセッションを新たに作らせることをお薦めします。
表12-1 共通セッション設定
設定 | 説明 |
---|---|
セッションのライフタイム |
ユーザーの認証セッションが有効な状態に維持される時間(分)。ライフタイムに達すると、そのセッションは期限切れとなります。 デフォルト = 480分 値を0にするとこのタイムアウト設定は無効となります。 注意: 期限切れセッションのセッション・データは、メモリー内キャッシュ(またはデータベース)から自動的に削除されます。 |
アイドル・タイムアウト |
ユーザーの認証セッションが、Oracle Access Managerに保護されたリソースにアクセスすることなく有効な状態に維持される時間(分)。これよりも長い時間アイドル状態が続くと、ユーザーは再認証を求められます。 デフォルト = 15分 値を0にするとこのタイムアウト設定は無効となります。 注意: 非アクティブ・セッションのセッション・データは、メモリー内キャッシュ(またはデータベース)から自動的に削除されます。 |
1ユーザーの最大セッション数 |
各ユーザーが同時に持つことのできるセッションの数。すべてのユーザーに対する複数セッション制限を構成するには、この設定を使用します。 |
有効なOAM管理者ユーザー資格証明を有するユーザーは、以下の手順により、OAM管理者コンソールを使用して共通セッションのライフサイクル設定を変更することができます。
共通セッションのライフサイクル設定を表示または変更する方法
Oracle Access Managerの管理コンソールで、「システム構成」タブをクリックします。
「システム構成」ナビゲーション・ツリーが表示されます。
ナビゲーション・ツリーの「サーバー・インスタンス」をダブルクリックします。
OAMサーバー共通設定ページで「セッション」タブをクリックし、ライフサイクル設定を表示します。
必要に応じ、各リストの横にある矢印キーをクリックしてセッションのライフサイクルを増減させます(表12-1)。
セッションのライフタイム
アイドル・タイムアウト
1ユーザーの最大セッション数
「適用」をクリックして変更を送信します(または変更を適用せずにページを閉じます)。
終了したらページを閉じます。
「アクティブ・ユーザー・セッションの管理」へ進んでください。
この項では、1ユーザーまたは全ユーザーの1つまたは複数のセッションを特定し、削除する方法を説明します。
「システム・ユーティリティ」ノードの「システム構成」タブにある「セッション管理」ページを図12-3 に示します。詳細については図の下のリンクをクリックしてください。
「セッション管理」ページのコントロールと結果の表を表12-2に示します。
表12-2 「セッション管理」ページのコントロールと結果の表
ツール・バー・アイコン | 名前 | 説明 |
---|---|---|
N/A |
すべてのユーザー・セッションを削除 |
すべてのユーザーのアクティブ・セッションを削除するには、このコマンド・ボタンを選択します。 注意: 動作を確認したり拒否したりすることのできる「構成」ウィンドウが表示されます。 |
N/A |
ユーザー名 |
特定のユーザーIDをフィールドに入力して>ボタンをクリックすると、そのユーザーのすべてのアクティブ・セッションが表示されます。 注意: ユーザーIDは正確に入力してください。ワイルド・カードは使用できず、自動入力も使用できません。 |
N/A |
ツール・バー |
表示されたメニューからコマンドを選択するか、結果表の上にあるツール・バーのコマンド・ボタンを選択します。 |
表示 |
表示メニュー |
結果表の上にある「表示」メニューからコマンドを選択して、表を構成します。以下のコマンドを使用できます。
|
![]() |
削除 |
結果表から選択した項目を削除するには、このコマンド・ボタンを選択します。 注意: 動作を確認したり拒否したりすることのできる「構成」ウィンドウが表示されます。 |
![]() |
デタッチ |
結果の表を展開してフルページ表示にするには、このボタンをクリックします。 注意: 表がすでにデタッチされてフルページ表示になっている状態で「デタッチ」をクリックすると、「セッション管理」ページに戻ります。 |
N/A |
結果表(名前なし) |
特定ユーザーのアクティブ・セッションを検索後、表に結果が表示されます。この表には以下の詳細が含まれます。
|
有効なOAM管理者資格証明を持つユーザーは、以下の手順に示す情報を使って、検索結果表の検索の構成、特定ユーザーのアクティブ・セッションの特定、特定ユーザーの1つまたは複数のセッションの削除、またはすべてのユーザーのすべてのセッションの削除を行なうことができます。
必要のないステップはスキップしてください。
前提条件
OAMサーバーが実行中でなければなりません。
アクティブ・セッションの特定と管理
Oracle Access Managerの管理コンソールで、「システム構成」タブをクリックします。
「システム構成」ナビゲーション・ツリーが表示されます。
ナビゲーション・ツリーで「システム・ユーティリティ」をクリックします。
「システム・ユーティリティ」の「セッション管理」をクリックします。
「ユーザー名」フィールドと結果表を含む「セッション管理」ページが表示されます。
結果表の構成:
「表示」をクリックして「表示」メニューを開き、さらに「列」をクリックしてオプション・リストを表示します。
オプション・リストで、表に表示(または表示しない)項目をクリックして選択(または選択解除)します。
結果表を表示して新しい設定を確認します。
特定ユーザーのセッションの特定:
「ユーザー名」フィールドに正しいユーザーIDを入力します。
右側にある>ボタンをクリックして、このユーザーのセッションを特定します。
結果表を確認します。
結果表のデタッチ: 「デタッチ」コマンド・ボタンをクリックして(または「表示」メニューから「デタッチ」を選択して)、表だけを表示します。
特定ユーザーのセッションの削除:
結果表で、ユーザーの1つまたは複数のセッションをクリックします。
「削除」ボタンをクリックしてセッションを選択します。
「はい」をクリックして選択したセッションの削除を確定します(または「いいえ」をクリックして削除を取り消します)。
必要に応じてユーザーに通知します。
すべてのユーザーのセッションの削除:
右上隅にある「すべてのユーザー・セッションを削除」ボタンをクリックします。
確認を求めるメッセージが表示されたら「はい」をクリックします。
終了したら「セッション管理」ページを閉じます。
「セッション管理の検証」へ進んでください。
以下の手順を使用してセッション管理操作を検証します。
セッション管理の検証方法
ブラウザからリソースにアクセスします。
「アクティブ・ユーザー・セッションの管理」の説明に従い、OAM管理コンソールの「システム・ユーティリティ」からユーザー・セッションが存在することを検証します。
複数セッション:
(Cookieを削除した)別のブラウザから別のリソースへアクセスします。
ステップ2を繰り返して2つのセッションが存在することを確認します。
OAM管理コンソールですべてのユーザー・セッションを削除し(「アクティブ・ユーザー・セッションの管理」のステップ7)、アクティブ・ユーザー・セッションが削除されていることを確認します。
再認証:
ステップ2のブラウザから、別のリソースへのアクセスを試みます。
資格証明が要求されることを確認します。
データベースにセッション・データが作成されることを確認:
ステップ2のブラウザから、別のリソースへのアクセスを試みます。
資格証明が要求されることを確認します。
データベースにセッション・データが作成されることを確認:
ステップ4を繰返してすべてのユーザー・セッションを削除します。
OAMユーザーとしてデータベースに接続し、下に示す問合せを実行して表示結果を取得します。
SQL> select * from oam_session
次の結果が得られることを確認します。
1 row selected
ステップ2のブラウザから、別のリソースへのアクセスを試みます。
OAMユーザーとしてデータベースに接続し、下に示す問合せを実行します。
SQL> select * from oam_session
次のようなデータが1行表示されることを確認します。
no rows selected
OAM_SESSION_ATTRIBUTESから行を選択して、そのユーザーのデータが存在することを確認します。
セッション管理のロギングの最適化:
以下のパスから使用プラットフォームのWLSTを起動します。例:
MW_HOME/oracle_common/common/bin/wlst.sh
WLSTに接続してログインします。
domainRuntime()とsetLogLevel(target="oam_server1",logger="oracle.oam.engine.session",level="FINEST",addLogger=1)を実行します。
ファイル<domainhome>/servers/oam_server1/logs/oam_server1-diagnostic.logの内容を追跡確認します。
セッション操作を実行します。
セッション管理エンジンとセッション・ストア・モジュールのログ・メッセージを表示します。
ステップcを繰り返して「SEVERE」レベルに設定し、操作を実行してログ・メッセージを表示します。
この項では、Oracle Access Manager 11gのセッション・セキュリティについて説明します。
Oracle Access Manager 11gは、プロキシによるIPアドレス・チェックを行なってセッションの固定化防止を助けます。セッションの固定化防止をさらに強化するには、セキュアHTTPSプロトコルを使用してください。
メモリー内ではデータは暗号化されませんが、転送時は保護されます。Coherenceは、様々なサーバー上の異なるOAMインスタンス間の通信を行ないます。この通信のセキュリティは以下の2つの方法によって確保されます。
Coherenceが前もってID確認されたホスト間の通信だけをサポートします。
これは一定のIPアドレス範囲として行なうか、特定のホスト名によって行ないます。OAM構成ファイルには、通信に参加するサーバーのエントリが含まれています。起動時にはこの情報がCoherenceに提供され、認可されたサーバーだけが通信に参加するようにします。
Coherenceは、すべての通信に適用されるネットワーク・フィルターをサポートしています。カスタム・フィルタをプラグインすれば、必要な特性を持つフィルタリングを行なうことができます。
OAMは、インスタンス間で行なわれるすべての通信が共通鍵で暗号化/解読されるようにするカスタム・フィルタを備えています。この128ビット鍵はJCKESで使用することができ、インストール時に作成されます。
詳細についてはOracle Coherenceのドキュメントを参照してください。
このセッション管理エンジンはデータを暗号化しません。
セッション管理エンジンは、セッション・データをデータベースに書き込む際に暗号化を行ないません。
懸念がある場合は、Oracle Advanced Securityなどを使用してデータベース内の暗号化を行なってください。