前へ     目次     索引     DocHome     次へ     
iPlanet Calendar Server 管理者ガイド



第 1 章   iPlanet Calendar Server の概要


Calendar Server は、企業とサービスプロバイダを対象とした、集中型カレンダー操作とスケジュール設定を集中化するスケーラブルな Web ベースソリューションです。Calendar Server は、個人カレンダーやグループカレンダー、および会議室や各種備品といったリソースのカレンダーをサポートします。

この章では、次の項目について説明します。



Calendar Server 管理者


Calendar Server 管理者 (calmaster)

Calendar Server 管理者は、Calendar Server を管理できるユーザ名と関連するパスワードです。このユーザは、Calendar Server に対する管理特権を持ちますが、ディレクトリサーバに対する管理特権は持ちません。デフォルトのユーザ ID は calmaster ですが、希望すれば、インストール時に他のユーザを指定することができます。インストール後、ics.conf ファイル内の service.admin.calmaster.userid に別のユーザを指定することができます。

Calendar Server 管理者として指定するユーザ ID は、ディレクトリサーバ内で有効なユーザアカウントにする必要があります。Calendar Server 管理者のユーザアカウントが、インストール時にディレクトリに存在していない場合には、インストール終了後にこのアカウントを追加する必要があります。たとえば、デフォルトの calmaster を受け入れる場合には、calmaster という名前のユーザがディレクトリサーバに存在していなければなりません。

表 1-1 では、ics.conf ファイル内の Calendar Server 管理者構成パラメータについて説明しています。


表 1-1    Calendar Server 管理者構成パラメータ 

パラメータ

説明

service.admin.calmaster.userid  

Calendar Server 管理者として指名されたユーザのユーザ ID。Calendar Server のインストール時にこの必須の値を与える必要がある。デフォルトは、calmaster  

service.admin.calmaster.cred  

Calendar Server 管理者として指名されたユーザ ID のパスワード。Calendar Server のインストール時にこの必須の値を与える必要がある  

caldb.calmaster  

Calendar Server 管理者の電子メールアドレス。デフォルトは root@localhost  

service.admin.calmaster.overrides.accesscontrol  

Calendar Server 管理者が、アクセス制御をオーバーライドできるかどうかを示す。デフォルトは no  

service.admin.calmaster.wcap.allowgetmodifyuserprefs  

Calendar Server 管理者が、WCAP コマンドによってユーザ設定の取得と設定を行えるかどうかを示す。デフォルトは no  

service.admin.ldap.enable  

service.admin.calmaster.userid に指定されているユーザのユーザ認証に対し、LDAP を有効にする。デフォルトは yes  


Calendar Server のユーザおよびグループ (UNIX のみ)

Solaris および他の UNIX システムの場合、これらのアカウントは Calendar Server を稼動する UNIX ユーザ ID とグループ ID です。デフォルト値である icsuser と icsgroup を使用することを iPlanet はお勧めします。これらのデフォルト値が存在しない場合には、インストールプログラムによって自動的に作成されます。icsuser 値は ics.conf ファイルの local.serveruid パラメータに、icsgroup 値は同ファイルの local.servergid パラメータに格納されています。


root (UNIX のみ)

Solaris および他の UNIX システムで Calendar Server のインストール、再インストール、またはアップグレードを行うときには、root (ユーザ ID = 0) としてログインするか、root になる必要があります。コマンド行ユーティリティを使用して Calendar Server を管理するには、root や icsuser などの管理者としてログインするか、root や icsuser になる必要があります。


Windows NT 管理者

Windows NT システムで Calendar Server のインストールや管理を行うには、システムに対する完全な管理権限を持つ管理者としてログインする必要があります。



Calendar Server ユーザ



Calendar Server ユーザの作成

