Sun Java System Message Queue 3.7 UR1 管理ガイド

ユーザー承認: アクセス制御プロパティーファイル

アクセス制御プロパティーファイル (ACL ファイル) には、ユーザーおよびユーザーグループがどの操作を実行できるかを指定する規則が収められています。ACL ファイルを編集して、操作を特定のユーザーやグループに制限します。ブローカインスタンスごとに異なる ACL ファイルを使用できます。

ユーザー情報が単層型ファイルのユーザーリポジトリにある場合でも LDAP ユーザーリポジトリにある場合でも、ACL ファイルが使用されます。ブローカは、クライアントアプリケーションが次の操作のいずれかを実行するときに ACL ファイルをチェックします。

接続の作成
プロデューサの作成
コンシューマの作成
キューの検索

ブローカは ACL ファイルをチェックして、要求を生成したユーザーまたはユーザーが所属するグループに対して、操作の実行を許可するかどうかを決定します。

ACL ファイルを編集する場合、次にブローカがファイルをチェックして認証を検証するまで、新しい設定は有効になりません。ファイルの編集後、ブローカを再起動する必要はありません。

アクセス制御プロパティーファイルの作成

ACL ファイルはインスタンス固有です。ブローカインスタンスを起動する場合は常に、インスタンスディレクトリでデフォルトファイル accesscontrol.properties が作成されます。ファイルのパスは次のような形式です (付録 A 「プラットフォームごとの Message Queue^TM データの場所」を参照)。

…/instances/brokerInstanceName/etc/accesscontrol.properties

ACL ファイルは、Java プロパティーファイルのような形式になっています。ACL ファイルは、ファイルのバージョンを指定すると起動し、次の 3 つのセクションのアクセス制御規則を指定します。

接続のアクセス制御
物理的送信先のアクセス制御
物理的送信先の自動作成アクセス制御

version プロパティーでは、ACL プロパティーファイルのバージョンが定義されるので、このエントリを変更しないでください。

version=JMQFileAccessControlModel/100

アクセス制御を指定する ACL ファイルの 3 つのセクションについては、アクセス規則の基本構文およびアクセス権の計算方法に続いて、説明します。

アクセス規則の構文

ACL プロパティーファイルでは、アクセス制御は、特定のユーザーやグループが物理的送信先や接続サービスといった保護されたリソースに対してどのアクセスを持っているのかを定義します。アクセス制御は、それぞれ Java プロパティーとして提示されている規則、または規則のセットで表現されます。

これらの規則の基本的な構文は次のとおりです。

resourceType.resourceVariant

.operation.access.
principalType=principals

表 7–3 に構文規則の各要素を示します。

表 7–3 アクセス規則の構文要素


要素	説明
`resourceType`	次のうちのいずれか: `connection`、`queue`、`topic`。
`resourceVariant`	`resourceType` で指定されたタイプのインスタンス。たとえば、`myQueue`。ワイルドカードの文字 (*) を、すべての接続サービスの種類、またはすべての物理的な送信先を表すのに使用できます。
`operation`	公式化されているアクセス規則の種類に依存する値です。
`access`	次のうちのいずれか: `allow` か `deny`。
`principalType`	次のうちのいずれか: `user` か `group`。詳細は、「グループ」を参照してください。
`principals`	規則の左側で指定されるアクセス権を保持するユーザーを示します。ここでは、`principalType` が `user` の場合は個々のユーザーまたはコンマで区切られたユーザーのリストとなり、`principalType` が `group` の場合は 1 つのグループまたはコンマで区切られたグループのリストとなります。ワイルドカードの文字 (*) を、すべてのユーザーまたはすべてのグループを表すのに使用できます。

ここで、アクセス規則の例をいくつか紹介します。

次の規則では、あらゆるユーザーがメッセージを ql という名前のキューに送信します。
```
queue.q1.produce.allow.user=*
```
次の規則では、あらゆるユーザーがあらゆるキューにメッセージを送信します。
```
queue.*.produce.allow.user=*
```

注 –

ASCII でないユーザー、グループ、または送信先の名前を指定するには、Unicode エスケープ (\\uXXXX) の表記法を使用します。ASCII コードではない名前を含む ACL ファイルを編集して保存した場合、Java native2ascii ツールを使用して、ファイルを ASCII に変換できます。詳細は、次を参照してください。

http://java.sun.com/j2se/1.4/docs/guide/intl/faq.html

権限の計算方法

ファイル内に複数のアクセス規則が存在する場合、権限を次のように計算します。

特定のアクセス規則は、一般的なアクセス規則に優先します。次の 2 つの規則が適用されると、ユーザーはだれでもすべてのキューに送信できますが、Bob は tq1 に送信できません。
```
queue.*.produce.allow.user=*
queue.tq1.produce.deny.user=Bob
```
明示的な principal に指定されたアクセスは、* principal に指定されたアクセスに優先します。次の規則で、Bob は tq1 へのメッセージを生成できませんが、その他のユーザーはメッセージを生成できます。
```
queue.tq1.produce.allow.user=*
queue.tq1.produce.deny.user=Bob
```
ユーザーの * principal 規則は、グループの対応する * principal 規則に優先します。たとえば、次の 2 つの規則では、すべての認証済みユーザーがメッセージを tq1 に送信できます。
```
queue.tq1.produce.allow.user=*
queue.tq1.produce.deny.group=*
```
ユーザーに許可されたアクセスは、ユーザーのグループに許可されたアクセスに優先します。次の例では、Bob が User のメンバーである場合でも、tq1 へのメッセージは生成できません。User のその他のメンバーはすべて、メッセージを生成できます。
```
queue.tq1.produce.allow.group=User
queue.tq1.produce.deny.user=Bob
```
アクセスを介して明示的に指定されていないアクセス権は、暗黙的に拒否されます。たとえば、ACL ファイルにアクセス規則がない場合、すべてのユーザーはすべての操作を実行できません。
同じユーザーまたはグループにアクセス権の拒否と許可を行うと、すべてが取り消されます。たとえば、次の 2 つの規則が適用されると、Bob は q1 を検索できなくなります。
```
queue.q1.browse.allow.user=Bob
queue.q1.browse.deny.user=Bob
```
次の 2 つの規則は、グループ User が q5 でメッセージを消費するのを禁止します。
```
queue.q5.consume.allow.group=User
queue.q5.consume.deny.group=User
```
同じ左側の規則が複数ある場合、最後のエントリが有効になります。

接続サービスのアクセス制御

ACL プロパティーファイルの接続アクセス制御のセクションには、ブローカの接続サービスのアクセス制御規則が含まれます。接続アクセス制御規則の構文は次のとおりです。

connection.resourceVariant.
access.principalType=
principals

resourceVariant には 2 つの値が定義されています: NORMAL と ADMIN。これらの定義済みの値は、アクセス権を付与できる唯一のタイプの接続サービスです。

デフォルトの ACL プロパティーファイルは、すべてのユーザーに NORMAL 接続サービスへのアクセス権を付与し、グループ admin のユーザーに ADMIN 接続サービスへのアクセス権を付与します。

connection.NORMAL.allow.user=*
connection.ADMIN.allow.group=admin

ファイルベースのユーザーリポジトリを使用している場合、ユーザーマネージャーユーティリティーによりデフォルトのグループ admin が作成されます。LDAP ユーザーリポジトリを使用している場合、次のいずれかを実行して、デフォルトの ACL プロパティーファイルを使用します。

LDAP ディレクトリでグループ admin を定義します。
ACL プロパティーファイルの名前 admin を、LDAP ディレクトリで定義される 1 つ以上のグループの名前と置換します。

接続アクセス権限を制限できます。たとえば、次の規則では Bob が NORMAL にアクセスすることは拒否されますが、ほかのユーザーはすべてアクセスが許可されます。

connection.NORMAL.deny.user=Bob
connection.NORMAL.allow.user=*

アスタリスク (*) 文字を使用して、すべての認証済みユーザーまたはグループを指定できます。

ACL プロパティーファイルを使用して ADMIN 接続へのアクセスを付与する方法は、次のように、ファイルベースのユーザーリポジトリと LDAP ユーザーリポジトリでは異なります。

