1. Real Application Security管理者および開発者ガイド
  2. アプリケーション・セッションの構成

3 アプリケーション・セッションの構成

この章の内容は次のとおりです。

3.1 アプリケーション・セッションについて

アプリケーション・セッションには、アプリケーションとそのユーザーに関連する情報が含まれます。アプリケーション・セッションは、アプリケーション・セッション状態を属性と値のペアのコレクションとして格納します。これらの属性値のペアは、ネームスペースに分割されます。従来の重量データベース・セッションとは異なり、アプリケーション・セッションは、トランザクションやカーソルなどの独自のデータベース・リソースを保持しません。アプリケーション・セッションが消費するサーバー・リソースは重量セッションよりはるかに少ないため、アプリケーション・セッションを各エンド・アプリケーション・ユーザー専用にできます。アプリケーション・セッションは、データベースに永続化でき、後で最小限のコストで再開できます。

アプリケーション・セッションを構成する場合、次の2つの作業フェーズがあります。

  1. アプリケーション・セッションを作成して管理します。

  2. セッションの継続期間中にセッション状態を操作できます。

PL/SQL APIまたはJava APIを使用してアプリケーション・セッションを構成できます。この章では、PL/SQLでのアプリケーション・セッションのプログラムによる作成、使用およびメンテナンスについて説明し、対応するJava情報への特定のリンクを含めます。

関連項目:

この項の内容は次のとおりです。

3.1.1 Real Application Securityでのアプリケーション・セッションについて

図3-1は、アプリケーション・セッションが適用される部分を示したReal Application Securityのアーキテクチャ図です。この図は、データベースでアプリケーション・セッションを作成するアプリケーションを示しています。これらのアプリケーション・セッションの一部は、従来のデータベース(DB)・セッションに関連付けられます。

図3-1は、ACL、アプリケーション権限、アプリケーション・ユーザー、アプリケーション・ロールなどのReal Application Securityの他のコンポーネントも示しています。

図3-1 Real Application Securityのアーキテクチャ

図3-1の説明が続きます
「図3-1 Real Application Securityのアーキテクチャ」の説明

3.1.2 アプリケーション・セッションのメリット

アプリケーション・セッションは、従来のデータベース・セッションよりも機能的に優れています。たとえば、従来のデータベース・セッションは、通常、エンド・ユーザー・アイデンティティや、それらのエンド・ユーザーのセキュリティ・ポリシーを認識しません。これに対して次のようになります。

  • アプリケーション・セッションは、エンド・ユーザーのセキュリティ・コンテキストをカプセル化します。これにより、アプリケーションは、エンド・ユーザー・アイデンティティに基づいて、アクセス制御でデータベースの認可メカニズムを使用できます。

  • アプリケーション・セッションは、同時に複数のデータベース・セッションに関連付けることができます。

  • Oracle Real Application Clusters (Oracle RAC)環境のすべてのノードからアクセスできます。

アプリケーション・セッションには、従来のデータベース・セッションに比べて次のパフォーマンス上のメリットがあります。

  • 従来のデータベース・セッションより少ないオーバーヘッドで作成できます。

  • データベースで維持し、後から最小限のコストで再開できます。

  • Real Application Securityで、キャッシュを使用してクライアント上のセッション属性の変更およびセッション状態を収集できます。その後、これらの変更は次回のデータベース・ラウンドトリップまでデータベースに追加されるため、データベース・ラウンドトリップの回数が減少します。

3.2 アプリケーション・セッションの作成とメンテナンスについて

この項の内容は次のとおりです。

3.2.1 アプリケーション・セッションの作成

アプリケーション・セッションは、PL/SQLでDBMS_XS_SESSIONS.CREATE_SESSIONプロシージャを使用するか、JavaでXSSessionManagerクラスのcreateSessionメソッドを使用して作成できます。アプリケーション・セッションを作成する場合、実行するユーザーには、CREATE_SESSIONアプリケーション権限が必要です。この権限は、XS_SESSION_ADMINデータベース・ロールを通じて取得するか、XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE APIコールによって取得できます(詳細は、「GRANT_SYSTEM_PRIVILEGEプロシージャ」を参照してください)。CREATE_SESSIONプロシージャによって、sessionid OUTパラメータの新規作成セッションの一意識別子にデータが移入されます。この一意識別子は、後続のコールでセッションを参照する場合に使用できます。DBA_XS_SESSIONSデータ・ディクショナリ・ビューに、データベースのすべてのアプリケーション・セッションが表示されます。

セッションの作成時に作成されるネームスペースのリストも指定できます。セッションの作成時にネームスペースを指定した場合、コール元はネームスペースに対するアプリケーション権限MODIFY_NAMESPACEまたはMODIFY_ATTRIBUTE、あるいはADMIN_NAMESPACEシステム権限を持ちます。

例3-1に、lwuser1でのアプリケーション・セッションの作成方法を示します。

例3-1 アプリケーション・セッションの作成

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
END;

関連項目:

3.2.2 匿名アプリケーション・セッションの作成

PL/SQLでDBMS_XS_SESSIONS.CREATE_SESSIONプロシージャを使用するか、JavaでXSSessionManagerクラスのcreateAnonymousSessionメソッドを使用して、匿名アプリケーション・セッションを作成することもできます。PL/SQL APIを通じて匿名セッションを作成するには、事前定義されたユーザー名のXSGUESTを指定する必要があります。

例3-2に、事前定義されたユーザーXSGUESTを使用して匿名セッションを作成する方法を示します。

匿名アプリケーション・セッションを作成したら、そのセッションに名前付きユーザーを割り当てることができます。

例3-2 匿名アプリケーション・セッションの作成

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('XSGUEST', sessionid);
END;

関連項目:

3.2.3 従来のデータベース・セッションへのアプリケーション・セッションの連結

アプリケーション・セッションを使用するには、データベース・セッションに関連付ける必要があります。この操作は、連結と呼ばれます。PL/SQLでDBMS_XS_SESSIONS.ATTACH_SESSIONプロシージャを使用するか、JavaでXSSessionManagerクラスのattachSessionメソッドを使用して、アプリケーション・セッションを従来のデータベース・セッションに関連付けることができます。データベース・セッションが一度に連結できるアプリケーション・セッションは、1つのみです。DBA_XS_ACTIVE_SESSIONS動的データ・ディクショナリ・ビューに、データベースのすべての連結済アプリケーション・セッションが表示されます。

このプロシージャを実行するには、従来のセッション・ユーザーにATTACH_SESSIONアプリケーション権限が必要です。この権限は、XS_SESSION_ADMINデータベース・ロールを通じて取得するか、XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE APIコールによって取得できます。ネームスペースを指定する場合、ユーザーにはネームスペースに対するアプリケーション権限MODIFY_NAMESPACEまたはMODIFY_ATTRIBUTE、あるいはADMIN_NAMESPACEシステム権限が必要です。

例3-3に、アプリケーション・セッションをデータベース・セッションに連結する方法を示します。

Oracle Database 12cリリース2 (12.2)からは、Oracle Label SecurityでReal Application Securityユーザーがサポートされるようになりました。これは、連結操作中にReal Application SecurityセッションにOracle Label Securityコンテキストが確立されるため、Real Application Securityユーザー・セッションでOracle Label Security認可を実行できることを意味します。Oracle Label Securityによって、データ・ラベルの定義、ユーザー・ラベルの割当て、およびOracleデータベース内の機密アプリケーション・データの保護が可能になります。

