Sun Java System Calendar Server 6 2005Q4 管理ガイド

カレンダのアクセス制御

Calendar Server は、ACL (アクセス制御リスト) を使用して、カレンダ、カレンダプロパティー、予定や仕事 (作業) などのカレンダコンポーネントへのアクセスを制御します。

ここで説明する内容は次のとおりです。

セキュリティー保護された Calendar Server へのログイン

ユーザーが Communications Express 経由で Calendar Server にログインする場合、デフォルトでは、認証プロセスはユーザー名とパスワードを含むログイン情報を暗号化しません。サイトへのセキュリティー保護されたログインを希望する場合は、SSL (Secure Sockets Layer) プロトコルを使用してログインデータを暗号化するように Calendar Server を設定します。詳細は、第 8 章「SSL の設定」を参照してください。

ユーザー別のアクセス制御

カレンダ、カレンダプロパティー、カレンダコンポーネントへのアクセスの可否を決定する上で、Calendar Server は次のユーザーを区別します。

一次カレンダ所有者

一次カレンダ所有者は、所有するカレンダに対する完全なアクセス権を持ちます。一次カレンダ所有者が本人所有のカレンダにアクセスする場合、Calendar Server はアクセス制御チェックを一切行いません。
管理者とスーパーユーザー

calmaster などの管理者、または root などのスーパーユーザーは、アクセス制御の対象とはならず、カレンダまたはカレンダコンポーネントに対してどのような処理も実行できます。詳細は、「Calendar Server の特別なアカウント」を参照してください。
その他のカレンダ所有者

一次カレンダ所有者は、本人が所有するカレンダにその他の所有者を指定できます。その他の所有者は一次所有者に代わって予定や仕事 (作業) のスケジューリング、削除、変更、了解、拒否を実行できます。
anonymous ユーザー

ics.conf ファイルの service.http.allowanonymouslogin が “yes” (デフォルト) に設定されている場合、特別なカレンダ ID (calid) である anonymous は、任意のパスワードを使用して Calendar Server にアクセスできます。anonymous ユーザーは、特定のドメインに関連付けられていません。calstore.anonymous.calid パラメータを編集することにより、anonymous ユーザーの calid を変更できます。

カレンダのアクセス権が全員に読み取りアクセスを許可している場合にも、カレンダを匿名で表示できます。たとえば、次のリンクを使用することにより、ユーザーは tchang:meetings という calid のカレンダを匿名表示できます (全員にカレンダへの読み取りアクセス権が許可されている場合)。

http://calendar.sesta.com:8080/?calid=tchang:meetings

anonymous ユーザーは、カレンダ上で公開されている予定と仕事を表示、印刷、検索することはできますが、その他の処理は行えません。

リソースカレンダの匿名表示については、「カレンダへのリンク設定」を参照してください。

アクセス制御リスト (ACL)

Calendar Server は、カレンダ、カレンダプロパティー、予定や仕事 (作業) などのカレンダコンポーネントへのアクセスを制御するために、ACL (アクセス制御リスト) を使用します。ACL は、1 つ以上の ACE (アクセス制御エントリ) から構成されます。ACE は同じカレンダまたはコンポーネントに集合的に適用される文字列であり、ACL 内の各 ACE はセミコロンで区切られます。次に例を示します。

jsmith^c^wd^g には 1 つの ACE が含まれる。
@@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g には 3 つの ACE が含まれる。

ACE には次の要素が含まれ、各要素はキャレット (^) で区切られます。

「Who」: ACE の適用対象となる個人、ユーザー、ドメイン、またはユーザータイプ。
「What」: アクセスの対象となるターゲット。カレンダ、予定や仕事 (作業) などのカレンダコンポーネント、カレンダプロパティーなど。
「How」: 許可されるアクセス権の種類。読み取り、書き込み、削除など。
「Grant」: 許可または拒否される具体的なアクセス制御権。

たとえば、jsmith^c^wd^g という ACE は次のように機能します。

jsmith は ACE の適用対象を示す Who 要素。
c はアクセス対象ターゲットを示す What 要素 (カレンダコンポーネントのみ)。
wd は許可または拒否されるアクセス権の種類を示す How 要素 (書き込みと削除)。
g はカレンダコンポーネントに対する特定のアクセス権 (書き込みと削除) を jsmith に与えることを示す Grant 要素。

Who

Who 要素は、個人、ユーザー、ドメイン、特定のユーザータイプなど、ACE の適用対象を指定する ACE の主要値です。

Who 要素は UPN (Universal Principal Name) と呼ばれます。ユーザーの UPN はユーザーのログイン名とユーザーのドメインを組み合わせたものです。たとえば、ドメイン sesta.com に属するユーザー bill の UPN は、bill@sesta.com です。

表 1–2 ACE (アクセス制御エントリ) 文字列の “Who” 要素の形式


形式	説明
`user`	特定のユーザーを表します。例: jsmith。
`user@domain`	特定ドメインの特定ユーザーを表します。例: `jsmith@sesta.com`
`@domain`	指定ドメインの任意のユーザーを表します。例: `@sesta.com` は、`jsmith@sesta.com`、`sally@sesta.com`、および `sesta.com` に属する任意のユーザーを表します。ドメインのユーザー全体を対象にアクセスを許可または拒否するときは、この形式を使用します。
`@`	すべてのユーザーを表します。
`@@{d\|p\|o\|n}`	カレンダの所有者を表します。 `@@d`: 一次所有者のドメイン `@@p`: 一次所有者のみ `@@o`: 一次所有者を含むすべての所有者 `@@n`: 所有者以外

