認証の構成

このトピックには次の項が含まれます:

•

認証サーバーの構成

•	認可されたユーザーの定義

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

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

•	パスワードによる認証の構成

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

•	証明書による認証の構成

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

•

アクセス制御の構成

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

注意:	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ファイルで認証サーバーを定義する部分です。

リスト7-1 認証サーバーのパラメータ

*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ファイルで指定する必要があります。詳細は、7-3ページの「認可されたユーザーの定義」を参照してください。

認可されたユーザーの定義

CORBAアプリケーションのセキュリティ構成の中で、CORBAアプリケーションに対するアクセス権を持つプリンシパルおよびプリンシパル・グループを定義する必要があります。

認可されたユーザーの定義方法は、次のとおりです。

•	パスワードによる認証の場合、認可されたユーザーを定義するにはパスワードと関連パスワードを使用します。

•	証明書による認証の場合、認可されたユーザーを識別するには電子メール・アドレスを使用します。電子メール・アドレスによって、デジタル証明書で表されるプリンシパルの外部IDがCORBAアプリケーションで使用されるIDにマップされます。

認可されたプリンシパルのリストが格納されたファイルを作成するには、tpusraddコマンドを使用します。tpusraddコマンドは、新しいプリンシパルをOracle Tuxedoのセキュリティ・データ・ファイルに追加します。この情報は、認証サーバーがプリンシパルを認証する場合に使用します。プリンシパルが格納されたファイルはtpusrと呼ばれます。

ファイルはコロン区切りのフラットなASCIIファイルで、CORBAアプリケーションのシステム管理者だけが読取り可能です。システム・ファイルのエントリは、1行当たり512文字までです。ファイルはアプリケーション・ディレクトリに格納され、環境変数の$APPDIRで指定されます。環境変数$APPDIRには、CORBAアプリケーションのパス名を設定する必要があります。

tpusraddファイルは、管理者アカウントで所有する必要があります。このファイルを保護して、ファイルのオーナーだけが読み書き権限を持つようにすることをお薦めします。

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ファイルの例を示します。

リスト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ファイルを変更するための次のコマンドが用意されています。

•

tpusrdel

•

tpusrmod

•

tpgrpdel

•

tpgrpmod

コマンドの説明については、Oracle Tuxedoオンライン・ドキュメントの『Oracle Tuxedoコマンド・リファレンス』を参照してください。

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

1.	アプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。

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

tpaclcvt-u/etc/password

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

注意:	シャドウ・パスワード・ファイルを使用するシステムでは、ファイル内のユーザーごとにパスワードの入力が要求されます。

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

tpaclcvt-g/etc/group

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

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

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

*RESOURCES
	SECURITY {NONE|APP_PW|USER_AUTH|ACL|MANDATORY_ACL}

表7-1では、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を返します。

注意:	IIOPリスナー/ハンドラが証明書による認証を使用するように構成されている場合、SECURITYパラメータの値はUSER_AUTH以上でなければなりません。

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

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

1.	アプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。

2.	UBBCONFIGファイルのRESOURCESセクションのSECURITYパラメータにAPP_PWを構成します。

3.	tmloadcfコマンドを実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

4.	パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはアプリケーションのパスワードとなり、tmadminコマンドのpasswdパラメータを使用して変更しないかぎり有効です。

5.	電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してアプリケーション・パスワードを配布します。

パスワードによる認証の構成

パスワードによる認証では、CORBAアプリケーションと対話するため、各クライアント・アプリケーションは、アプリケーション・パスワードのほか、有効なユーザー名とユーザー固有のデータ(パスワードなど)を提示しなければなりません。パスワードは、tpusrファイルに保存されているユーザー名に関連付けられたパスワードと一致する必要があります。ユーザー・パスワードと、tpusr内のユーザー名/パスワードとの照合は、認証サーバーAUTHSVRの認証サービスAUTHSVCによって実行されます。

パスワードによる認証を有効にするには、次の手順に従います。

1.	ユーザーとその関連パスワードをtpusrファイルで定義します。tpusrファイルの詳細は、7-3ページの「認可されたユーザーの定義」を参照してください。