たとえば、Oracle Label Securityデータ・ラベルを使用すると、機密レベルに基づくラベルを表の各行に付けることができます。データ・ラベルは、レベル、コンパートメント、グループの3つのコンポーネントで構成されます。そのためデータ・ラベルには、1つのレベル、0個以上のコンパートメント、0個以上のグループが関連付けられています。コンパートメントを使用すると、レベル内により細かい粒度を定義でき、特定のプロジェクトに属するすべてのデータに同じコンパートメントを使用してラベルを付けることができます。グループは階層であるため、親グループに関連付けることができます。

また、Oracle Label Securityユーザー・ラベルを使用すると、ラベル付きデータへのアクセスに制約を加えるためのラベルを、各ユーザーに割り当てることができます。各ユーザーには、レベル、区分およびグループの範囲が割り当てられ、各セッションはその認可範囲内で動作してその範囲内のラベル付きデータにアクセスできます。

さらに、Oracle Label Securityの権限はポリシー固有であり、この権限を使用すると、ユーザーが特殊な操作を実行するため特定の権限、またはユーザーが自身のラベル認可外のデータにアクセスするための特定の権限を、ユーザーに提供できます。ポリシー固有の権限は、FULL、READ、COMPACCESS、PROFILE_ACCESS、WRITEUP、WRITEDOWN、WRITEACROSSです。

Oracle Label Securityを使用すると、トラステッド・ストアド・プログラムを使用できます。トラステッド・ストアド・プログラム・ユニットは、1つ以上のLabel Security権限を付与されたストアド・プロシージャ、ファンクションまたはパッケージです。トラステッド・ストアド・プログラム・ユニットは、ユーザーが権限を付与されている操作を制御された方法で実行したり、複数のラベルのデータを更新できるようにするために使用されます。プログラム・ユニットに権限を付与することで、ユーザーに必要な権限を効果的に減らすことができます。

Oracle Label Securityを使用すると、データ・ラベルまたはユーザー・ラベルあるいはその両方を定義し、適切な権限をユーザーに割り当てた後に、表またはスキーマ全体にポリシーが適用されます。表にポリシーが適用される際に、ラベル・セキュリティによってポリシー固有のNUMBER列が表に作成され、ポリシー用に以前定義されたデータ・ラベルと等しい数値が格納されます。列は、ユーザーに対して表示または非表示として作成できます。表にポリシーを適用する際に、様々な強制オプションを指定できます。たとえば、READ_CONTROL強制オプションは表を問合せから保護し、WRITE_CONTROLはDML操作から保護します。

Real Application SecurityセッションでOracle Label Securityコンテキストが確立すると、SELECTおよびDML操作によって、Real Application Securityユーザーに対して認可されている結果が返されます。

セッションを動的ロールと連結するために、PL/SQL ATTACH_SESSIONプロシージャで動的ロールのリストを渡すことができます。

注意:

アプリケーションを開発する場合、すべてのアプリケーション・エンド・ユーザー・アクションがATTACH_SESSION ... DETACH_SESSIONプログラミング・ブロック内で取得されていることを確認してください。(詳細は、「従来のデータベース・セッションからのアプリケーション・セッションの連結解除」を参照してください。)

例3-3 アプリケーション・セッションの連結

