|
|
|
|
|
|
デフォルトの認証と認可
BEA Tuxedo 製品の ATMI 環境に用意されている、デフォルトの認証および認可のプラグインは、BEA Tuxedo で最初に実現された、従来の認証および認可のインプリメンテーションと同じように機能します。
アプリケーション管理者は、デフォルトの認証および認可のプラグインを使用して、5 つのうち、1 つのセキュリティ・レベルを ATMI アプリケーションに設定できます。5 つのセキュリティ・レベルは、以下のとおりです。
最も低いセキュリティ・レベルでは、認証は行われません。最も高いセキュリティ・レベルでは、アクセス制御リストの機能により、サービスを実行し、イベントをポストし、アプリケーション・キューのメッセージをキューに登録 (または登録解除) するユーザが決定されます。次の表は、セキュリティ・レベルを簡単にまとめたものです。
注記 「クライアント」という用語は「クライアント・プロセス」と同義であり、実行中のクライアント・プログラムの特定のインスタンスを意味します。ATMI のクライアント・プログラムは、任意の数の個別インスタンスのアクティブ・メモリ内に存在することができます。
アプリケーション管理者は、UBBCONFIG コンフィギュレーション・ファイルの SECURITY パラメータに適切な値を設定することにより、セキュリティ・レベルを指定できます。
|
セキュリティ・レベル |
SECURITY パラメータに設定する値 |
|---|---|
|
認証なし |
なし |
|
アプリケーション・パスワードによるセキュリティ |
APP_PW |
|
ユーザ・レベルの認証 |
USER_AUTH |
|
オプションのアクセス制御リスト (ACL) |
ACL |
|
必須のアクセス制御リスト (ACL) |
MANDATORY_ACL |
デフォルト値は NONE です。SECURITY に USER_AUTH、ACL、または MANDATORY_ACL を設定した場合、アプリケーション管理者は、システム側で提供される AUTHSVR という名前の認証サーバを設定しなければなりません。AUTHSVR は、ユーザ単位で認証を行います。
アプリケーション開発者は、AUTHSVR を、ATMI アプリケーションに固有のロジックを持つ認証サーバに置き換えることができます。たとえば、広く使用されている Kerberos のメカニズムを使用して認証を行うため、認証サーバをカスタマイズすることもできます。
クライアントの名前付け
クライアント・プロセスは、ATMI アプリケーションに参加すると、ユーザ・クライアント名 (ユーザとクライアントを組み合わせた名前) およびアプリケーション・キー (一意なクライアント識別名) を持ちます。
tpsysadm および tpsysop という 2 つのクライアント名が、特殊なセマンティクス用に用意されています。tpsysadm は、アプリケーション管理者として扱われます。tpsysop は、アプリケーション・オペレータとして扱われます。
ユーザ/クライアント名
認証されたクライアントは、ATMI アプリケーションに参加すると、ユーザ名とクライアント名を TPINIT バッファの tpinit(3c) に渡すか (アプリケーションが C で記述されている場合)、または、TPINFDEF-REC レコードの TPINITIALIZE(3cbl) に渡します (アプリケーションが COBOL で記述されている場合)。次の表では、ユーザ名とクライアント名、および、TPINIT バッファまたは TPINFDEF-REC レコード内のその他のセキュリティ関連フィールドを説明します。
認証されたセキュリティ・レベル (USER_AUTH、ACL、または MANDATORY_ACL) では、ユーザ名、クライアント名、およびユーザ固有のデータは、BEA Tuxedo システムで変換されることなく AUTHSVR に転送されます。これらの情報が変換されるとすれば、ワークステーション・クライアントからネットワーク経由で送信されるときに暗号化が行われる場合のみです。
アプリケーション・キー
クライアントが ATMI アプリケーションに参加するたびに、BEA Tuxedo システムはクライアントに 32 ビットのアプリケーション・キーを割り当てます。クライアントは、アプリケーションとの関連付けを解除し、別のユーザとして ATMI アプリケーションに参加しない限り、このアプリケーション・キーをリセットできません。
割り当てられたアプリケーション・キーは、クライアントのセキュリティ・クリデンシャルです。クライアントは、TPSVCINFO 構造体の一部として、すべてのサービス呼び出しに appkey フィールドを指定します。TPSVCINFO の詳細については、『BEA Tuxedo C 言語リファレンス』 の tpservice(3c) を参照してください。
次の表は、さまざまなセキュリティ・レベルとクライアントに割当てられるアプリケーション・キーを示します。アプリケーション・キーの割り当ては、最後の項目を除き、すべてハードコーディングされます。
さらに、C プログラムの tpsvrinit(3c) または tpsvrdone(3c) (COBOL では TPSVRINIT(3cbl) または TPSVRDONE(3cbl)) から発信されるメッセージには、管理者のアプリケーション・キーである 0x80000000 が割り当てられます。クライアントのアプリケーション・キーは、クライアントからサーバに送信されるメッセージに割り当てられます。この規則の例外については、「クライアント・トークンとサーバ・トークンの交換」を参照してください。
ユーザ識別子 (UID) は、特定のユーザを示すため、アプリケーション側で使用される識別子であり、0 〜 128K の整数で表されます。グループ識別子 (GID) は、アプリケーション・グループを示すため、アプリケーション側で使用される識別子であり、0 〜 16K の整数で表されます。
ユーザ、グループ、および ACL のファイル
アクセス制御機能を使用するため、アプリケーション管理者は、(1) ユーザ、(2) グループ、および (3) グループとアプリケーション・エンティティ (サービス、イベント、およびアプリケーション・キューなど) のマッピング・リストを管理する必要があります。3 つ目のアプリケーション・エンティティへのグループのマッピング・リストは、アクセス制御リスト (ACL) と呼ばれます。
クライアントがサービスなどのアプリケーション・リソースに対してアクセスを試みると、システム側では、クライアントのアプリケーション・キーをチェックし、ユーザが属するグループを識別します。次に、システムは、ACL にあるターゲット・リソースをチェックし、そのリソースに対するアクセス権がクライアントのグループに付与されているかどうかを判別します。アプリケーション管理者、アプリケーション・オペレータ、およびアプリケーション管理者またはオペレータの権限で実行中のプロセスやサービス要求は、ACL によるパーミッションのチェックの対象にはなりません。
ユーザ、グループ、および ACL のファイルは、application_root ディレクトリに置かれています。application _root は、APPDIR 変数に定義された最初のパス名です。次の図は、これらのファイルと、各リストを制御するための管理コマンドを示しています。
デフォルトのユーザ、グループ、および ACL のファイル
注記 Compaq VMS オペレーティング・システムで動作する ATMI アプリケーションでは、ユーザ、グループ、および ACL ファイルの名前に .dat 拡張子が付きます (tpusr.dat、tpgrp.dat、および tpacl.dat など)。 これらのファイルは、コロンで区切られたフラットなテキスト・ファイルであり、アプリケーション管理者 (TUXCONFIG 変数が参照する TUXCONFIG ファイルの所有者) だけが読み書きできます。これらのファイルは一連の専用コマンドで完全に管理されるため、ファイルの形式は無関係です。これらのコマンドを使用できるのは、アプリケーション管理者だけです。 アプリケーション管理者は、tpaclcvt(1) コマンドを使用して、セキュリティに関するデータ・ファイルを ACL チェック用の形式に変換できます。たとえば、UNIX ホスト・マシンで tpaclcvt を実行して /etc/password ファイルを変換し、変換後のファイルを tpusr ファイルに保存できます。この管理者は、tpaclcvt を実行して /etc/group ファイルを変換し、変換後のファイルを tpgrp ファイルに保存することもできます。 AUTHSVRサーバは、tpusr ファイル内のユーザ情報を使用して、ATMI アプリケーションに参加しようとするユーザを認証します。 オプションの ACL と必須の ACL ACL および MANDATORY_ACL のセキュリティ・レベルは、BEA Tuxedo 製品の ATMI 環境用の、デフォルトの認可インプリメンテーションです。 セキュリティ・レベルが ACL の場合、ターゲット・アプリケーションのエンティティに関連するエントリが tpacl ファイルになくても、クライアントはそのエンティティにアクセスできます。管理者は、このセキュリティ・レベルで、より高度なセキュリティを必要とするリソースに対してだけアクセスを設定できます。つまり、すべてのユーザにアクセスを許可するサービス、イベント、およびアプリケーション・キューについて、tpacl ファイルにエントリを追加する必要はありません。 一方、セキュリティ・レベルが MANDATORY_ACL の場合、ターゲット・アプリケーションのエンティティに関連するエントリが tpacl ファイルにないと、クライアントはそのエンティティにアクセスできません。したがって、このレベルは「必須」と呼ばれます。クライアントがアクセスを必要とするアプリケーション・エンティティごとに、tpacl ファイル内にエントリが必要です。 ACL および MANDATORY_ACL のセキュリティ・レベルで、クライアントが、tpacl ファイルにエントリがあるエンティティに対してアクセスしようとする場合、クライアントに関連するユーザは、そのエンティティへのアクセスを許可されたグループのメンバでなければなりません。そうでない場合、アクセスは拒否されます。 ATMI アプリケーションによっては、システム・レベルとアプリケーション・レベルの両方の認可を使用することが必要な場合もあります。tpacl ファイルのエントリを使用すると、サービスに対するアクセスを許可するユーザを制限できます。また、アプリケーションのロジックを使用して、データ依存型のアクセスを制御することもできます。たとえば、100 万ドル以上のトランザクションを処理するユーザを指定することができます。 先頭にピリオド (.) が付く管理サービス、イベント、およびアプリケーション・キューは、ACL によるパーミッションのチェック対象にはなりません。たとえば、.SysMachineBroadcast、.SysNetworkConfig、および .SysServerCleaning などの管理イベントには、どのクライアントもサブスクライブできます。さらに、アプリケーション管理者、アプリケーション・オペレータ、およびアプリケーション管理者またはオペレータの権限で実行中のプロセスやサービス要求は、ACL によるパーミッションのチェックの対象にはなりません。 関連項目
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|