ファイルベースのユーザーリポジトリ
- アクセス制御が無効に設定されている場合、グループ admin には ADMIN 接続権限が割り当てられます。
- アクセス制御が有効な場合、ACL ファイルを編集します。ユーザーまたはグループに、ADMIN 接続サービスへのアクセス権を明示的に付与します。

LDAP ユーザーリポジトリ。LDAP ユーザーリポジトリを使用している場合、次のいずれかを実行します。
- アクセス制御を有効にします。
- ACL ファイルを編集して、ADMIN 接続を作成できるユーザーまたはグループの名前を指定します。LDAP ディレクトリサーバーで定義されるユーザーまたはグループを指定します。

物理的な送信先のアクセス制御

アクセス制御プロパティーファイルの送信先アクセス制御セクションには、物理的送信先ベースのアクセス制御規則が含まれます。これらの規則では、だれ (ユーザーまたはグループ) が何 (操作) をどこ (物理的送信先) に行うかが決定されます。これらの規則で統制されるアクセスのタイプには、キューへのメッセージの送信、トピックへのメッセージの発行、キューからのメッセージの受信、トピックへのサブスクライブ、キューでのメッセージの検索が含まれます。

デフォルトでは、あらゆるユーザーまたはグループが、任意の物理的送信先に対してあらゆるタイプのアクセス権を保持できます。さらに詳細な送信先アクセス規則を追加したり、デフォルトの規則を編集したりできます。この節の残りの部分では、自分自身の規則を記述するために理解しておく必要のある物理的送信先アクセス規則の構文について説明します。

送信先規則の構文は次のとおりです。

resourceType.resourceVariant.operation.access.principalType=principals

表 7–4 にこれらの要素の説明を示します。

表 7–4 送信先アクセス制御規則の要素


コンポーネント	説明
`resourceType`	`queue` か `topic` のいずれかです。
`resourceVariant`	物理的送信先名、またはすべてのキューやすべてのトピックを表す、すべての物理的送信先 (*) です。
`operation`	`produce`、`consume` または `browse` のいずれかです。
`access`	`allow` か `deny` のいずれかです。
`principalType`	`user` か `group` のいずれかです。

アクセス権は、1 人以上のユーザーまたは 1 つ以上のグループ、あるいはその両方に対して指定できます。

次の例では、さまざまな種類の物理的送信先のアクセス制御規則を示します。

すべてのユーザーが、あらゆるキュー送信先に対してメッセージを送信できます。
```
queue.*.produce.allow.user=*
```
user グループのメンバーがトピック Admissions にサブスクライブする機能を拒否します。
```
topic.Admissions.consume.deny.group=user
```

自動作成された物理的送信先のアクセス制御

ACL プロパティーファイルの最後のセクションには、どのユーザーおよびグループに対してブローカが物理的送信先を自動作成するのかを指定するアクセス規則が含まれます。

まだ存在していない物理的送信先でユーザーがプロデューサまたはコンシューマを作成すると、ブローカの自動作成プロパティーが有効になっている場合、ブローカは送信先を作成します。

デフォルトでは、任意のユーザーやグループは、ブローカに物理的送信先を自動作成させる権限を持っています。この権限は、次の規則で指定されます。

queue.create.allow.user=*
topic.create.allow.user=*

ACL ファイルを編集して、このタイプのアクセスを制限できます。

物理的送信先の自動作成アクセス規則の一般的な構文は、次のとおりです。

resourceType.create.access.principalType=principals

resourceType の部分には、queue か topic が表示されます。

たとえば次の規則により、ブローカは Snoopy 以外の全員に対してトピック送信先を自動作成できます。

topic.create.allow.user=*
topic.create.deny.user=Snoopy

物理的送信先の自動作成規則の結果は、物理的送信先のアクセス規則の影響と一致している必要があります。たとえば、1) 送信先アクセス規則を変更して、どのユーザーも送信先にメッセージを送信できないようにしてから、2) 送信先の自動作成を有効にすると、ブローカは物理的送信先が存在しない場合、物理的送信先を作成しますが、メッセージの配信は行いません。