| Oracle® Fusion Middleware Oracle WebLogic Server Tuxedo Connector管理ガイド 11gリリース1 (10.3.6) B55553-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server Tuxedo Connector管理ガイド 11gリリース1 (10.3.6) B55553-04 |
|
前 |
次 |
この章では、Oracle WebLogic Tuxedo Connectorを構成して接続を確立する方法、およびWebLogic ServerアプリケーションとTuxedo環境の間にセキュリティを提供する方法について説明します。Oracle WebLogic Tuxedo Connectorでは、Tuxedoアクセス・ポイント間の通信に必要な相互運用属性に類似した属性を使用します。
Oracle WebLogic Tuxedo Connectorを含むOracle WebLogic Server管理の詳細は、Oracle WebLogic Server MBeanリファレンスを参照してください。
アクセス・ポイントがリモート・アクセス・ポイントとの接続を確立する条件を指定できるオプションがいくつかあります。これらの条件は、WTCサービスのローカルTuxedoアクセス・ポイントおよびリモートTuxedoアクセス・ポイントの構成で「接続」タブのConnectionPolicy属性を使用して指定します。次の接続ポリシーのいずれかを選択できます。
On StartupおよびIncoming Onlyの接続ポリシーでは、動的ステータスが呼び出されます。動的ステータスは、各リモート・アクセス・ポイントに関連してインポートされたサービスのステータスをチェックして、レポートします。
WTCローカル・アクセス・ポイントには、ON_DEMAND、INCOMING_ONLY、およびON_STARTUPの3種類の接続ポリシーがあります。デフォルトはON_DEMANDです。
WTCリモート・アクセス・ポイントには、ON_DEMAND、INCOMING_ONLY、ON_STARTUP、およびLOCALの4種類の接続ポリシーがあります。デフォルトはLOCALです。リモート・アクセス・ポイントの接続ポリシー設定にLOCALを指定すると、ローカル・アクセス・ポイントの接続ポリシーが使用されます。リモート・アクセス・ポイントの接続ポリシーは、ローカル・アクセス・ポイントの接続ポリシーよりも優先されます。
ローカル・アクセス・ポイントの接続ポリシーは、リモート・アクセス・ポイントの接続ポリシーのバックアップとして機能します。WTCの起動時に、WTCはすべてのリモート・アクセス・ポイント定義を処理し、次の表に示されているように実際の接続ポリシーを決定します。
表3-1 アクセス・ポイントの接続ポリシー設定
| ローカル・アクセス・ポイント設定 | リモート・アクセス・ポイント設定 | 実際の接続ポリシー |
|---|---|---|
|
ON_DEMAND |
ON_DEMAND |
ON_DEMAND |
|
ON_DEMAND |
ON_STARTUP |
ON_STARTUP |
|
ON_DEMAND |
INCOMING_ONLY |
INCOMING_ONLY |
|
ON_DEMAND |
LOCAL |
ON_DEMAND |
|
ON_STARTUP |
ON_DEMAND |
ON_DEMAND |
|
ON_STARTUP |
ON_STARTUP |
ON_STARTUP |
|
ON_STARTUP |
INCOMING_ONLY |
INCOMING_ONLY |
|
ON_STARTUP |
LOCAL |
ON_STARTUP |
|
INCOMING_ONLY |
ON_DEMAND |
ON_DEMAND |
|
INCOMING_ONLY |
ON_STARTUP |
ON_STARTUP |
|
INCOMING_ONLY |
INCOMING_ONLY |
INCOMING_ONLY |
|
INCOMING_ONLY |
LOCAL |
INCOMING_ONLY |
次の表に、ローカル・アクセス・ポイントの接続ポリシー、リモート・アクセス・ポイントの接続ポリシー、およびリモート・ドメインにおけるこれらのパラメータの設定の明確な相互関係を示します。
表3-2 ローカルおよびリモート・アクセス・ポイントの接続ポリシーの相互関係
| ローカル・システムの有効な接続ポリシー | リモート・システムの有効な接続ポリシー | リモート・ドメインにおけるパラメータの設定 |
|---|---|---|
|
ON_DEMAND |
ON_DEMAND |
ON_DEMAND (いずれか一方に基づく) |
|
ON_DEMAND |
ON_STARTUP |
ON_STARTUP (両方とも動作している場合) |
|
ON_DEMAND |
INCOMING_ONLY |
ON_DEMAND (ローカルに基づく) |
|
ON_STARTUP |
ON_DEMAND |
ON_STARTUP (両方とも動作している場合) |
|
ON_STARTUP |
ON_STARTUP |
ON_STARTUP (両方とも動作している場合) |
|
ON_STARTUP |
INCOMING_ONLY |
ON_STARTUP (両方とも動作している場合) |
|
INCOMING_ONLY |
ON_DEMAND |
ON_DEMAND (リモートに基づく) |
|
INCOMING_ONLY |
ON_STARTUP |
ON_STARTUP (両方とも動作している場合) |
|
INCOMING_ONLY |
INCOMING_ONLY |
手動接続(両方とも動作している場合のみ) |
On Startupのポリシーは、ゲートウェイ・サーバーの初期化時に、アクセス・ポイントがリモート・アクセス・ポイントを使用して接続を確立することを示します。この接続ポリシーは、RetryIntervalパラメータとMaxRetriesパラメータで指定された一定の間隔で、エラーとなった接続を再試行します。起動時に接続を要求するには、ローカルTuxedoアクセス・ポイントの「接続」タブでConnectionPolicy属性をOn Startupに設定します。
自動接続の試行の頻度は、接続を再試行する前にアクセス・ポイントが待機する間隔(秒)を指定することによって制御できます。最小値は0、デフォルト値は60、そして最大値は2147483647です。
MaxRetriesパラメータに値を割り当てることによって、アクセス・ポイントが終了するまでにリモート・アクセス・ポイントへの接続を試行する回数を指定します。最小値は0、デフォルトおよび最大値は2147483647です。
MaxRetriesを0に設定すると、自動接続の再試行処理はオフになります。サーバーは、リモート・アクセス・ポイントに自動接続しません。
MaxRetriesに数値を設定すると、アクセス・ポイントは指定された回数だけ接続を再試行してから終了します。
MaxRetriesを2147483647に設定すると、再試行処理は無期限でまたは接続が確立するまで繰り返されます。
この設定は、ConnectionPolicyがOn Startupに設定されているときだけ使用してください。他の接続ポリシーの場合、再試行処理は無効になります。
表3-3 MaxRetriesパラメータおよびRetryIntervalパラメータの設定例
| 設定 | 処理 |
|---|---|
ConnectionPolicy: On Startup RetryInterval: 30 MaxRetries: 3 |
アクセス・ポイントは、接続の確立を30秒間隔で3回試行してから終了します。 |
ConnectionPolicy: On Startup MaxRetries: 0 |
アクセス・ポイントは初期化時に接続の確立を試行するが、最初の試行がエラーとなった場合は再試行しません。 |
ConnectionPolicy: On Startup RetryInterval: 30 |
アクセス・ポイントは、接続が確立されるまで、30秒おきに接続の確立を試行します。 |
On Demandの接続ポリシーは、リモート・サービスに対するクライアント・リクエスト、または管理接続開始コマンドのいずれかによって要求されたときのみに、接続が試行されることを示します。
|
注意: ローカル・アクセス・ポイントのConnectionPolicyを指定しない場合、Oracle WebLogic Tuxedo ConnectorはOn DemandのConnectionPolicyを使用します。 |
Incoming Onlyの接続ポリシーは、アクセス・ポイントが起動時にリモート・アクセス・ポイントへの接続を確立しないことを示します。アクセス・ポイントは、リモート・アクセス・ポイントからの接続リクエストの受信時に使用できます。
LOCALの接続ポリシーは、リモート・ドメインの接続ポリシーが明示的にローカル・ドメインのConnectionPolicy属性値にデフォルト設定されることを示します。リモート・アクセス・ポイントのConnectionPolicyが定義されていない場合、システムは関連するローカル・アクセス・ポイントで指定されている設定を使用します。
|
注意: LOCALのConnectionPolicyは、ローカル・アクセス・ポイントでは無効です。 |
Oracle WebLogic Tuxedo Connectorが提供するフェイルオーバーは、プライマリ・リモート・アクセス・ポイントでエラーが発生したとき、代替リモート・アクセス・ポイントにリクエストを転送するメカニズムです。このフェイルオーバーは、アクセス・ポイントが復元されると、プライマリ・リモート・アクセス・ポイントにフェイルバックします。このレベルのフェイルオーバーおよびフェイルバックは、接続ステータスに依存します。フェイルオーバーとフェイルバックを有効にするには、アクセス・ポイントがOn StartupまたはIncoming Onlyの接続ポリシーで構成されている必要があります。
|
注意: Tuxedo T/ Domainでは、バックアップ・リモート・アクセス・ポイントは2つに制限されています。Oracle WebLogic Tuxedo Connectorには、サービスに構成できるバックアップ・アクセス・ポイントの数に制限はありません。 |
フェイルオーバーまたはフェイルバックを使用するには、Connection Policyパラメータの値にON_STARTUPまたはINCOMING_ONLYを指定する必要があります。
On Demandの接続ポリシーは、リモート・アクセス・ポイントが常に使用可能であることを想定して動作するため、フェイルバックには適しません。接続ポリシーとしてON_STARTUPまたはINCOMING_ONLYを指定しないと、サーバーはTuxedoのRDOMパラメータを使用して指定した代替リモート・アクセス・ポイントにフェイルオーバーできません。
|
注意: リモート・アクセス・ポイントはそれに対するネットワーク接続があれば「使用可能」であり、それに対するネットワーク接続がなければ「使用不可能」です。 |
フェイルオーバーをサポートするには、特定のサービスを実行する責任を持つリモート・アクセス・ポイントを指定する必要があります。WTCサービスで、以下の項目を指定する必要があります。
リモート・アクセス・ポイントごとに、リモートTuxedoアクセス・ポイント構成を作成します。
各リモート・アクセス・ポイントが提供するサービスを指定する、インポートされたサービス構成を作成します。
TOUPPERというサービスが、TDOM1とTDOM3という2つのリモート・アクセス・ポイントから使用可能であるとします。使用するWTCサービスには2つのリモートTuxedoアクセス・ポイント構成と2つのインポートされたサービス構成が含まれています。config.xmlファイルに定義されているWTCサービスの内容は次のとおりです。
<wtc-server>
<name>WTCsimpapp</name>
<wtc-local-tux-dom>
<access-point>TDOM2</access-point>
<access-point-id>TDOM2</access-point-id>
<connection-policy>ON_DEMAND</connection-policy>
<interoperate>no</interoperate>
<nw-addr>//123.123.123.123:5678</nw-addr>
<name>myLoclTuxDom</name>
<security>NONE</security>
</wtc-local-tux-dom>
<wtc-remote-tux-dom>
<access-point>TDOM1</access-point>
<access-point-id>TDOM1</access-point-id>
<local-access-point>TDOM2</local-access-point>
<nw-addr>//123.123.123.123:1234</nw-addr>
<name>myRTuxDom</name>
</wtc-remote-tux-dom>
<wtc-remote-tux-dom>
<access-point>TDOM3</access-point>
<access-point-id>TDOM3</access-point-id>
<local-access-point>TDOM2</local-access-point>
<nw-addr>//234.234.234.234:5555</nw-addr>
<name>2ndRemoteTuxDom</name>
</wtc-remote-tux-dom>
<wtc-export>
<ejb-name>tuxedo.services.TOLOWERHome</ejb-name>
<local-access-point>TDOM2</local-access-point>
<name>myExportedResources</name>
<resource-name>TOLOWER</resource-name>
</wtc-export>
<wtc-import>
<name>imp0</name>
<resource-name>TOUPPER</resource-name>
<local-access-point>TDOM2</local-access-point>
<remote-access-point-list>TDOM1,TDOM3</remote-access-point-list>
<remote-name>TOUPPER</remote-name>
</wtc-import>
<wtc-import>
<name>imp1</name>
<resource-name>TOUPPER</resource-name>
<local-access-point>TDOM2</local-access-point>
<name>2ndImportedResources</name>
<remote-access-point-list>TDOM3,TDOM1</remote-access-point-list>
<remote-name>TOUPPER</remote-name>
</wtc-import>
</wtc-server>
リンク・レベルのフェイルオーバーをサポートするには、WTCRemoteTuxDomMBeanおよびWTCLocalTuxDomMBean定義で、カンマで区切られた構文<nw-addr> XMLタグで正しいフェイルオーバー・シーケンス情報を指定する必要があります。ネットワーク・アドレスの順序によって、フェイルオーバーの優先順位が決まります。
|
注意: XMLタグの値は、正しい構文であるかどうかチェックされます。構文が正しくない場合、InvalidAttributeExceptionが送出されます。 |
リンク・レベルのフェイルオーバーのセマンティックは、レイト・バインディングです。つまり、MBean作成時に、有無や可用性はチェックされません。これは、WTC構成の作成後、かつTDomainセッション接続の作成前に、ユーザーがDNSをマシンに追加できるようにするためです。
config.xmlでの正しい構文は、次のように<nw-addr> XMLタグのカンマで区切られた構文を使用します。
<nw-addr>//host1:4001</nw-addr> --> only one host, no link-level failover <nw-addr>//host1:4001,//host2:4001</nw-addr> --> can failover to host2 <nw-addr>//host1:4001,//host2:4001,//host3:4001</nw-addr> --> can failover from host 1 to host2, and if host2 still not available then failover to host3
次の例では、WDOMというWTCローカル・アクセス・ポイントと、TDOMというTDomainセッションを構成します。このTDomainセッションは、DOM1というリモート・アクセス・ポイントも定義します。この場合、TDomainセッションは、WDOMとTDOMの間のセッションです。ローカル・アクセス・ポイントはまず、エンド・ポイント「//pluto:4100」をリスニングしようとします。リスニング・エンド・ポイントの作成に失敗した場合、セッションは「//saturn:4101」にリスニング・エンド・ポイントを作成しようとします。plutoからsaturnにWTCが移行した場合、リモート・アクセス・ポイントDOM1は「//saturn:4101」を使用してWDOMにアクセスできます。
リモート・アクセス・ポイントDOM1がホストmercuryからホストmarsに移行した場合、WDOMは「//mars:4001」のDOM1にアクセスできます。
リストに指定されたネットワーク・アドレスの順序によって、優先順位が決まります。WDOMでは、「//pluto:4100」がリスニング・エンド・ポイントを作成する最初の候補であり、「//saturn:4101」が2番目の候補です。リモート・アクセス・ポイントDOM1では、「//mercury:4001」がWDOMとDOM1の間の接続を作成する最初の候補であり、「//mars:4001」が2番目の候補です。
例3-1 リンク・レベルのフェイルオーバーの構成
<wtc-server> <name>myWTCserver</name> .... <wtc-local-tux-dom> <name>WDOM</name> <access-point>WDOM</access-point> <access-point-id>WDOM</access-point-id> <nw-addr>//pluto:4100,//saturn:4101</nw-addr> </wtc-local-tux-dom> <wtc-remote-tux-dom> <name>TDOM</name> <access-point>DOM1</access-point> <access-point-id>DOM1</access-point-id> <local-access-point>WDOM</local-access-point> <nw-addr>//mercury:4001,//mars:4001</nw-addr> </wtc-remote-tux-dom> ..... </wtc-server>
MBSTRINGバッファをサポートするようにWTCを構成するには、WTCResources定義のRemoteMBEncoding属性に、使用するエンコーディングを指定する必要があります。この属性は省略可能であり、指定されていない場合や無効な場合は、Javaのデフォルト・エンコーディングが使用されます。
TypedMBStringは、Unicodeと外部エンコーディングの間の変換に変換関数java.lang.Stringクラスを使用します。TypedMBStringはマップ・ファイルを使用してJavaとGNUのiconv間のエンコーディング名をマップします(これは、MBSTRINGのC言語APIによって使用されます)。マップ・ファイルは、デフォルトでは$WL_HOME/server/libディレクトリにあるmbencmapというテキスト・ベースのファイルです。このマップ・ファイルでは、各「user_name java_name」のペアを含むハッシュ・マップが作成されます。このマップ・ファイルはカスタマイズできます。
エンコーディング・マップ・ファイルには、次の構文に従う1つまたは複数の行が含まれます。
<user_name> <java_name1>[,<java_name2>,[java_name3,...]]
1行に複数のjava_nameを指定することにより、複数のJavaエンコーディング名が1つのuser_nameにマップされます。user_nameは常に、その行の最初のjava_nameにマップされます。
|
注意: Tuxedo 6.5ユーザーは、InteroperateパラメータをYesに設定します。 |
ドメイン・ゲートウェイは、リモート・アクセス・ポイントから要求された受信時接続、およびローカル・アクセス・ポイントから要求された送信時接続を認証するように設定できます。アプリケーション管理者は、リモート・アクセス・ポイントからの受信時接続のセキュリティを強化する必要のある場合を定義できます。WTCサービスのローカルTuxedoアクセス・ポイント構成の「セキュリティ」タブでSecurity属性を設定すると、特定のローカル・アクセス・ポイントで使用するセキュリティのレベルを指定できます。パスワード・セキュリティには次のような3つのレベルがあります。
なし - リモート・アクセス・ポイントからの受信時接続は認証されません。
アプリケーション・パスワード - WTCサービスのリソース構成に定義されているアプリケーション・パスワードを使用して、リモート・アクセス・ポイントからの受信時接続が認証されます。暗号化されたアプリケーション・パスワードを作成するには、weblogic.wtc.gwt.genpasswdユーティリティを使用します。
ドメイン・パスワード - 2つ以上のアクセス・ポイント間のセキュリティが強化されます。ローカルおよびリモートのアクセス・ポイント間の接続は、WTCサービスのパスワード構成に定義されているパスワードのペアを使用して、認証されます。暗号化されたローカルおよびリモートのドメイン・パスワードを作成するには、weblogic.wtc.gwt.genpasswdユーティリティを使用します。
WTCサービスのローカルTuxedoアクセス・ポイントの「セキュリティ」タブのSecurity属性は、Tuxedoドメイン構成ファイルの*DM_LOCAL_DOMAINSセクションのSECURITY属性と一致していなければなりません。
認証が必要な場合、ローカル・アクセス・ポイントとリモート・アクセス・ポイント間で接続が確立されるたびに認証が行われます。
WTCサービスのローカルTuxedoアクセス・ポイントのセキュリティ・タイプが*DM_LOCAL_DOMAINSのセキュリティ・タイプと一致しない場合、またはパスワードが一致しない場合、接続は失敗します。
SECURITY=DM_PWの/Domainアーキテクチャでは、接続プリンシパルごとにパスワードが必要になります。2つのTDomainゲートウェイ間の各TDomainセッションには、関連付けられている独自の2つの接続プリンシパルがあります。それらはデフォルトではドメインIDで表されます。DM_PWを使用するデフォルトのセッション認証では、接続の両サイドで両方の接続プリンシパルに対して2つの秘密を構成することが必要になります。これにより、両サイドが相互に認証できます。次の例では、WTCおよびTuxedo両方の構成を示します。
WTCは次で構成されます:
DOMAIN ID WDOM1を持つローカル・アクセス・ポイントWDOM1
DOMAIN ID TDOM1を持つリモート・アクセス・ポイントTDOM1
セキュリティはDM_PW
Tuxedoは次で構成されます:
DOMAIN ID TDOM1を持つ独自のローカル・アクセス・ポイントTDOM1
DOMAIN ID WDOM1を持つリモート・アクセス・ポイントWDOM1
セキュリティはDM_PW
WTCで、TDOMAINセッション(WDOM1, TDOM1)に対するパスワードのペアを構成する必要があります。たとえば、TDOMAINセッション(WDOM1, TDOM1)に対するパスワードのペアは(pWDOM1, pTDOM1)のように表されます。Tuxedo TDOMAINで、TDOMAINセッション(TDOM1, WDOM1)に対するパスワードのペアを構成する必要があります。この場合、パスワードのペアは(pTDOM1, pWDOM1)となります。
PasswordKeyの割当て方法については、「Oracle WebLogic Tuxedo Connectorプロパティの設定方法」を参照してください。
このリリースのWebLogic Serverでは、必要に応じて、パスワードを256ビットのAESで暗号化できます。暗号化は、weblogic.wtc.gwt.genpasswdユーティリティの-Daesフラグを設定して行います(「暗号化されたパスワードの生成」を参照)。これは、TuxedoのGWTDOMAINプロセスでGWT_SNP_MINCRYPT環境変数をAESに設定するのと同じことです。
|
注意: Tuxedo 10におけるGWTDOMAINのAESサポートでは、tpusrファイルのパスワードは引続き元の暗号化方式で暗号化されます。tpusrファイルは通常、Tuxedoのネイティブ・ドメインで生成され、その後WTC (WLSドメインを経由)がアクセスできる場所にコピーされます。 |
暗号化されたパスワードの生成方法は以下のとおりです。
weblogic.wtc.gwt.genpasswdを使用して、ローカル・パスワード、リモート・パスワード、およびアプリケーション・パスワードの属性の暗号パスワードを生成します。このユーティリティは、キーを使用してWTCサービスのパスワード構成またはリソース構成にコピーされるパスワードを暗号化します。
WTCサービスのパスワード構成には、クリア・テキスト形式のパスワードは保存されません。
キー値は、WebLogic Serverプロパティです。
PasswordKey属性を使用してキーを割り当てます。
-Dweblogic.wtc.PasswordKey=mykey
ここで、mykeyはキー値です。
PasswordKey属性は、1つのキー値にのみ割り当てられます。このキー値は、指定されたWebLogic Serverで使用するため、生成されるすべてのOracle WebLogic Tuxedo Connector (ローカル、リモート、アプリケーション)パスワードに対して使用されます。
引数なしでユーティリティを呼び出し、コマンド・ライン・オプションを表示します。
例:
$ java weblogic.wtc.gwt.genpasswd Usage: genpasswd [-Daes] Key <LocalPassword|RemotePassword|AppPassword> <local|remote|application>
キー値、暗号化するパスワード、およびパスワード・タイプを指定してこのユーティリティを呼び出します。256ビットのAESでエンコードされたパスワードおよびパスワードIVを生成するには、-Daesフラグを含めます。
例:
$ java weblogic.wtc.gwt.genpasswd Key1 LocalPassword1 local
このユーティリティは、エンコードされたパスワードとパスワードIVを返します。返された結果を切り取り、WTCサービスのパスワード構成の適切なフィールドに貼り付けます。
Local Password : my_password Local Password IV: my_passwordIV
説明:
my_passwordで表された文字列を切り取り、Passwordフィールドに貼り付けます。
my_passwordIVで表された文字列を切り取り、PasswordIVフィールドに貼り付けます。
この節では、各パスワード要素タイプの例を紹介します。
次の例では、ローカル・アクセス・ポイントのパスワードとして「LocalPassword1」を暗号化するためにkey1を使用します。
$ java weblogic.wtc.gwt.genpasswd key1 LocalPassword1 local Local Password : FMTCg5Vi1mTGFds1U4GKIQQj7s2uTlg/ldBfy6Kb+yY= Local Password IV : NAGikshMiTE=
使用するパスワード属性は、次のとおりです。
Local Password: FMTCg5Vi1mTGFds1U4GKIQQj7s2uTlg/ldBfy6Kb+yY= Local Password IV: NAGikshMiTE=
次の例では、ローカル・アクセス・ポイントのパスワードとして「LocalPassword1」をエンコードするためにAES暗号化を使用します。
$ java weblogic.wtc.gwt.genpasswd -Daes LocalPassword1 local Local Password : 71Im/Y4VcuhInuN1My5wWRjIneu+KPR0aN1WBliwIq4= Local Password IV: a9qAjBpYExA=
使用するパスワード属性は、次のとおりです。
Local Password: 71Im/Y4VcuhInuN1My5wWRjIneu+KPR0aN1WBliwIq4= Local Password IV: a9qAjBpYExA=
次の例では、リモート・アクセス・ポイントのパスワードとして「RemotePassword1」を暗号化するためにmykeyを使用します。
$ java weblogic.wtc.gwt.genpasswd mykey RemotePassword1 remote Remote Password : A/DgdJYOJunFUFJa62YmPgsHan8pC02zPT0T7EigaVg= Remote Password IV : ohYHxzhYHP0=
使用するパスワード属性は、次のとおりです。
Remote Password: A/DgdJYOJunFUFJa62YmPgsHan8pC02zPT0T7EigaVg= Remote Password IV: ohYHxzhYHP0=
次の例では、アプリケーション・パスワードとして「test123」を暗号化するためにmykeyを使用します。
$ java weblogic.wtc.gwt.genpasswd mykey test123 application App Password : uou2MALQEZgNqt8abNKiC9ADN5gHDLviqO+Xt/VjakE= App Password IV : eQuKjOaPfCw=
使用するリソース属性は、次のとおりです。
Application Password: uou2MALQEZgNqt8abNKiC9ADN5gHDLviqO+Xt/VjakE= Application Password IV: eQuKjOaPfCw=
アクセス制御リスト(ACL)は、サービスを実行できるリモートTuxedoアクセス・ポイントを制限することによって、ローカル・アクセス・ポイントの内部にあるローカル・サービスへのアクセスを制限します。リモートTuxedoアクセス・ポイントからの着信ポリシーは、AclPolicy属性を使用して指定します。リモートTuxedoドメインへの発信ポリシーは、CredentialPolicy属性を使用して指定します。これによって、WebLogic ServerとTuxedoアプリケーションは同じセットのユーザーを共有でき、ユーザーはあるシステムから別のシステムへユーザーの資格証明を伝播できます。
AclPolicyおよびCredentialPolicyの有効な値は次のとおりです。
LOCAL
GLOBAL
Oracle WebLogic Tuxedo ConnectorのACLポリシーがLocalに設定されている場合、ローカル・サービスへのアクセスは、リモート・ユーザー資格証明には依存しません。Tuxedoリモート・アクセス・ポイントIDは、ローカルなWebLogic Serverユーザーとして認証されます。Oracle WebLogic Tuxedo ConnectorでDOMAINIDがローカル・ユーザーとして認証されるようにするには、WebLogic Serverコンソールを使用して、以下の手順を実行します。
WebLogic管理コンソールで、「セキュリティ・レルム」を選択します。
デフォルトのセキュリティ・レルムを選択します。
「レルム」設定ページで、「ユーザーとグループ」>「ユーザー」を選択します。
「ユーザー」表が表示されます。「ユーザー」表には、認証プロバイダで定義されているすべてのユーザーの名前が表示されます。
「新規作成」をクリックして、新しいユーザーを構成します。「新しいユーザーの作成」ページが表示されます。
「新しいユーザーの作成」ページで、以下の手順を行います。
「名前」フィールドにTuxedoのDOMAINIDを追加します。
パスワードを入力し、確認用にもう一度入力します。
「OK」をクリックします。「ユーザー」表にユーザー名が表示されます。
Oracle WebLogic Tuxedo ConnectorのACLポリシーがGLOBALになっている場合、ローカル・サービスへのアクセスは、リモート・ユーザー資格証明によって異なります。
CredentialPolicyがGLOBALに設定された状態でリモート・ドメインが実行されている場合、リクエストにはリモート・ユーザーの資格証明があります。そのため、ローカル・サービスにアクセスできるかどうかは、この資格証明によって異なります。
WTCのCredentialPolicyがGLOBALに設定されていると、WLSユーザーの資格証明はWTCからリモートTuxedoドメインに伝播されます。リモートTuxedoドメインでACL_POLICYがGLOBALに設定されている場合、リモートTuxedoドメインではWLSユーザーの資格証明が受け付けられ、Tuxedoサービスへのアクセスにはその資格証明が使用されます。リモートTuxedoドメインでACL_POLICYがLOCALに設定されている場合、リモートTuxedoドメインでは受信したWLSユーザーの資格証明は破棄され、TuxedoサービスへのアクセスにはWTC DOMAINIDが使用されます。
WTCのCredentialPolicyがLOCALに設定されていると、WLSユーザーの資格証明はリモートTuxedoドメインに伝播されません。リモートTuxedoアクセス・ポイントは、WTCドメインから受信したサービス要求のIDを、リモートTuxedoドメインのローカル・プリンシパル名で指定されたプリンシパル名に設定します。
以下の節では、Tuxedoにセキュリティ情報を提供するようにWebLogic Tuxedoを構成する方法について説明します。
TpUsrFileプラグインでは、シングル・ポイント・セキュリティ管理またはカスタム・セキュリティ認証を必要としないユーザー向けに、従来のTuxedo TpUsrFile機能が提供されます。TuxedoアプリケーションとWebLogic Serverアプリケーションの間でTpUsrFileプラグインのAppKeyジェネレータを使用してセキュリティを提供するようにOracle WebLogic Tuxedo Connectorを構成するには、次の手順に従います。
WTCサービスのローカルTuxedoアクセス・ポイントの「セキュリティ」タブのsecurity属性を、Tuxedoドメイン構成ファイルの*DM_LOCAL_DOMAINSセクションのSECURITYパラメータと一致するように設定します。
WTCサービスのリモートTuxedoアクセス・ポイントの「セキュリティ」タブを、着信および発信のアクセス制御リスト(ACL)ポリシーを確立するように構成します。
WebLogic Server環境を準備するには、次の手順を実行します。
AclPolicy属性をGLOBALに設定します。
CredentialPolicy属性をGLOBALに設定します。
環境の「匿名を許可」属性を設定します。匿名ユーザーによるTuxedoへのアクセスを許可する場合は、匿名ユーザーが使用する「デフォルトAppKey」の値を設定する必要があります。匿名ユーザーの詳細は、「匿名ユーザー」を参照してください。
「AppKeyジェネレータ」ドロップダウン・ボックスから「TpUsrFile」を選択します。
「TPユーザー・ファイル」属性の値をユーザー・パスワード・ファイルの絶対パスに設定します。
WebLogic Server環境にTuxedo tpusrファイルのコピーが必要です。TUXEDOからWebLogic Serverアプリケーション環境にtpusrファイルをコピーするか、独自のtpusrファイルを生成します。Tuxedo tpusrファイル作成方法の詳細は、「ユーザー・レベルの認証によるセキュリティを有効にする方法」を参照してください。
TpUsrFileの場所は、リモートTuxedoアクセス・ポイント構成またはリソース構成から指定できます。TpUsrFile属性の値の割当ては、リモートTuxedoアクセス・ポイントのすべての構成で個別に行うよりも、WTCサービス・レベルでグローバルに行う方が簡単です。TpUsrFile属性の構成に最も適した場所を決定するには、次のガイドラインに従ってください。
AppKeyジェネレータとしてTpUsrFileプラグインが選択されていないと、場所とは無関係にTpUsrFile属性の値はすべて無視されます。
リソース構成にTpUsrFile属性の値がない場合は、リモートTuxedoアクセス・ポイントの構成にTpUsrFile属性の値を指定する必要があります。キャッシュされたユーザー・レコード情報は無視されます。
リソースとリモートTuxedoアクセス・ポイントの両方の構成にTpUsrFile属性の値が含まれている場合は、リモートTuxedoアクセス・ポイントにある属性値が使用されます。キャッシュされたユーザー・レコード情報は無視されます。
リモートTuxedoアクセス・ポイントの構成にTpUsrFile属性の値がない場合は、リソース構成にTpUsrFile属性の値を指定する必要があります。キャッシュされたユーザー・レコードが使用され、システムのパフォーマンスが向上します。ただし、その場合、すべてのリモートTuxedoアクセス・ポイントでユーザーが同じIDを持つように制限されます。
LDAPプラグインではシングル・ポイント・セキュリティ管理が提供され、WebLogic Server組込みLDAPサーバーでのユーザー・セキュリティ情報の管理、およびWebLogic Serverコンソールを使用した単一システムからのセキュリティ情報の管理が可能になります。Tuxedo 8.1以降が必要です。TuxedoアプリケーションとWebLogic Serverアプリケーションの間でLDAPプラグインのAppKeyジェネレータを使用してセキュリティを提供するようにOracle WebLogic Tuxedo Connectorを構成するには、次の手順に従います:
シングル・ポイント・セキュリティ管理の実装方法の詳細は、「シングル・ポイント・セキュリティ管理の実装」を参照してください。WebLogicセキュリティの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』を参照してください。
WTCサービスのローカルTuxedoアクセス・ポイントの「セキュリティ」タブのsecurity属性を、Tuxedoドメイン構成ファイルの*DM_LOCAL_DOMAINSセクションのSECURITYパラメータと一致するように設定します。
WTCサービスのリモートTuxedoアクセス・ポイントの「セキュリティ」タブを、着信および発信のアクセス制御リスト(ACL)ポリシーを確立するように構成します。
WebLogic Server環境を準備するには、次の手順を実行します。
AclPolicy属性をGLOBALに設定します。
CredentialPolicy属性をGLOBALに設定します。
環境の「匿名を許可」属性を設定します。匿名ユーザーによるTuxedoへのアクセスを許可する場合は、匿名ユーザーが使用する「デフォルトAppKey」の値を設定する必要があります。匿名ユーザーの詳細は、「匿名ユーザー」を参照してください。
「AppKeyジェネレータ」ドロップダウン・ボックスから「LDAP」を選択します。
必要に応じて、「Tuxedo UIDキーワード」属性および「Tuxedo GIDキーワード」属性の値を設定します。これらの値には、デフォルト値が提供されています。TuxedoユーザーID (UID)のこれらのキーワードは、組込みLDAPデータベースのユーザー・レコードにあるTuxedo UIDおよびTuxedo GIDを抽出するために使用されます。
カスタム・プラグインを使用すると、カスタマイズされたセキュリティ認証を作成できます。TuxedoアプリケーションとWebLogic Serverアプリケーションの間でカスタム・プラグインのAppKeyジェネレータを使用してセキュリティを提供するようにOracle WebLogic Tuxedo Connectorを構成するには、次の手順に従います:
カスタム・プラグインの作成方法については、『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connectorプログラマーズ・ガイド』の「カスタムAppKeyプラグインの作成方法」を参照してください。
WTCサービスのローカルTuxedoアクセス・ポイントの「セキュリティ」タブのsecurity属性を、Tuxedoドメイン構成ファイルの*DM_LOCAL_DOMAINSセクションのSECURITYパラメータと一致するように設定します。
WTCサービスのリモートTuxedoアクセス・ポイントの「セキュリティ」タブを、着信および発信のアクセス制御リスト(ACL)ポリシーを確立するように構成します。
WebLogic Server環境を準備するには、次の手順を実行します。
AclPolicy属性をGLOBALに設定します。
CredentialPolicy属性をGLOBALに設定します。
環境の「匿名を許可」属性を設定します。匿名ユーザーによるTuxedoへのアクセスを許可する場合は、匿名ユーザーが使用する「デフォルトAppKey」の値を設定する必要があります。匿名ユーザーの詳細は、「匿名ユーザー」を参照してください。
「AppKeyジェネレータ」ドロップダウン・ボックスから「Custom」を選択します。
「カスタムAppKeyクラス」属性の値を、カスタムAppKeyジェネレータ・クラスの絶対パスに設定します。このクラスは、WTCサービスの開始時にロードされます。
WTCサービスの開始時、AppKeyクラスが初期化されるときにカスタムAppKeyクラスを使用するには、「カスタムAppKeyパラメータ」属性の値を、必要なパラメータ(オプション)に設定します。
リモートTuxedoアクセス・ポイントの「セキュリティ」タブの「匿名を許可」属性では、匿名ユーザーによるTuxedoへのアクセスを許可するかどうかを指定します。匿名ユーザーによるTuxedoへのアクセスを許可する場合、TpUsrFileとLDAPのAppKeyプラグインには「デフォルトAppKey」属性の値が使用されます。TpUsrFileプラグインとLDAPプラグインでは、「匿名を許可」属性が有効な場合以外は、ユーザー・データベースに定義されていないユーザーによるTuxedoへのアクセスが許可されません。カスタムAppKeyプラグインとの対話は、カスタムAppKeyジェネレータの設計に応じて異なります。
「デフォルトAppKey」のデフォルト値は -1です。この値を使用する場合は、このキー値に割り当てられているユーザーがTuxedo環境に存在することを確認する必要があります。「デフォルトAppKey」の値を0にしないでください。一部のシステムでは、0はユーザーをルートに指定します。
ATMIサービスとCORBAサービスによる匿名ユーザーの認証方法の違いを理解しておく必要があります。ATMIサービスは、メッセージと共に送信される「デフォルトAppKey」の値を使用します。CORBAサービスは、デフォルトのWebLogic Server匿名ユーザー名である<anonymous>を使用して、Tuxedo tpusrファイルに定義されているユーザーの資格証明を識別します。CORBAを使用する場合に、認証されたユーザーになるには次のいずれかの方法を使用して匿名ユーザーを構成する必要があります。
Tuxedo tpusrファイルに「anonymous」を追加します。
WebLogic認証プロバイダにanonymousをユーザーとして定義します。WebLogic Serverのインスタンスを起動するときに、以下の引数を設定して定義します。
-Dweblogic.security.anonymousUserName=anonymous
データの機密性を守るために暗号化を使用できます。これによって、ネットワーク・ベースの傍受者は、あるドメイン・ゲートウェイから別のドメイン・ゲートウェイに送信されるメッセージやアプリケーション生成メッセージの内容を知ることができなくなります。このセキュリティ・メカニズムを構成するには、WTCサービスのリモートTuxedoアクセス・ポイント構成の「セキュリティ」タブでMINENCRYPTBITS属性およびMAXENCRYPTBITS属性を設定します。
このリリースのWebLogic Serverでは、信頼性のある認証局や秘密鍵の利用など、ドメイン間通信のセキュリティを実現するセキュア・ソケット・レベル(SSL)の暗号化がサポートされています。このセキュリティ・メカニズムを構成するには、WTCサービスのリモートTuxedoアクセス・ポイント構成およびローカルTuxedoアクセス・ポイント構成で、「セキュリティ」タブのMINENCRYPTBITS属性およびMAXENCRYPTBITS属性を設定し、またSSL構成およびKeyStore構成の属性を設定します。Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある以下のトピックを参照してください。
このリリースのWTCでは、SSLの再ネゴシエーションはサポートされていません。WTCと通信するすべてのTUXEDOリモート・アクセス・ポイントでは、再ネゴシエーション機能を無効にする必要があります。デフォルトでは、GWTDOMAINのSSL再ネゴシエーションは無効になっています。