What

What 要素は、カレンダ、カレンダコンポーネント (予定または作業)、カレンダプロパティーなど、アクセスの対象となるターゲットを指定します。

表 1–3 ACE (アクセス制御エントリ) 文字列の “What” 要素の値

値

説明

予定や作業などのカレンダコンポーネントを指定します

名前、説明、所有者などのカレンダプロパティーを指定します

コンポーネントとプロパティーの両方を含むカレンダ全体 (すべて) を指定します

How

How 要素は、読み取り、書き込み、削除など、許可されるアクセス権の種類を指定します。

表 1–4 ACE (アクセス制御エントリ) 文字列の “How” 要素の種類


種類	説明
`r`	読み取りアクセス。
`w`	書き込みアクセス。新規項目の追加、既存項目の変更を含みます。
`d`	削除アクセス。
`s`	スケジュール (出席依頼) アクセス。要求の送信、応答の受け付け、その他の ITIP スケジューリング操作を実行できます。
`f`	空き/予定ありアクセス権のみ。空き/予定ありアクセスでは、ユーザーはカレンダにスケジュールされている時刻を確認することはできますが、予定の詳細を確認することはできません。その代わりに、スケジュールが組まれている時間帯には「利用不可」だけが表示されます。予定がスケジュールされていない時間帯には、「空き時間」が表示されます。
l	ドメインのルックアップアクセス
`e`	応答アクセスの代行操作。このアクセス権を持つユーザーは、カレンダの一次所有者に代わって出席依頼を受け入れるか、または拒否することができます。ユーザーがカレンダの一次所有者以外の所有者として指定された段階で暗黙的に付与される権限であるため、このアクセス権を明示的に付与する必要はありません。
`i`	出席依頼アクセスの代行操作。このアクセス権を持つユーザーは、カレンダの一次所有者に代わってほかのユーザーに出席を依頼したコンポーネントを作成、変更することができます。ユーザーがカレンダの一次所有者以外の所有者として指定された段階で暗黙的に付与される権限であるため、このアクセス権を明示的に付与する必要はありません。
`c`	キャンセルアクセスの代行操作。このアクセス権を持つユーザーは、カレンダの一次所有者に代わってほかのユーザーに出席を依頼したコンポーネントを取り消すことができます。ユーザーがカレンダの一次所有者以外の所有者として指定された段階で暗黙的に付与される権限であるため、このアクセス権を明示的に付与する必要はありません。
`z`	自己管理アクセス。認証されたユーザーは、アクセス制御エントリを追加または削除する権限を付与されます。この権限を持つユーザーは、自分自身で権限を追加したり削除したりすることができます。たとえば、UserA は、UserB のカレンダへの書き込みアクセス権はありませんが、UserB のカレンダへの自己管理アクセスを許可されているとします。これにより、UserA は、UserB のカレンダへの書き込みアクセスを自分自身に許可するためのアクセス制御エントリを追加できます。注: この特権を使用した場合も、UserA は、UserB のカレンダへのアクセスをほかのユーザーに許可することはできません。たとえば、UserA が自己管理の特権を使用して、UserB のカレンダへのアクセスを UserC に許可することはできません。

Grant

Grant 要素は、d (削除) や r (読み取り) など、指定されたアクセス権の許可または拒否を指定します。

表 1–5 ACE (アクセス制御エントリ) 文字列の Grant 要素の値


値	説明
`g`	指定したアクセス制御権を付与します。
`d`	指定したアクセス制御権を拒否します。

ACE の例

次に、ACE の使用例を示します。

コンポーネントとプロパティーの両方を含むカレンダ全体に対する読み取りアクセス権をユーザー ID jsmith に付与します。

jsmith^a^r^g
コンポーネントだけに対する書き込みアクセス権と削除アクセス権を jsmith に付与します。

jsmith^c^wd^g
sesta.com ドメインのすべてのユーザーに、コンポーネントのみに対するスケジュール、予定状況、読み取りのアクセス権を付与します。

@sesta.com^c^sfr^g
コンポーネントだけに対する書き込みアクセス権と削除アクセス権をすべての所有者に付与します。

@@o^c^wd^g
カレンダデータに対する jsmith によるあらゆるアクセスを拒否します。

jsmith^a^sfdwr^d
コンポーネントとプロパティーの両方を含むカレンダ全体に対する読み取り、スケジュール、空き時間確認のアクセス権をすべての所有者に付与します。

@@o^a^rsf^g
すべてのユーザーに読み取りアクセス権を付与します。

@^a^r^g

ACL への ACE の配置

Calendar Server は、ACL を読み取るときに、ターゲットに対するアクセスの許可または拒否を指示する ACE のうち、最初に見つかったものを使用します。このため、ACL の順序は重要で、より一般的な制御の前に、より具体的な制御が配置されるように ACE 文字列の順序を決定する必要があります。

たとえば、カレンダ jsmith:sports の ACL 内の最初の ACE がすべてのユーザーに読み取りアクセス権を付与すると仮定します。次に、Calendar Server はこのカレンダに対する bjones によるアクセスを拒否する第 2 の ACE を見つけます。この場合、Calendar Server はこのカレンダに対する読み取りアクセス権を bjones に付与し、最初の ACE と矛盾する第 2 の ACE は無視されます。このため、bjones のような特定のユーザーのアクセス権を有効にするには、カレンダのすべてのユーザーに適用される ACE のように一般的なエントリの前に、bjones 用の ACE を配置する必要があります。