| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2) B69533-02 |
|
 前へ |
 次へ |
この章では、Access Managerのセッションの概念および手順について説明します。この章の内容は次のとおりです。
この章のタスクで必要なことには、次のことが含まれます。
一般的に、ユーザーがWebサイトにアクセスすることをセッションと呼びます。Access Managerでは、ユーザーはAccess Managerの認証サービスを通じて認証を受け、Access Managerによって保護されているリソースにアクセスする必要があります。作成されたAccess Managerセッションは、認証されているユーザーとクライアントにバインドされます。
Access Managerセッションのライフサイクルは、セッションの作成、更新、アイドルおよび期限切れの状態遷移で構成されています。Access ManagerセッションはOAMサーバー内で保持され、(管理者によって手動で、または自動化されたフローを使用して実行された)特定のセッションのライフサイクルの追跡およびポリシー強制を行います。
Access Managerのセッション管理とは、セッションのライフサイクル要件を管理するプロセス、およびグローバル・ログアウトを有効化するためのセッション・イベントの通知を指します。管理者は、Oracle Access Managementコンソールを使用して、Access Managerセッションのライフサイクル設定を構成できます。
Access Managerのセッション管理エンジン(SME)は、セッション・イベントと通知のコントローラとして動作するSSOエンジンとのインタフェース接続します。SMEサービスは、セッションの自動生成、更新および管理を実現し、管理者がセッション・ライフサイクルを構成し、特定のアクティブ・セッションを検索および削除できるようにします。
|
注意: ユーザーは、同じセッションの間、登録されたOAMエージェントとOSSOエージェントの両方に保護されたリソースにアクセスできます。 |
セッション・データのストレージは、Access Managerをインストールして構成するときに選択する必要があります。クラスタ内のすべてのサーバーには同じストレージ・メカニズムが適用されますが、これはインストール後に変更できます。
セッション・データは、待機時間、可用性、およびリソース消費のバランスを取るために複数の層に保存されます。これには以下のものが含まれます:
各管理対象Access Managerサーバーのローカルのメモリー内キャッシュ
このキャッシュには、アクティブ・サーバー・リクエストに使用するセッション・データが格納されます。現在使われていないデータを迅速に排除するために短いTTLが使われます。このキャッシュは、Oracle Coherenceの埋込みテクノロジを使用することで、分散キャッシュのデータ・アクセス待機時間が短縮され、分散キャッシュ(およびデータベース)間でのデータ移動が透過的になります。
すべての管理対象Access Managerサーバーによって共有される分散メモリー内キャッシュ
このキャッシュには、Oracle Coherenceによる管理のためにシリアル化されたセッション・データが格納されます。Coherenceを使用すれば、エージェントがコンタクトしてセッション関連のアクセス・リクエストを行なうことのできるすべての管理サーバーで、セッション・データを使用することができます。また、Coherenceは実行中のサーバー間でこのデータを複製して、フォールトトレランス性を提供します。分散キャッシュ内のエントリは、TTLではなく、マシンごとに適用される全体的なキャッシュ・メモリ・サイズに基づいて排除されます。
最大キャッシュ・メモリ・サイズに達すると、次のどちらのアクションが取られます:
セッション・ストアが有効になると、スペースを確保するために分散キャッシュからエントリが排除されます。これらのエントリはデータベース内には存在しており、必要な場合は分散キャッシュに呼び戻すことができます。
セッション・ストアが有効になっていない場合は、フォールバック・メカニズムとしてローカル・マシン上のフラット・ファイルにエントリが書き込まれます。このファイル内のエントリ数がそのアクティブ・セッション合計数のパーセンテージとともに増えるに従い、パフォーマンスは低下していきます。
|
注意: ユーザーがログアウトした時、またはセッションが期限切れとなった時は、メモリ内ストアからセッション・データが自動的に削除されます。詳細は、「セッションのライフサイクルについて」を参照してください。 |
Access Managerを使用するには、Access Managerポリシー・データおよび(オプションで) Access Managerセッション・データを保存するデータベースが必要です。このデータベースは、(何十万という同時ログインが行なわれるような)非常に大きなデプロイメントにフォールトトレランス性とスケーラビリティを提供します。Access Manager固有のスキーマを使用して拡張されたデータベース・ポリシーとセッション・データ・ストアを使用する必要があります。
セッション・ストアには、セッション変更ごとに最新のデータが書き込まれます(ステップアップ認証はセッション変更の一例です)。これは非同期で行なわれるので、セッションの作成や更新を伴うリクエストの待機時間に影響しません。セッション・データは不意の電源異常時にも使用できます。
Access Managerセッション・データを保存するには、Access Manager固有のスキーマで拡張されたデータベース・セッション・ストアが必要です。
Access Manager固有のスキーマを使用してRCUを実行し、ポリシー・ストアおよびセッション・データ・ストアとしてデータベースを設定します。
Access Managerでデータベース・ポリシー・ストア構成テンプレートを使用して、Access Managerでポリシー・ストアおよびセッション・データ・ストアとしてデータベースを使用できるようにします。
Access Managerは、Oracle Coherenceを使用してデータ・アクセス待機時間の短い分散キャッシュを提供し、分散キャッシュ間で(およびセッション・ストアへ)データを透過的に移動します。セッション・データは、これらの層の間で冗長性を有しています。たとえば、セッションが作成されると、そのセッションを作成したサーバー上のローカル・キャッシュ内、分散キャッシュ、および(有効になっている場合は)セッション・ストア・データベース上にも同じものが複製されます。詳細は、「Oracle Coherenceとセッション管理について」を参照してください。
管理者は、セッション・ライフサイクルを構成して、セッションの最大継続時間、ユーザーが再認証を要求される非アクティブ時間、ユーザー当たりの最大アクティブ・セッション数を定義できます。セッションの期限切れを設定すれば、ユーザーのログイン時とログアウト時にのみサーバーから認識できるOSSOエージェント(mod_osso)との相互運用性を有効にすることができます。詳細は、「セッションのライフサイクル設定の構成」を参照してください。
各セッションは固有のものであり、同じユーザーの別のセッションと区別するために、ユーザーIDとセッションIDによって識別されます。管理者は、特定のユーザーもしくはすべてのユーザーの1つまたは複数のアクティブ・セッションを特定して、削除することができます。たとえば、開いているセッションの数が多すぎるユーザーは、管理者に連絡して、新しくセッションを開始できるように自分のセッションの一部またはすべてを削除してもらうことができます。詳細は、「アクティブ・セッションの管理」を参照してください。
Access Managerは、Oracle Coherenceを使用して、分散インストール内でセッション状態をレプリケートします。Coherenceを使用して、Oracle Access ManagementコンソールとOAMサーバーの間の状態変更を通信します。クラスタ検出およびハートビートについて、Coherenceはユーザー・データグラム・プロトコル(UDP)に基づきます。一部のコンポーネント間にファイアウォールが存在する場合、Coherenceが使用するUDPポートを開いておく必要があります。それ以外の場合、Access Managerは正常に作動しない可能性があります。詳細は、「Coherenceの使用」を参照してください。
セッション・セキュリティは、サーバー間で時刻を同期させることを含むセキュアなインストールから始まります。インストールの詳細は、『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』: Oracle Fusion Middlewareコンポーネント間のSSLによるセキュア通信の構成の詳細 |
この項では、Access Managerセッション・セキュリティについて説明します。
Access Managerは、プロキシによるIPアドレス・チェックを提供することでセッションの固定化防止に役立ちます。
セッション固定化の防止効果をさらに高めるために、WebgateおよびOAMサーバーの間ではセキュアHTTPSプロトコルを使用してください。
メモリー内ではデータは暗号化されませんが、転送時は保護されます。Oracle Coherenceは、様々なサーバーで動作する複数のAccess Managerインスタンス間の通信を処理します。この通信のセキュリティは以下の2つの方法によって確保されます。
Coherenceが前もってID確認されたホスト間の通信だけをサポートします。
これは一定のIPアドレス範囲として行なうか、特定のホスト名によって行ないます。OAM構成ファイルには、通信に参加するサーバーのエントリが含まれています。起動時にはこの情報がCoherenceに提供され、認可されたサーバーだけが通信に参加するようにします。
Coherenceは、クラスタ内のすべてのサーバー間で相互認証されたSSLを使用します。インストール時に、適用可能なキーおよび証明書を保持するjceksが作成されます。
詳細についてはOracle Coherenceのドキュメントを参照してください。
このセッション管理エンジンはデータを暗号化しません。セキュリティ上の懸念がある場合は、Oracle Advanced Securityなどを使用してデータベース内を暗号化します。
セッションのライフサイクル設定は、Oracle Access Managementコンソールを使用して定義できます。WebLogic Scripting Toolには、セッション管理ためのオプションは含まれていません。
セッションのライフサイクルとは、セッションの開始から終了までのユーザー・アクティビティの期間を指します。セッション・ライフサイクルの状態には以下のものがあります。
アクティブ: ユーザーがAccess Managerによって認証されるとセッションが開始されます。ユーザーがAccess Managerによって保護されているコンテンツのリクエストを繰り返し、セッションが有効であるかぎり、セッションはアクティブです。
非アクティブ: ユーザーがAccess Managerによって保護されているコンテンツにアクセスしない状態が、セッション・ライフサイクル構成の「アイドル・タイムアウト」属性によって定義されている時間を超えて継続すると、セッションは非アクティブになります。
期限切れ: セッション持続時間が、「セッションの存続期間」属性によって定義された時間を超えました。
定められた「アイドル・タイムアウト」時間にわたってユーザーが何もしないと、アクティブ・セッションは非アクティブになります。セッション継続時間が定められた「セッションの存続期間」を超えると、そのセッションは期限切れとなります。
セッション管理エンジンは、非アクティブ・セッションのリストを維持します。アクティブ・セッションが非アクティブになるか期限切れになると、ユーザーは再認証をしなければなりません。期限切れとなったセッションのデータは自動的にメモリー内キャッシュ(またはオプションのSMEデータベース)から削除されます。管理者が削除できるのはアクティブ・ユーザー・セッションのデータだけです。
OSSO GITOのサポート: OAMサーバーとともに動作する複数のタイプのエージェント(mod_ossoおよびWebgate)でタイムアウトをサポートする特別なケースでは、GITO Cookieが必要です。これが有効になっている時に(editGITOValues WLSTコマンドを使用)ユーザーがアクティブ・セッション(OAMエージェントによるもの)をそのままにしてOSSOエージェントによるセッションを開始した場合、そのユーザーが最初のセッション(OAMエージェントによるもの、その時点では非アクティブ)に戻ると、セッション管理エンジンはOAMエージェントでの休止時間とOSSOエージェントでの活動時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。切断された状態でセッションが稼動しているとしても、アイドル・タイムアウトは適切な形で適用されます(mod_ossoリクエストが実行されてもWebgateによって行われることはなく、サーバーから見るとそのセッションはアイドル・アウトしているように見えます)。
|
注意: セッション管理エンジンは、OSSOエージェントでの活動時間に対してOAMエージェントでの休止時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。詳細については「mod_osso Cookie」を参照してください。 |
OAMエージェントのセッションのライフサイクル設定は、Oracle Access Managementコンソールを使用して定義できます。WebLogic Scripting Toolには、セッション管理ためのオプションは含まれていません。
切断された状態でセッションが稼動しているとしても、アイドル・タイムアウトは適切な形で適用されます(mod_ossoリクエストが実行されてもWebgateによって行われることはなく、サーバーから見るとそのセッションはアイドル・アウトしているように見えます)。
セッション管理エンジンは、OSSOエージェントでの活動時間に対してOAMエージェントでの休止時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。詳細については「mod_osso Cookie」を参照してください。
OAMサーバーとともに動作する複数のタイプのエージェント(mod_ossoおよびWebgate)でタイムアウトをサポートする特別なケースでは、GITO Cookieが必要です。これが有効になっている時に(editGITOValues WLSTコマンドを使用)ユーザーがアクティブ・セッション(OAMエージェントによるもの)をそのままにしてOSSOエージェントによるセッションを開始した場合、そのユーザーが最初のセッション(OAMエージェントによるもの、その時点では非アクティブ)に戻ると、セッション管理エンジンはOAMエージェントでの休止時間とOSSOエージェントでの活動時間のリコンシリエーションを行い、OSSOエージェントのグローバル・ログアウトができるようにします。
セッション管理上は、OpenSSOエージェントはWebgateと同じです。
OpenSSOエージェントは、mod_ossoと異なり、切断状態では動作しません。
この項では、メモリー内キャッシュとSMEセッション・データ・ストアとして構成されたデータベースによるセッション管理において、組み込みのOracle Coherenceデータ管理およびキャッシング・サービスを使用する方法を説明します。
|
注意: OAMサーバー間で共通のセッション状態を維持するには、Coherenceインフラストラクチャのクラスタ・メンバーをネットワーク接続する必要があります。ネットワーク・コンポーネントに障害が発生した場合もAccess Managerセッション・データの整合性が要求されるデプロイメントには、冗長ネットワーキング・インフラストラクチャを使用することをお薦めします。 |
Oracle Coherenceは、セッション・データを複製してクラスタ内のすべての管理サーバーに分散します。クライアントはセッション・データの場所を意識せずに処理を行なうことができます。Oracle Coherenceのトラフィックは自動的に暗号化されます。セッション管理エンジンは、必要に応じて他のAccess Managerコンポーネントにセッション・オブジェクトを開示します。データ待機時間を補正してオブジェクトのシリアル化とネットワーク転送を考慮に入れるために、キャッシュは、短命のセッション・オブジェクトを使用時に保持しておくためのニア・キャッシュとして構成されています。
|
注意: Oracle Coherenceのトラフィックは自動的に暗号化されます。 |
Oracle Coherenceはフェイルオーバーとリコンシリエーションも行ないます。たとえば、1つの管理サーバーに障害が発生した場合、Oracle Coherenceは障害発生サーバーのデータを、他の管理サーバー・ホストの分散メモリー内キャッシュへ自動的に分散します。
図14-1は、組込みOracle Coherenceを使用する場合のセッション・データの保存を示します。説明は図の下のリンクをクリックしてください。
|
注意: Oracle Access Managementコンソールは、WebLogic AdminServerに存在するアプリケーションです。セッション・データはAdminServerには保存されません。Oracle Access Managementコンソールからセッション管理操作を実行するには、OAMサーバーが稼動している必要があります。 |
プロセス概要: 認証成功後のSSOセッション・データの保存
セッションは、分散メモリー内キャッシュに作成されます。リソースをホストするコンピュータ(この例では管理対象サーバー1)のローカルのメモリー内キャッシュには、そのコピーがあります。セッションは、データベースにも書き込まれます。
セッションが変化するたびに、Oracle Coherenceはセッションを更新し、OAMサーバー(この例では管理対象サーバー2)間で分散キャッシュにセッションをレプリケートして分散します。デフォルトでは、変化するたびに、データベースにも書き込まれます。
新しくリソースがリクエストされると、リソースをホストしているコンピュータ(この例では管理対象サーバー3)のローカルのメモリー内キャッシュにセッションが読み込まれます。
この項の内容は次のとおりです。
ユーザー・セッションのライフサイクル設定は、すべてのOAMサーバーが共有する共通設定の一部です。図14-2は、「共通設定」ページの構成可能なライフサイクル属性を示しています。
表14-1に、共通セッションのライフサイクル設定およびそのデフォルトを示します。セッションは切断モードで動作させることができます(たとえばmod_osso)。したがって、セッション規則を確立する構成の変更は、新しいセッションだけに適用されます。変更を直ちに適用する必要がある場合は既存のセッションを終了し、ユーザーには新規則に適合するセッションを新たに作らせることをお薦めします。
表14-1 共通セッション設定
| 設定 | 説明 |
|---|---|
|
セッションの存続期間(分) |
ユーザーの認証セッションがアクティブな状態に維持される分単位の時間。ライフタイムに達すると、そのセッションは期限切れとなります。 デフォルト = 1440分(整数表現の分数で表した24時間) ゼロ(0)は、この設定を無効にします。0(ゼロ)から2147483647の任意の値が許可されます。 注意: 有効期限が切れたセッションは、メモリー内キャッシュ(またはデータベース)から自動的に削除されます。 |
|
アイドル・タイムアウト(分) |
ユーザーの認証セッションが、Access Managerで保護されたリソースにアクセスすることなくアクティブな状態に維持される分単位の時間。これよりも長い時間アイドル状態が続くと、ユーザーは再認証を求められます。 デフォルト = 15分 ゼロ(0)は、この設定を無効にします。0(ゼロ)から2147483647の任意の値が許可されます。 非アクティブ・セッションのセッション・データは、メモリー内キャッシュ(またはデータベース)から自動的に削除されます。 注意: 非アクティブ・セッションのセッション・データは、セッションのアイドル・タイムアウトを経過したときに、メモリー内キャッシュ(またはデータベース)から自動的に削除されます。OAMサーバーは、アイドル・タイムアウトを認識して、同じセッションを使用する認証を再開始します。 |
|
1ユーザーの最大セッション数 |
各ユーザーが同時に持つことのできるセッションの数。すべてのユーザーに対する複数セッション制限を構成するには、この設定を使用します。 正の整数が許可されます。 このカウントに"1"を指定すると、特殊モードがアクティブ化されます。ユーザーが別のデバイスを使用してセッションの認証を済ませている(つまり、新しいセッションを作成する)場合、そのユーザーの既存のセッションは削除されます。エラーの報告も、警告の表示もありません。 注意: 数値を大きくしすぎると、パフォーマンスに影響を及ぼし、セキュリティのリスクを招くことになります。ユーザーごとの適切な制限として20未満の数値をお薦めします。それ以外の場合は、パフォーマンスに影響する可能性があります。チューニングの詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。 |
|
アクティブ・セッションのデータベース永続性が有効 |
ローカルおよび分散キャッシュに加えて、構成済データベース・セッション・ストアにアクティブ・セッションを永続化します。すべての管理対象サーバーが停止している場合でも、セッションは保持されます。 デフォルト = 有効(選択) 使用する環境でこの必要がない場合、またはデータベースを考慮したサイズでデプロイメントを実行する場合、チェック・ボックスの選択を解除し、すべてのOAMサーバーを再起動してこの機能を無効にします。 |
有効な管理者の資格証明を持つユーザーは、Oracle Access Managementコンソールで次の手順を使用して、共通セッションのライフサイクル設定を変更できます。
共通セッションのライフサイクル設定を表示または変更する方法
「システム構成」タブから「共通構成」セクションを展開し、「共通設定」をダブルクリックします。
「共通設定」ページで「セッション」セクションを展開します。
必要に応じ、各リストの横にある矢印キーをクリックしてセッションのライフサイクルを増減させます(表14-1)。
セッションのライフタイム
アイドル・タイムアウト
1ユーザーの最大セッション数
ボックスを選択してアクティブ・セッションのデータベース永続性を有効化します。
「適用」をクリックして変更を送信します(または変更を適用せずにページを閉じます)。
終了したらページを閉じます。
「アクティブ・セッションの管理」に進みます。
「セッション管理」ページには、管理者がフィルタ条件に基づいて問合せを作成し、検索基準を後で使用するために保存し、検索をさらに絞り込むために問合せフォームにフィールドを追加できる検索コントロールが用意されています。
データベース・ストア構成で、セッションがデータベースには存在するがキャッシュには存在しない場合があります。セッション検索はシステム・タイムスタンプに基づきます。データベースに対して、タイムスタンプよりも先に更新されたセッションの問合せが行われます(書込み遅延を差し引いて)。キャッシュに対しては、このタイムスタンプよりも後に更新されたセッションの問合せが行われます。キャッシュおよびデータベースで検出された結果のデータがマージされます。重複した結果が存在する場合、キャッシュ・データが優先されます。検索操作に詳細パフォーマンス・メトリックが生成されます。
この項では、1ユーザーまたは全ユーザーの1つまたは複数のセッションを特定し、削除する方法を説明します。ここでは、次の情報が提供されます。
図14-3に、「システム構成」タブの「共通構成」セクションにある「セッション管理」ページを示します。詳細は、図の後に説明します。
表14-2では、選択したフィルタ条件に基づいて問合せを作成できる「セッション管理」ページおよび検索コントロールについて説明します。
表14-2 セッション管理のコントロールと結果表
| 名前 | 説明 |
|---|---|
|
すべてのユーザー・セッションを削除 |
すべてのユーザーのアクティブ・セッションを削除するには、このコマンド・ボタンを選択します。 注意: 操作を確認または拒否できる「確認」ウィンドウが表示されます。 |
|
保存済の検索 |
再使用のために以前保存した検索基準をリストします。検索基準を保存すると次のようなリストが常に使用可能になります。 
パーソナライズを選択すると、次のウィンドウで新しい選択を行うことによって保存済検索基準の動作を変更できます。  |
|
一致、すべて、任意 |
検索中に、指定した条件のいずれかに一致させるか、またはすべてに一致させることができます。 注意: リソースが |
|
ユーザーID |
特定のユーザーIDをフィールドに入力して「検索」ボタンをクリックすると、そのユーザーのすべてのアクティブ・セッションが表示されます。不完全な文字列およびワイルド・カードを使用できます。 検索を支援する次のリストが使用可能です。  |
|
クライアントIPアドレス |
クライアントIPアドレスを入力して「検索」ボタンをクリックすると、そのユーザーのすべてのアクティブ・セッションが表示されます。不完全な文字列およびワイルド・カードを使用できます。ユーザーID検索およびクライアントIPアドレス検索を支援する同じリストが使用可能です。 |
|
検索 |
このボタンをクリックすると、フォームの基準に基づいて検索が開始されます。 |
|
リセット |
このボタンをクリックすると、フォームのすべての基準がクリアされます。 |
|
保存 |
このボタンをクリックすると、検索基準の再使用を有効にする検索操作が開始されます。次のウィンドウが開きます。 
|
|
フィールドの追加 |
検索フォームに別のフィールドを追加できます。支援する次のリストが使用可能です。 
項目を追加した後、検索を支援するリストが使用可能になります。たとえば、雇用および時間ベースの選択には、次のリストが用意されています。  |
|
表示 |
結果表の上にある「表示」メニューからコマンドを選択して、表を構成します。以下のコマンドを使用できます。
|
|
削除  |
結果表から選択した項目を削除するには、このコマンド・ボタンを選択します。 注意: セッション検索基準が一般的なものである場合(たとえば、ワイルドカード(*)のみを使用する場合など)、大きなセッション・リストからセッションを削除する際に制限があります。セッション検索基準を十分に細分化することによって比較的小さな結果セット(理想的には20以下)を取得することをお薦めします。 付記: 操作を確認または拒否できる「確認」ウィンドウが表示されます。 |
|
デタッチ  |
結果の表を展開してフルページ表示にするには、このボタンをクリックします。 注意: 表がすでにデタッチされてフルページ表示になっている状態で「デタッチ」をクリックすると、「セッション管理」ページに戻ります。 |
|
結果表(名前なし) |
特定ユーザーのアクティブ・セッションを検索後、表に結果が表示されます。詳細には次が含まれます。
|
有効なOracle Access Management管理者の資格証明を持つユーザーは、次の手順に示す情報を利用して、検索結果表の構成、特定ユーザーのアクティブ・セッションの特定、特定ユーザーの1つ以上のセッションの削除、またはすべてのユーザーのすべてのセッションの削除を実行できます。
リソースがAnonymousSchemeによって保護されている場合、セッション検索には表示されません。
必要のないステップはスキップしてください。
前提条件
OAMサーバーが実行中でなければなりません。
アクティブ・セッションの特定と管理
「システム構成」タブの「共通構成」セクションから「セッション管理」ノードを開きます。
「ユーザー名」フィールドと結果表を含む「セッション管理」の「検索」ページが表示されます。
フィールドの追加: 「フィールドの追加」リストから、目的のフィールド名を選択します(表14-2)。
演算子の選択: 選択した検索フィールドの演算子のリストを開き、目的の関数を選択します。
セッションの検索:
目的の問合せフィールドで、基準を入力します(ワイルド・カード(*)の使用は任意)。
「検索」ボタンをクリックして、基準のいずれかまたはすべてに一致するセッションを探します。
結果表を確認します。
必要に応じて繰り返し、検索を絞り込みます。
結果表の構成: 「表示」メニューの機能を使用して、目的の結果表を作成します。
セッションの削除:
結果表で、削除する1つ以上のセッションをクリックします。
「削除」(x)ボタンをクリックして選択したセッションを削除します。
「はい」をクリックして選択したセッションの削除を確定します(または「いいえ」をクリックして削除を取り消します)。
必要に応じてユーザーに通知します。
すべてのユーザーのセッションの削除:
右上隅にあるすべてのセッションを削除ボタンをクリックします。
確認を求めるメッセージが表示されたら「はい」をクリックします。
終了したら「セッション管理」ページを閉じます。
「セッション操作の検証」に進みます。
以下の手順を使用してセッション管理操作を検証します。
セッション管理の検証方法
認証:
管理資格証明以外の資格証明を使用して、ブラウザでリソースにアクセスします。
「アクティブ・セッションの管理」の説明に従って、セッションが存在することを検証します。
複数セッション:
(Cookieを削除した)2番目のブラウザで同じリソースにアクセスします。
2つのセッションが存在することを検証します。
すべてのセッションを削除し(「アクティブ・セッションの管理」の手順7)、アクティブ・セッションが削除されていることを確認します。
再認証の検証:
2番目のブラウザ(手順2)で別のリソースにアクセスして、再認証を要求されることを確認します。
そのリソースに必要な資格証明を入力します。
セッションが作成されていることを検証します。
データベースの検証:
すべてのセッションを削除します。
データベースに接続し、次の問合せを実行します。
SQL> select * from oam_session
次の結果が得られることを確認します。
no row selected
2番目のブラウザで別のリソースにアクセスします。
データベースに接続し、次の問合せを実行します。
SQL> select * from oam_session
次のようなデータが1行表示されることを確認します。
1 rows selected
OAM_SESSION_ATTRIBUTESから行を選択して、そのユーザーのデータが存在することを確認します。
