認証の構成

認証を行うには、ユーザーの個々のパスワードを正当なユーザーのファイルと照合することでユーザーを認証するための認証サーバーを構成する必要があります。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ファイルで認証サーバーを定義する部分です。

パラメータと値の組合せであるAUTHSVCのエントリを省略すると、Oracle TuxedoシステムはデフォルトでAUTHSVCを呼び出します。

AUTHSVRは、アプリケーション固有のロジックを実装する認証サーバーと置き換えることができます。たとえば、広く使用されているKerberosのメカニズムを使用して認証を行うため、認証サーバーをカスタマイズすることもできます。

カスタマイズした認証サービスをアプリケーションに追加するには、UBBCONFIGファイルで認証サービスと認証サーバーを定義する必要があります。例:

デフォルトの認証サーバーを構成したら、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例外が生成されます。

tpusraddおよびtpgrpaddコマンド以外にも、Oracle Tuxedo製品には、tpusrおよびtpgrpファイルを変更するための次のコマンドが用意されています。

ホスト・システムには、ユーザーとグループのリストを格納したファイルがすでに存在する場合があります。これらのファイルをCORBAアプリケーションのユーザー・ファイルおよびグループ・ファイルとして使用するには、Oracle Tuxedoシステムで受け付けられる形式に変換する必要があります。ファイルを変換するには、次の手順例に示すように、tpaclcvtコマンドを実行します。この手順例は、UNIXホスト・マシン用に記述されています。

アプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。
/etc/passwordファイルをOracle Tuxedoシステムで受け付けられる形式に変換するには、次のコマンドを入力します。

tpaclcvt -u /etc/password

このコマンドにより、tpusrファイルが作成され、変換されたデータが格納されます。tpusrファイルがすでに存在する場合、tpaclcvtにより、変換したデータがファイルに追加されます。ただし、重複するユーザー情報が追加されることはありません。

/etc/groupファイルをOracle Tuxedoシステムで受け付けられる形式に変換するには、次のコマンドを入力します。

tpaclcvt -g /etc/group

このコマンドにより、tpgrpファイルが作成され、変換されたデータが格納されます。tpgrpファイルがすでに存在する場合、tpaclcvtにより、変換したデータがファイルに追加されます。ただし、重複するグループ情報が追加されることはありません。

セキュリティ・レベルの定義

CORBAアプリケーションのセキュリティ定義の中で、UBBCONFIGファイルのRESOURCESセクションのSECURITYパラメータを定義する必要があります。SECURITYパラメータの形式は次のとおりです。

表7-1 SECURITYパラメータの値
値	説明
`NONE`	CORBAアプリケーションでパスワードまたはアクセスのチェックを行わないことを示します。 `Tobj::PrincipalAuthenticator::get_auth_type()`は、値`TOBJ_NOAUTH`を返します。
`APP_PW`	Oracle Tuxedoドメインにアクセスするには、クライアント・アプリケーションはアプリケーション・パスワードを提供する必要があることを示します。tmloadcfコマンドでは、アプリケーション・パスワードの入力が要求されます。 Tobj::PrincipalAuthenticator::get_auth_type()は、値TOBJ_SYSAUTHを返します。
`USER_AUTH`	クライアント・アプリケーションとIIOPリスナー/ハンドラはOracle Tuxedoドメインに対して自身を認証する必要があることを示します。値USER_AUTHはAPP_PWと似ていますが、クライアントの初期化時にユーザー認証も行われることを示します。tmloadcfコマンドでは、アプリケーション・パスワードの入力が要求されます。 Tobj::PrincipalAuthenticator::get_auth_type()は、値TOBJ_APPAUTHを返します。このセキュリティ・レベルでは、アクセス制御のチェックは行われません。
`ACL`	CORBAアプリケーションで認証が使用され、インタフェース、サービス、キュー名、およびイベント名に対するアクセス制御のチェックが行われることを示します。名前にACLが関連付けられていなければ、アクセス権が付与されているとみなされます。tmloadcfコマンドでは、アプリケーション・パスワードの入力が要求されます。 Tobj::PrincipalAuthenticator::get_auth_type()は、値TOBJ_APPAUTHを返します。
`MANDATORY_ACL`	CORBAアプリケーションで認証が使用され、インタフェース、サービス、キュー名、およびイベント名に対するアクセス制御のチェックが行われることを示します。値`MANDATORY_ACL`は`ACL`と似ていますが、名前に`ACL`が関連付けられていなければ、アクセスは拒否されます。tmloadcfコマンドでは、アプリケーション・パスワードの入力を要求されます。 `Tobj::PrincipalAuthenticator::get_auth_type`は、値`TOBJ_APPAUTH`を返します。