DECLARE
  sessionid raw(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
END;

関連項目:

3.2.4 アプリケーション・セッションのCookieの設定

アプリケーション・セッションに特定のCookieを関連付けるには、PL/SQLのDBMS_XS_SESSIONS.SET_SESSION_COOKIEプロシージャを使用するか、JavaのXSSessionManagerクラスのsetCookieメソッドを使用します。Cookieは、セッションの作成時にCREATE_SESSION PL/SQL APIを通じて関連付けることもできます。Cookieは、アプリケーション・セッションの間にWebサイトによってユーザーのセッションに埋め込まれるトークンです。次回同じユーザーがそのWebサイトから何かをリクエストすると、アプリケーション・セッションにCookieが送信され、サーバーがセッションとユーザーを関連付けられるようになります。

このプロシージャを実行するには、ユーザーにMODIFY_SESSIONアプリケーション権限を付与する必要があります。この権限は、XS_SESSION_ADMINデータベース・ロールを通じて取得するか、XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE APIコールによって取得できます。

例3-4に、アプリケーション・セッションのCookieを設定する方法を示します。

例3-4 アプリケーション・セッションのCookieの設定

DECLARE
  sessionid raw(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.SET_SESSION_COOKIE('Cookie1', sessionid);
END;

関連項目:

3.2.5 匿名アプリケーション・セッションへのアプリケーション・ユーザーの割当て

現在連結されている匿名アプリケーション・セッションに名前付きのアプリケーション・ユーザーを割り当てるには、PL/SQLのDBMS_XS_SESSIONS.ASSIGN_USERプロシージャを使用するか、JavaのXSSessionManagerクラスのassignUserメソッドを使用します。ユーザーを割り当てると、ユーザー・セッションが匿名から名前付きユーザーに変更されます。

このプロシージャを実行するには、ディスパッチャまたは接続ユーザーにASSIGN_USERアプリケーション権限が必要です。この権限は、XS_SESSION_ADMINデータベース・ロールを通じて取得するか、XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE APIコールによって取得できます。ネームスペースを指定する場合、ユーザーにはネームスペースに対するアプリケーション権限MODIFY_NAMESPACEまたはMODIFY_ATTRIBUTE、あるいはADMIN_NAMESPACEシステム権限が付与されている必要があります。動的ロールのリストも、DBMS_XS_SESSIONS.ASSIGN_USERプロシージャを使用して有効にできます。

Oracle Database 12cリリース2 (12.2)からは、Oracle Label SecurityでReal Application Securityユーザーがサポートされるようになりました。Real Application SecurityユーザーがいずれかのOracle Label Securityポリシーで認可されている場合は、assign_userコールの実行中に、名前付きReal Application Securityユーザー・セッションに対応するラベル・セキュリティ認可が確立されます。Real Application SecurityセッションでOracle Label Securityコンテキストが確立すると、SELECTおよびDML操作によって、Real Application Securityユーザーに対して認可されている結果が返されます。

例3-5に、アプリケーション・ユーザーlwuser1をアプリケーション・セッションに割り当てる方法を示します。

例3-5 アプリケーション・セッションへのアプリケーション・ユーザーの割当て

DECLARE
  sessionid raw(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('XSGUEST', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.ASSIGN_USER('lwuser1');
END;

関連項目:

3.2.6 現在のアプリケーション・セッションの別のアプリケーション・ユーザーへの現在のアプリケーション・ユーザーの切替え

PL/SQLでDBMS_XS_SESSIONS.SWITCH_USERプロシージャを使用するか、JavaでSessionインタフェースのswitchUserメソッドを使用して、現在のアプリケーション・セッションのセキュリティ・コンテキストを、指定したアプリケーション・ユーザーの新規に初期化したセキュリティ・コンテキストに切替えまたはプロキシ設定できます。別のアプリケーション・ユーザーを代理するには、切替え操作を実行する前に、現在のアプリケーション・セッション・ユーザーをターゲット・ユーザーのプロキシ・ユーザーとして設定する必要があります。これは、XS_PRINCIPAL.ADD_PROXY_USER PL/SQL APIを通じて実行します。

ユーザーを切り替えると、2つの名前付きユーザー間でユーザー・セッションが変更されます。

プロキシ操作のターゲット・アプリケーション・ユーザーが、プロキシ・ユーザー用に設定されたフィルタ・ロール(プロキシ・ロール)のリストを持っている場合、それらはセッションで有効化されます。

Oracle Database 12cリリース2 (12.2)からは、Oracle Label SecurityでReal Application Securityユーザーがサポートされるようになりました。これは、target_userのOracle Label Securityコンテキストが、proxy_userセッションからtarget_userセッションへの切替え時に確立されることを意味します。

切替え操作の後、アプリケーションのネームスペースおよび属性を保持または消去できます。keep_stateパラメータがTRUEに設定されている場合、アプリケーションのネームスペースおよび属性はすべて保持されますが、それ以外の場合、セッションの以前の状態はすべて消去されます。

ネームスペースを指定する場合、ユーザーにはネームスペースに対するアプリケーション権限MODIFY_NAMESPACEまたはMODIFY_ATTRIBUTE、あるいはADMIN_NAMESPACEシステム権限が付与されている必要があります。

例3-6に、アプリケーション・ユーザーlwuser1を現在のアプリケーション・セッションのアプリケーション・ユーザーlwuser2に切り替える方法を示します。ネームスペース・テンプレートのns1およびns2がSYSDBAによって作成されている必要があることに注意してください。

例3-6 現在のアプリケーション・セッションの別のアプリケーション・ユーザーへのアプリケーション・ユーザーの切替え

DECLARE
  sessionid RAW(16);
  nsList DBMS_XS_NSATTRLIST;
BEGIN 
  nsList := DBMS_XS_NSATTRLIST(DBMS_XS_NSATTR('ns1'),DBMS_XS_NSATTR('ns2'));
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.SWITCH_USER(username => 'lwuser2',
                               keep_state => TRUE,
                               namespaces => nsList);
END;

関連項目:

3.2.7 グローバル・コールバック・イベント・ハンドラ・プロシージャの作成について

コールバック・イベント・ハンドラ・プロシージャは、指定の引数セットが含まれたプロトタイプに従う必要があります。

たとえば、次のcallback_procedureでは既存のPL/SQLプロシージャを指定しますが、これはイベント・ハンドラであり、2つの形式が可能です。 

PROCEDURE callback_procedure (sessionid in raw, error out pls_integer)

最初の形式には、sessionid (RAW)、およびエラー設定の目的に使用するOUTパラメータerrorの2つのパラメータが含まれます。sessionidには、イベントがトリガーされたセッションのセッションIDが格納されます。OUTパラメータerrorを使用すると、イベント・ハンドラ・コードでエラーを表示できます。 

PROCEDURE callback_procedure (sessionid in raw, user in varchar2, error out pls_integer)

2番目の形式には、このイベントをトリガーしたユーザーを指定するための追加パラメータuser (VARCHAR2)が含まれます。

注意:

エラー値は、PL/SQL本体または例外ブロックで、error:= 0;のような値に明示的に設定する必要があります。

そうしないと、エラー「ORA-46071: イベント・ハンドラ<name-of-event-handler>でエラーが発生しました」に続いて、別のエラー「ORA-1405: フェッチした列の値がNULLです」が発生し、エラー値がNULLであることが示されます。

次の例は、2番目の形式のコールバック・プロシージャを使用したエラー値の明示的な設定を示しています。

CREATE OR REPLACE PACKAGE CALLBACK_PACKAGE AS
PROCEDURE CALLBACK_PROCEDURE (sessionid in RAW, user in VARCHAR2, error out PLS_INTEGER);
END CALLBACK_PACKAGE;
/

CREATE OR REPLACE PACKAGE BODY CALLBACK_PACKAGE AS
PROCEDURE CALLBACK_PROCEDURE (sessionid in RAW, user in VARCHAR2, error out PLS_INTEGER) IS
BEGIN
  error := 0;
  dbms_output.put_line('Inside callback procedure');
EXCEPTION
WHEN OTHERS THEN
        error:=0;
        dbms_output.put_line('Error');
END CALLBACK_PROCEDURE;
END CALLBACK_PACKAGE;

関連項目:

3.2.8 アプリケーション・セッションのグローバル・コールバック・イベント・ハンドラの構成

グローバル・コールバック・イベント・ハンドラは、目的とする特定のセッション・イベントが発生したときに起動してセッション状態を検査、記録および変更できる、事前定義されたPL/SQLプロシージャです。セッション・イベントには複数のグローバル・コールバック・イベント・ハンドラを追加できます。PL/SQLプロシージャを作成したら、それぞれ次のプロシージャを使用して、それを登録または登録解除するか、有効化または無効化することができます。

  • DBMS_XS_SESSIONS.ADD_GLOBAL_CALLBACK

    このプロシージャを使用して、コールバック・イベント・ハンドラを登録します。

  • DBMS_XS_SESSIONS.DELETE_GLOBAL_CALLBACK

    このプロシージャを使用して、グローバル・コールバックを登録解除します。

  • DBMS_XS_SESSIONS.ENABLE_GLOBAL_CALLBACK

    このプロシージャを使用して、有効にするにはTRUEを、無効にするにはFALSEの値を指定して、グローバル・コールバック・プロシージャを有効化または無効化します。

これらのAPIを実行するには、ユーザーは、CALLBACKアプリケーション権限を持っている必要があります。これは、XSPROVISIONERアプリケーション・ロールを通じて取得するか、XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE APIをコールすることで取得できます。アプリケーション・セッションで使用する1つ以上のグローバル・コールバック・イベント・ハンドラを構成できます。複数のコールバック・イベント・ハンドラを構成すると、Oracle Databaseでは、ハンドラが作成された順序で実行されます。

オプションで、次のステップに従って実行順序を変更できます。

  1. DBMS_XS_SESSIONS.DELETE_GLOBAL_CALLBACKプロシージャを実行して既存のコールバックをすべて登録解除します。
  2. DBMS_XS_SESSIONS.ADD_GLOBAL_CALLBACKプロシージャを実行してコールバックを登録します。

例3-7 アプリケーション・セッションでのグローバル・コールバックの登録

BEGIN
  SYS.DBMS_XS_SESSIONS.ADD_GLOBAL_CALLBACK 
   (DBMS_XS_SESSIONS.CREATE_SESSION_EVENT, 
   'CALLBACK_SCHM','CALLBACK_PKG','CALLBACK_PROC');
END;
/

表3-1に、コールバック・イベント・ハンドラを使用できるセッション・イベントを示します。

表3-1 コールバック・イベント・ハンドラを使用できるセッション・イベント

セッション・イベント コールバックが実行される時期

新規アプリケーション・セッションの作成

セッションが作成された後。

既存のアプリケーション・セッションへの連結

セッションが連結された後。

動的アプリケーション・ロールの有効化

動的アプリケーション・ロールが有効化された後。

動的アプリケーション・ロールの無効化

動的アプリケーション・ロールが無効化された後。

アプリケーション・セッションの直接ログイン

セッションが添付された後(セッション連結がアプリケーション・セッションの直接ログオンの一部としてコールされる場合)。

指定されたアプリケーション・ユーザーの匿名アプリケーション・セッションへの割当て

指定されたユーザーが匿名アプリケーション・セッションに割り当てられた後。

ある名前付きアプリケーション・ユーザーから別の名前付きアプリケーション・ユーザーへの切替え

アプリケーション・ユーザーが切り替えられた後(アプリケーション・ユーザーが元のアプリケーション・ユーザーに戻されない場合)。

名前付きアプリケーション・ユーザーから元のアプリケーション・ユーザーへの復帰

アプリケーション・ユーザーが切り替えられた後(アプリケーション・ユーザーが元のアプリケーション・ユーザーに戻される場合)。

標準アプリケーション・ロールの有効化

アプリケーション・ロールが有効化された後。

標準アプリケーション・ロールの無効化

アプリケーション・ロールが無効化された後。

既存のアプリケーション・セッションまたはデータベース・セッションからの連結解除

セッションが連結解除される前。

既存のアプリケーション・セッションまたはデータベース・セッションの終了

セッションが破棄される前。

アプリケーション・セッションまたはデータベース・セッションの直接ログオフ

セッションが連結解除される前(セッションの連結解除がアプリケーション・セッションの直接ログオフの一部としてコールされる場合)。

セッションの作成後にアプリケーション固有の特定の状態を初期化するとします。例3-7に、CALLBACK_PROCという状態を設定するグローバル・コールバックを登録する方法を示します(これは、パッケージCALLBACK_PKGで定義され、スキーマCALLBACK_SCHMによって所有されます)。

状態のCALLBACK_PROCは、イベントCREATE_SESSION_EVENTのグローバル・コールバックとして登録されます。

その他の例および各プロシージャの構文の詳細は、次の項を参照してください。

3.2.9 アプリケーション・セッションの保存

現在のユーザー・アプリケーション・セッションを保存するには、PL/SQLのDBMS_XS_SESSIONS.SAVE_SESSIONプロシージャを使用するか、JavaのXSSessionManagerクラスのsaveSessionメソッドを使用します。保存操作を使用するのは、現在のセッションと同じセッションを使用して、セッションの変更を他のセッションに即座に伝播する必要がある場合です。保存操作を使用しない場合、セッションの変更は、現在のセッションが連結解除された後にのみ他のセッションに反映されます。

コール元ユーザーがこの操作を実行するために権限は必要ありません。

例3-8に、現在のユーザー・アプリケーション・セッションを保存する方法を示します。

例3-8 現在のユーザー・アプリケーション・セッションの保存

BEGIN
 SYS.DBMS_XS_SESSIONS.SAVE_SESSION;
END;

関連項目:

3.2.10 従来のデータベース・セッションからのアプリケーション・セッションの連結解除

次のいずれかのプロシージャを使用して、従来のデータベース・セッションからアプリケーション・セッションを連結解除できます。

  • DBMS_XS_SESSIONS.DETACH_SESSION(abort => FALSE)

    このプロシージャを使用すると、セッションを連結解除して、最後にセッションの変更が保存されてから発生したすべての変更をコミットできます。abortパラメータをFALSE (デフォルト値)に指定すると、現在のセッションで実行されたすべての変更が保持されます。現在連結されているユーザーは、追加の権限なしでこの操作を実行できます。

    DETACH_SESSIONは、常に現在連結されているセッションに対して実行されます。

  • DBMS_XS_SESSIONS.DETACH_SESSION(abort => TRUE)

    このプロシージャを使用すると、変更を保存せずにセッションを連結解除できます。abortパラメータをTRUEに指定すると、現在のセッションで実行された変更がロールバックされます。連結以降にセッションに対して行われたロールとネームスペースの変更は破棄されます。

例3-9に、データベース・セッションからアプリケーション・セッションを連結解除して変更をコミットする方法を示します。DETACH_SESSIONを任意の場所でコールして、現在連結されているセッションを連結解除できます。

JavaのXSSessionManagerクラスのdetachSessionメソッドを使用できます。

例3-10に、変更を保存せずにアプリケーション・セッションからデータベース・セッションを連結解除する方法を示します。

注意:

アプリケーションを開発する場合、すべてのアプリケーション・エンド・ユーザー・アクションがATTACH_SESSION ... DETACH_SESSIONプログラミング・ブロック内で取得されていることを確認してください。(詳細は、「従来のデータベース・セッションへのアプリケーション・セッションの連結」を参照してください。)

例3-9 アプリケーション・セッションの連結解除とコミット

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
...
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
...
END;

例3-10 アプリケーション・セッションの連結解除と非コミット

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
...
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION(TRUE);
END;

関連項目:

3.2.11 アプリケーション・セッションの破棄

PL/SQLでDBMS_XS_SESSIONS.DESTROY_SESSIONプロシージャを使用するか、JavaでXSSessionManagerクラスのdestroySessionメソッドを使用して、アプリケーション・セッションを終了できます。このプロシージャは、アプリケーション・セッションから従来のセッションをすべて連結解除します。

このプロシージャを実行する場合、実行するユーザーには、TERMINATE_SESSIONアプリケーション権限が必要です。この権限は、XS_SESSION_ADMINデータベース・ロールを通じて取得するか、XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE APIコールによって取得できます。

例3-11に、アプリケーション・セッションを破棄する方法を示します。

例3-11 アプリケーション・セッションの破棄

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;

関連項目:

3.3 アプリケーション・セッションの状態の操作について

この項の内容は次のとおりです。

3.3.1 ネームスペース・テンプレートを使用したネームスペースの作成について

アプリケーションは、ネームスペースを使用して、アプリケーションで定義された属性と値のペアを格納します。アプリケーションは、通常、異なるアプリケーション・セッション全体で同じネームスペースを使用する必要があります。ネームスペース・テンプレートは、ネームスペースを定義および初期化するための方法です。

ネームスペース・テンプレートは、ネームスペースとそのプロパティを定義します。これを使用して、アプリケーション・セッションでネームスペースを初期化します。ネームスペースの名前は、それを定義するテンプレートと同じである必要があります。

この項の内容は次のとおりです。
3.3.1.1 ネームスペース・テンプレートの構成要素

ネームスペース・テンプレートには、次のものが含まれます。

  • ネームスペースの名前

    アプリケーション・ネームスペースの名前によって、ネームスペースが一意に識別されます。この名前は、アプリケーション・セッションでのネームスペースの作成時に使用されます。

  • ネームスペース・ハンドラ

    ネームスペース・ハンドラは、属性値が設定または取得されたときにコールされます。ハンドラの指定はオプションです。

    ネームスペースは、イベント処理ファンクションに関連付けることができます。イベント処理用に登録されている属性に対する操作が実行されるたびに、サーバーによってこのファンクションが起動されます。イベント処理ファンクションには、引数として属性名、属性値およびイベント・コードを指定します。たとえば、次のようになります。

    FUNCTION event_handling_function_name(
         session_id IN RAW,
         namespace  IN VARCHAR2,
         attribute  IN VARCHAR2,
         old_value  IN VARCHAR2,
         new_value  IN VARCHAR2,
         event_code IN PLS_INTEGER)
RETURNS PLS_INTEGER;

  • 属性リスト

    属性リストには、ネームスペースに対して定義された属性が含まれます。これらの属性は、ネームスペースの作成時にセッションで作成されます。

    属性には、次のオプション・データを指定できます。

    • デフォルト値

      属性は、アプリケーション・セッションでのネームスペースの作成時にデフォルト値で初期化されます。デフォルト値と、イベント・タイプFIRSTREAD_EVENTおよびFIRSTREAD_PLUS_UPDATE_EVENTは、同時に存在できません。

    • イベント・タイプ

      属性には、次のイベント・タイプを指定できます。

      • FIRSTREAD_EVENT

        値の設定されていない属性が最初に読み取られたときにネームスペース・ハンドラをコールするには、このイベント・タイプを指定します。このイベント・タイプを指定できるのは、属性にデフォルト値が設定されていない場合のみです。

      • UPDATE_EVENT

        属性値が更新されたときにネームスペース・ハンドラをコールするには、このイベント・タイプを指定します。

      • FIRSTREAD_PLUS_UPDATE_EVENT

        値の設定されていない属性が最初に読み取られたとき、またはその値が更新されたときにネームスペース・ハンドラをコールするには、このイベント・タイプを指定します。このイベント・タイプを指定できるのは、属性にデフォルト値が設定されていない場合のみです。

  • ネームスペースACL

    ネームスペース操作のための権限モデル。ネームスペース操作は、テンプレートに設定されたACLによって保護されます。デフォルトでは、NS_UNRESTRICTED_ACLがテンプレートに設定されており、テンプレートから作成されたネームスペースに対する無制限の操作が許可されます。

3.3.1.2 ネームスペース・ビューについて

次のデータ・ディクショナリ・ビューを問い合せることで、現在およびすべてのアプリケーション・セッションのネームスペース・テンプレート、ネームスペース・テンプレート属性およびネームスペース属性に関する情報を検索できます。

3.3.1.3 アプリケーション・セッションのネームスペース・テンプレートの作成

ネームスペース・テンプレートを作成するには、PL/SQLのXS_NAMESPACE.CREATE_TEMPLATEプロシージャを使用するか、JavaのSessionインタフェースのcreateNamespaceメソッドを使用します。

例3-12に、アプリケーション・セッションのネームスペース・テンプレートns1を作成する方法を示します。このネームスペースの属性は、属性リストattrsを使用して定義されます。このネームスペース・テンプレートでは、NS_UNRESTRICTED_ACLがテンプレートに設定されているため、テンプレートから作成されたネームスペースに対する無制限の操作が許可されます。

コール側ユーザーは、ネームスペース・テンプレートおよび属性を管理できるADMIN_ANY_SEC_POLICYアプリケーション権限を持っている必要があります。

例3-12 ネームスペース・テンプレートの作成

DECLARE
  attrs XS$NS_ATTRIBUTE_LIST;
BEGIN
  attrs := XS$NS_ATTRIBUTE_LIST();
  attrs.extend(3);
 
  attrs(1) := XS$NS_ATTRIBUTE('attr1','value1',
    XS_NAMESPACE.UPDATE_EVENT);
  attrs(2) := XS$NS_ATTRIBUTE('attr2',null,
    XS_NAMESPACE.FIRSTREAD_PLUS_UPDATE_EVENT);
  attrs(3) := XS$NS_ATTRIBUTE('attr3','value3');
 
  SYS.XS_NAMESPACE.CREATE_TEMPLATE(name=>'ns1',
                               description=>'namespace template 1',
                               attr_list=>attrs,
                               schema=>'SCOTT',
                               package=>'PKG1',
                               function=>'FN1',
                               acl=>'SYS.NS_UNRESTRICTED_ACL');
END;
/

関連項目:

3.3.2 アプリケーション・セッションでのネームスペースの初期化

次の各イベントの発生時に、この項の説明に従ってネームスペース・テンプレートを使用することで、ネームスペースを初期化できます。

この項の内容は次のとおりです。
3.3.2.1 セッションが作成されたときにネームスペースを初期化する方法

PL/SQLのDBMS_XS_SESSIONS.CREATE_SESSIONプロシージャを使用するか、JavaのXSSessionManagerクラスのcreateSessionメソッドを使用してアプリケーション・セッションを作成する場合、初期化するネームスペースのリストを指定できます。

例3-13に、アプリケーション・セッションを作成するときに、2つのネームスペースns1およびns2を初期化する方法を示します。

セッションの作成時にネームスペースを指定した場合、コール元にはネームスペースに対するアプリケーション権限MODIFY_NAMESPACEまたはMODIFY_ATTRIBUTEが付与されているか、ADMIN_NAMESPACEシステム権限が付与されている必要があります。

注意:

例3-13で使用されるネームスペースは、対応するネームスペース・テンプレートが定義されている必要があります。

例3-13 アプリケーション・セッションを作成するときにネームスペースを初期化する方法

DECLARE
  nsList DBMS_XS_NSATTRLIST;
  sessionid RAW(16);
BEGIN
    nsList := DBMS_XS_NSATTRLIST(DBMS_XS_NSATTR('ns1'),DBMS_XS_NSATTR('ns2'));
    SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid, FALSE, FALSE, nsList);
END;
/

関連項目:

3.3.2.2 セッションが連結されたときにネームスペースを初期化する方法

PL/SQLのDBMS_XS_SESSIONS.ATTACH_SESSIONプロシージャを使用するか、JavaのXSSessionManagerクラスのattachSessionメソッドを使用してセッションを連結する場合、初期化するネームスペースのリストを指定できます。

例3-14に、アプリケーション・セッションを連結するときに、2つのネームスペースns1およびns2を初期化する方法を示します。

ネームスペースを指定する場合、ユーザーにはネームスペースに対するアプリケーション権限MODIFY_NAMESPACEまたはMODIFY_ATTRIBUTE、あるいはADMIN_NAMESPACEシステム権限が付与されている必要があります。

注意:

例3-14で使用されるネームスペースは、対応するネームスペース・テンプレートが定義されている必要があります。

例3-14 アプリケーション・セッションを連結するときにネームスペースを初期化する方法

DECLARE
  nsList DBMS_XS_NSATTRLIST;
  sessionid RAW(16);
BEGIN
    nsList := DBMS_XS_NSATTRLIST(DBMS_XS_NSATTR('ns1'),DBMS_XS_NSATTR('ns2'));
    SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
    SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid, NULL, NULL, NULL, NULL, nsList);
END;
/

関連項目:

3.3.2.3 名前付きアプリケーション・ユーザーが匿名アプリケーション・セッションに割り当てられたときにネームスペースを初期化する方法

PL/SQLのDBMS_XS_SESSIONS.ASSIGN_USERプロシージャを使用するか、JavaのXSSessionManagerクラスのassignUserメソッドを使用してアプリケーション・セッションにアプリケーション・ユーザーを割り当てる場合、初期化するネームスペースのリストを指定できます。

ネームスペースを指定する場合、ユーザーにはネームスペースに対するアプリケーション権限MODIFY_NAMESPACEまたはMODIFY_ATTRIBUTE、あるいはADMIN_NAMESPACEシステム権限が付与されている必要があります。

例3-15に、アプリケーション・セッションにアプリケーション・ユーザーを割り当てるときに、2つのネームスペースns1およびns2を初期化する方法を示します。

注意:

例3-15で使用されるネームスペースは、対応するネームスペース・テンプレートが定義されている必要があります。

例3-15 アプリケーション・セッションにアプリケーション・ユーザーを割り当てるときにネームスペースを初期化する方法

DECLARE
  sessionid RAW(30);
  nsList DBMS_XS_NSATTRLIST;
BEGIN 
  nsList := DBMS_XS_NSATTRLIST(DBMS_XS_NSATTR('ns1'),DBMS_XS_NSATTR('ns2'));
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('XSGUEST', sessionid);
  SYS.DBMS_XS_SESSIONS.ASSIGN_USER(username => 'lwuser2',
                               sessionid => sessionid,
                               namespaces => nsList);
END;
/

関連項目:

3.3.2.4 アプリケーション・セッションでアプリケーション・ユーザーが切り替えられたときにネームスペースを初期化する方法

PL/SQLのDBMS_XS_SESSIONS.SWITCH_USERプロシージャを使用するか、JavaのSessionインタフェースのswitchUserメソッドを使用してアプリケーション・セッションでアプリケーション・ユーザーを切り替える場合、初期化するネームスペースのリストを指定できます。

ネームスペースを指定する場合、ユーザーにはネームスペースに対するアプリケーション権限MODIFY_NAMESPACEまたはMODIFY_ATTRIBUTE、あるいはADMIN_NAMESPACEシステム権限が付与されている必要があります。

注意:

セッションの連結後にlwuser1からlwuser2への切替えを有効にするには、次のように最初にlwuser1のターゲット・ユーザーとしてlwuser2を定義する必要があります。 

exec XS_PRINCIPAL.ADD_PROXY_USER('lwuser2', 'lwuser1');

例3-16に、アプリケーション・セッションでアプリケーション・ユーザーを切り替えるときに、2つのネームスペースns1およびns2を初期化する方法を示します。

注意:

例3-16で使用されるネームスペースは、対応するネームスペース・テンプレートが定義されている必要があります。

例3-16 アプリケーション・セッションでアプリケーション・ユーザーを切り替えるときにネームスペースを初期化する方法

DECLARE
  sessionid RAW(30);
  nsList DBMS_XS_NSATTRLIST;
BEGIN 
  nsList := DBMS_XS_NSATTRLIST(DBMS_XS_NSATTR('ns1'),DBMS_XS_NSATTR('ns2'));
 SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
 SYS. DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.SWITCH_USER(username => 'lwuser2',
                               namespaces => nsList);
END;
/

関連項目:

3.3.2.5 明示的にネームスペースを初期化する方法

アプリケーション・セッションで明示的にネームスペースを初期化するには、PL/SQLのDBMS_XS_SESSIONS.CREATE_NAMESPACEプロシージャを使用するか、JavaのSessionインタフェースのcreateNamespaceメソッドを使用します。

DBMS_XS_SESSIONS.CREATE_NAMESPACEプロシージャを実行する場合、コール側ユーザーは、ネームスペースに対するMODIFY_NAMESPACEアプリケーション権限を持っているか、ADMIN_NAMESPACEシステム権限を持っている必要があります。

例3-17に、アプリケーション・セッションで明示的にネームスペースns1を初期化する方法を示します。

注意:

例3-17で使用されるネームスペースは、対応するネームスペース・テンプレートが定義されている必要があります。

例3-17 アプリケーション・セッションで明示的にネームスペースを初期化する方法

DECLARE
  sessionid RAW(30);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.CREATE_NAMESPACE('ns1');
END;
/

関連項目:

3.3.3 アプリケーション・セッションでのセッション属性の設定

特定のセッション属性の値を設定するには、PL/SQLのDBMS_XS_SESSIONS.SET_ATTRIBUTEプロシージャを使用するか、JavaのSessionNamespaceインタフェース・メソッドのsetAttributeメソッドを使用します。

コール側ユーザーに、ネームスペースに対するMODIFY_ATTRIBUTEアプリケーション権限を付与するか、ADMIN_NAMESPACEシステム権限を付与する必要があります。

注意:

属性には、最大4000文字の長さの文字列値を格納できます。

例3-18に、アプリケーション・セッションの属性attr1に値val1を設定する方法を示します。

例3-18 アプリケーション・セッションのネームスペース属性の設定

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBS_XS_SESSIONS.CREATE_NAMESPACE('ns1');
  SYS.DBMS_XS_SESSIONS.SET_ATTRIBUTE('ns1', 'attr1', 'val1');
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/

関連項目:

3.3.4 アプリケーション・セッションでのセッション属性の取得

特定のセッション属性の値を取得するには、PL/SQLのDBMS_XS_SESSIONS.GET_ATTRIBUTEプロシージャを使用するか、JavaのSessionNamespaceインタフェース・メソッドのgetAttributeメソッドを使用します。

コール側ユーザーに、DBMS_XS_SESSIONS.GET_ATTRIBUTEプロシージャを使用して属性を取得するための権限を付与する必要はありません。

注意:

属性値が設定されておらず、属性にFIRSTREAD_EVENTが指定されている場合、属性値を読み取ろうとすると、ネームスペース・イベント・ハンドラがコールされます。通常、ネームスペース・イベント・ハンドラ・プロシージャによって、属性の値が設定され、他のアプリケーション固有の処理タスクが実行されます。

例3-19に、アプリケーション・セッションの属性attr1を取得する方法を示します。

例3-19 アプリケーション・セッションのネームスペース属性の取得

DECLARE
  sessionid RAW(16);
  attrib_out_val VARCHAR2(4000);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.CREATE_NAMESPACE('ns1');
  SYS.DBMS_XS_SESSIONS.SET_ATTRIBUTE('ns1', 'attr1', 'val1');
  SYS.DBMS_XS_SESSIONS.GET_ATTRIBUTE('ns1', 'attr1', attrib_out_val);
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/

関連項目:

3.3.5 アプリケーション・セッションでのカスタム属性の作成

ネームスペースでカスタム属性を作成するには、PL/SQLのDBMS_XS_SESSIONS.CREATE_ATTRIBUTEプロシージャを使用するか、JavaのSessionNamespaceインタフェース・メソッドのcreateAttributeメソッドを使用します。

カスタム属性は、テンプレート属性とは異なります。テンプレート属性は、ネームスペース・テンプレートの一部であり、ネームスペースの作成時にセッションで自動的に作成されます。カスタム属性は、CREATE_ATTRIBUTEプロシージャを使用してネームスペースでプログラム的に作成します。

コール側アプリケーションに、ネームスペースに対するMODIFY_ATTRIBUTEアプリケーション権限を付与するか、ADMIN_NAMESPACEシステム権限を付与する必要があります。

例3-20に、アプリケーション・セッションのネームスペースでカスタム属性customattrを作成する方法を示します。

例3-20 アプリケーション・セッションのカスタム・ネームスペース属性の作成

DECLARE
  sessionid RAW(16);
  attrib_out_val VARCHAR2(4000);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.CREATE_NAMESPACE('ns1');
  SYS.DBMS_XS_SESSIONS.CREATE_ATTRIBUTE('ns1','customattr','default_value_custom',NULL);
  SYS.DBMS_XS_SESSIONS.SET_ATTRIBUTE('ns1','customattr','newvalue');
  SYS.DBMS_XS_SESSIONS.GET_ATTRIBUTE('ns1', 'customattr', attrib_out_val);
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/

関連項目:

3.3.6 アプリケーション・セッションでのネームスペースの削除

PL/SQLでDBMS_XS_SESSIONS.DELETE_NAMESPACEプロシージャを使用するか、JavaでSessionNamespaceインタフェースのdeleteAttributeメソッドを使用して、ネームスペースおよびそれによって識別されるすべての属性をアプリケーション・セッションから削除できます。

コール側ユーザーは、ネームスペースに対するMODIFY_NAMESPACEアプリケーション権限を持っているか、ADMIN_NAMESPACEシステム権限を持っている必要があります。

例3-21に、アプリケーション・セッションからネームスペースns1を削除する方法を示します。

例3-21 アプリケーション・セッションのネームスペースの削除

DECLARE
  sessionid RAW(16);
  out_value VARCHAR2(4000);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.CREATE_NAMESPACE('ns1');
  SYS.DBMS_XS_SESSIONS.SET_ATTRIBUTE('ns1', 'attr1', 'val1');
  SYS.DBMS_XS_SESSIONS.GET_ATTRIBUTE('ns1', 'attr1', out_value);
  SYS.DBMS_XS_SESSIONS.DELETE_NAMESPACE('ns1');
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/

関連項目:

3.3.7 セッションでのアプリケーション・ロールの有効化

アプリケーション・セッション・ユーザーの直接付与された標準アプリケーション・ロールのみを有効化するには、PL/SQLのDBMS_XS_SESSIONS.ENABLE_ROLEプロシージャを使用するか、JavaのSessionインタフェースのenableRoleメソッドを使用します。

DBA_XS_SESSION_ROLES動的データ・ディクショナリ・ビューには、すべてのアプリケーション・セッションで有効化されているアプリケーション・ロールがリストされます。V$XS_SESSION_ROLES動的データ・ディクショナリ・ビューには、現在連結されているアプリケーション・セッションで有効になっているアプリケーション・ロールがリストされます。

例3-22に、アプリケーション・セッションでロールを有効にする方法を示します。

例3-22 アプリケーション・セッションでのロールの有効化

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.ENABLE_ROLE('auth1_role');
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/

関連項目:

3.3.8 セッションでのアプリケーション・ロールの無効化

特定のセッションでアプリケーション・ロールを無効化するには、PL/SQLのDBMS_XS_SESSIONS.DISABLE_ROLEプロシージャを使用するか、JavaのSessionインタフェースのdisableRoleメソッドを使用します。

例3-23に、アプリケーション・セッションでロールを無効にする方法を示します。

例3-23 アプリケーション・セッションでのロールの無効化

DECLARE
  sessionid RAW(16);
BEGIN
  SYS.DBMS_XS_SESSIONS.CREATE_SESSION('lwuser1', sessionid);
  SYS.DBMS_XS_SESSIONS.ATTACH_SESSION(sessionid);
  SYS.DBMS_XS_SESSIONS.ENABLE_ROLE('auth1_role');
  SYS.DBMS_XS_SESSIONS.DISABLE_ROLE('auth1_role');
  SYS.DBMS_XS_SESSIONS.DETACH_SESSION;
  SYS.DBMS_XS_SESSIONS.DESTROY_SESSION(sessionid);
END;
/

関連項目:

3.4 外部ユーザーおよびロール用の管理APIについて

この項では、外部ユーザーおよびロールのために必要な次の管理APIについて説明します。

3.5 ACLによって有効範囲が指定されたReal Application Securityセッション権限について

ACLによって有効範囲が指定されるセッション権限について説明します。プリンシパルに設定されているACLを使用して、プリンシパル・セッションごとに権限を付与できます。この場合のプリンシパルは、アプリケーション・ユーザーまたは動的ロールのいずれかです。

Oracle Database 12cリリース1 (12.1)では、Real Application Securityセッション権限はGRANT_SYSTEM_PRIVILEGEプロシージャを使用して付与されるか、XS_ADMIN_UTILパッケージのREVOKE_SYSTEM_PRIVILEGEプロシージャを使用して取り消されます。これらの権限付与はシステム全体に適用され、権限受領者はどのReal Application Securityプリンシパルのセッション操作に対しても権限を行使できるようになります。これは、シードされたシステムACL – SESSIONACLを使用して実装されます。すべてのセッション権限チェックはこのACLで実行されます。複数のアプリケーションを複数のユーザー・コミュニティで実行しているデータベースの場合、この方法ではReal Application Securityセッションを適切に管理することが難しくなります。

セッション管理の有効範囲指定には、2つの問題があります。1つ目の問題は、ユーザーのセッションを作成、連結、連結解除または破棄できるのは誰かということです。2つ目の問題は、ユーザー・セッションの動的ロールを有効化できるのは誰かということです。動的ロールは付与するものではなく、動的に有効化されるものであるため、ACLを使用したセッション権限の有効範囲指定が必要になります。標準ロールはアプリケーション・ユーザーに付与されるため、これにACLは必要ありません。

Oracle Database 12cリリース2 (12.2)からは、Real Application SecurityでACLを使用したセッション権限の有効範囲指定がサポートされます。この機能により、プリンシパルに設定されたACLを使用した、プリンシパルごとのセッション権限付与が可能になります。セッション権限付与を含むACLは、標準Real Application Securityアプリケーション・ユーザーまたは動的ロールに設定することはできますが、標準Real Application Securityロールまたは外部プリンシパルに設定することはできません。Real Application Securityのセッションの有効範囲指定は、セッション操作に関与するアプリケーション・ユーザーまたは動的ロールに設定されたACLごとに強制できるため、セッション操作を特定のユーザー・コミュニティ向けに、より厳密に制限することができます。たとえば、別々のセッション・マネージャ(ディスパッチャ)が管理する、別個のユーザー・コミュニティ用のセッション操作を設定できます。その場合、同じユーザー・コミュニティに属するユーザーには同じACLが設定されます。また、動的ロールの有効化および無効化を制限するための、新たに追加された権限ENABLE_DYNAMIC_ROLEを使用して、動的ロールの有効化および無効化を該当するディスパッチャに限定できます。この権限は、前の連結からの既存のセッション範囲の動的ロールの有効化にも強制されます。これらの機能を使用して、Real Application Securityセッション管理者は、権限を付与したReal Application Securityユーザー・コミュニティまたはReal Application Securityユーザー・コミュニティのグループのセッションをユーザーが作成、連結または変更できるような、セッション権限の有効範囲を指定できます。

ACLは、プリンシパルの作成時にReal Application Securityの最小システム権限であるPROVISIONを使用して設定できます。この権限では、アプリケーション・ユーザーとアプリケーション・ロールを作成、変更、または削除できます。また、CREATE_USERプロシージャおよびCREATE_DYNAMIC_ROLEプロシージャを使用することもできます。これには、作成するプリンシパルに応じて、コール元がALTER USERまたはALTER ROLE権限を持っていることが必要になります。または、SET_ACLプロシージャを使用して、プリンシパルの作成後にACLを作成することもできます。これには、プリンシパルがアプリケーション・ユーザーであるか動的ロールであるかに応じて、コール元が前述した権限と同じ権限を持っていることが必要になります。SET_ACLプロシージャを使用してACLを設定する前に、アプリケーション・ユーザーまたは動的ロールとACLの両方が存在している必要があります。また、ACLはSYSスキーマに作成されている必要があります。

セッション操作には特定のセッション権限が必要であり、システム全体のACLまたは対象となるユーザーまたはロールに連結されたACLによって、セッション・マネージャにセッション操作に応じたセッション権限が付与されている必要があります。ADMINISTER_SESSION権限には、特定のすべてのセッション権限が集約されています。この権限は、すべてのセッション権限と同じように、システム全体のACLまたはプリンシパル固有のACLを使用して、セッション・マネージャに付与することができます。新しい権限を使用する際には、他のシステム権限と同じように監査が実施されます。ユーザーまたは動的ロールに設定されたACLは、システム全体のACLをオーバーライドします。

DBA_XS_USERSビューとDBA_XS_DYNAMIC_ROLESビューが機能拡張され、Real Application Securityアプリケーション・ユーザーまたは動的ロールに設定されるACL用の追加の列が表示されるようになりました。

システム・レベルのセッション権限付与は、プリンシパル固有のACLと共存できますが、プリンシパル固有のACLが優先されます。Real Application Securityのプリンシパル固有のACLでは付与が拒否される場合があるので、これが優先されることが重要です。付与の拒否はプリンシパル固有のACLでのみ発生し、システムACLでは発生しないことに注意してください。

次の表では、プリンシパル固有ACL(列1)とシステムACL (列2)のセッション権限チェックの動作を比較して説明し、セッション権限チェックの結果をTrueまたはFalseで示します(列3)。たとえば、チェックされた権限がプリンシパル固有ACLで付与も拒否もされなかった場合、次にシステムACLが権限に対してチェックされます。

表3-2 セッション権限チェック

プリンシパル固有ACL システムACL セッション権限チェック結果
付与 拒否、付与、または未指定 True
拒否 拒否、付与、または未指定 False
未指定またはACL不存在 付与 True
未指定またはACL不存在 未指定 False

プリンシパルに設定されているACLに基づくセッション権限の強制

セッション権限は、セッション操作内のReal Application Securityアプリケーション・ユーザーに設定されているACLに従って強制されます。動的ロールを有効化するための権限は、動的ロールに設定されているACLに従って強制されます。たとえば、セッションの作成操作の場合、コール元でReal Application Securityアプリケーション・ユーザーに設定されているACLにCREATE_SESSION権限が指定されている必要があります。同様に、動的ロールでの連結操作の場合、動的ロールに設定されるACLにENABLE_DYNAMIC_ROLES権限が必要です。前述のように、既存のシステム・レベル・セッション権限付与は引き続き共存できますが、プリンシパル固有のACL権限付与が優先されます。

権限チェックは、最初にプリンシパルに関連するACLで実行されます(そのような設定である場合)。ACLチェックが成功した場合は操作が続行します。チェックで拒否された場合、操作は権限不足エラーで失敗します。付与にも拒否にもならなかった場合、SESSION_SCセキュリティ・クラスに関連付けられたシステムACLでのチェックが実行され、この権限チェックの結果に基づいて操作が失敗または成功します。

次の表に、Real Application Securityのセッション操作と、その操作を実行するために必要なセッション権限をリストします。この情報は、プリンシパルに特定のセッション操作用のACLを作成するために役立ちます。ADMINISTER_SESSION権限には、この表にリストされているすべてのセッション権限が集約されています。

表3-3 セッション権限操作とその実行に必要な権限

セッション操作 必要なセッション権限
セッションの作成 Real Application Securityアプリケーション・ユーザー(セッションの作成に使用した)に設定されたACLまたはシステムACLのCREATE_SESSION権限。プリンシパル固有ACLで付与が拒否された場合、操作は失敗します。
セッションの連結 Real Application Securityアプリケーション・ユーザー(セッションの作成に使用した)に設定されたACLまたはシステムACLのATTACH_SESSION権限。動的ロール(セッションの作成に使用した)に設定されたACLまたはシステムACLのENABLE_DYNAMIC_ROLE権限。プリンシパル固有ACLで付与が拒否された場合、操作は失敗します。
ユーザーの割当て 割り当てられる名前付きReal Application Securityアプリケーション・ユーザーに設定されたACLまたはシステムACLのASSIGN_SESSION権限。動的ロール(セッションの作成に使用した)に設定されたACLまたはシステムACLのENABLE_DYNAMIC_ROLE権限。そのため、動的ロールが有効化されている場合は、これらの権限がチェックされます。プリンシパル固有ACLで付与が拒否された場合、操作は失敗します。
ユーザーの切替え プロキシ構成のため、セッション権限はチェックされません。
ロールの有効化 セッション権限はチェックされません。
ロールの無効化 セッション権限はチェックされません。
ネームスペース操作(ネームスペースの作成、ネームスペースの削除、属性の作成、属性の設定、属性のリセット、属性の削除) セッション権限はチェックされません。ネームスペース権限のみがチェックされます。
セッションの保存、セッションの連結解除 セッション権限はチェックされません。
セッションの破棄 Real Application Securityアプリケーション・ユーザー(セッションの作成に使用した)に設定されたACLまたはシステムACLのTERMINATE_SESSION権限。
セッションCookieの設定 Real Application Securityアプリケーション・ユーザー(セッションの作成に使用した)に設定されたACLまたはシステムACLのMODIFY_SESSION権限。
非アクティブのタイムアウトの設定 Real Application Securityアプリケーション・ユーザー(セッションの作成に使用した)に設定されたACLまたはシステムACLのMODIFY_SESSION権限。
セッションの再認可 Real Application Securityアプリケーション・ユーザー(セッションの作成に使用した)に設定されたACLまたはシステムACLのMODIFY_SESSION権限。
CookieからのSIDの取得 セッション権限はチェックされません。
グローバル・コールバック構成(グローバル・コールバックの追加、グローバル・コールバックの削除、グローバル・コールバックの有効化) セッション権限はチェックされません。コールバック権限のみがチェックされます。

関連項目:

3.5.1 ACLを使用したプリンシパルへのセッション権限の付与

ユーザーの作成時またはユーザーの作成後に、ACLを使用してプリンシパルにセッション権限を付与する方法について説明します。

次の例では、ユーザーの作成時およびユーザーの作成後に、USER_ACLというACLを使用してプリンシパルにセッション権限を付与する方法を示します。
最初に、USER_ACLというACLを作成し、権限ADMINISTER_SESSIONをユーザーlwuser3に付与し、権限CREATE_SESSION、MODIFY_SESSIONおよびATTACH_SESSIONをユーザーlwuser4に付与し、権限CREATE_SESSIONおよびMODIFY_SESSIONをユーザーlwuser5に付与します。
sqlplus /nolog
SQL> CONNECT SYS/password as SYSDBA
SQL> GRANT CREATE SESSION, XS_SESSION_ADMIN TO SEC_MGR IDENTIFIED BY password;
SQL> EXEC SYS.XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE('PROVISION', 'sec_mgr', SYS.XS_ADMIN_UTIL.PTYPE_DB);

CONNECT SEC_MGR
Enter password: password
Connected. 
DECLARE
ace_list  XS$ACE_LIST;

BEGIN

ace_list := XS$ACE_LIST(
    XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"ADMINISTER_SESSION"'),
                granted=>true,
                principal_name=>'lwuser3'),
    XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"CREATE_SESSION"','"MODIFY_SESSION"','"ATTACH_SESSION"'),       
                granted=>true,
                principal_name=>'lwuser4'),
    XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"CREATE_SESSION"','"MODIFY_SESSION"'),       
                granted=>true,
                principal_name=>'lwuser5'));

