![]() ![]() ![]() ![]() ![]() ![]() ![]() |
注意: | Oracle Tuxedo CORBA JavaクライアントとOracle Tuxedo CORBA JavaクライアントORBはTuxedo 8.1で非推奨になり、サポートされなくなりました。 Oracle Tuxedo CORBA JavaクライアントおよびOracle Tuxedo CORBA JavaクライアントORBのテキスト参照、関連するコード・サンプルはすべてサードパーティのJava ORBライブラリの実装/実行の簡易化とプログラマによる参照だけに使用する必要があります。 |
注意: | サード・パーティのCORBA Java ORBのテクニカル・サポートは、各ベンダーによって提供されます。 Oracle Tuxedoでは、サード・パーティのCORBA Java ORBに関する技術的なサポートやドキュメントは提供していません。 |
注意: | 認証サーバーを構成する必要があるのは、SECURITY パラメータにUSER_AUTH 以上の値を指定し、デフォルトの認証プラグインを使用する場合だけです。 |
認証を行うには、ユーザーの個々のパスワードを正当なユーザーのファイルと照合することでユーザーを認証するための認証サーバーを構成する必要があります。Oracle Tuxedoシステムでは、AUTHSRV
というデフォルトの認証サーバーを使用して認証を実行します。AUTHSVR
は、認証を実行するAUTHSVC
というサービスだけを提供します。セキュリティ・レベルがACL
またはMANDATORY_ACL
に設定されている場合、AUTHSVR
サーバーは、AUTHSVC
をAUTHSVC
として公開します。
CORBAアプリケーションがユーザーを認証するには、UBBCONFIG
ファイルのRESOURCES
セクションのAUTHSVC
パラメータの値として、CORBAアプリケーションの認証サーバーとして使用するプロセスの名前を指定する必要があります。 サービスは、AUTHSVC
と呼ばれます。 AUTHSVC
パラメータをUBBCONFIG
ファイルのRESOURCES
セクションに指定した場合、SECURITY
パラメータも少なくともUSER_AUTH
に指定する必要があります。 この値を指定しない場合、tmloadcf
コマンドが実行されたときにエラーが発生します。 -m
オプションをUBBCONFIG
ファイルのISL
プロセスで構成する場合、AUTHSVC
は、ISL
プロセスの前に、UBBCONFIG
ファイルに定義する必要があります。
また、UBBCONFIG
ファイルのSERVERS
セクションでAUTHSVR
を定義する必要があります。 SERVERS
セクションには、CORBAアプリケーションで起動するサーバー・プロセスに関する情報が格納されます。 AUTHSVC
をアプリケーションに追加するには、UBBCONFIG
ファイルで、認証サービスとしてAUTHSVC
を定義し、認証サーバーとしてAUTHSVR
を定義する必要があります。 リスト7-1は、UBBCONFIG
ファイルで認証サーバーを定義する部分です。
*RESOURCES
SECURITY USER_AUTH
AUTHSVC “AUTHSVC”
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name
" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
パラメータと値の組合せであるAUTHSVC
のエントリを省略すると、Oracle TuxedoシステムはデフォルトでAUTHSVC
を呼び出します。
AUTHSVR
は、アプリケーション固有のロジックを実装する認証サーバーと置き換えることができます。 たとえば、広く使用されているKerberosのメカニズムを使用して認証を行うため、認証サーバーをカスタマイズすることもできます。
カスタマイズした認証サービスをアプリケーションに追加するには、UBBCONFIG
ファイルで認証サービスと認証サーバーを定義する必要があります。 たとえば、次のように入力します。
*RESOURCES
SECURITY USER_AUTH
AUTHSVC KERBEROS
.
.
.
*SERVERS
KERBEROSSVR SRVGRP="group_name
" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
デフォルトの認証サーバーを構成したら、IIOPリスナー/ハンドラのID (UBBCONFIG
ファイルのSEC_PRINCIPAL_NAME
パラメータで指定)をtpusr
ファイルで指定する必要があります。また、CORBAアプリケーションのすべてのユーザーをtpusr
ファイルで指定する必要があります。詳細は、「認可されたユーザーの定義」を参照してください。
CORBAアプリケーションのセキュリティ構成の中で、CORBAアプリケーションに対するアクセス権を持つプリンシパルおよびプリンシパル・グループを定義する必要があります。
認可されたプリンシパルのリストが格納されたファイルを作成するには、tpusradd
コマンドを使用します。 tpusradd
コマンドは、新しいプリンシパルをOracle Tuxedoのセキュリティ・データ・ファイルに追加します。 この情報は、認証サーバーがプリンシパルを認証する場合に使用します。 プリンシパルが格納されたファイルはtpusr
と呼ばれます。
ファイルはコロン区切りのフラットなASCIIファイルで、CORBAアプリケーションのシステム管理者だけが読取り可能です。 システム・ファイルのエントリは、1行あたり512文字までです。 ファイルはアプリケーション・ディレクトリに格納され、環境変数の$APPDIR
で指定されます。 環境変数$APPDIR
には、CORBAアプリケーションのパス名を設定する必要があります。
tpusradd
ファイルは、管理者アカウントで所有する必要があります。このファイルを保護して、ファイルのオーナーだけが読み書き権限を持つようにすることをお薦めします。
-u
uid
ユーザーのID番号。 UIDは、128K以下の正の10進整数でなければなりません。 また、アプリケーションの既存の識別子リスト内でユニークでなければなりません。 UIDは、次に利用可能な(ユニークな) 0より大きい識別子にデフォルト設定されます。
-g
gid
グループのID番号。 GIDは、整数識別子または文字列名です。 このオプションは、新しいユーザーのグループ・メンバーシップを定義します。 デフォルトでは、other
グループ(識別子0)となります。
-c
client_name
プリンシパル名を指定する出力可能な文字列。 名前には、コロン(:)、シャープ記号(#)、改行文字(\n)を使用できません。 プリンシパル名はCORBAアプリケーションの既存のプリンシパル・リスト内でユニークでなければなりません。
usrname
ユーザーの新規ログイン名を指定する出力可能な文字列。 名前には、コロン(:)、シャープ記号(#)、改行文字(\n)を使用できません。 ユーザー名はCORBAアプリケーションの既存のユーザー・リスト内でユニークでなければなりません。
デフォルトの認証サーバーを使用する場合、IIOPリスナー/ハンドラのID (UBBCONFIG
ファイルのSEC_PRINCIPAL_NAME
パラメータで指定)をtpusr
ファイルで指定する必要があります。 また、CORBAアプリケーションのすべてのユーザーをtpusr
ファイルで指定する必要があります。
カスタム認証サービスを使用する場合、IIOPリスナー/ハンドラおよびCORBAアプリケーションのユーザーを、カスタム認証サービスのユーザー・レジストリで定義します。 また、tpusr
というファイルが$APPDIR
に指定されていてはなりません。 この名前のファイルが指定されていた場合、CORBA/NO_PERMISSION
例外が生成されます。
リスト7-2に、tpusr
ファイルの例を示します。
Usrname Cltname Password Entry Uid GID
milozzi “bar” 2 100 0
smart “ “ 1 1 0
pat “tpsysadmin” 3 0 8192
butler “tpsysadmin” 3 N/A 8192
注意: | Oracle Tuxedoのセキュリティ・データ・ファイルにプリンシパル・グループを追加するには、tpgrpadd コマンドを使用します。 |
tpusradd
およびtpgrpadd
コマンド以外にも、Oracle Tuxedo製品には、tpusr
およびtpgrp
ファイルを変更するための次のコマンドが用意されています。
コマンドの説明については、Oracle Tuxedoオンライン・ドキュメントの『Oracle Tuxedoコマンド・リファレンス』を参照してください。
ホスト・システムには、ユーザーとグループのリストを格納したファイルがすでに存在する場合があります。これらのファイルをCORBAアプリケーションのユーザー・ファイルおよびグループ・ファイルとして使用するには、Oracle Tuxedoシステムで受け付けられる形式に変換する必要があります。ファイルを変換するには、次の手順例に示すように、tpaclcvt
コマンドを実行します。この手順例は、UNIXホスト・マシン用に記述されています。
注意: | シャドウ・パスワード・ファイルを使用するシステムでは、ファイル内のユーザーごとにパスワードの入力が要求されます。 |
CORBAアプリケーションのセキュリティ定義の中で、UBBCONFIG
ファイルのRESOURCES
セクションのSECURITY
パラメータを定義する必要があります。 SECURITY
パラメータの形式は次のとおりです。
*RESOURCES
SECURITY {NONE|APP_PW|USER_AUTH|ACL|MANDATORY_ACL}
表7-1では、SECURITY
パラメータの値について説明します。
注意: | IIOPリスナー/ハンドラが証明書による認証を使用するように構成されている場合、SECURITY パラメータの値はUSER_AUTH 以上でなければなりません。 |
アプリケーション・パスワードによるセキュリティを構成するには、以下の手順に従います。
MASTER
マシンで作業しており、アプリケーションが非アクティブであることを確認します。UBBCONFIG
ファイルのRESOURCES
セクションのSECURITY
パラメータにAPP_PW
を構成します。tmloadcf
コマンドを実行して構成をロードします。 tmloadcf
コマンドを実行すると、UBBCONFIG
が解析され、TUXCONFIG
変数が指す場所にバイナリ形式のTUXCONFIG
ファイルがロードされます。tmadmin
コマンドのpasswd
パラメータを使用して変更しないかぎり有効です。
パスワードによる認証では、CORBAアプリケーションと対話するため、各クライアント・アプリケーションは、アプリケーション・パスワードのほか、有効なユーザー名とユーザー固有のデータ(パスワードなど)を提示しなければなりません。 パスワードは、tpusr
ファイルに保存されているユーザー名に関連付けられたパスワードと一致する必要があります。 ユーザー・パスワードと、tpusr
内のユーザー名/パスワードとの照合は、認証サーバーAUTHSVR
の認証サービスAUTHSVC
によって実行されます。
パスワードによる認証を有効にするには、以下の手順に従います。
tpusr
ファイルで定義します。tpusr
ファイルの詳細は、「認可されたユーザーの定義」を参照してください。MASTER
マシンで作業しており、アプリケーションが非アクティブであることを確認します。UBBCONFIG
を開き、RESOURCES
セクションとSERVERS
セクションに次の行を追加します。*RESOURCES
SECURITY USER_AUTH
AUTHSVC “AUTHSVC”
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name
" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
CLOPT="-A"を指定すると、tmboot
コマンドは、tmboot
によってアプリケーションが起動するときに、"-A"で呼び出されたデフォルトのコマンドライン・オプションだけをAUTHSVR
に渡します。
tmloadcf
コマンドを実行して構成をロードします。 tmloadcf
コマンドを実行すると、UBBCONFIG
が解析され、TUXCONFIG
変数が指す場所にバイナリ形式のTUXCONFIG
ファイルがロードされます。tmadmin
コマンドのpasswd
パラメータを使用して変更しないかぎり有効です。
リスト7-3は、パスワードによる認証を使用するアプリケーション用のUBBCONFIG
ファイルを示しています。 UBBCONFIG
ファイルの重要なセクションは、太字で表記されています。
*RESOURCES
IPCKEY 55432
DOMAINID securapp
MASTER SITE1
MODEL SHM
LDBAL N
SECURITY USER_AUTH
AUTHSVR “AUTHSVC”
*MACHINES
"ICEAXE"
LMID = SITE1
APPDIR = "D:\TUXDIR\samples\corba\SECURAPP"
TUXCONFIG = "D:\TUXDIR\samples\corba\SECURAPP\results
\tuxconfig"
TUXDIR = "D:\Tux8"
MAXWSCLIENTS = 10
*GROUPS
SYS_GRP
LMID = SITE1
GRPNO = 1
APP_GRP
LMID = SITE1
GRPNO = 2
*SERVERS
DEFAULT:
RESTART = Y
MAXGEN = 5
AUTHSVR
SRVGRP = SYS_GRP
SRVID = 1
RESTART = Y
GRACE = 60
MAXGEN = 2
TMSYSEVT
SRVGRP = SYS_GRP
SRVID = 1
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 2
CLOPT = "-A -- -N -M"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 3
CLOPT = "-A -- -N"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 4
CLOPT = "-A -- -F"
simple_server
SRVGRP = APP_GRP
SRVID = 1
RESTART = N
ISL
SRVGRP = SYS_GRP
SRVID = 5
CLOPT = “-A -- -n //PCWIZ::2500”
SEC_PRINCIPAL_NAME="IIOPListener"
SEC_PRINCIPAL_PASSVAR="ISH_PASS"
証明書による認証ではSSLプロトコルを使用するので、SSLプロトコル用のライセンスをインストールし、SSLプロトコルを構成してからでないと、証明書による認証を使用できません。SSLプロトコル用のライセンスのインストールについては、「Oracle Tuxedoシステムのインストール」を参照してください。SSLプロトコルの構成の詳細は、「SSLプロトコルの構成」を参照してください。
また、CORBAアプリケーションで証明書による認証を使用する前に、LDAP対応のディレクトリおよび認証局を用意する必要があります。LDAP対応であれば、どのディレクトリ・サービスでもかまいません。また、CORBAアプリケーションで使用する証明書および秘密鍵の取得先の認証局を選択することもできます。詳細は、「公開鍵によるセキュリティ機能の管理」を参照してください。
Home
ディレクトリまたは次のディレクトリに格納します。 %TUXDIR%\udataobj\security\keys
$TUXDIR/udataobj/security/keys
SEC_PRINCIPAL
、SEC_PRINCIPAL_LOCATION
、およびSEC_PRINCIPAL_PASSVAR
をUBBCONFIG
ファイルで定義します。詳細は、「IIOPリスナー/ハンドラのセキュリティ・パラメータの定義」を参照してください。tpusradd
コマンドを使用して、CORBAアプリケーションおよびIIOPリスナー/ハンドラの認可されたユーザーを定義します。tpusr
ファイルでは、ユーザーの電子メール・アドレスを使用します。tpusr
ファイルの詳細は、「認可されたユーザーの定義」を参照してください。IIOPリスナー/ハンドラのパスワードとして、SEC_PRINCIPAL_PASSVAR
で定義したパス・フレーズを使用します。-S
オプションを使用して、安全な通信用のIIOPリスナー/ハンドラのポートを定義します。詳細は、「SSLネットワーク接続用のポートの定義」を参照してください。-a
オプションを使用して、IIOPリスナー/ハンドラで証明書による認証を有効にします。trust_ca.cer
)を作成します。詳細は、「信頼性のある認証局の定義」を参照してください。UBBCONFIG
を開き、RESOURCES
セクションとSERVERS
セクションに次の行を追加します。tmloadcf
コマンドを実行して構成をロードします。 tmloadcf
コマンドを実行すると、UBBCONFIG
が解析され、TUXCONFIG
変数が指す場所にバイナリ形式のTUXCONFIG
ファイルがロードされます。peer_val.rul
)を作成します。詳細は、「ピア・ルール・ファイルの作成」を参照してください。証明書による認証を有効にするには、次のいずれかを実行します。
証明書による認証を有効にするには、SSLプロトコル用のライセンスをインストールしておく必要があります。 -a
オプションまたは-ORBmutualAuth
コマンドライン・オプションを実行したときに、SSLプロトコルを有効にするためのライセンスがインストールされていないと、IIOPリスナー/ハンドラまたはCORBA C++ ORBは起動しません。
リスト7-4は、証明書による認証を使用するCORBAアプリケーション用のUBBCONFIG
ファイルを示しています。 UBBCONFIG
ファイルの重要なセクションは、太字で表記されています。
*RESOURCES
IPCKEY 55432
DOMAINID simpapp
MASTER SITE1
MODEL SHM
LDBAL N
SECURITY USER_AUTH
AUTHSVR “AUTHSVC”
*MACHINES
"ICEAXE"
LMID = SITE1
APPDIR = "D:\TUXDIR\samples\corba\SIMPAP~1"
TUXCONFIG = "D:\TUXDIR\samples\corba\SIMPAP~1
\results\tuxconfig"
TUXDIR = "D:\TUX8"
MAXWSCLIENTS = 10
*GROUPS
SYS_GRP
LMID = SITE1
GRPNO = 1
APP_GRP
LMID = SITE1
GRPNO = 2
*SERVERS
DEFAULT:
RESTART = Y
MAXGEN = 5
AUTHSVR
SRVGRP = SYS_GRP
SRVID = 1
RESTART = Y
GRACE = 60
MAXGEN = 2
TMSYSEVT
SRVGRP = SYS_GRP
SRVID = 1
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 2
CLOPT = "-A -- -N -M"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 3
CLOPT = "-A -- -N"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 4
CLOPT = "-A -- -F"
simple_server
SRVGRP = APP_GRP
SRVID = 1
RESTART = N
ISL
SRVGRP = SYS_GRP
SRVID = 5
CLOPT = "-A -- -a -z40 -Z128 -S2458 -n //ICEAXE:2468"
SEC_PRINCIPAL_NAME="IIOPListener"
SEC_PRINCIPAL_LOCATION="IIOPListener.pem"
SEC_PRINCIPAL_PASSVAR="ISH_PASS"
注意: | アクセス制御の適用対象は、デフォルトの認可実装のみです。 CORBAセキュリティ環境のデフォルトの認可プロバイダでは、アクセス制御のチェックが行われません。 また、UBBCONFIG ファイルのSECURITY パラメータの構成は、サード・パーティ製の認可実装で使用されるアクセス制御を管理または実施しません。 |
アクセス制御によるセキュリティには、オプションのアクセス制御リスト(ACL
)と必須のアクセス制御リスト(MANDATORY_ACL
)の2つのレベルがあります。 アクセス制御リストは、ユーザーがアプリケーションへの参加を認証された場合にのみ有効になります。
アクセス制御リストを使用すると、システム管理者はユーザーを複数のグループにまとめ、それらのグループに対して、メンバー・ユーザーがアクセス権を持つオブジェクトを関連付けることができます。 アクセス制御は、次の理由により、グループ・レベルで行われます。
デフォルトの認可プロバイダを使用する場合、アクセス制御のチェック機能は、システム管理者が作成して管理する次のファイルに基づきます。
ACL
とMANDATORY_ACL
との違いは次のとおりです。
オプションのACLセキュリティでは、各クライアントは、アプリケーションに参加するため、アプリケーション・パスワード、ユーザー名、およびユーザー固有のデータ(パスワードなど)を提示しなければなりません。
オプションのACLセキュリティを構成するには、次の手順に従います。
MASTER
マシンで作業しており、アプリケーションが非アクティブであることを確認します。UBBCONFIG
を開き、RESOURCES
セクションとSERVERS
セクションに次の行を追加します。*RESOURCES
SECURITY ACL
AUTHSVC “AUTHSVC”
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name
" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
CLOPT="-A"を指定すると、tmboot
コマンドは、tmboot
によってアプリケーションが起動するときに、"-A"で呼び出されたデフォルトのコマンドライン・オプションだけをAUTHSVR
に渡します。 デフォルトでは、AUTHSVR
はtpusr
ファイルのユーザー情報を使用して、CORBAアプリケーションと対話するクライアントを認証します。
tmloadcf
コマンドを実行して構成をロードします。 tmloadcf
コマンドを実行すると、UBBCONFIG
が解析され、TUXCONFIG
変数が指す場所にバイナリ形式のTUXCONFIG
ファイルがロードされます。tmadmin
のpasswd
コマンドを使用して変更しないかぎり有効です。必須のACLセキュリティ・レベルでは、各クライアントは、CORBAアプリケーションと対話するため、アプリケーション・パスワード、ユーザー名、およびユーザー固有のデータ(パスワードなど)を提示しなければなりません。
必須のACLセキュリティを構成するには、以下の手順に従います。
MASTER
マシンで作業しており、アプリケーションが非アクティブであることを確認します。UBBCONFIG
を開き、RESOURCES
セクションとSERVERS
セクションに次の行を追加します。*RESOURCES
SECURITYMANDATORY_
ACL
AUTHSVC ..AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name
" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
CLOPT="-A"を指定すると、tmboot
コマンドは、tmboot
によってアプリケーションが起動するときに、"-A"で呼び出されたデフォルトのコマンドライン・オプションだけをAUTHSVR
に渡します。 デフォルトでは、AUTHSVR
はtpusr
ファイルのクライアント・ユーザー情報を使用して、アプリケーションに参加するクライアントを認証します。 tpusr
ファイルは、アプリケーションのAPPDIR
変数で定義されている最初のパス名が指すディレクトリにあります。
tmloadcf
コマンドを実行して構成をロードします。 tmloadcf
コマンドを実行すると、UBBCONFIG
が解析され、TUXCONFIG
変数が指す場所にバイナリ形式のTUXCONFIG
ファイルがロードされます。tmadmin
のpasswd
コマンドを使用して変更しないかぎり有効です。管理者は、次の構成パラメータを使用して、別々のOracle TuxedoドメインにあるCORBAアプリケーション間のアクセス制御リスト(ACL)ポリシーを構成および管理します。
以下では、ACL_POLICY
の構成が、ローカル・ドメイン・ゲートウェイ(GWTDOMAIN
)のプロセスの動作に与える影響について説明します。
GWTDOMAIN
)がインバウンドのCORBAクライアント・リクエスト(リモート・アプリケーションからネットワーク経由で受信されるリクエスト)を変更しています。変更されたリクエストは、リモート・ドメイン・アクセス・ポイントに設定されたDOMAINID
のIDを持つため、そのIDに設定されたアクセス権も取得することになります。各ドメイン・ゲートウェイは、アウトバウンドのクライアント・リクエストを変更しないで渡します。この構成では、各アプリケーションにACLデータベースがあります。このデータベースには、ドメイン内のユーザーに関するエントリだけが格納されます。
GWTDOMAIN
)は、インバウンドとアウトバウンドのCORBAクライアント・リクエストを変更しないで渡します。この構成では、各アプリケーションにACLデータベースがあります。このデータベースには、ドメイン内のユーザーに関するエントリのほか、リモート・ドメインのユーザーの情報も格納されます。 ドメイン・ゲートウェイは、ローカルのDMCONFIG
ファイルのACL_POLICY
パラメータにLOCAL
(デフォルト)が設定されたリモート・ドメインからクライアント・リクエストを受け取ると、リクエストからトークンを削除し、リモート・ドメイン・アクセス・ポイントのDOMAINID
を含むアプリケーション・キーを作成します。
リスト7-5では、リモート・ドメイン・アクセス・ポイントb01
を介した接続に対し、ローカルのDMCONFIG
ファイルでACLがグローバルに構成されています。つまり、ドメイン・アクセス・ポイントc01
のドメイン・ゲートウェイ・プロセスは、ドメイン・アクセス・ポイントb01
に対し、クライアント・リクエストを変更しないで受け渡します。
*DM_LOCAL_DOMAINS
# <LDOM name> <Gateway Group name> <domain type> <domain id>
# [<connection principal name>] [<security>]...
c01 GWGRP=bankg1
TYPE=TDOMAIN
DOMAINID="BA.CENTRAL01"
CONN_PRINCIPAL_NAME="BA.CENTRAL01"
SECURITY=DM_PW
.
.
.*DM_REMOTE_DOMAINS
# <RDOM name> <domain type> <domain id> [<ACL policy>]
# [<connection principal name>] [<local principal name>]...
b01 TYPE=TDOMAIN
DOMAINID="BA.BANK01"
ACL_POLICY=GLOBAL
CONN_PRINCIPAL_NAME="BA.BANK01"
Oracle TuxedoドメインのCORBAサーバー・アプリケーションを、WebLogic Enterprise製品のリリース4.2および5.0で利用可能なセキュリティ機能を備えたクライアント・アプリケーションと安全に相互運用させることが必要になる場合があります。 CORBAサーバー・アプリケーションを旧バージョンの安全なクライアント・アプリケーションと相互運用させるには、UBBCONFIG
ファイルでCLOPT -t
オプションを設定するか、CORBAオブジェクト・リクエスト・ブローカ(ORB)の-ORBinterOp
コマンドライン・オプションを指定します。
CLOPT -t
オプションを設定するか、-ORBinterOP
コマンドライン・オプションを指定すると、CORBAサーバーの有効なセキュリティ・レベルを引き下げることになります。 したがって、互換モードをサーバー・アプリケーションで有効にする前に、十分に考慮する必要があります。
以前のクライアント・アプリケーションと相互運用するすべてのサーバー・アプリケーションのCLOPT -t
オプションを設定する必要があります。CLOPT -t
オプションは、リスト7-6の*SERVERS
セクションに指定します。
*SERVERS
SecureSrv SRVGRP=group_name
SRVID=server_number
CLOPT=A -t..
リモートCORBA C++ ORBを使用する場合、ORBの -ORBinterOp
コマンドライン・オプションを指定して、ORBがリリース4.2または5.0のWebLogic Enterprise製品のセキュリティ機能を使用するクライアント・アプリケーションと相互運用できるようにします。
![]() ![]() ![]() |