Calendar Server ユーザの作成は、手動と自動のどちらでも行えます。

  • 手動の場合−管理者は、ディレクトリサーバのツールを使用してディレクトリサーバにユーザを追加し、Calendar Server の cscal ユーティリティを使用してユーザのデフォルトカレンダーを作成できます。ユーザがディレクトリサーバに存在していない場合、管理者は Calendar Server の csuser ユーティリティを使用して、ユーザとカレンダーの両方を同時に作成できます。

  • 自動の場合−ユーザがディレクトリサーバにすでに存在している場合、Calendar Server はユーザが初めてログインしたときに、自動的にデフォルトカレンダーを作成します。Calendar Server は、そのユーザのユーザ ID をデフォルトカレンダーのカレンダー ID (calid) として使用します (その名前のカレンダーがすでに存在している場合を除く)。

    たとえば、TChang はディレクトリサーバに存在していますが、カレンダー操作はまだ有効になっていません (つまり、デフォルトカレンダーを持っていません)。TChang が初めて Calendar Server にログインする際、TChang のカレンダー操作が自動的に有効になり、TChang という calid を持つデフォルトカレンダーが作成されます。


Calendar Server ユーザの認証

iPlanet Calendar Server は、カレンダー、カレンダーのプロパティ、アクセス制御情報、イベント、予定 (todo)、およびアラームの格納と管理を行います。ただし、Calendar Server でユーザの認証とユーザ設定の格納と検索を行うには、LDAP サーバのようなディレクトリサービスが必要です。

デフォルトの Calendar Server は、Netscape Directory Server などの LDAP ディレクトリで定義および維持されるユーザをサポートします。LDAP 以外のディレクトリサーバに定義されているユーザがアクセスできるようにするために、Calendar Server では Calendar Server API (CSAPI) プラグインもサポートしています。

詳細については、「新しい Calendar Server ユーザのプロビジョニング」を参照してください。



Calendar Server データ


データのアクセス制御の詳細については、「Calendar Server アクセス制御」を参照してください。


Calendar Server データ形式

Calendar Server のデータ形式は、RFC 2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar) をもとにモデル化されています。 Calendar Server は、カレンダー、カレンダーのプロパティ、アクセス制御情報、イベント、予定 (todo)、およびアラームの格納と管理を行います。ただし、Calendar Server はユーザ情報の管理は行いません。ユーザ認証やユーザ設定の格納と検索のような処理を行うには、ディレクトリサービスが必要です。


Calendar Server の形式の符号化

Calendar Server は、次の形式の符号化をサポートします。

  • SHTML (.shtml)−デフォルト

  • XML (.xml)−WCAP のみ

  • iCalendar (.ical)−WCAP のみ

Calendar Express のビューとダイアログ用に独自の XSL 変換を開発すると、ほかの形式を追加できます。また、CSAPI を使用すると、WCAP プロトコルのための変換 DLL や共有ライブラリを開発できます。

CSAPI の詳細については、『iPlanet Calendar Server プログラマーズマニュアル』を参照してください。


カレンダーグループ

カレンダーグループとは、名前のついた独立したカレンダーリストです。グループカレンダーによって、複数のカレンダーを 1 つのカレンダーにまとめて表示できます。たとえば、ユーザは個人のカレンダー、部門カレンダー、会社の祝日カレンダーで構成されるカレンダーグループを持つことができます。

カレンダーグループの作成や購読を行い、そのカレンダーグループの表示や変更を行えます (アクセス制御が適用されます)。カレンダーグループを表示できることによって、複数のカレンダーを並べて表示したり、それぞれのカレンダー所有者をイベントに招待したりする際に、カレンダーのリストを選択する必要がなくなります。


Calendar Server イベントフィード

Calendar Server はイベントフィードをサポートしているので、ユーザは iCalendar (.ics) または XML (.xml) の形式で、カレンダーデータのインポートとエクスポートが行えます。エンドユーザは、Calendar Express を使用してデータのインポートとエクスポートが行えます。詳細については、Calendar Express のオンラインヘルプを参照してください。

また、祝日スケジュール、コンベンションセンターのスケジュール、コンサートのスケジュール、およびその他の興味あるイベントのスケジュールのような、イベントやグループのカレンダーも購読できます。

Calendar Server 管理者は、csimport と csexport のコマンド行ユーティリティを使用してもカレンダーデータのインポートとエクスポートが行えます。


Calendar Server のデータ交換とアラーム

カレンダーは電子メールメッセージと Web ページ内に埋め込むリンクとして参照されることができます。リンクをクリックすればカレンダーを表示することができ、カレンダーが読み取りアクセスを許可している場合には、ユーザは Calendar Server にログインする必要はありません。たとえば、次のリンクは Auditorium というリソース室を指定します。

