bea ホーム | 製品 | dev2dev | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > Tuxedo > Tuxedo CORBA アプリケーションのセキュリティ機能 > 認証のコンフィギュレーション |
Tuxedo CORBA アプリケーションのセキュリティ機能
|
認証のコンフィギュレーション
ここでは、以下の内容について説明します。
認証サーバのコンフィギュレーション
注記 認証サーバをコンフィギュレーションする必要があるのは、SECURITY パラメータに USER_AUTH 以上の値を指定し、デフォルトの認証プラグインを使用する場合だけです。
認証を行うには、ユーザの個々のパスワードを正当なユーザのファイルと照合することでユーザを認証するための認証サーバをコンフィギュレーションする必要があります。BEA 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 のエントリを省略すると、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 コマンドのオプションは以下のとおりです。
ユーザの ID 番号。UID は、128K 以下の正の 10 進整数でなければなりません。また、アプリケーションの既存の識別子リスト内で一意でなければなりません。UID は、次に利用可能な (一意な) 0 より大きい識別子にデフォルト設定されます。
グループの ID 番号。GID は、整数識別子または文字列名です。このオプションは、新しいユーザのグループ・メンバーシップを定義します。デフォルトでは、other グループ (識別子 0) となります。
プリンシパル名を指定する出力可能な文字列。名前には、コロン (:)、シャープ記号 (#)、改行文字 (¥n) を使用できません。プリンシパル名は CORBA アプリケーションの既存のプリンシパル・リスト内で一意でなければなりません。
ユーザの新規ログイン名を指定する出力可能な文字列。名前には、コロン (:)、シャープ記号 (#)、改行文字 (¥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
注記 BEA Tuxedo のセキュリティ・データ・ファイルにプリンシパル・グループを追加するには、 tpgrpadd コマンドを使用します。
tpusradd および tpgrpadd コマンド以外にも、BEA Tuxedo 製品には、tpusr および tpgrp ファイルを変更するための次のコマンドが用意されています。
各コマンドの詳細については、BEA Tuxedo オンライン・マニュアルの『BEA Tuxedo コマンド・リファレンス』を参照してください。
ホスト・システムには、ユーザとグループのリストを格納したファイルが既に存在する場合があります。これらのファイルを CORBA アプリケーションのユーザ・ファイルおよびグループ・ファイルとして使用するには、BEA Tuxedo システムで受け付けられる形式に変換する必要があります。ファイルを変換するには、次の手順例に示すように、tpaclcvt コマンドを実行します。この手順例は、UNIX ホスト・マシン用に記述されています。
tpaclcvt -u /etc/password
注記 シャドウ・パスワード・ファイルを使用するシステムでは、ファイル内のユーザごとにパスワードの入力が要求されます。
セキュリティ・レベルの定義
CORBA アプリケーションのセキュリティ定義の中で、UBBCONFIG ファイルの RESOURCES セクションの SECURITY パラメータを定義する必要があります。SECURITY パラメータの形式は次のとおりです。
*RESOURCES
SECURITY {NONE|APP_PW|USER_AUTH|ACL|MANDATORY_ACL}
表 7-1 では、SECURITY パラメータの値について説明します。
注記 IIOP リスナ/ハンドラが証明書による認証を使用するようにコンフィギュレーションされている場合、SECURITY パラメータの値は USER_AUTH 以上でなければなりません。
アプリケーション・パスワードによるセキュリティのコンフィギュレーション
アプリケーション・パスワードによるセキュリティをコンフィギュレーションするには、以下の手順に従います。
パスワードによる認証のコンフィギュレーション
パスワードによる認証では、CORBA アプリケーションと対話するため、各クライアントは、アプリケーション・パスワードのほか、有効なユーザ名とユーザ固有のデータ (パスワードなど) を提示しなければなりません。パスワードは、tpusr ファイルに保存されているユーザ名に関連付けられたパスワードと一致する必要があります。ユーザ・パスワードと、tpusr 内のユーザ名/パスワードとの照合は、認証サーバ AUTHSVR の認証サービス AUTHSVC によって実行されます。
パスワードによる認証を有効にするには、以下の手順に従います。
*RESOURCES
SECURITY USER_AUTH
AUTHSVC “AUTHSVC”
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
パスワードによる認証用の 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 ページ「公開鍵によるセキュリティ機能の管理」を参照してください。
証明書による認証を有効にするには、以下の手順に従います。
証明書による認証を有効にするには、次のいずれかを実行します。
証明書による認証を有効にするには、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 セキュリティのコンフィギュレーション
ACL と MANDATORY_ACL との違いは次のとおりです。
オプションの ACL セキュリティでは、各クライアントは、アプリケーションに参加するため、アプリケーション・パスワード、ユーザ名、およびユーザ固有のデータ (パスワードなど) を提示しなければなりません。
オプションの ACL セキュリティをコンフィギュレーションするには、次の手順に従います。
*RESOURCES
SECURITY ACL
AUTHSVC “AUTHSVC”
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
必須の ACL セキュリティのコンフィギュレーション
必須の ACL セキュリティ・レベルでは、各クライアントは、CORBA アプリケーションと対話するため、アプリケーション・パスワード、ユーザ名、およびユーザ固有のデータ (パスワードなど) を提示しなければなりません。
必須の ACL セキュリティをコンフィギュレーションするには、以下の手順に従います。
*RESOURCES
SECURITY MANDATORY_ACL
AUTHSVC ..AUTHSVC
.
.
.
*SERVERS
AUTHSVR SRVGRP="group_name" SRVID=1 RESTART=Y GRACE=600 MAXGEN=2 CLOPT="-A"
CORBA アプリケーション間の ACL 方針の設定
管理者は、次のコンフィギュレーション・パラメータを使用して、別々の BEA Tuxedo ドメインにある CORBA アプリケーション間のアクセス制御リスト (ACL) 方針をコンフィギュレーションおよび管理します。
. 以下では、ACL_POLICY のコンフィギュレーションが、ローカル・ドメイン・ゲートウェイ (GWTDOMAIN) のプロセスの動作に与える影響について説明します。
このコンフィギュレーションでは、各アプリケーションに 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 クライアント・アプリケーションと相互運用するためのセキュリティのコンフィギュレーション
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 製品のセキュリティ機能を使用するクライアント・アプリケーションと相互運用できるようにします。
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |