| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
次の各トピックでは、サーバー側セッション管理の概要について説明します。
セッションのセキュリティは、安全なインストールから始まります。
インストールの詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。
関連項目:
Oracle Fusion Middlewareコンポーネント間のSSLを使用したセキュア通信の構成の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。
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などを使用してデータベース内を暗号化します。
セッション・ライフサイクルは、定義されているある状態から別の状態への遷移を含む状態のセットです。この遷移は、ユーザーのアクティビティ(またはその欠如)や手動(または自動)の管理者アクティビティにより異なります。
管理者は、次のグローバル・セッション・ライフサイクル設定を定義できます。
セッションの存続期間
アイドル・タイムアウト
セッションの最大数
アクティブ・セッションのデータベース永続性
ノート:
アイドル・タイムアウトは、アプリケーション固有の設定としても実装できます(後述)。
表16-1に、セッション・ライフサイクルの各状態を示します。
表16-1 セッション・ライフサイクルの状態
| 状態 | 説明 |
|---|---|
アクティブ |
新たに作成されたセッションはアクティブです。ユーザーがAccess Managerによって認証されるとセッションが作成されます。 セッションは、この表内の別の状態のいずれかに遷移する必要があるとAccess Managerが判断するまで、アクティブな状態を維持します。 ノート: 管理者が削除できるのは、アクティブなセッションのみです。 |
アイドル |
ユーザーがAccess Managerによって保護されているコンテンツにアクセスしない状態が、管理者により定義された期間継続すると、セッションはアイドルになります。 アクティブ・セッションがアイドルになると、先に進む場合、ユーザーは再認証する必要があります。再認証に成功すると、セッションはアクティブな状態に戻ります。セッションの属性値はこのプロセスを通して保持されます。 |
期限切れ |
セッションの期間が定義されたライフタイムを超えると、アクティブなセッションは期限切れとなります。期限切れのセッションは、完全にアクセス不能で、削除の対象となります。アクティブ・セッションが期限切れになると、先に進む場合、ユーザーは再認証する必要があります。 再認証に成功すると、新しいセッションが作成されます。ただし、(アイドル状態のように)セッション属性値が保持されることはありません。 |
各Access Managerセッションは、2つの時間属性および適用可能な値を保持します。
表16-2 状態変更のためのセッション・チェック
| セッション・チェック | 説明 |
|---|---|
セッションはアイドルか。 |
最終アクセス時間を構成されているアイドル・タイムアウト値と比較します。構成されている期間を超えている場合、アクティブからアイドルの状態への変更がトリガーされます。 |
セッションは期限切れか。 |
セッションの作成時間を構成されているセッションの存続期間と比較します。構成されている期間を超えている場合、アクティブから期限切れの状態への変更がトリガーされます。 |
アイドル状態への遷移の際、基盤となるセッション属性は保持されます。これは、ユーザーが以前満たしていた認証条件およびデータが信頼できるためです。ただし、そのセッションに基づいて保護されているリソースや、そのセッション内のデータの変更結果に引き続きアクセスすることは、ユーザーが再認証を行い、ロック解除されたコンピュータへのアクセス権を持つ悪意のあるユーザーでないことを証明するまで、許可されません。
セッションは、期限切れ、ユーザー・ログアウトおよび終了の3つのアクションによって削除できます。
表16-3で、セッションの削除アクションについて説明します。
表16-3 セッションの削除
| アクション | 説明 |
|---|---|
期限切れ |
期限切れのセッションは、その作成時間に基づいて、削除の対象となります。実際の削除は、格納メカニズムによって決定されます。セッションは、サーバーで実行されるバックグラウンド・タスクを使用して分散キャッシュから削除され、同様のバックグラウンド・タスク、オプションで有効となるデータベース内のジョブ、または両方の方法を組み合せて使用して、データベースから削除されます。 セッションがすべての層の記憶域(ローカルおよび分散キャッシュ、および有効な場合、データベース)から削除されると、そのセッションは完全に除去されます。 |
ユーザー・ログアウト |
ユーザー・ログアウトにより、現在のデータベース・セッションの書込みおよびパフォーマンスの量に従い、分散キャッシュからの迅速な削除がトリガーされます。 |
終了 |
終了は、管理コンソールによりセッションが対話的に終了されるのか、Oracle Identity Managementのユーザー・ロックアウトまたはプロビジョニング解除フローの一部として自動的に行われるのかに関係なく、ユーザー・ログアウトと同じです。 |
ステップアップ・フローを完了するために、単一のセッションで複数の認証フォームが必要となり、実行される場合があります。再認証レベルは、セッションからのステップダウンの場合もあります。
ステップアップ・フローでは、ユーザーが保護されたコンテンツにアクセスするために認証した後、同じセッション内で、より機密性の高い別のコンテンツをリクエストすると、それにアクセスするため、より厳しいレベルで再度認証を要求されます。ステップアップ・フローでは、常に、認証レベルが上昇する順に、複数の認証が発生します。各セッションでは、ステップアップ認証実行の認証レベル属性を保持します。
再認証レベルが、前にセッションに含まれていたレベルより低い場合、ユーザーによりステップダウン・プロセスが行われています。正常に再認証すると、セッションは、使用された認証スキームのうち低い方と等しい認証レベルで、アクティブな状態に復元されます。後でユーザーが、より高いレベルで保護されたコンテンツにアクセスを試みると、ステップアップ認証が発生します。
Access Managerは、1セットのグローバル・セッション・タイミング、またはアクセスが単一の認証レベルのみに依存する1セットの認証スキームで可能な方法より粒度の細かい方法で、リソースへのユーザー・アクセスを制限します。特定のデータへのアクセスには、より厳しい要件がありますが、その他すべてのデータへのアクセスは、グローバルに構成されます。
管理者は、アプリケーション・ドメイン設定の一部として定義されたグローバル・セッション・タイムアウト設定を、アプリケーションごとにオーバーライドできます。オプションのアプリケーション固有セッションの設定では、次の機能が提供されます。
アプリケーションごとにセッション・アイドルのタイミングを宣言する機能。これは一般的に、デプロイメント全体で定義されているグローバル・アイドルのタイミングより厳しくなります。
アプリケーションごとのセッション非アクティブのタイムアウトの後、ユーザーに再認証を要求する機能。
表16-4では、グローバル・セッション設定に対するアプリケーション・ドメイン固有のオーバーライドを定義した場合のセッションの実施について説明します。
表16-4 アプリケーション・ドメイン固有のオーバーライド
| オーバーライド | 説明 |
|---|---|
セッションはアイドルか。 |
最終アクセス時間を、定義したアプリケーション・ドメインのみに対して構成されているアイドル・タイムアウト値と比較します。構成されている期間を超えている場合、アクティブからアイドルの状態への変更がトリガーされます。 |
セッションは期限切れか。 |
セッションの作成時間を構成されているセッションの存続期間と比較します。構成されている期間を超えている場合、定義したアプリケーション・ドメイン・グループのみに対して、アクティブから期限切れの状態への変更がトリガーされます。 |
アイドル・タイムアウトは、セッションが切断されている状態で動作している場合でも適切に適用されます。(切断された状態は、Webゲート以外によりmod_ossoリクエストが行われている場合に発生します。この場合、サーバーにはセッションがアイドル・タイムアウトしたように見えます。)OSSOエージェントのグローバル・ログアウトを有効にするには、セッション管理エンジンで、OSSOエージェントでの活動時間に対してOAMエージェントでの休止時間のリコンシリエーションを行います。
mod_ossoエージェントは、(editGITOValues WLSTコマンドを使用して)グローバルな非アクティブ・タイムアウトが有効になっている場合にのみ、粒度の細かいタイムアウトをサポートします。OAMサーバーとともに動作する複数のタイプのエージェント(mod_ossoやWebゲートなど)でタイムアウトをサポートする特別なケースでは、OAM_GITO Cookieが必要です。ユーザーがアクティブ・セッション(OAMエージェントによるもの)をそのままにしてOSSOエージェントによるセッションを開始した場合、そのユーザーが最初のセッション(OAMエージェントによるもの、その時点では非アクティブ)に戻ると、セッション管理エンジンはOAMエージェントでの休止時間とOSSOエージェントでの活動時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。
ノート:
OAM_GITO Cookieを使用する際は、「アイドル・タイムアウト」パラメータの値を変更することを強くお薦めします。
管理者としてOAMコンソールにログインします。
「システム構成」タブをクリックします。
「共通設定」をクリックします。
(「セッション」セクションで)「アイドル・タイムアウト」パラメータの値を、定義されているOAM_GITO Cookieの値と一致するように変更します。
OAM_GITO Cookieの有効化と構成は、editGITOValues WLSTコマンドを使用して行います。詳細は、Oracle Fusion Middleware WebLogic Scripting Tool Identity and Access Managementコマンド・リファレンスを参照してください。
Access Managerセッションは、永続または分散セッションとして構成できます。
Access Managerのデフォルトの構成は永続セッションですが、Oracle Access Managementコンソールを使用してこれを変更できます。
Access Managerが永続セッション用に構成されている場合、すべてのユーザー・セッションはバッキング・データベースに格納され、サーバーの再起動後も使用できます。最近作成されたセッションおよびもっとも頻繁に使用されるセッションも、コヒーレンス・キャッシュのメモリーに格納されます。セッションは非同期スレッドにバッチ・モードでデータベースに書き込まれ、セッションの作成および更新の際の待機時間を短縮できます。サーバーから要求されると、コヒーレンス・キャッシュは、その時点のキャッシュのヒット数に基づいて、ローカル・コピーまたはバッキング・データベースに格納されたコピーのいずれかを透過的にフェッチします。インメモリー・キャッシュのサイズは、アクティブなセッションを格納するくらいの小容量にすることができます。コヒーレンス・キャッシュのサイズは構成可能です。デフォルトでは、100MBで定義されています。
Access Managerが分散セッション用に構成されている場合、ユーザー・セッションは、インメモリー・コヒーレンス・キャッシュにのみ格納されます。これらのセッションは、サーバー・クラスタの再起動後に使用できません。ただし、いずれかの特定のノードが停止している場合は、そのノードのバックアップ・セッションが使用されます。保持されるセッションの合計は、コヒーレンス・キャッシュのサイズ( Oracle Access Managementコンソールを使用して構成可能)に制限されます。キャッシュに格納できないほど多くのユーザーがログインした場合は、もっとも古い非アクティブなセッションがキャッシュから削除されます。キャッシュからセッションが削除されたユーザーは、認識されて保護されたリソースへのアクセスを付与されるために再ログインする必要があります。
前述のいずれかの構成のために必要なコヒーレンス・キャッシュのサイズは、次の式を使用して計算されます。
S = N * (1 + b) * s / n
Sは、OAMサーバーごとにコヒーレンス・セッション・キャッシュに割り当てられるヒープのサイズです。OAMノードごとにセッションに割り当てられるヒープのサイズは、OAM構成ファイルのDistributedCacheMaxSizeという設定要素で更新できます。この構成の更新には、サーバーのローリング再起動が少なくとも必要です。
Nは、キャッシュに格納される最大セッション数です。
bは、バックアップ・コピーの数です。
sは、セッション・オブジェクトの平均サイズです。セッション・オブジェクトの平均サイズは、セッションに格納された属性および応答に基づいて異なる場合があります。この値は、SmeNearCacheキャッシュのバッキング・ストアのコヒーレンスMBeanを調べることにより、任意のインストールで見つけることができます。
nは、クラスタを構成するOAMサーバー・ノード数です。