2.	アプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。

3.	テキスト・エディタで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に渡します。

4.	tmloadcfコマンドを実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

5.	パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはアプリケーションのパスワードとなり、tmadminコマンドのpasswdパラメータを使用して変更しないかぎり有効です。

6.	電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してアプリケーション・パスワードを配布します。

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

リスト7-3は、パスワードによる認証を使用するアプリケーション用のUBBCONFIGファイルを示しています。UBBCONFIGファイルの重要なセクションは、太字で表記されています。

リスト7-3 パスワードによる認証用の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プロトコルの構成の詳細は、6-1ページの「SSLプロトコルの構成」を参照してください。

また、CORBAアプリケーションで証明書による認証を使用する前に、LDAP対応のディレクトリおよび認証局を用意する必要があります。LDAP対応であれば、どのディレクトリ・サービスでもかまいません。また、CORBAアプリケーションで使用する証明書および秘密鍵の取得先の認証局を選択することもできます。詳細は、4-1ページの「公開鍵によるセキュリティ機能の管理」を参照してください。

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

1.	SSLプロトコルを使用するためのライセンスをインストールします。

2.	LDAP対応ディレクトリ・サービスを構成します。

3.	IIOPリスナー/ハンドラの証明書および秘密鍵を認証局から取得します。

4.	CORBAアプリケーションの証明書および秘密鍵を認証局から取得します。

5.	CORBAアプリケーションの秘密鍵をユーザーのHomeディレクトリまたは次のディレクトリに格納します。

Windows 2003

%TUXDIR%\udataobj\security\keys

UNIX

$TUXDIR/udataobj/security/keys

6.	IIOPリスナー/ハンドラ、CORBAアプリケーション、および認証局の証明書をLDAP対応ディレクトリ・サービスで公開します。

7.	ISLサーバー・プロセスのSEC_PRINCIPAL、SEC_PRINCIPAL_LOCATION、およびSEC_PRINCIPAL_PASSVARをUBBCONFIGファイルで定義します。詳細は、6-6ページの「IIOPリスナー/ハンドラのセキュリティ・パラメータの定義」を参照してください。

8.	tpusraddコマンドを使用して、CORBAアプリケーションおよびIIOPリスナー/ハンドラの認可されたユーザーを定義します。tpusrファイルでは、ユーザーの電子メール・アドレスを使用します。tpusrファイルの詳細は、7-3ページの「認可されたユーザーの定義」を参照してください。IIOPリスナー/ハンドラのパスワードとしてSEC_PRINCIPAL_PASSVARで定義したフェーズ・フレーズを使用してください。

9.	ISLコマンドの-Sオプションを使用して、安全な通信用のIIOPリスナー/ハンドラのポートを定義します。詳細は、6-2ページの「SSLネットワーク接続用のポートの定義」を参照してください。

10.	ISLコマンドの-aオプションを使用して、IIOPリスナー/ハンドラで証明書による認証を有効にします。

11.	CORBAアプリケーションが信頼する認証局を定義する信頼性のある認証局ファイル(trust_ca.cer)を作成します。詳細は、4-7ページの「信頼性のある認証局の定義」を参照してください。

12.	テキスト・エディタでUBBCONFIGを開き、RESOURCESセクションとSERVERSセクションに次の行を追加します。

*RESOURCES
SECURITY USER_AUTH

13.	tmloadcfコマンドを実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

14.	オプションで、CORBAアプリケーションおよびIIOPリスナー/ハンドラのピア・ルール・ファイル(peer_val.rul)を作成します。詳細は、4-8ページの「ピア・ルール・ファイルの作成」を参照してください。

15.	オプションで、エンタープライズの階層に合せてLDAP検索フィルタ・ファイルを変更します。詳細は、4-4ページの「LDAP検索フィルタ・ファイルの編集」を参照してください。

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

•	ISLコマンドの-aオプションを使用して、IIOPリスナー/ハンドラに接続するアプリケーションが証明書による認証を使用しなければならないことを指定します。

