| Oracle® Fusion Middleware Oracle WebLogic Serverリソース・アダプタのプログラミング 11gリリース1 (10.3.6) B60996-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverリソース・アダプタのプログラミング 11gリリース1 (10.3.6) B60996-04 |
|
前 |
次 |
リソース・アダプタは外部システムとの接続を確立する必要があるため、認証および接続の確立に必要なその他の情報を構成する必要があります。次の項では、発信通信におけるWebLogic Serverリソース・アダプタのセキュリティについて説明します。
WebLogicセキュリティの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Securityの紹介』および『Oracle Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
リソース・アダプタはエンタープライズ情報システム(EIS)への発信接続を行うときに、有効なセキュリティ資格証明を使用してサインオンする必要があります。J2CA 1.5仕様(http://java.sun.com/j2ee/connector/)に従って、WebLogic Serverでは、発信接続に関するコンテナ管理およびアプリケーション管理によるサインオンをサポートしています。実行時にWeblogic Serverは、呼出し側クライアント・コンポーネントのデプロイメント記述子、またはリソース・アダプタ・デプロイメント記述子のres-auth要素で指定された情報に基づいて、選択されたサインオン・メカニズムを判断します。リソース・アダプタのデプロイメント記述子で指定されたサインオン・メカニズムは、呼出し側クライアント・コンポーネントのデプロイメント記述子で指定されたメカニズムに優先します。コンテナ管理によるサインオンを使用する場合でも、クライアント・コンポーネントで明示的に指定されたセキュリティ情報があれば、接続を取得する呼出しの際に提示されます。
WebLogic Server Java EE 1.5コネクタ・アーキテクチャの実装で、クライアント・コンポーネントがリクエストしているサインオン・メカニズムを判断できない場合、コネクタ・コンテナはコンテナ管理によるサインオンを試行します。
アプリケーション管理によるサインオンの場合、クライアント・コンポーネントは、EISに接続するための呼出しを実行するときに、必要なセキュリティ資格証明(通常はユーザー名とパスワード)を提示します。この場合、アプリケーション・サーバーは、接続リクエストでこの情報を渡す以外にセキュリティ関連の処理を行いません。
WebLogic ServerとEISはそれぞれ独立したセキュリティ・レルムを保持しています。コンテナ管理によるサインオンの目的は、ユーザーにWebLogic Serverへのサインオンを許可することと、EISに別にサインオンしなくても、リソース・アダプタを介してEISにアクセスするアプリケーションを使用できるようにすることです。Weblogic Serverのコンテナ管理によるサインオンでは、資格証明マッピングを使用します。資格証明マッピングとは、WebLogicセキュリティ・プリンシパル(認証を受ける個々のユーザーまたはクライアント・アプリケーション)の資格証明(ユーザー名とパスワードのペアまたはセキュリティ・トークン)を、EISへのアクセスに必要な、対応する資格証明にマップしたものです。デプロイ済みのリソース・アダプタに対して、適切なセキュリティ・プリンシパルの資格証明マッピングを構成できます。関連情報については、「資格証明マッピング」を参照してください。
J2CA 1.5仕様(http://java.sun.com/j2ee/connector/)では、javax.security.auth.Subjectに資格証明を格納することを求めています。資格証明はManagedConnectionFactoryオブジェクトのcreateManagedConnection()またはmatchManagedConnection()メソッドに渡されます。資格証明のマッピング情報はWebLogic Serverの組込みLDAPサーバーに格納されます。資格証明マッピングは発信リソース・アダプタに固有のものです。
WebLogic Serverユーザーの資格証明マッピングを、リソース・アダプタを使用して接続するエンタープライズ情報システム(EIS)のユーザー名に作成する場合、次の点に注意してください。
WebLogic Serverはデフォルト・セキュリティ・レルムのみに定義したWebLogic Serverユーザーの資格証明マッピングの作成をサポートします。カスタマイズしたデフォルト・セキュリティ・レルムを使用している場合、リソース・アダプタの資格証明マッピングを構成する前に、それをデフォルトのセキュリティ・レルムとして定義する必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のデフォルト・セキュリティ構成のカスタマイズに関する項およびOracle Fusion Middleware 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 Fusion Middleware 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を作成するようにリクエストする必要があります。
|
注意: コンテナ管理によるサインオンにのみ適用されます。 |
サーバーは次の順序でマッピングを検索します。
接続ファクトリ・レベルの特定のマッピング(または、未認証の場合、匿名マッピング)。
グローバル・レベルの特定のマッピング(または、未認証の場合、匿名マッピング)。
接続ファクトリ・レベルのデフォルトのマッピング。
グローバル・レベルのデフォルトのマッピング。
たとえば、例8-1に、次のような2つの接続プールと資格証明マッピングがあるとします。
例8-1 資格証明マッピングの例
poolA system user name: admin system password: adminpw default user name: guest1 default password: guest1pw1 poolB wlsjoe user name: harry wlsjoe password: harrypw global system user name: sysman system password: sysmanpw wlsjoe user name: scott wlsjoe password: tiger default user name: viewer default password: viewerpw anonymous user name: foo anonymous password: bar
例8-1の例の場合に、あるアプリケーションがsystemとして認証を受け、poolAに対して接続リクエストをします。poolAではsystemに対する特定の資格証明マッピングが定義されているので、リソース・アダプタはこのマッピング(admin/adminpw)を使用します。
アプリケーションがsystemとして、同じリクエストをpoolBに対して行うと、systemに対する特定の資格証明マッピングがありません。そのため、サーバーはグローバル・レベルで資格証明マッピングを検索して、マッピング(sysman/sysmanpw)を見つけます。
別のアプリケーションがwlsjoeとして認証を受け、poolAに対してリクエストを行った場合、poolAにはwlsjoeに対して定義されたマッピングがないことがわかります。そこで、グローバル・レベルで検索して、wlsjoeに対するマッピング(scott/tiger)を見つけます。poolBに対してリクエストを行った場合、このアプリケーションはpoolBに対して定義されたマッピング(harry/harrypw)を見つけます。
アプリケーションがuser1として認証を受け、poolAに対してリクエストを行った場合、poolAにはuser1に対して定義されたマッピングがないことがわかります。次のシーケンスが発生します。
アプリケーションはグローバル・レベルで検索します。グローバル・レベルでもuser1に対するマッピングはありません。
アプリケーションはpoolAでデフォルト・マッピングがないか検索し、デフォルト・マッピングを見つけます。
アプリケーションはWLSに認証されていなくてもpoolAに対してリクエストを行った場合、poolAには匿名ユーザーに対して定義されたマッピングがないことがわかります。グローバル・レベルで検索して、匿名ユーザー(foo/bar)に対するマッピングを見つけます。
WebLogic Serverは、アプリケーションのリクエストがない場合のアダプタからのManagedConnectionが必要です。これは、WebLogic Serverがデプロイメント時に初期接続を作成する(つまり、weblogic-ra.xml内のinitial-capacity要素が0より大きい値に設定されている)場合か、WebLogicが特にXAリカバリのためにManagedConnectionを取得する必要がある場合です。
|
注意: コンテナ管理によるサインオンおよびアプリケーション管理によるサインオンに適用されます。 |
サーバーは次の順序でマッピングを検索します。
接続ファクトリ・レベルの初期マッピング。
グローバル・レベルの初期マッピング。
接続ファクトリ・レベルのデフォルトのマッピング。
グローバル・レベルのデフォルトのマッピング。
初期マッピングとデフォルト・マッピングのどちらも定義していない場合、WebLogic Serverは、ManagedConnectionを作成するためにアダプタを呼び出す時に、Subjectとしてnullを使用します。
たとえば、次のような2つの接続プールと資格証明マッピングがあるとします。
例8-2 資格証明マッピングの例
poolA initial user name: admin initial password: adminpw poolB default user name: harry default password: harrypw global initial user name: sysman initial password: sysmanpw
例8-2で示したように、WebLogic Serverは、poolAのXAリカバリし、poolAに対して接続リクエストをします。poolAではsystemに対する特定の資格証明マッピングが定義されているので、リソース・アダプタはこのマッピング(admin/adminpw)を使用します。
WebLogic ServerはpoolBに対しても同じリクエストを行うと、poolBに対応する初期の資格証明マッピングはありません。WebLogic Serverはグローバル・レベルで初期の資格証明マッピングを検索して、マッピング(sysman/sysmanpw)を見つけます。
リソース・アダプタで使用できる3つの特殊なユーザーが提供されます。
初期ユーザー(初期接続を作成するユーザー) - このユーザーに対してマッピングを定義すると、指定した資格証明は以下の状態で作成された初期接続のために使用します。
このリソース・アダプタ用の接続プールの起動
接続プール用のXAトランザクションのリカバリ
プールのInitialCapacityパラメータは、初期接続の数を指定します。このユーザーに対して、マッピングを定義しない場合は、デフォルトのマッピング(提供している場合)が使用されます。それ以外の場合、初期接続に対して資格証明は提供されません。
匿名ユーザー(認証されていないWLSユーザー): このユーザーに対してマッピングを定義すると、リソース・アダプタ上の接続リクエストのためにユーザーが認証していない場合、特別な資格証明が使用されます。
デフォルトのユーザー - このユーザーに対してマッピングを定義すると、以下の状態で指定した資格証明を使用します。
その他のマッピングは現在のユーザーに対して適用されません。
認証済みユーザーがない場合、匿名のマッピングは提供されていません。
WebLogic Server管理コンソールを使用して資格証明マップを作成できます。WebLogic資格証明マッピング・プロバイダを使用する場合、資格証明マップは組込みLDAPサーバーに格納されます。資格証明マッピングの作成方法については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの資格証明マッピングの作成に関する項を参照してください。
セキュリティ・ポリシーは、権限のないアクセスからWebLogicリソースを保護するための、WebLogicリソースと1つまたは複数のユーザー、グループ、セキュリティ・ロールとの関連付けです。J2CA 1.5仕様(http://java.sun.com/j2ee/connector/)では、アプリケーション・サーバーで実行されるリソース・アダプタのデフォルト・セキュリティ・ポリシーを定義しています。リソース・アダプタが、デフォルトをオーバーライドする独自のセキュリティ・ポリシーを提供する方法も定義されています。WebLogic Serverに同梱されているweblogic.policyファイルでは、J2CA 1.5仕様に従ってデフォルト・セキュリティ・ポリシーを規定しています。
リソース・アダプタで固有のセキュリティ・ポリシーを定義していない場合、WebLogic Serverは、weblogic.policyファイルで指定されたデフォルト・セキュリティ・ポリシーを使用して、リソース・アダプタの実行時環境を確立します。weblogic.policyファイルはJ2CA 1.5仕様で規定されたデフォルトに準拠しています。リソース・アダプタで固有のセキュリティ・ポリシーが定義されている場合、Weblogic Serverは、リソース・アダプタのデフォルト・セキュリティ・ポリシーとリソース・アダプタに定義された固有のポリシーを併用して、リソース・アダプタの実行時環境を確立します。リソース・アダプタの固有のセキュリティ・ポリシーを定義するには、ra.xmlデプロイメント記述子ファイルのsecurity-permission-spec要素を使用します。
セキュリティ・ポリシーの処理の要件については、J2CA 1.5仕様の第18章「実行時環境」の項「Security Permissions」を参照してください。セキュリティ・ポリシーとWebLogicセキュリティ・フレームワークの詳細は、『ロールおよびポリシーによるWebLogicリソースの保護』の「セキュリティ・ポリシー」を参照してください。
この項では、weblogic-ra.xmlデプロイメント記述子でWebLogic Serverリソース・アダプタの様々なセキュリティIDを構成する方法について説明します。セキュリティIDによって、リソース・アダプタの特定の機能を実行できるセキュリティ・プリンシパルが決まります。WebLogicリソース・アダプタでは、1つのセキュリティIDですべての機能を実行することも、機能の個々のクラスごとに別々のIDを使用することもできます。次の4種類のセキュリティIDをweblogic-ra.xmlデプロイメント記述子に定義できます。
デフォルト・プリンシパル - リソース・アダプタのすべてのタスクを実行できるセキュリティ・プリンシパル。
run-asプリンシパル - 接続リクエスト時にコネクタ・コンテナからリソース・アダプタ・コードへの呼出しで使用されるセキュリティ・プリンシパル。
run-work-asプリンシパル - リソース・アダプタによって起動されたWorkインスタンスで使用されるセキュリティ・プリンシパル。
manage-asプリンシパル - 起動、停止、テスト、トランザクション管理などのリソース・アダプタの管理タスクに使用されるセキュリティ・プリンシパル。
例8-3は、weblogic-ra.xmlデプロイメント記述子の抜粋です。様々なリソース・アダプタのタスクを実行するためにこれらの4つのセキュリティIDをすべて構成する方法を示しています。
例8-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>
例8-4は、<default-principal-name>要素を使用して、リソース・アダプタのすべてのタスクを実行する1つのデフォルト・プリンシパルのセキュリティIDを構成する方法を示しています。
例8-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の値は、systemなどの定義済みのWebLogic Serverユーザー名を設定することも、匿名のIDを使用するように設定することもできます(匿名IDの場合は、セキュリティIDがないのと同じことになります)。
たとえば、次の例8-6で示すように、デフォルトのsystem IDを使用して、WebLogic Serverからリソース・アダプタへのすべての呼出しを行い、リソース・アダプタのすべての管理タスクを行う、1つのセキュリティIDを作成することができます。
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がデフォルトになります。
例8-7は、リソース・アダプタが、WebLogic Serverで定義されたユーザー名systemを使用して管理呼出しを実行するように構成する方法を示しています。
例8-7 定義済みのWebLogic Server名の使用
<security>
<manage-as-principal-name>
<principal-name>system</principal-name>
</manage-as-principal-name>
</security>
例8-8は、リソース・アダプタが匿名のIDを使用して管理呼出しを実行するように構成する方法を示しています。
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要素を例8-9に示すように指定します。
Java EE標準リソース・アダプタのデプロイメント記述子ra.xmlで、リソース・アダプタの認証および再認証メカニズムを指定できます。この設定はすべての発信接続ファクトリに適用されます。
authentication-mechanism要素では、すべての発信接続ファクトリで使用される認証メカニズムを指定します。
reauthentication-support要素では、発信接続ファクトリが既存のManagedConnectionインスタンスの再認証をサポートするかどうかを指定します。これは、リソース・アダプタのすべての接続ファクトリのデフォルト値となります。
ra.xmlデプロイメント記述子のauthentication-mechanismとreauthentication-supportの値は、weblogic-ra.xmlデプロイメント記述子で値を指定するとオーバーライドできます。それにより、これらの設定を、すべての接続ファクトリではなく、特定の接続ファクトリに適用することができます。「表A-13 default-connection-propertiesのサブ要素」の「authentication-mechanism」および「reauthentication-support」を参照してください。