http://calendar.sesta.com:8080/?calid=Auditorium

Calendar Server は、サーバ側の電子メールアラームをサポートします。このアラームは、受取人リストに送信できます。電子メールメッセージの形式は、ユーザやカレンダーの属性としてではなく、サーバの属性として構成および管理されます。Calendar Server は、イベントのために PUBLISH、REQUEST、REPLY、および CANCEL のITIP メソッドを含む ITIP/IMIP 標準 (RFC-2446 と RFC-2447) を制限付きでサポートします。


Calendar Server ユーザ設定

Calendar Server は、ユーザ設定と呼ばれる属性に従って、各々のユーザのカレンダー情報の表示をカスタマイズします。ユーザ設定 (カレンダー設定とは対象的に) は、ユーザインタフェースにカレンダー情報を表示する方法を指定します。ユーザ設定には、電子メールアドレス、ユーザ名、およびカレンダー情報を描画するときに使用する色などがあります。設定のリストについては、『iPlanet Calendar Server プログラマーズマニュアル』にある「get_userprefs コマンド」と 「set_userprefs コマンド」の項を参照してください。



Calendar Server アーキテクチャ


複雑な Calendar Server 構成については、「Calendar Server の導入構成」を参照してください。


Calendar Server 内部サブシステム

Calendar Server には、次の内部サブシステムを構成する共有ライブラリの集合が組み込まれています。

図 1-1 は、これらのサブシステムの論理フローを示しています。

図 1-1    Calendar Server 内部サブシステムの論理フロー




プロトコルサブシステム

コマンドと要求が HTTP プロトコル層に入ります。これは、カレンダー要求をサポートするために簡素化した、最小限の HTTP サーバ実装です。

クライアントは、SHTML または Web Calendar Access Protocol (WCAP) を使用して要求を発行します。

  • SHTML は、コマンドに応答してユーザインタフェースを生成する XML と XSLT の仕様に準拠し、それらはコマンドに応答しユーザインターフェースを生成します。要求に応答して、UI ジェネレータは、アクセス制御を適用し、カレンダーとユーザデータを持つドキュメントツリーの作成に、XML 仕様を使用します。次に、XSLT 仕様がドキュメントデータツリーを走査し、HTML を作成します。この設計より、クライアントとサーバとの対話が少なくなり、ネットワークトラフィックが減少します。UI ジェネレータにより生成される HTML のカスタマイズについては、iPlanet ドキュメント web サイト「Calendar Express Customization Tips」を参照して下さい。

  • WCAP は、一部の管理コマンド以外のあらゆるサーバコマンドが実行可能な公開プロトコルです。WCAP は、フォーマットされていない生のカレンダー情報を必要とするクライアントが使用します。また、JavaScript ベースのユーザインタフェースを取得するときにも使用できます。WCAP コマンド (つまり、.wcap 拡張子を使用するコマンド) は、HTML にラップされた XML や iCalendar として出力を要求することもできます。

    WCAP の詳細については、『iPlanet Calendar Server プログラマーズマニュアル』を参照してください。


コアサブシステム

コアサブシステムは、アクセス制御サブシステム、UI ジェネレータサブシステム (XML と XSLT を使用する SHTML、またはデータ変換機能を使用する WCAP)、caldb サブシステム、および CSAPI プラグインで構成されます。コアサブシステムはカレンダー要求を処理し、目的の UI 出力を生成します。また、以下のユーザ認証もコアサブシステムが処理します。


データベースサブシステム

データベースサブシステムは、Sleepycat Software 製バークレー DB を使用します (データベース API は公開されていません)。データベースサブシステムは、イベント、予定 (todo)、およびアラームを含むカレンダーデータをデータベースに格納したり、データベースから取り出したりします。カレンダーデータは iCalendar 形式をベースにしており、Calendar Server データに使用されるスキーマは iCalendar 標準のスーパーセットです。データベースサブシステムは低レベルの形式でデータを返し、コア UI ジェネレータ (SHTML または WCAP) がこの低レベルデータを目的の出力に変換します。

分散カレンダーストアの場合、Calendar Server はデータベースワイヤプロトコル (DWP) を使用してネットワーキング機能を提供します。詳細については、「分散データベースサービス - csdwpd」を参照してください。

データベース管理の詳細については、csdb ユーティリティを使用するデータベースとカレンダーデータの管理方法について解説している第 5 章「Calendar Server データベースの管理」を参照してください。


Calendar Server サービス

これらのサービスは、プロセス (UNIX システムの場合はデーモン) として実行されます。使用している構成に基づいて、1 台のマシン上で実行される場合と複数のマシン上で実行される場合とがあります。


管理サービス - csadmind

Calendar Server の各インスタンスについて、csadmind サービスが必要です。このサービスは 1 か所で Calendar Server 管理の認証を提供します。また、サービスの起動と停止、ユーザのリストやログアウト、ユーザやリソースの作成と削除、カレンダーのフェッチと格納、およびカウンタのフェッチとリセットなどを行うコマンドのようなほとんどの管理ツールを提供します。また、csadmind サービスは、アラームの通知、グループスケジュール設定の要求、データベースのチェックポイントの設定、デッドロックの検出、およびディスク使用状況とサーバ応答の監視なども管理します。


HTTP サービス - cshttpd

Calendar Server は HTTP をプライマリトランスポートとして使用するので、cshttpd サービスは HTTP コマンドを待機します。cshttpd はユーザコマンドを受け取り、受け取ったコマンドの形式に基づいてデータを呼び出し側に返します。

  • デフォルトの .shtml 拡張子とともに受け取ったコマンドの場合、cshttpd は HTML でフォーマットしたデータを返します。

  • .wcap 拡張子とともに受け取ったコマンドの場合、 cshttpd は標準の RFC2445 iCalendar 形式のカレンダーデータ (text/calendar) として、XML 形式 (text/xml) で 、または HTML に埋め込まれた JavaScript 形式 (text/js) としてフォーマットされたデータを返します。


通知サービス - csnotifyd

csnotifyd サービスは、イベントブローカとしてイベント通知サービス (ENS) を使用して、イベントと予定 (todo) の通知を送信します。csnotifyd は、アラームイベントの購読も行います。アラームイベントが発生すると、csnotifyd は SMTP メッセージアラームを受取人に送信します。


イベント通知サービス (ENS) - enpd

enpd サービスはイベント通知サービス (ENS) の一部であり、イベントアラームのブローカとして動作します。 enpd は csadmind サービスからアラームの通知を受け取り、このイベントの購読の有無を確認し、"subscrided-to" のアラーム通知を csnotifyd に渡すことによってイベントの購読者に通知します。また、csnotifyd から購読および購読取り消し (購読解除) を受信し、これらを格納します。


分散データベースサービス - csdwpd

csdwpd サービスを利用すると、同じ Calendar Server システム内で複数のサーバを直結して分散カレンダーストアを形成することができます。csdwpd は、Calendar Server がインストールされている任意のサーバ上にバックグラウンドで実行できます。このサービスは、データベースワイヤプロトコル (DWP) に準拠するカレンダー情報の要求を受け付けます。DWP は、Calendar Server データベースのネットワーキング機能を提供するために使用される内部プロトコルです。

csdwpd サービスは、ローカルカレンダーデータベースがあるサーバ上でのみ実行し、インストールされているほかの Calendar Server がこのカレンダーデータにネットワーク経由のアクセスを提供する必要があります。

DWP は、比較的高速なネットワークで使用してください。複数のデータベースをつなぐネットワークが遅い場合、DWP によってシステム全体の性能が低下することがあります。


基本的な Calendar Server 構成

Calendar Server は、組織のさまざまなニーズを満たすように構成することができます。たとえば、スタンドアロンサーバとして使用することもできれば、さまざまな Calendar Server サービスをインスタンス間で重複させたり分割したりして、複数のインスタンスで構成することもできます。

この節では、このような基本的な Calendar Server 構成について説明します。

複雑な Calendar Server 構成については、「Calendar Server の導入構成」を参照してください。


最小規模の Calendar Server 構成