アプリケーション・パスワードによるセキュリティの構成

アプリケーション・パスワードによるセキュリティを構成するには、次の手順に従います。

アプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。
UBBCONFIGファイルのRESOURCESセクションのSECURITYパラメータにAPP_PWを構成します。
tmloadcfコマンドを実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。
パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはアプリケーションのパスワードとなり、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ファイルがロードされます。
パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはアプリケーションのパスワードとなり、tmadminコマンドのpasswdパラメータを使用して変更しないかぎり有効です。
電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してアプリケーション・パスワードを配布します。

パスワードによる認証用のUBBCONFIGファイルの例

リスト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アプリケーションで使用する証明書および秘密鍵の取得先の認証局を選択することもできます。詳細は、「公開鍵によるセキュリティ機能の管理」を参照してください。

証明書による認証を有効にするには、次の手順に従います。

SSLプロトコルを使用するためのライセンスをインストールします。
LDAP対応ディレクトリ・サービスを構成します。
IIOPリスナー/ハンドラの証明書および秘密鍵を認証局から取得します。
CORBAアプリケーションの証明書および秘密鍵を認証局から取得します。
CORBAアプリケーションの秘密鍵をユーザーのHomeディレクトリまたは次のディレクトリに格納します。

Windows 2003

%TUXDIR%\udataobj\security\keys

UNIX

$TUXDIR/udataobj/security/keys

IIOPリスナー/ハンドラ、CORBAアプリケーション、および認証局の証明書をLDAP対応ディレクトリ・サービスで公開します。
ISLサーバー・プロセスのSEC_PRINCIPAL、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARをUBBCONFIGファイルで定義します。詳細は、「IIOPリスナー/ハンドラのセキュリティ・パラメータの定義」を参照してください。
tpusraddコマンドを使用して、CORBAアプリケーションおよびIIOPリスナー/ハンドラの認可されたユーザーを定義します。tpusrファイルでは、ユーザーの電子メール・アドレスを使用します。tpusrファイルの詳細は、「認可されたユーザーの定義」を参照してください。IIOPリスナー/ハンドラのパスワードとして、SEC_PRINCIPAL_PASSVARで定義したパス・フレーズを使用します。
ISLコマンドの-Sオプションを使用して、安全な通信用のIIOPリスナー/ハンドラのポートを定義します。詳細は、「SSLネットワーク接続用のポートの定義」を参照してください。
ISLコマンドの-aオプションを使用して、IIOPリスナー/ハンドラで証明書による認証を有効にします。
CORBAアプリケーションが信頼する認証局を定義する信頼性のある認証局ファイル(trust_ca.cer)を作成します。詳細は、「信頼性のある認証局の定義」を参照してください。
テキスト・エディタでUBBCONFIGを開き、RESOURCESセクションとSERVERSセクションに次の行を追加します。

*RESOURCES SECURITY USER_AUTH

tmloadcfコマンドを実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。
オプションで、CORBAアプリケーションおよびIIOPリスナー/ハンドラのピア・ルール・ファイル(peer_val.rul)を作成します。詳細は、「ピア・ルール・ファイルの作成」を参照してください。
オプションで、エンタープライズの階層に合せてLDAP検索フィルタ・ファイルを変更します。詳細は、「LDAP検索フィルタ・ファイルの編集」を参照してください。

証明書による認証を有効にするには、次のいずれかを実行します。

証明書による認証を有効にするには、SSLプロトコル用のライセンスをインストールしておく必要があります。-aオプションまたは-ORBmutualAuthコマンドライン・オプションを実行したときに、SSLプロトコルを有効にするためのライセンスがインストールされていないと、IIOPリスナー/ハンドラまたはCORBA C++ ORBは起動しません。

証明書による認証用のUBBCONFIGファイルの例

リスト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"

アクセス制御の構成

