|
|
| 注意 : | WebLogic Tuxedo Connector を含む WebLogic Server 管理の詳細については、『WebLogic Server MBean リファレンス』を参照してください。 |
以下の節では、接続の確立方法および WebLogic Server アプリケーションと Tuxedo 環境の間にセキュリティを提供する方法について説明します。WebLogic Tuxedo Connector では、Tuxedo アクセス ポイント間の通信に必要な相互運用属性に類似した属性を使用します。
以下の節では、WebLogic Tuxedo Connector のコンフィグレーション情報について説明します。
アクセス ポイントがリモート アクセス ポイントとの接続を確立する条件を指定できるオプションがいくつかあります。これらの条件は、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 はすべてのリモート アクセス ポイント定義を処理し、次の表に示されているように実際の接続ポリシーを決定します。
次の表に、ローカル アクセス ポイントの接続ポリシー、リモート アクセス ポイントの接続ポリシー、およびリモート ドメインにおけるこれらのパラメータの設定の明確な相互関係を示します。
On Startup のポリシーは、ゲートウェイ サーバの初期化時に、アクセス ポイントがリモート アクセス ポイントを使用して接続を確立することを示します。この接続ポリシーは、RetryInterval パラメータと MaxRetries パラメータで指定された一定の間隔で、エラーとなった接続を再試行します。起動時に接続を要求するには、ローカル Tuxedo アクセス ポイントの [接続] タブで ConnectionPolicy 属性を On Startup に設定します。
自動接続の試行の頻度は、接続を再試行する前にアクセス ポイントが待機する間隔 (秒) を指定することによって制御できます。最小値は 0、デフォルト値は 60、そして最大値は 2147483647 です。
| 注意 : | ConnectionPolicy が On Startup に設定されているときだけ使用してください。他の接続ポリシーの場合、再試行処理は無効になります。 |
MaxRetries パラメータに値を割り当てることによって、アクセス ポイントが終了するまでにリモート アクセス ポイントへの接続を試行する回数を指定します。最小値は 0、デフォルトおよび最大値は 2147483647 です。
| 注意 : | ローカル アクセス ポイントの ConnectionPolicy を指定しない場合、WebLogic Tuxedo Connector は On Demand の ConnectionPolicy を使用します。 |
On Demand の接続ポリシーは、リモート サービスに対するクライアント リクエスト、または管理接続開始コマンドのいずれかによって要求されたときのみに、接続が試行されることを示します。
Incoming Only の接続ポリシーは、アクセス ポイントが起動時にリモート アクセス ポイントへの接続を確立しないことを示します。アクセス ポイントは、リモート アクセス ポイントからの接続リクエストの受信時に使用できます。
| 注意 : | LOCAL の ConnectionPolicy は、ローカル アクセス ポイントでは無効です。 |
LOCAL の接続ポリシーは、リモート ドメインの接続ポリシーが明示的にローカル ドメインの ConnectionPolicy 属性値にデフォルト設定されることを示します。リモート アクセス ポイントの ConnectionPolicy が定義されていない場合、システムは関連するローカル アクセス ポイントで指定されている設定を使用します。
| 注意 : | Tuxedo T/ Domain では、バックアップ リモート アクセス ポイントは 2 つに制限されています。WebLogic Tuxedo Connector には、サーバにコンフィグレーションできるバックアップ アクセス ポイントの数に制限はありません。 |
WebLogic Tuxedo Connector が提供するフェイルオーバは、プライマリ リモート アクセス ポイントでエラーが発生したとき、代替リモート アクセス ポイントにリクエストを転送するメカニズムです。このフェイルオーバは、アクセス ポイントが復元されると、プライマリ リモート アクセス ポイントにフェイルバックします。このレベルのフェイルオーバおよびフェイルバックは、接続ステータスに依存します。フェイルオーバとフェイルバックを有効にするには、アクセス ポイントが On Startup または Incoming Only の接続ポリシーでコンフィグレーションされている必要があります。
フェイルオーバまたはフェイルバックを使用するには、Connection Policy パラメータの値に ON_STARTUP または INCOMING_ONLY を指定する必要があります。
On Demand の接続ポリシーは、リモート アクセス ポイントが常に使用可能であることを想定して動作するため、フェイルバックには適しません。接続ポリシーとして ON_STARTUP または INCOMING_ONLY を指定しないと、サーバは Tuxedo の RDOM パラメータを使用して指定した代替リモート アクセス ポイントにフェイルオーバできません。
| 注意 : | リモート アクセス ポイントはそれに対するネットワーク接続があれば「使用可能」であり、それに対するネットワーク接続がなければ「使用不可能」です。 |
フェイルオーバをサポートするには、特定のサービスを実行する責任を持つリモート アクセス ポイントを指定する必要があります。WTC サービスで、以下の項目を指定する必要があります。
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><wtc-export>
<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>
<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></wtc-import>
<remote-access-point-list>TDOM1,TDOM3</remote-access-point-list>
<remote-name>TOUPPER</remote-name>
<wtc-import>
<name>imp1</name>
<resource-name>TOUPPER</resource-name><local-access-point>TDOM2</local-access-point></wtc-server>
<name>2ndImportedResources</name>
<remote-access-point-list>TDOM3,TDOM1</remote-access-point-list>
<remote-name>TOUPPER</remote-name>
</wtc-import>
フェイルバックは、プライマリ リモート アクセス ポイントへのネットワーク接続が、次の理由で再確立された場合に発生します。
リンクレベルのフェイルオーバをサポートするには、WTCRemoteTuxDomMBean および WTCLocalTuxDomMBean 定義で、カンマで区切られた構文 <nw-addr> XML タグで正しいフェイルオーバ シーケンス情報を指定する必要があります。ネットワーク アドレスの順序によって、フェイルオーバの優先順位が決まります。
| 注意 : | XML タグの値は、正しい構文であるかどうかチェックされます。構文が正しくない場合、InvalidAttributeException が送出されます。 |
リンクレベルのフェイルオーバのセマンティックは、レイト バインディングです。つまり、MBean 作成時に、有無や可用性はチェックされません。これは、WTC コンフィグレーションの作成後、かつ TDomain セッション接続の作成前に、ユーザが DNS をマシンに追加できるようにするためです。
config.xml での正しい構文は、次のように <nw-addr> XML タグのカンマで区切られた構文を使用します。
<nw-addr>//host1:4001</nw-addr> --> ホスト 1 つのみ、リンクレベルのフェイルオーバはなし <nw-addr>//host1:4001,//host2:4001</nw-addr> --> host2 にフェイルオーバできる <nw-addr>//host1:4001,//host2:4001,//host3:4001</nw-addr> --> host 1 から host2 にフェイルオーバできる。host2 が使用可能でない場合は 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 番目の候補です。
<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 クラスを使用し、Java と GNU アイコンの間のエンコーディング名のマップにマップ ファイルを使用します。このマップ ファイルは、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 つのレベルがあります。
weblogic.wtc.gwt.genpasswd ユーティリティを使用します。weblogic.wtc.gwt.genpasswd ユーティリティを使用します。
WTC サービスのローカル Tuxedo アクセス ポイントの [セキュリティ] タブの Security 属性は、Tuxedo ドメイン コンフィグレーション ファイルの *DM_LOCAL_DOMAINS セクションの SECURITY 属性と一致していなければなりません。
| 注意 : | PasswordKey の割り当て方法については、「WebLogic Tuxedo Connector プロパティの設定方法」を参照してください。 |
SECURITY=DM_PW の /Domain アーキテクチャでは、接続プリンシパルごとにパスワードが必要になります。2 つの TDomain ゲートウェイ間の各 TDomain セッションには、関連付けられている独自の 2 つの接続プリンシパルがあります。それらはデフォルトではドメイン ID で表されます。DM_PW を使用するデフォルトのセッション認証では、接続の両サイドで両方の接続プリンシパルに対して 2 つの秘密をコンフィグレーションすることが必要になります。これにより、両サイドが相互に認証できます。次の例では、WTC および Tuxedo 両方のコンフィグレーションを示します。
WTC で、TDOMAIN セッション (WDOM1, TDOM1) に対するパスワードのペアをコンフィグレーションする必要があります。たとえば、TDOMAIN セッション (WDOM1, TDOM1) に対するパスワードのペアは (pWDOM1, pTDOM1) のように表されます。Tuxedo TDOMAIN で、TDOMAIN セッション (TDOM1, WDOM1) に対するパスワードのペアをコンフィグレーションする必要があります。この場合、パスワードのペアは (pTDOM1, pWDOM1) となります。
weblogic.wtc.gwt.genpasswd を使用して、ローカル パスワード、リモート パスワード、およびアプリケーション パスワードの属性の暗号パスワードを生成します。このユーティリティは、キーを使用して WTC サービスのパスワード コンフィグレーションまたはリソース コンフィグレーションにコピーされるパスワードを暗号化します。
引数なしでユーティリティを呼び出し、コマンドライン オプションを表示します。
$ java weblogic.wtc.gwt.genpasswd
使い方 : genpasswd Key <LocalPassword|RemotePassword|AppPassword> <local|remote|application>
キー値、暗号化するパスワード、およびパスワード タイプを指定してこのユーティリティを呼び出します。
$ java weblogic.wtc.gwt.genpasswd Key1 LocalPassword1 local
このユーティリティは、エンコードされたパスワードとパスワード IV を返します。返された結果を切り取り、WTC サービスのパスワード コンフィグレーションの適切なフィールドに貼り付けます。
[ローカル パスワード] : my_password
[ローカル パスワード IV] : my_passwordIV
次の例では、ローカル アクセス ポイントのパスワードとして「LocalPassword1」を暗号化するために key1 を使用します。
$ java weblogic.wtc.gwt.genpasswd key1 LocalPassword1 local
Local Password : FMTCg5Vi1mTGFds1U4GKIQQj7s2uTlg/ldBfy6Kb+yY=
Local Password IV : NAGikshMiTE=
[ローカル パスワード] : FMTCg5Vi1mTGFds1U4GKIQQj7s2uTlg/ldBfy6Kb+yY=
Local Password IV: NAGikshMiTE=
次の例では、リモート アクセス ポイントのパスワードとして「RemotePassword1」を暗号化するために mykey を使用します。
$ java weblogic.wtc.gwt.genpasswd mykey RemotePassword1 remote
Remote Password : A/DgdJYOJunFUFJa62YmPgsHan8pC02zPT0T7EigaVg=
Remote Password IV : ohYHxzhYHP0=
[リモート パスワード] : 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=
[アプリケーション パスワード] : uou2MALQEZgNqt8abNKiC9ADN5gHDLviqO+Xt/VjakE=
Application Password IV: eQuKjOaPfCw=
アクセス制御リスト (ACL) は、サービスを実行できるリモート Tuxedo アクセス ポイントを制限することによって、ローカル アクセス ポイントの内部にあるローカル サービスへのアクセスを制限します。リモート Tuxedo アクセス ポイントからの着信ポリシーは、AclPolicy 属性を使用して指定します。リモート Tuxedo ドメインへの発信ポリシーは、CredentialPolicy 属性を使用して指定します。これによって、WebLogic Server と Tuxedo アプリケーションは同じセットのユーザを共有でき、ユーザはあるシステムから別のシステムへユーザの資格を伝播できます。
AclPolicy および CredentialPolicy の有効な値は次のとおりです。
WebLogic Tuxedo Connector の ACL ポリシーが Local に設定されている場合、ローカル サービスへのアクセスは、リモート ユーザ資格には依存しません。Tuxedo リモート アクセス ポイント ID は、ローカルな WebLogic Server ユーザとして認証されます。WebLogic Tuxedo Connector で DOMAINID がローカル ユーザとして認証されるようにするには、WebLogic Server コンソールを使用して、以下の手順を実行します。
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 6.5 ユーザは、Interoperate パラメータを Yes に設定します。AclPolicy 要素と CredentialPolicy 要素は無視され、Tuxedo リモート アクセス ポイント ID は、ローカル WebLogic Server ユーザとして認証されます。ユーザ セキュリティ機能が必要で、かつ WebLogic Tuxedo Connector を使用する場合は、Tuxedo 7.1 以上にアップグレードする必要があります。
以下の節では、Tuxedo にセキュリティ情報を提供するように WebLogic Tuxedo をコンフィグレーションする方法について説明します。
TpUsrFile プラグインでは、シングル ポイント セキュリティ管理またはカスタム セキュリティ認証を必要としないユーザ向けに、従来の Tuxedo TpUsrFile 機能が提供されます。Tuxedo アプリケーションと WebLogic Server アプリケーションの間で TpUsrFile プラグインの AppKey ジェネレータを使用してセキュリティを提供するように WebLogic Tuxedo Connector をコンフィグレーションするには、次の手順に従います。
WTC サービスのローカル Tuxedo アクセス ポイントの [セキュリティ] タブの security 属性を、Tuxedo ドメイン コンフィグレーション ファイルの *DM_LOCAL_DOMAINS セクションの SECURITY パラメータと一致するように設定します。
WTC サービスのリモート Tuxedo アクセス ポイントの [セキュリティ] タブを、着信および発信のアクセス制御リスト (ACL) ポリシーを確立するようにコンフィグレーションします。
WebLogic Server 環境を準備するには、次の手順を実行します。
GLOBAL に設定します。GLOBAL に設定します。 TpUsrFile] を選択します。
WebLogic Server 環境に Tuxedo tpusr ファイルのコピーが必要です。TUXEDO から WebLogic Server アプリケーション環境に tpusr ファイルをコピーするか、独自の tpusr ファイルを生成します。Tuxedo tpusr ファイル作成方法の詳細については、「ユーザ・レベルの認証によるセキュリティを有効にする方法」を参照してください。
TpUsrFile の場所は、リモート Tuxedo アクセス ポイント コンフィグレーションまたはリソース コンフィグレーションから指定できます。TpUsrFile 属性の値の割り当ては、リモート Tuxedo アクセス ポイントのすべてのコンフィグレーションで個別に行うよりも、WTC サービス レベルでグローバルに行う方が簡単です。TpUsrFile 属性のコンフィグレーションに最も適した場所を決定するには、次のガイドラインに従ってください。
LDAP プラグインではシングル ポイント セキュリティ管理が提供され、WebLogic Server 組み込み LDAP サーバでのユーザ セキュリティ情報の管理、および WebLogic Server Console を使用した単一システムからのセキュリティ情報の管理が可能になります。Tuxedo 8.1 以降が必要です。Tuxedo アプリケーションと WebLogic Server アプリケーションの間で LDAP プラグインの AppKey ジェネレータを使用してセキュリティを提供するように WebLogic Tuxedo Connector をコンフィグレーションするには、次の手順に従います。
シングル ポイント セキュリティ管理の実装方法の詳細については、「シングル・ポイント・セキュリティ管理のインプリメント」を参照してください。WebLogic セキュリティの詳細については、『WebLogic Security について』を参照してください。
WTC サービスのローカル Tuxedo アクセス ポイントの [セキュリティ] タブの security 属性を、Tuxedo ドメイン コンフィグレーション ファイルの *DM_LOCAL_DOMAINS セクションの SECURITY パラメータと一致するように設定します。
WTC サービスのリモート Tuxedo アクセス ポイントの [セキュリティ] タブを、着信および発信のアクセス制御リスト (ACL) ポリシーを確立するようにコンフィグレーションします。
WebLogic Server 環境を準備するには、次の手順を実行します。
GLOBAL に設定します。GLOBAL に設定します。 LDAP] を選択します。| 注意 : | カスタム プラグインの作成方法については、「カスタム AppKey プラグインの作成方法」を参照してください。 |
カスタム プラグインを使用すると、カスタマイズされたセキュリティ認証を作成できます。Tuxedo アプリケーションと WebLogic Server アプリケーションの間でカスタム プラグインの AppKey ジェネレータを使用してセキュリティを提供するように WebLogic Tuxedo Connector をコンフィグレーションするには、次の手順に従います。
WTC サービスのローカル Tuxedo アクセス ポイントの [セキュリティ] タブの security 属性を、Tuxedo ドメイン コンフィグレーション ファイルの *DM_LOCAL_DOMAINS セクションの SECURITY パラメータと一致するように設定します。
WTC サービスのリモート Tuxedo アクセス ポイントの [セキュリティ] タブを、着信および発信のアクセス制御リスト (ACL) ポリシーを確立するようにコンフィグレーションします。
WebLogic Server 環境を準備するには、次の手順を実行します。
GLOBAL に設定します。GLOBAL に設定します。 Custom] を選択します。
リモート Tuxedo アクセス ポイントの [セキュリティ] タブの [匿名を許可] 属性では、匿名ユーザによる Tuxedo へのアクセスを許可するかどうかを指定します。匿名ユーザによる Tuxedo へのアクセスを許可する場合、TpUsrFile と LDAP の AppKey プラグインには [デフォルト AppKey] 属性の値が使用されます。TpUsrFile プラグインと LDAP AppKey プラグインでは、[匿名を許可] 属性が有効な場合以外は、ユーザ データベースに定義されていないユーザによる Tuxedo へのアクセスが許可されません。カスタム AppKey プラグインとの対話は、カスタム AppKey ジェネレータの設計に応じて異なります。
[デフォルト AppKey] のデフォルト値は -1 です。この値を使用する場合は、このキー値に割り当てられているユーザが Tuxedo 環境に存在することを確認する必要があります。[デフォルト AppKey] の値を 0 にしないでください。一部のシステムでは、0 はユーザをルートに指定します。
ATMI サービスと CORBA サービスによる匿名ユーザの認証方法の違いを理解しておく必要があります。ATMI サービスは、メッセージと共に送信される [デフォルト AppKey] の値を使用します。CORBA サービスは、デフォルトの WebLogic Server 匿名ユーザ名である「anonymous」を使用して、Tuxedo tpusr ファイルに定義されているユーザの資格を識別します。CORBA を使用する場合に、認証されたユーザになるには次のいずれかの方法を使用して匿名ユーザをコンフィグレーションする必要があります。
データの機密性を守るために暗号化を使用できます。これによって、ネットワークベースの傍受者は、あるドメイン ゲートウェイから別のドメイン ゲートウェイに送信されるメッセージやアプリケーション生成メッセージの内容を知ることができなくなります。このセキュリティ メカニズムをコンフィグレーションするには、WTC サービスのリモート Tuxedo アクセス ポイント コンフィグレーションの [セキュリティ] タブで MINENCRYPTBITS 属性および MAXENCRYPTBITS 属性を設定します。
| 注意 : | 暗号を使用するには、適切なライセンスが必要です。ライセンス要件の詳細については、「ライセンス」を参照してください。 |
  
|