図 1-2 は、以下で構成される最小規模の Calendar Server 構成を示しています。

  • イベント通知をサポートする、単一インスタンスの Calendar Server。この構成は、必須である管理サービス (csadmind)、入力される SHTML と WCAP の要求を処理する HTTP サービス (cshttpd)、およびイベント通知サービス (ENS) である enpd と csnotifyd から成ります。

  • LDAP サーバなどのディレクトリサービス。

図 1-2 の CLD は、Calendar Lookup Database です。CUA は Calendar User Agent のことであり、カレンダークライアントが Calendar Server へのアクセスに使用するアプリケーションです。iCal は、RFC 2445、Internet Calendaring and Scheduling Core Object Specification (iCalendar) のことです。カレンダーデータベースはローカルなので、データベースワイヤプロトコル (DWP) サービスは不要です。

図 1-2    最小規模の Calendar Server 構成




スケーラブルな Calendar Server 構成

Calendar Server は、垂直方向と水平方向の両方向に拡張できます。Calendar Server は、1 台のマシンの複数のプロセッサで稼動することも、複数のマシン上で稼動することもできます。Calendar Server は、cshttpd、csadmind、csdwpd、csnotifyd、および enpd の各サービスで構成されます。これらのサービスをさまざまな構成で実行できるため、強力な柔軟性とスケーラビリティが得られます。

Calendar Server では複数のマシンあたりに 1 つのインストレーションを分散する、水平方向のスケーラビリティがサポートされます。水平方向のスケーラビリティを実現するには、Calendar Server のさまざまなインスタンスを複数のマシンにまたがってインストールします。各システムの基本要件は、次のとおりです。

  • 各 Calendar Server インスタンスに管理サービス (csadmind) を持たせる必要があります。ただし、イベント通知サービス (ENS) である enpd と csnotifyd を別のインスタンスにインストールする場合、csadmind サービスは不要です。

  • その他の Calendar Server サービスはすべて、1 回以上インストールする必要があります。ただし、ローカルデータベースを使用して、単一インスタンスをインストールする場合は例外です。このようなインストールの場合、カレンダーデータベースがローカルなので、DWP (csdwpd) サービスは不要です。

図 1-3 は、3 個の Calendar Server データベースサービスを使用する 3 個の Calendar Server HTTP フロントエンドサービスを示しています。この 6 個のインスタンスすべてを別々のマシン上で実行することができます。

この構成では、データベースワイヤプロトコル (DWP) を使用します。DWP は、Calendar Server データベースのためのネットワーキング機能を提供する内部プロトコルです。DWP は HTTP が基盤となっており、HTTP の POST コマンドまたは GET コマンドと、直列化されたバイナリデータベース情報が入った 1 つのバイナリ MIME 部で構成されます。詳細については、「分散データベースサービス - csdwpd」を参照してください。

図 1-3    スケーラブルな Calendar Server 構成





Calendar Server アクセス制御


Calendar Server は、アクセス制御リスト (ACL) を使用してカレンダー、カレンダーのプロパティ、およびイベントや仕事 (todo) などのカレンダーコンポーネントへのアクセス制御を決定します。ACL は、1 つまたは複数のアクセス制御エントリ (ACE) で構成されます。これらのアクセス制御エントリは、同じカレンダーやコンポーネントに一括して適用される文字列です。ACL 内の各 ACE は、セミコロンで区切る必要があります。たとえば、次のようになります。

  • jsmith^c^wd^g は、1 つの ACE で構成されます。

  • @@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g は、3 個の ACE で構成されます。

Calendar Server のアクセス制御機能は、次のとおりです。

  • カレンダープロパティ - カレンダーの削除や ACL を含めて、カレンダープロパティの変更を行えるのは、カレンダーの 1 次所有者または管理者だけです。

  • グループスケジューリング - 開催者がグループイベントをスケジューリングする際、Calendar Server は ACL を使用して招待者のカレンダーに対するアクセスを決定します。たとえば、イベント開催者が見ることができるのは出席予定者の空き時間/予定ありの時間だけであり、出席予定者のカレンダー全体は見られないということがあります。

  • その他の所有者 - カレンダーの 1 次所有者は、自分の代わりを務めるカレンダーの他の所有者を指定できます。たとえば、副社長などの 1 次所有者は、管理アシスタントを任命することによって、会議のスケジュール設定や出席予定者への出席依頼または他の人がスケジュールした会議への出席依頼に対する辞退や受諾を代わりに管理アシスタントに行わせることができます。