アクセス制御によるセキュリティには、オプションのアクセス制御リスト(ACL)と必須のアクセス制御リスト(MANDATORY_ACL)の2つのレベルがあります。アクセス制御リストは、ユーザーがアプリケーションへの参加を認証された場合にのみ有効になります。

アクセス制御リストを使用すると、システム管理者はユーザーを複数のグループにまとめ、それらのグループに対して、メンバー・ユーザーがアクセス権を持つオブジェクトを関連付けることができます。アクセス制御は、次の理由により、グループ・レベルで行われます。

デフォルトの認可プロバイダを使用する場合、アクセス制御のチェック機能は、システム管理者が作成して管理する次のファイルに基づきます。

オプションの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ファイルがロードされます。
パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはアプリケーションのパスワードとなり、tmadminのpasswdコマンドを使用して変更しないかぎり有効です。
電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してアプリケーション・パスワードを配布します。

必須のACLセキュリティの構成

必須のACLセキュリティ・レベルでは、各クライアントは、CORBAアプリケーションと対話するため、アプリケーション・パスワード、ユーザー名、およびユーザー固有のデータ(パスワードなど)を提示しなければなりません。

必須のACLセキュリティを構成するには、次の手順に従います。

アプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。
テキスト・エディタでUBBCONFIGを開き、RESOURCESセクションとSERVERSセクションに次の行を追加します。

*RESOURCES
SECURITY   MANDATORY_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ファイルがロードされます。
パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはアプリケーションのパスワードとなり、tmadminのpasswdコマンドを使用して変更しないかぎり有効です。
電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してアプリケーション・パスワードを配布します。

CORBAアプリケーション間のACLポリシーの設定

管理者は、次の構成パラメータを使用して、別々のOracle TuxedoドメインにあるCORBAアプリケーション間のアクセス制御リスト(ACL)ポリシーを構成および管理します。

次では、ACL_POLICYの構成が、ローカル・ドメイン・ゲートウェイ(GWTDOMAIN)のプロセスの動作に与える影響について説明します。

ローカルのACLポリシーを使用する場合、各ドメイン・ゲートウェイ(GWTDOMAIN)がインバウンドのCORBAクライアント・リクエスト(リモート・アプリケーションからネットワーク経由で受信されるリクエスト)を変更しています。変更されたリクエストは、リモート・ドメイン・アクセス・ポイントに設定されたDOMAINIDのIDを持つため、そのIDに設定されたアクセス権も取得することになります。各ドメイン・ゲートウェイは、アウトバウンドのクライアント・リクエストを変更しないで渡します。

この構成では、各アプリケーションにACLデータベースがあります。このデータベースには、ドメイン内のユーザーに関するエントリだけが格納されます。

グローバルのACLポリシーを使用する場合、各ドメイン・ゲートウェイ(GWTDOMAIN)は、インバウンドとアウトバウンドのCORBAクライアント・リクエストを変更しないで渡します。この構成では、各アプリケーションにACLデータベースがあります。このデータベースには、ドメイン内のユーザーに関するエントリのほか、リモート・ドメインのユーザーの情報も格納されます。

リモート・ドメイン・ゲートウェイの偽装化

ドメイン・ゲートウェイは、ローカルのDMCONFIGファイルのACL_POLICYパラメータにLOCAL(デフォルト)が設定されたリモート・ドメインからクライアント・リクエストを受け取ると、リクエストからトークンを削除し、リモート・ドメイン・アクセス・ポイントのDOMAINIDを含むアプリケーション・キーを作成します。

ACLポリシーを指定するDMCONFIGのエントリ例

リスト7-5では、リモート・ドメイン・アクセス・ポイントb01を介した接続に対し、ローカルのDMCONFIGファイルでACLがグローバルに構成されています。つまり、ドメイン・アクセス・ポイントc01のドメイン・ゲートウェイ・プロセスは、ドメイン・アクセス・ポイントb01に対し、クライアント・リクエストを変更しないで受け渡します。

旧バージョンのWebLogic Enterpriseクライアント・アプリケーションと相互運用するためのセキュリティの構成

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セクションに指定します。

リモートCORBA C++ ORBを使用する場合、ORBの -ORBinterOpコマンドライン・オプションを指定して、ORBがリリース4.2または5.0のWebLogic Enterprise製品のセキュリティ機能を使用するクライアント・アプリケーションと相互運用できるようにします。

CORBAアプリケーションにおけるセキュリティの使用