WebLogic Serverでは、インバウンド通信とアウトバウンド通信でのリソース・アダプタのセキュリティ・サービスをいくつか提供しています。リソース・アダプタが外部システムとの接続を確立できるようにするには、認証および他の必要なセキュリティ情報を構成する必要があります。
WebLogicセキュリティの詳細は、『Oracle WebLogic Serverセキュリティの理解』および『Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』を参照してください。
res-auth
要素で指定された情報に基づいて、選択されたサインオン・メカニズムを判断します。リソース・アダプタのデプロイメント記述子で指定されたサインオン・メカニズムは、呼出し側クライアント・コンポーネントのデプロイメント記述子で指定されたメカニズムに優先します。コンテナ管理によるサインオンを使用する場合でも、クライアント・コンポーネントで明示的に指定されたセキュリティ情報があれば、接続を取得する呼出しの際に提示されます。WebLogic Server Java EE 1.6 Connector Architectureの実装で、クライアント・コンポーネントがリクエストしているサインオン・メカニズムを判断できない場合、コネクタ・コンテナはコンテナ管理によるサインオンを試行します。
アプリケーション管理によるサインオンの場合、クライアント・コンポーネントは、EISに接続するための呼出しを実行するときに、必要なセキュリティ資格証明(通常はユーザー名とパスワード)を提示します。この場合、アプリケーション・サーバーは、接続リクエストでこの情報を渡す以外にセキュリティ関連の処理を行いません。
WebLogic ServerとEISはそれぞれ独立したセキュリティ・レルムを保持しています。コンテナ管理によるサインオンの目的は、ユーザーにWebLogic Serverへのサインオンを許可することと、EISに別にサインオンしなくても、リソース・アダプタを介してEISにアクセスするアプリケーションを使用できるようにすることです。Weblogic Serverのコンテナ管理によるサインオンでは、アウトバウンド資格証明マッピングを使用します。資格証明マッピングとは、WebLogicセキュリティ・プリンシパル(認証を受ける個々のユーザーまたはクライアント・アプリケーション)の資格証明(ユーザー名とパスワードのペアまたはセキュリティ・トークン)を、EISへのアクセスに必要な、対応する資格証明にマップしたものです。デプロイ済みのリソース・アダプタに対して、適切なセキュリティ・プリンシパルのアウトバウンド資格証明マッピングを構成できます。関連情報は、「アウトバウンド資格証明マッピング」を参照してください
javax.security.auth.Subject
に資格証明を格納することが必要です。アウトバウンド接続が確立すると、これらの資格証明はManagedConnectionFactory
オブジェクトのcreateManagedConnection
またはmatchManagedConnection
メソッドに渡されます。WebLogic Serverの組込みLDAPサーバーに格納されたアウトバウンド資格証明のマッピングは、アウトバウンド・リソース・アダプタに固有です。WebLogic Serverユーザーのアウトバウンド資格証明マッピングを、リソース・アダプタを使用して接続するEISのユーザー名に対して作成する場合、次の点に注意してください。
WebLogic Serverはデフォルト・セキュリティ・レルムのみに定義したWebLogic Serverユーザーのアウトバウンド資格証明マッピングの作成をサポートします。カスタマイズしたデフォルト・セキュリティ・レルムを使用している場合、リソース・アダプタのアウトバウンド資格証明マッピングを構成する前に、それをデフォルトのセキュリティ・レルムとして定義する必要があります。詳細は、s『Oracle WebLogic Serverセキュリティの管理』のデフォルト・セキュリティ構成のカスタマイズに関する項および『Oracle WebLogic Server Administration Consoleオンラインヘルプ』のデフォルト・セキュリティ・レルムの変更に関する項を参照してください。
次のいずれかのデプロイメント記述子ファイルに接続プールの認証メカニズム
要素を定義する必要があります。
リソース・アダプタのすべての接続プールのために機能する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セキュリティの管理』の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管理コンソール・オンライン・ヘルプのアウトバウンド資格証明マッピングの作成に関する項を参照してください。
Work
インスタンスを発行するときや、WebLogic Serverでホストされるメッセージ・エンドポイントにメッセージを配信するときに使用されます。Java 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.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
デプロイメント記述子に定義できます。デフォルト・プリンシパル - リソース・アダプタのすべてのタスクを実行できるセキュリティ・プリンシパル。
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を参照してください。