| Oracle® Fusion Middleware Oracle WebLogic Serverリソース・アダプタの開発 12c (12.2.1.1.0) E77376-01 |
|
 前 |
 次 |
この章の内容は以下のとおりです。
WebLogicセキュリティの詳細は、『Oracle WebLogic Serverセキュリティの理解』および『Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』を参照してください。
リソース・アダプタはエンタープライズ情報システム(EIS)への発信接続を行うときに、有効なセキュリティ資格証明を使用してサインオンする必要があります。『JSR 322: Java EE Connector Architecture 1.6』に従って、WebLogic Serverでは、アウトバウンド接続に関するコンテナ管理およびアプリケーション管理によるサインオンをサポートしています。実行時にWebLogic Serverは、呼出し側クライアント・コンポーネントのデプロイメント記述子、またはリソース・アダプタ・デプロイメント記述子のres-auth要素で指定された情報に基づいて、選択されたサインオン・メカニズムを判断します。リソース・アダプタのデプロイメント記述子で指定されたサインオン・メカニズムは、呼出し側クライアント・コンポーネントのデプロイメント記述子で指定されたメカニズムに優先します。コンテナ管理によるサインオンを使用する場合でも、クライアント・コンポーネントで明示的に指定されたセキュリティ情報があれば、接続を取得する呼出しの際に提示されます。
WebLogic Server Java EE 1.6コネクタ・アーキテクチャの実装で、クライアント・コンポーネントがリクエストしているサインオン・メカニズムを判断できない場合、コネクタ・コンテナはコンテナ管理によるサインオンを試行します。
アプリケーション管理によるサインオンの場合、クライアント・コンポーネントは、EISに接続するための呼出しを実行するときに、必要なセキュリティ資格証明(通常はユーザー名とパスワード)を提示します。この場合、アプリケーション・サーバーは、接続リクエストでこの情報を渡す以外にセキュリティ関連の処理を行いません。
WebLogic ServerとEISはそれぞれ独立したセキュリティ・レルムを保持しています。コンテナ管理によるサインオンの目的は、ユーザーにWebLogic Serverへのサインオンを許可することと、EISに別にサインオンしなくても、リソース・アダプタを介してEISにアクセスするアプリケーションを使用できるようにすることです。Weblogic Serverのコンテナ管理によるサインオンでは、アウトバウンド資格証明マッピングを使用します。資格証明マッピングとは、WebLogicセキュリティ・プリンシパル(認証を受ける個々のユーザーまたはクライアント・アプリケーション)の資格証明(ユーザー名とパスワードのペアまたはセキュリティ・トークン)を、EISへのアクセスに必要な、対応する資格証明にマップしたものです。デプロイ済みのリソース・アダプタに対して、適切なセキュリティ・プリンシパルのアウトバウンド資格証明マッピングを構成できます。関連情報は、「アウトバウンド資格証明マッピング」を参照してください
『JSR 322: Java EE Connector Architecture 1.6』では、javax.security.auth.Subjectに資格証明を格納することが必要です。資格証明はManagedConnectionFactoryオブジェクトのcreateManagedConnection()またはmatchManagedConnection()メソッドに渡されます。アウトバウンド資格証明のマッピング情報はWebLogic Serverの組込みLDAPサーバーに格納されます。アウトバウンド資格証明マッピングはアウトバウンド・リソース・アダプタに固有のものです。
WebLogic Serverユーザーのアウトバウンド資格証明マッピングを、リソース・アダプタを使用して接続するEISのユーザー名に対して作成する場合、次の点に注意してください。
WebLogic Serverはデフォルト・セキュリティ・レルムのみに定義したWebLogic Serverユーザーのアウトバウンド資格証明マッピングの作成をサポートします。カスタマイズしたデフォルト・セキュリティ・レルムを使用している場合、リソース・アダプタのアウトバウンド資格証明マッピングを構成する前に、それをデフォルトのセキュリティ・レルムとして定義する必要があります。詳細は、『Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)』のデフォルト・セキュリティ構成のカスタマイズに関する項およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのデフォルト・セキュリティ・レルムの変更に関する項を参照してください。
次のいずれかのデプロイメント記述子ファイルに接続プールの認証メカニズム要素を定義する必要があります。
リソース・アダプタのすべての接続プールのために機能するra.xmlファイル
各接続プール用のweblogic-ra.xmlファイル
有効な認証メカニズム要素が定義されていない場合、「認証メカニズム」項の説明どおりに発信資格証明マッピングは有効になりません次にra.xmlサンプル・ファイルのスニペットを示します。
<authentication-mechanism> <authentication-mechanism-type>BasicPassword</authentication-mechanism-type> <credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface> </authentication-mechanism>
WebLogic Serverユーザーは、保護されているWebLogic Serverリソースへのアクセスをリクエストする場合、必ず認証を受けなければなりません。このため、各ユーザーは資格証明(ユーザー名/パスワードの組合せまたはデジタル証明書)をWebLogic Serverに提示する必要があります。
パスワード認証は、WebLogic Serverがデフォルトでサポートしている唯一の認証メカニズムです。パスワード認証は、ユーザーIDとパスワードからなります。構成済みのマッピングに基づいて、ユーザーがリソース・アダプタへの接続をリクエストすると、そのユーザーの適切な資格証明がリソース・アダプタに提供されます。
SSL (またはHTTPS)プロトコルを使用すると、パスワード認証にさらに高度なレベルのセキュリティを提供できます。SSLプロトコルは、クライアントとWebLogic Serverとの間で転送されるデータを暗号化するので、ユーザーIDとパスワードはクリア・テキストでは転送されません。SSLを使用すると、WebLogic Serverは、ユーザーのIDとパスワードの機密性を保持しながらユーザーを認証できます。詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のSSLの構成に関する項を参照してください。
アウトバウンド資格証明マッピングはアウトバウンド・リソース・アダプタに固有のものです。アウトバウンド資格証明マッピングを構成するには、WebLogic Server管理コンソールを使用します。資格証明マッピングを構成する前に、リソース・アダプタを正常にデプロイしておく必要があります。
注意:
リソース・アダプタを最初にデプロイしたとき、アウトバウンド資格証明マッピングは構成されていません。アウトバウンド資格証明マッピングが構成されるまで、初期接続は失敗します。
このため、リソース・アダプタが資格証明を要求し、デプロイメント時に接続を作成するよう構成されている(つまりweblogic-ra.xml内のinitial-capacity要素が0より大きな値に設定されている)場合、初期接続が失敗することがあります。初期接続の失敗を回避するには、このリソース・アダプタの初期インストールおよびデプロイメント時には、接続プールのinitial-capacity要素を0に設定することをお薦めします。リソース・アダプタが初回にデプロイされるときに、initial-capacity要素の値が変更できます。詳細は、「initial-capacity : ManagedConnectionの初期数の設定」を参照してください
アウトバウンド資格証明マッピングは、個々のアウトバウンド接続プールに対して、またはリソース・アダプタのすべての接続プールに対して構成できます。リソース・アダプタが接続リクエストを受信すると、WebLogic Serverは、特定の接続プールに対して構成されているアウトバウンド資格証明マッピングを検索してから、リソース・アダプタに対してグローバルに構成されているマッピングをチェックします。
次の項に記載されている状況を確認します。
WebLogic Serverは、アプリケーションのリクエストに応じて、アダプタからのManagedConnectionが必要です。たとえば、アプリケーションはプールからの接続を必要となりますが、ManagedConnectionがプールにない場合、WebLogic Serverは、アダプタに新しいManagedConnectionを作成するようにリクエストする必要があります。
注意:
コンテナ管理によるサインオンにのみ適用されます。
サーバーは以下の順序でアウトバウンド・マッピングを検索します。
例9-1 アウトバウンド資格証明マッピングの例
poolA system user name: admin system password: admin_password default user name: guest1 default password: guest1_password poolB wlsjoe user name: harry wlsjoe password: harry_password global system user name: sysman system password: sysman_password wlsjoe user name: scott wlsjoe password: scott_password default user name: viewer default password: viewer_password anonymous user name: foo anonymous password: foo_password
例9-1の例の場合に、あるアプリケーションがsystemとして認証を受け、poolAに対して接続リクエストをします。poolAではsystemに対する特定のアウトバウンド資格証明マッピングが定義されているので、リソース・アダプタはこのマッピング(admin/admin_password)を使用します。
アプリケーションがsystemとして、同じリクエストをpoolBに対して行うと、systemに対する特定のアウトバウンド資格証明マッピングがありません。そのため、サーバーはglobalレベルで資格証明マッピングを検索して、マッピング(sysman/sysman_password)を見つけます。
別のアプリケーションがwlsjoeとして認証を受け、poolAに対してリクエストを行った場合、poolAにはwlsjoeに対して定義されたマッピングがないことがわかります。その後、グローバル・レベルで検索して、wlsjoeに対するマッピング(scott/scott_password)を見つけます。poolBに対してリクエストを行った場合、このアプリケーションはpoolBに対して定義されたマッピング(harry/happy_password)を見つけます。
アプリケーションがuser1として認証を受け、poolAに対してリクエストを行った場合、poolAにはuser1に対して定義されたマッピングがないことがわかります。次のシーケンスが発生します。
アプリケーションはグローバル・レベルで検索します。グローバル・レベルでもuser1に対するマッピングはありません。
アプリケーションはpoolAアウトバウンド・マッピングでデフォルト・マッピングがないか検索し、デフォルト・マッピングを見つけます。
アプリケーションはWebLogic Serverに認証されていなくてもpoolAに対してリクエストを行った場合、poolAには匿名ユーザーに対して定義されたアウトバウンド・マッピングがないことがわかります。グローバル・レベルで検索して、匿名ユーザー(foo/foo_password)に対するマッピングを見つけます。
たとえば、例9-1に、次のような2つの接続プールとアウトバウンド資格証明マッピングがあるとします。
WebLogic Serverは、アプリケーションのリクエストがない場合にアダプタからのManagedConnectionが必要です。これは、WebLogic Serverがデプロイメント時に初期接続を作成する(つまり、weblogic-ra.xml内のinitial-capacity要素が0より大きい値に設定されている)場合か、WebLogicが特にXAリカバリのためにManagedConnectionを取得する必要がある場合です。
注意:
コンテナ管理によるサインオンおよびアプリケーション管理によるサインオンに適用されます。
WebLogic Serverは以下の順序でアウトバウンド・マッピングを検索します。
例9-2 資格証明マッピングの例
poolA initial user name: admin initial password: admin_password poolB default user name: harry default password: harry_password global initial user name: sysman initial password: sysman_password
例9-2で示したように、WebLogic Serverは、poolAのXAリカバリを実行し、poolAに対して接続リクエストをします。poolAではsystemに対する初期のアウトバウンド資格証明マッピングが定義されているので、リソース・アダプタはこのマッピング(admin/admin_password)を使用します。
WebLogic ServerはpoolBに対しても同じリクエストを行うと、poolBに対応する初期のアウトバウンド資格証明マッピングはありません。WebLogic Serverはグローバル・レベルで初期の資格証明マッピングを検索して、マッピング(sysman/sysman_password)を見つけます。
初期マッピングとデフォルト・マッピングのどちらも定義していない場合、WebLogic Serverは、ManagedConnectionを作成するためにアダプタを呼び出す時に、Subjectとしてnullを使用します。
たとえば、次のような2つの接続プールとアウトバウンド資格証明マッピングがあるとします。
リソース・アダプタで使用できる3つの特殊なユーザーが提供されます。
初期ユーザー(初期接続を作成するユーザー) - このユーザーに対してアウトバウンド資格証明マッピングを定義すると、指定した資格証明は以下の状態で作成された初期接続のために使用されます。
このリソース・アダプタ用の接続プールの起動
接続プール用のXAトランザクションのリカバリ
プールのInitialCapacityパラメータは、初期接続の数を指定します。このユーザーに対して、マッピングを定義しない場合は、デフォルトのマッピング(提供している場合)が使用されます。それ以外の場合、初期接続に対して資格証明は提供されません。
匿名ユーザー(認証されていないWebLogic Serverユーザー) — このユーザーに対してマッピングを定義すると、リソース・アダプタ上の接続リクエストのためにユーザーが認証していない場合、特別な資格証明が使用されます。
デフォルトのユーザー - このユーザーに対してマッピングを定義すると、以下の場合に、指定した資格証明が使用されます。
その他のマッピングは現在のユーザーに対して適用されません。
認証済みユーザーがない場合、匿名のマッピングは提供されていません。
WebLogic Server管理コンソールを使用してアウトバウンド資格証明マップを作成できます。WebLogic資格証明マッピング・プロバイダを使用している場合、アウトバウンド資格証明のマッピングは組込みLDAPサーバーに格納されます。アウトバウンド資格証明マッピングの作成方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのアウトバウンド資格証明マッピングの作成に関する項を参照してください。
『JSR 322: Java EE Connector Architecture 1.6』では、EIS/リソース・アダプタとアプリケーション・サーバー間の標準の汎用セキュリティ・コンテキストが定義されます。これは『JSR 196: Java Authentication Service Provider Interface for Containers』の仕様を活用しています。セキュリティ・コンテキストを使用して、リソース・アダプタがセキュリティ情報を確立します。この情報は、実行するWorkインスタンスを発行するときや、WebLogic Serverでホストされるメッセージ・エンドポイントにメッセージを配信するときに使用されます。
『JSR 322: Java EE Connector Architecture 1.6』:
リソース・アダプタとアプリケーション・サーバー間の規約として、抽象クラスSecurityContextを定義します。
フローされたIDがアプリケーション・サーバーのセキュリティ・ドメインに含まれるかどうかに応じて、IDを処理する方法に関して2つのシナリオを定義します。
ケース1 (『JSR 322: Java EE Connector Architecture 1.6』の16.4.3項「Case 1: Identity in the Container Security Domain」を参照)
ケース2 (16.4.4項「Case 2: Identity Translated Between Security Domains」)
『JSR 196: Java Authentication Service Provider Interface for Containers』で定義されたCallbackHandlerを使用します。
『JSR 196: CallerPrincipalCallback, GroupPrincipalCallback, and PasswordValidationCallback』のコールバックを使用します。
注意:
WebLogic Serverコネクタ・コンテナが、リソース・アダプタで提供されるSecurityContext実装のsetupSecurityContextメソッドを呼び出すとき、アダプタに渡されるserviceSubjectは常にnullです。
WebLogicコネクタ・コンテナにデプロイされるリソース・アダプタは、ID (呼出し側プリンシパル、グループ・プリンシパルまたは両方)をコンテナにフローできます。IDは、WebLogicドメイン(ケース1のシナリオ)またはEISセキュリティ・ドメイン(ケース2のシナリオ)で定義されます。
IDがEISセキュリティ・ドメインで定義される場合、WebLogicコンテナ・ドメインは、フローされたプリンシパルをWebLogicドメインに定義されたプリンシパルにマップできることが必要です。このシナリオをサポートするため、WebLogic Serverでは、EISプリンシパルと対応するWebLogicドメインの間のインバウンド・プリンシパル・マッピングを作成することができます。
以下のマッピングを作成できます。
EISユーザー名から特定のWebLogicユーザーまたはWebLogicユーザーanonymousへのデフォルト・マッピング
特定のEISユーザー名から特定のWebLogicユーザーまたはWebLogicユーザーanonymousへ
EISグループ名からWebLogicグループ名へのデフォルト・マッピング
特定のEISグループ名からWebLogicグループ名へ
インバウンド・プリンシパル・マッピング構成に定義するプリンシパル名は、空白以外の文字を少なくとも1つ含む必要があります。空白文字のみの文字列は有効なプリンシパル名になりません(WebLogic Server管理コンソールで指定できません)。
インバウンド・プリンシパル・マッピングに関する以下の動作に注意してください。
『JSR 322: Java EE Connector Architecture 1.6』によればリソース・アダプタはユーザーおよびグループのあらゆる組合せをコンテナに渡すことができますが、コネクタ・アーキテクチャ1.6ではセキュリティ制約をコンテナに適用することもできます。WebLogic Serverの場合、ユーザーおよびグループのすべての組合せが有効なわけではありません。マッピングで指定されたWebLogicプリンシパルはWebLogicセキュリティ・レルムで現在定義されている必要があり、ユーザーはマッピングで指定されたグループの有効なメンバーとしてWebLogicセキュリティ・レルムで定義されている必要があります。これはWebLogic Serverによって課される要件です。
たとえば、マッピングが特定のユーザーおよびグループの組合せを指定する場合に、そのユーザーまたはグループのいずれかがWebLogic Serverセキュリティ・レルムで定義されていないと、マッピングは無効になります。また、ユーザーおよびグループの両方がセキュリティ・レルムで定義されていても、そのユーザーがマッピングで指定された特定のグループのメンバーではない場合も、マッピングは無効です。WebLogic Serverでマッピングが有効ではないと判断されると、例外がスローされます。
また、インバウンド・プリンシパル・マッピングが構成される際に、WebLogic Serverによるユーザーまたはグループの検証は行われないことに注意してください。セキュリティ・レルムは、リソース・アダプタがデプロイされた後で変更できるため、インバウンド・プリンシパル・マッピングに指定されるWebLogicプリンシパルが検証されるのは実行時のみです。
フローされたIDは、管理者ロール(Admin、AdminChannelUser、Deployer、OperatorまたはMonitorなど)にマッピングされたプリンシパル(ユーザーまたはグループ)として実行できません。
デフォルトのインバウンド・マッピングがEISユーザー・プリンシパルに構成されず、そのEISユーザーに固有のマッピングも構成されない場合、そのユーザーは未認証ユーザーにマッピングされます。
デフォルトのインバウンド・マッピングがEISグループ・プリンシパルに構成されず、そのEISグループに固有のマッピングも構成されない場合、そのグループ・プリンシパルは無視されます。
インバウンド・プリンシパル・マッピングは、リソース・アダプタがデプロイされた後で構成できます。
WebLogic Server管理コンソールを使用してインバウンド・プリンシパル・マッピングを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのインバウンド・プリンシパル・マッピングの作成に関する項を参照してください。
リソース・アダプタがフローしたIDがCallerPrincipalCallback、GroupPrincipalCallbackおよびPasswordValidationCallbackを介してアプリケーション・サーバーで使用される場合、『JSR 322: Java EE Connector Architecture 1.6』ではコールバックの組合せの制限は指定されていません。ただし、WebLogic Serverコネクタ・アーキテクチャ1.6ではすべての組合せが有効なわけではありません。WebLogicコネクタ・コンテナは、この項で説明する要件に基づいてこれらのコールバックを検証します。コールバックをWebLogicコネクタ・コンテナに渡すときは、これらの要件を満たすようにリソース・アダプタを設計する必要があります。そのようにしないとコールバックは拒否されます。
WebLogic Serverでは、コネクタ・コンテナに渡すコールバックに関して次の要件があります。
リソース・アダプタがPasswordValidationCallbackを扱うとき、アダプタはCallerPrincipalCallbackも扱う必要があります。WebLogicセキュリティ・サービスでは、CallerPrincipalCallbackによって確立された呼出し側プリンシパルが、PasswordValidationCallBackによって認証されたユーザー名と一致する必要があります。
リソース・アダプタがGroupPrincipalCallbackを扱うとき、アダプタはCallerPrincipalCallbackも扱う必要があります。
ケース2 (『JSR 322: Java EE Connector Architecture 1.6』の16.4.4項「Case 2: Identity Translated Between Security Domains」を参照)ではリソース・アダプタはPasswordValidationCallbackを扱ってはいけません。PasswordValidationCallbackのユーザー名とパスワードはEISセキュリティ・ドメインに含まれるため、アプリケーション・サーバー(すなわちWebLogic Server)がそれらを認証できません。
WebLogic Serverでは、リソース・アダプタは構成されたプリンシパルを使用してWork.run()メソッドを実行できます。このプリンシパルは、WebLogic Server管理コンソール(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・プリンシパルの構成に関する項を参照)か、run-work-as-principal-nameおよびdefault-principal-nameを使用してweblogic-ra.xmlファイル内で構成できます。
この後、Work.run()メソッドが実行するときには、このプリンシパル(構成されている場合)またはデフォルトのanonymous (このプリンシパルが構成されていない場合)を使用します。
このメカニズムでアダプタ・レベルの基本のセキュリティ構成が提供され、そのアダプタによって発行されるすべてのWorkインスタンスに適用されます。ただし、様々なWorkインスタンスで他のセキュリティ・プリンシパルを選択して使用することはできません。
コネクタ・アーキテクチャ1.6のセキュリティ・コンテキスト機能は柔軟性が向上しており、各Workインスタンスが独自のSecurityContextを提供したり、各Workインスタンスが様々なセキュリティ・プリンシパルで実行したりできます。
WebLogic Serverコネクタ・コンテナには1.0および1.5のアダプタとの下位互換性があるため、リソース・アダプタがWorkインスタンスを発行するときは次の動作に注意してください。
WorkインスタンスがSecurityContextなしで発行されると、Workインスタンスはweblogic-ra.xmlファイルのrun-work-as-principal-name要素とdefault-principal-name要素に定義されたプリンシパルを使用します。
WorkインスタンスがSecurityContextを使用して発行されると、Workインスタンスは、『JSR 322: Java EE Connector Architecture 1.6』のSecurityContextクラスの記述に従って定義されたセキュリティ・プリンシパルで実行します。run-work-as-principal-name要素とdefault-principal-name要素に定義されるプリンシパルは存在していても無視されます。
セキュリティ・ポリシーは、権限のないアクセスからWebLogicリソースを保護するための、WebLogicリソースと1つまたは複数のユーザー、グループ、セキュリティ・ロールとの関連付けです。『JSR 322: Java EE Connector Architecture 1.6』では、アプリケーション・サーバーで実行されるリソース・アダプタのデフォルト・セキュリティ・ポリシーを定義しています。リソース・アダプタが、デフォルトをオーバーライドする独自のセキュリティ・ポリシーを提供する方法も定義されています。WebLogic Serverに同梱されているweblogic.policyファイルでは、Java EEコネクタ・アーキテクチャ仕様に従ってデフォルト・セキュリティ・ポリシーを規定しています。
リソース・アダプタで固有のセキュリティ・ポリシーを定義していない場合、WebLogic Serverは、weblogic.policyファイルで指定されたデフォルト・セキュリティ・ポリシーを使用して、リソース・アダプタの実行時環境を確立します。weblogic.policyファイルはJava EEコネクタ・アーキテクチャ仕様で規定されたデフォルトに準拠しています。リソース・アダプタで固有のセキュリティ・ポリシーが定義されている場合、Weblogic Serverは、リソース・アダプタのデフォルト・セキュリティ・ポリシーとリソース・アダプタに定義された固有のポリシーを併用して、リソース・アダプタの実行時環境を確立します。リソース・アダプタの固有のセキュリティ・ポリシーを定義するには、ra.xmlデプロイメント記述子ファイルのsecurity-permission-spec要素を使用します。
セキュリティ・ポリシーの処理の要件は、『JSR 322: Java EE Connector Architecture 1.6』の第21章「Runtime Environment」の項「Security Permissions」を参照してください。セキュリティ・ポリシーとWebLogicセキュリティ・フレームワークの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のセキュリティ・ポリシーに関する項を参照してください。
この項では、weblogic-ra.xmlデプロイメント記述子でWebLogic Serverリソース・アダプタの様々なセキュリティIDを構成する方法について説明します。セキュリティIDによって、リソース・アダプタの特定の機能を実行できるセキュリティ・プリンシパルが決まります。WebLogicリソース・アダプタでは、1つのセキュリティIDですべての機能を実行することも、機能の個々のクラスごとに別々のIDを使用することもできます。次の4種類のセキュリティIDをweblogic-ra.xmlデプロイメント記述子に定義できます。
デフォルト・プリンシパル - リソース・アダプタのすべてのタスクを実行できるセキュリティ・プリンシパル。
run-asプリンシパル - 接続リクエスト時にコネクタ・コンテナからリソース・アダプタ・コードへの呼出しで使用されるセキュリティ・プリンシパル。
run-work-asプリンシパル - リソース・アダプタによって起動されたWorkインスタンスで使用されるセキュリティ・プリンシパル。
manage-asプリンシパル - 起動、停止、テスト、トランザクション管理などのリソース・アダプタの管理タスクに使用されるセキュリティ・プリンシパル。
例9-3は、weblogic-ra.xmlデプロイメント記述子の抜粋です。様々なリソース・アダプタのタスクを実行するためにこれらの4つのセキュリティIDをすべて構成する方法を示しています。
例9-3 リソース・アダプタのすべてのセキュリティIDの構成
<weblogic-connector xmlns="http://xmlns.oracle.com/weblogic/weblogic-connector">
<jndi-name>900blackbox-notx</jndi-name>
<security>
<default-principal-name>
<principal-name>system</principal-name>
</default-principal-name>
<run-as-principal-name>
<principal-name>raruser</principal-name>
</run-as-principal-name>
<run-work-as-principal-name>
<principal-name>workuser</principal-name>
</run-work-as-principal-name>
<manage-as-principal-name>
<principal-name>raruser</principal-name>
</manage-as-principal-name>
</security>
</weblogic-connector>
例9-4は、default-principal-name要素を使用して、リソース・アダプタのすべてのタスクを実行する1つのデフォルト・プリンシパルのセキュリティIDを構成する方法を示しています。
例9-4 リソース・アダプタの1つのデフォルト・プリンシパルIDの構成
<weblogic-connector xmlns="http://xmlns.oracle.com/weblogic/weblogic-connector">
<jndi-name>900blackbox-notx</jndi-name>
<security>
<default-principal-name>
<principal-name>system</principal-name>
</default-principal-name>
</security>
</weblogic-connector>
セキュリティIDのプロパティの設定の詳細は、「security」を参照してください
default-principal-name要素を使用して、リソース・アダプタのすべての目的に使用できる1つのセキュリティIDを定義できます。run-as-principal-name、manage-as-principal-name、およびrun-work-as-principal-nameに値が指定されていない場合、default-principal-nameに設定した値がデフォルトになります。
default-principal-nameの値は、例9-5に示すように、systemなどの定義済のWebLogic Serverユーザー名を設定することも、匿名のIDを使用するように設定することもできます(匿名IDの場合は、セキュリティIDがないのと同じことになります)。
たとえば、次の例9-6で示すように、デフォルトのsystem IDを使用して、WebLogic Serverからリソース・アダプタへのすべての呼出しを行い、リソース・アダプタのすべての管理タスクを行う、1つのセキュリティIDを作成することができます。
例9-5 定義済みのWebLogic Server名の使用
<security>
<default-principal-name>
<principal-name>system</principal-name>
</default-principal-name>
</security>
次のように、default-principal-name要素をanonymousに設定できます。
例9-6 匿名IDの設定
<security>
<default-principal-name>
<use-anonymous-identity>true</use-anonymous-identity>
</default-principal-name>
</security>
manage-as-principal-name要素を使用して、起動、停止、テスト、縮小、トランザクション管理などの、リソース・アダプタの様々な管理タスクの実行に使用される管理IDを定義できます。
default-principal-nameと同様に、manage-as-principal-nameの値としてsystemなど定義済みのWebLogic Serverユーザー名を設定することも、匿名のIDを使用するように設定することもできます(匿名IDの場合は、セキュリティIDがないのと同じことになります)。manage-as-principal-name要素の値を設定しない場合、default-principal-nameで設定した値がデフォルトとして使用されます。default-principal-nameに値が設定されていない場合、匿名IDがデフォルトになります。
例9-7は、リソース・アダプタが、WebLogic Serverで定義されたユーザー名systemを使用して管理呼出しを実行するように構成する方法を示しています。
例9-7 定義済みのWebLogic Server名の使用
<security>
<manage-as-principal-name>
<principal-name>system</principal-name>
</manage-as-principal-name>
</security>
例9-8は、リソース・アダプタが匿名のIDを使用して管理呼出しを実行するように構成する方法を示しています。
例9-8 匿名IDの設定
<security>
<manage-as-principal-name>
<use-anonymous-identity>true</use-anonymous-identity>
</manage-as-principal-name>
</security>
run-as-principal-name要素では、接続リクエスト時にコネクタ・コンテナからリソース・アダプタ・コードへのすべての呼出しで使用されるプリンシパル名を定義できます。このプリンシパル名は、たとえば、ManagedConnectionFactoryなどのリソース・アダプタ・オブジェクトがインスタンス化されるときに使用されます。つまり、WebLogic Serverコネクタ・コンテナがリソース・アダプタに呼出しを行うときに、run-as-principal-name要素で定義されたIDが使用されます。この呼出しには、インバウンドまたはアウトバウンドのリクエストや設定に含まれる呼出しや、インバウンドまたはアウトバウンド・リソース・アダプタの初期化に含まれる呼出し(ResourceAdapter.start()など)があります。
run-as-principal-name要素の値は、次の3通りのいずれかで設定できます。
定義済みのWebLogic Server名を設定する
匿名のIDを使用する
呼出し側コードのセキュリティIDを使用する
run-as-principal-name要素の値が定義されていない場合は、default-principal-name要素の値がデフォルトになります。default-principal-name要素が定義されていない場合は、リクエストする呼出し側のIDがデフォルトになります。
インバウンド・リソース・アダプタの場合は、Workインスタンスを使用してインバウンド・リクエストを実行することをお薦めします。リソース・アダプタによって起動されるWorkインスタンスのセキュリティIDを設定するには、run-work-as-principal-name要素を使用して値を指定します。ただし、Workインスタンスは、アウトバウンド・リクエストを実行するために、アウトバウンド・リソース・アダプタの一部として作成されることもあります。アダプタでインバウンド・リクエストを処理するためにWorkインスタンスを使用しない場合、インバウンド・リクエストは、セキュリティ・コンテキストを確立せずに(匿名で)実行されます。または、リソース・アダプタがWebLogic Server固有の呼出しを行って、WebLogic Serverユーザーとして認証を受けることもできます。その場合は、WebLogic Serverユーザーのセキュリティ・コンテキストが使用されます。
run-work-as-principal-name要素の値は、次の3通りのいずれかで設定できます。
定義済みのWebLogic Server名を設定する
匿名のIDを使用する
呼出し側コードのセキュリティIDを使用する
run-work-as-principal-name要素の値が定義されていない場合は、default-principal-name要素の値がデフォルトになります。default-principal-name要素が定義されていない場合は、リクエストする呼出し側のIDがデフォルトになります。
リクエストする呼出し側のIDを使用して作業を実行するには、run-work-as-principal-name要素を例9-9に示すように指定します。
例9-9 リクエストする呼出し側のIDの使用
<security>
<run-work-as-principal-name>
<use-caller-identity>true</use-caller-identity>
</run-work-as-principal-name>
</security>
Java EE標準リソース・アダプタのデプロイメント記述子ra.xmlで、リソース・アダプタの認証および再認証メカニズムを指定できます。この設定はすべてのアウトバウンド接続ファクトリに適用されます。
authentication-mechanism要素では、すべてのアウトバウンド接続ファクトリで使用される認証メカニズムを指定します。
reauthentication-support要素では、アウトバウンド接続ファクトリが既存のManaged-Connectionインスタンスの再認証をサポートするかどうかを指定します。これは、リソース・アダプタのすべての接続ファクトリのデフォルト値となります。
ra.xmlデプロイメント記述子のauthentication-mechanismとreauthentication-supportの値は、weblogic-ra.xmlデプロイメント記述子で値を指定するとオーバーライドできます。それにより、これらの設定を、すべての接続ファクトリではなく、特定の接続ファクトリに適用することができます。表A-18のExample -00およびExample -00を参照してください。