エンドユーザは、Calendar Express を使用して自分のカレンダーのアクセス制御を設定します。Calendar Server 管理者は、ics.conf ファイルにアクセス制御構成パラメータを設定し、cscal、csresource、および csuser のコマンド行ユーティリティを使用することができます。

詳細については、第 4 章「Calendar Server アクセス制御の管理」を参照してください。



Calendar Server の API と SDK


これらの API の詳細については、『iPlanet Calendar Server プログラマーズマニュアル』を参照してください。


Calendar Server API (CSAPI)

Calendar Server API (CSAPIを使用すると、プログラマはユーザのログイン認証、アクセス制御、およびカレンダーの検索といった Calendar Server の機能領域をカスタマイズできます。

たとえば、デフォルトの場合、Calendar Server は LDAP サーバにあるエントリを使用してユーザの認証とユーザ設定の格納を行います。LDAP に基づかない他のメカニズムがあれば、既存の認証とディレクトリサービスを CSAPI によって実装し、デフォルトの Calendar Server メカニズムをオーバーライドすることができます。


イベント通知サービス (ENS) API

イベント通知サービス (ENS) は、アラームキュー上のイベントを検出し、それらのイベントの通知を購読者に送信する、アラームディスパッチャです。ENS API を使用すると、Calendar Server で使用される公開と購読に関する機能を、イベントの購読、イベントの購読解除、およびイベント購読者への通知、といった機能に変更できます。ENS API は、次の API で構成されます。

  • 公開済み API

  • 購読者 API

  • 公開と購読ディスパッチャ API


プロキシ認証 SDK (authSDK)

Calendar Server には、ユーザ認証用として authSDK が用意されています。authSDK を使用すると、既存のポータルサービスを Calendar Server に統合できるため、再認証を要求せずに、ユーザにさまざまなアプリケーションへのアクセスを許可できます。

Calendar Server と authSDK との間で接続が確立されると、信頼関係が形成されます。ユーザがログインして authSDK で認証されると、Calendar Server はプロキシがその機能のために生成した証明書を受け入れます。

authSDK は、DLL/共有オブジェクトライブラリ (libicsexp10) に入っている次の関数とヘッダ (ファイル、expapi.h) で構成されます

  • CEXP_GenerateLoginURL は、有効なセッション ID を持つ URL を生成

  • CEXP_GetVersion は、バージョン ID 文字列を生成

  • CEXP_Init は、SDK を初期化

  • CEXP_SetHttpPort によって、Calendar Server との接続時に使用するポートを指定することができる

  • CEXP_Shutdown は、メモリーの解放と接続のシャットダウンを含むすべてのシャットダウン手順を行う


Web カレンダーアクセスプロトコル (WCAP)

Calendar Server 5.x は、クライアントとの通信を実現する高レベルのコマンドベースプロトコルである WCAP 2.0 をサポートします。.wcap 拡張子を使用する WCAP コマンドによって、クライアントは、カレンダーコンポーネント、ユーザ設定、カレンダープロパティ、およびタイムゾーンなどの他のカレンダー情報を取得、変更、および削除することができます。時間、文字列、パラメータといった WCAP 要素は、原則として RFC2445、RFC2446、および RFC2447 の仕様に準拠しています。

WCAP は、次の形式の HTTP メッセージでカレンダーデータの出力を返します。

  • 標準の RFC2445 iCalendar 形式 (text/calendar)

  • XML 形式 (text/xml)

  • HTML に埋め込まれた JavaScript (text/js)

WCAP コマンドを使用している場合、login.wcap を使用してログインした Calendar Server 管理者は、次の処理を行えます。

  • WCAP コマンドのアクセス制御をオーバーライドする。

    管理者は、WCAP コマンドを使用して他のユーザのカレンダーの読み込み (フェッチ)、変更 (格納)、および削除を行うことができます。管理者がこの特権を持つには、ics.conf ファイル内の次のパラメータが yes に設定されている必要があります。

    service.admin.calmaster.overrides.accesscontrol="yes"

  • 任意のユーザのユーザ設定を検索して変更する。

    管理者は、get_userprefs.wcap と set_userprefs.wcap を使用して、任意のユーザの設定を検索して変更することができます。管理者がこの特権を持つには、ics.conf ファイル内の次のパラメータが yes に設定されている必要があります。

    service.admin.calmaster.wcap.allowmodifyuserprefs="yes"

詳細については、『iPlanet Calendar Server プログラマーズマニュアル』を参照してください。



シングルサインオン (SSO)


シングルサインオン (SSO) により、一度認証されたユーザは複数のアプリケーションを使用することができます。たとえば、iCalendar Express にログインしたユーザは、再度認証されなくても Messenger Express を使用できます。

SSO は、他の認証メカニズム、セッション管理、およびリソースアクセス制御からは独立しています。SSO を使用すると、アプリケーションは cookie を共有する信頼サークルを形成し、互いのユーザ認証を受け入れます。各検証機関は、他のアプリケーションの検証ルーチンが認識する cookie を格納します。必要に応じて、各アプリケーションは独自の検証インタフェースを持つこともできます。

SSO には、次の要件があります。

  • クライアントブラウザは、cookie を受け入れる必要がある。

  • 各アプリケーションは、検証プロトコルを実装している必要がある。

  • すべての信頼されるアプリケーションが同一ドメインに属している必要がある。

  • 1 つのブラウザセッションがサポートするのは 1 つのユーザ ID だけであるため、別の ID に切り替えるにはブラウザを再起動する必要があります。

アプリケーション間の SSO を有効にするには、各アプリケーションを設定する必要があります。Calendar Server の構成方法の詳細については、「シングルサインオン (SSO) の構成」を参照してください。



Calendar Server の導入構成


最小規模の Calendar Server 構成 (図 1-2) と スケーラブルな Calendar Server 構成
(図 1-3) を加えた、2 つの Calendar Server 構成を次に示します。

(特定サイトの要件に応じた、上記以外の Calendar Server 構成も可能です。)


ネットワークフロントエンド、単一データベースバックエンド

図 1-4 は、クライアントブラウザとアプリケーションが、フロントエンド (cal.example.com) の HTTP (cshttp) を介して Calendar Server に接続する構成を示しています。カレンダーデータに対する要求はすべて、DWP (csdwpd) サービスを使用してバックエンド (caldb.example.com) にルーティングされます。

フロントエンドはデータベース処理を行わないので、フロントエンドで必要となるのは HTTP サービス (cshttp) と管理サービス (csadmind) だけです。バックエンドでは cshttpd は不要ですが、管理サービス (csadmind) と DWP サービス (csdwpd)、および enpd と csnotifyd のイベント通知サービス (ENS) は必要です。

図 1-4    ネットワークフロントエンド、データベースバックエンド




複数のフロントエンド、複数のデータベースバックエンド

図 1-5 は、ユーザ提供メカニズムによって、複数のフロントエンド HTTP サービス (cshttp) の 1 つにクライアントがルーティングされる構成を示しています。ログイン時に返されるセッション ID は、ログインが行われるホストシステムでのみ有効です。このセッション ID に対する要求はすべて、同一のホストにルーティングされる必要があります。そうでなければ、ユーザは再度ログインしなければならなくなります。

この例では、カレンダー A-M は caldb1.example.com サーバに、カレンダー N-Z は caldb2.example.com サーバに、データベースが分散されています。CSAPI プラグインは、カレンダー ID とカレンダーが存在するサーバとのマッピングを処理します。(Calendar Server が提供するデフォルトの CSAPI 実装では、カレンダー ID とサーバ名を関連付けるアルゴリズムを使用します。詳細については、「カレンダー検索データベースプラグイン」を参照してください。)

各フロントエンドは、HTTP サービス (cshttp) と管理サービス (csadmind) を必要とします。カレンダーデータに対する要求はすべて、DWP (csdwpd) サービスを使用して該当するバックエンドにルーティングされます。各バックエンドは、管理サービス (csadmind) と DWP サービス (csdwpd) 、および enpd と csnotifyd のイベント通知サービス (ENS) が必要です。

図 1-5    複数のフロントエンド、複数のデータベースバックエンド




前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最終更新日： 2002 年 1 月 22 日