•	ORBの-ORBmutualAuthコマンド行オプションを使用して、CORBA C++ ORBに接続するアプリケーションが証明書による認証を使用しなければならないことを指定します。

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

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

リスト7-4は、証明書による認証を使用するCORBAアプリケーション用のUBBCONFIGファイルを示しています。UBBCONFIGファイルの重要なセクションは、太字で表記されています。

リスト7-4 証明書による認証用の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つのレベルがあります。アクセス制御リストは、ユーザーがアプリケーションへの参加を認証された場合にのみ有効になります。

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

•	システム管理を簡素化できます。新しいオブジェクトへのアクセス権を付与する場合、1つのグループに対してアクセス権を付与する方が、個別の複数のユーザーに付与するより簡単です。

•	パフォーマンスを高めることができます。エンティティを呼び出すたびにアクセス・パーミッションをチェックする必要があるため、パーミッションはすばやく解決できなければなりません。グループの数はユーザーの数より少ないため、権限を持つユーザーのリストを検索するよりも、権限を持つグループのリストを検索する方が高速です。

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

•	tpusrにはユーザーのリストが格納されています。

•	tpgrpにはグループのリストが格納されています。

•	tpaclにはACLのリストが格納されています。

オプションのACLセキュリティの構成

ACLとMANDATORY_ACLとの違いは次のとおりです。

•	ACLモードでは、サービス・リクエストは特定のACLがない場合に許可されます。

•	MANDATORY_ACLモードでは、サービス・リクエストは特定のACLがない場合に拒否されます。

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

オプションのACLセキュリティを構成するには、次の手順に従います。

1.	アプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。

2.	テキスト・エディタで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アプリケーションと対話するクライアントを認証します。

3.	tmloadcfコマンドを実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

4.	パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはアプリケーションのパスワードとなり、tmadminのpasswdコマンドを使用して変更しないかぎり有効です。

5.	電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してアプリケーション・パスワードを配布します。

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

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

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

1.	アプリケーションのMASTERマシンで作業しており、アプリケーションが非アクティブであることを確認します。

2.	テキスト・エディタで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変数で定義されている最初のパス名が指すディレクトリにあります。

3.	tmloadcfコマンドを実行して構成をロードします。tmloadcfコマンドを実行すると、UBBCONFIGが解析され、TUXCONFIG変数が指す場所にバイナリ形式のTUXCONFIGファイルがロードされます。

4.	パスワードの入力を求められます。パスワードには、最大30文字まで指定できます。これはアプリケーションのパスワードとなり、tmadminのpasswdコマンドを使用して変更しないかぎり有効です。

5.	電話や手紙など、オンライン以外の方法で、認可されたユーザーに対してアプリケーション・パスワードを配布します。

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

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

.

パラメータ名	説明	設定
DMCONFIGのACL_POLICY (DM_MIBのTA_DMACLPOLICY)	リモート・ドメイン・アクセス・ポイントごとに、DMCONFIGファイルのDM_REMOTE_DOMAINSセクションで指定される場合があります。特定のリモート・ドメイン・アクセス・ポイントに対するこのパラメータの値により、ローカル・ドメイン・ゲートウェイがリモート・ドメインから受信したサービス・リクエストのIDを変更するかどうかが決まります。*	LOCALまたはGLOBAL。デフォルトはLOCALです。 LOCALは、サービス・リクエストのIDを変更することを意味し、GLOBALは、変更なしでサービス・リクエストを渡すことを意味します。リモート・ドメイン・アクセス・ポイントのDOMAINID文字列。
* リモート・ドメイン・アクセス・ポイントは、RDOM (「are dom」と発音します)または単純にリモート・ドメインとも呼ばれます。

次では、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に対し、クライアント・リクエストを変更しないで渡します。

リスト7-5 ACLポリシーを指定するDMCONFIGファイルの例

*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"

 

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

リスト7-6 相互運用性を指定するUBBCONFIGファイルのエントリ例

*SERVERS
SecureSrv     SRVGRP=group_name SRVID=server_number
              CLOPT=A -t..

 

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