sys.xs_acl.create_acl(name=>'USER_ACL',
                    ace_list=>ace_list,
                    sec_class=>'SESSIONPRIVS',
                    description=>'Session management');
END;
/
次に、ユーザーlwuser3およびlwuser4を作成し、これらのユーザーにUSER_ACLというACLを付与します。
BEGIN
 SYS.XS_PRINCIPAL.CREATE_USER(name=>'lwuser3',
                              schema=>'HR',
                              acl=>'USER_ACL';
END;
/
EXEC  SYS.XS_PRINCIPAL.SET_PASSWORD('lwuser3', 'password');

BEGIN
 SYS.XS_PRINCIPAL.CREATE_USER(name=>'lwuser4',
                              schema=>'HR',
                              acl=>'USER_ACL';
END;
/
EXEC  SYS.XS_PRINCIPAL.SET_PASSWORD('lwuser4', 'password');
次に、ユーザーlwuser5を作成し、SET_ACLプロシージャを使用してUSER_ACLというACLをこのユーザーに設定します。
sqlplus SEC_MGR
Enter password: password
Connected. 
BEGIN
 SYS.XS_PRINCIPAL.CREATE_USER(name=>'lwuser5',
                              schema=>'HR');
END;
/
EXEC SYS.XS_PRINCIPAL.SET_ACL('lwuser5','USER_ACL');

関連項目: