bea ホーム | 製品 | dev2dev | support | askBEA
BEA Logo Tuxedo
 ドキュメントのダウンロード   サイトマップ   用語集 
検索
0

Tuxedo CORBA アプリケーションのセキュリティ機能

 Previous Next Contents Index View as PDF  

認証のコンフィギュレーション

ここでは、以下の内容について説明します。

 


認証サーバのコンフィギュレーション

注記 認証サーバをコンフィギュレーションする必要があるのは、SECURITY パラメータに USER_AUTH 以上の値を指定し、デフォルトの認証プラグインを使用する場合だけです。

認証を行うには、ユーザの個々のパスワードを正当なユーザのファイルと照合することでユーザを認証するための認証サーバをコンフィギュレーションする必要があります。BEA Tuxedo システムでは、AUTHSRV というデフォルトの認証サーバを使用して認証を実行します。AUTHSVR は、認証を実行する AUTHSVC というサービスだけを提供します。セキュリティ・レベルが ACL または MANDATORY_ACL に設定されている場合、AUTHSVR サーバは、AUTHSVCAUTHSVC として宣言します。

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 のエントリを省略すると、BEA 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 コマンドは、新しいプリンシパルを BEA Tuxedo のセキュリティ・データ・ファイルに追加します。この情報は、認証サーバがプリンシパルを認証する場合に使用します。プリンシパルが格納されたファイルは tpusr と呼ばれます。

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

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

tpusradd コマンドのオプションは以下のとおりです。

デフォルトの認証サーバを使用する場合、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

注記 BEA Tuxedo のセキュリティ・データ・ファイルにプリンシパル・グループを追加するには、 tpgrpadd コマンドを使用します。

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

各コマンドの詳細については、BEA Tuxedo オンライン・マニュアルの『BEA Tuxedo コマンド・リファレンス』を参照してください。

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

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

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

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

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

  1. /etc/group ファイルを BEA 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

BEA Tuxedo ドメインにアクセスするには、クライアント・アプリケーションはアプリケーション・パスワードを提供する必要があることを示します。tmloadcf コマンドでは、アプリケーション・パスワードの入力が要求されます。

Tobj::PrincipalAuthenticator::get_auth_type() は、値 TOBJ_SYSAUTH を返します。

USER_AUTH

クライアント・アプリケーションと IIOP リスナ/ハンドラは BEA Tuxedo ドメインに対して自身を認証する必要があることを示します。値 USER_AUTH は APP_PW と似ていますが、クライアントの初期化時にユーザ認証も行われることを示します。tmloadcf コマンドでは、アプリケーション・パスワードの入力が要求されます。

Tobj::PrincipalAuthenticator::get_auth_type() は、値 TOBJ_APPAUTH を返します。

このセキュリティ・レベルでは、アクセス制御のチェックは行われません。

ACL

CORBA アプリケーションで認証が使用され、インターフェイス、サービス、キュー名、およびイベント名に対するアクセス制御のチェックが行われることを示します。名前に ACL が関連付けられていなければ、アクセス権が付与されていると見なされます。tmloadcf コマンドでは、アプリケーション・パスワードの入力が要求されます。

Tobj::PrincipalAuthenticator::get_auth_type returns a value of TOBJ_APPAUTH.

MANDATORY_ACL

CORBA アプリケーションで認証が使用され、インターフェイス、サービス、キュー名、およびイベント名に対するアクセス制御のチェックが行われることを示します。値 MANDATORY_ACLACL と似ていますが、名前に 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 章の 4 ページ「認可されたユーザの定義」を参照してください。

  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-4 は、パスワードによる認証を使用するアプリケーション用の 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 プロトコル用のライセンスのインストールについては、『BEA Tuxedo システムのインストール』を参照してください。SSL プロトコルのコンフィギュレーション方法については、第 6 章の 1 ページ「SSL プロトコルのコンフィギュレーション」を参照してください。

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

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

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

  2. LDAP 対応ディレクトリ・サービスをコンフィギュレーションします。

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

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

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

    Windows 2000

    %TUXDIR%¥udataobj¥security¥keys

    UNIX

    $TUXDIR/udataobj/security/keys

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

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

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

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

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

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

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

    *RESOURCES
    SECURITY USER_AUTH

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

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

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

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

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

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

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

オプションの ACL セキュリティのコンフィギュレーション

ACLMANDATORY_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 に渡します。デフォルトでは、AUTHSVRtpusr ファイルのユーザ情報を使用して、CORBA アプリケーションと対話するクライアントを認証します。

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

  4. パスワードの入力を求められます。パスワードは、30 文字以内で構成します。これはアプリケーションのパスワードとなり、tmadminpasswd コマンドを使用して変更しない限り有効です。

  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 に渡します。デフォルトでは、AUTHSVRtpusr ファイルのクライアント・ユーザ情報を使用して、アプリケーションに参加するクライアントを認証します。tpusr ファイルは、アプリケーションの APPDIR 変数で定義されている最初のパス名が指すディレクトリにあります。

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

  4. パスワードの入力を求められます。パスワードは、30 文字以内で構成します。これはアプリケーションのパスワードとなり、tmadminpasswd コマンドを使用して変更しない限り有効です。

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

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

管理者は、次のコンフィギュレーション・パラメータを使用して、別々の BEA Tuxedo ドメインにある CORBA アプリケーション間のアクセス制御リスト (ACL) 方針をコンフィギュレーションおよび管理します。

.

パラメータ名

説明

設定

DMCONFIGACL_POLICY (DM_MIBTA_DMACLPOLICY)

リモート・ドメイン・アクセス・ポイントごとに、DMCONFIG ファイルの DM_REMOTE_DOMAINS セクションで指定される場合があります。特定のリモート・ドメイン・アクセス・ポイントに対するこのパラメータの値により、ローカル・ドメイン・ゲートウェイがリモート・ドメインから受信したサービス要求の ID を変更するかどうかが決まります。*

LOCAL または GLOBAL。デフォルト値は LOCAL です。

LOCAL は、サービス要求の ID を変更することを示します。GLOBAL は、サービス要求を変更しないで渡すことを示します。DOMAINID 文字列は、リモート・ドメイン・アクセス・ポイントです。

* リモート・ドメイン・アクセス・ポイントは、RDOM (アールドム) または単に「リモート・ドメイン」とも呼ばれます。


 

以下では、ACL_POLICY のコンフィギュレーションが、ローカル・ドメイン・ゲートウェイ (GWTDOMAIN) のプロセスの動作に与える影響について説明します。

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

ドメイン・ゲートウェイは、ローカルの 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 クライアント・アプリケーションと相互運用するためのセキュリティのコンフィギュレーション

BEA Tuxedo ドメインの CORBA サーバ・アプリケーションを、WebLogic Enterprise 製品のリリース 4.2 および 5.0 で利用可能なセキュリティ機能を備えたクライアント・アプリケーションと安全に相互運用させることが必要になる場合があります。CORBA サーバ・アプリケーションを旧バージョンの安全なクライアント・アプリケーションと相互運用させるには、UBBCONFIG ファイルで CLOPT -t オプションを設定するか、CORBA オブジェクト・リクエスト・ブローカ (ORB) の -ORBinterOp コマンド行オプションを指定します。

CLOPT -t オプションを設定するか、-ORBinterOP コマンド行オプションを指定すると、CORBA サーバの有効なセキュリティ・レベルを引き下げることになります。したがって、互換モードをサーバ・アプリケーションで有効にする前に、十分に考慮する必要があります。

以前のクライアント・アプリケーションと相互運用するすべてのサーバ・アプリケーションの CLOPT -t オプションを設定する必要があります。CLOPT -t オプションは、UBBCONFIG ファイルの *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 製品のセキュリティ機能を使用するクライアント・アプリケーションと相互運用できるようにします。

 

Back to Top Previous Next
Contact e-docsContact BEAwebmasterprivacy