前へ 目次 索引 DocHome 次へ |
iPlanet Calendar Server 5.1 プログラマーズマニュアル |
第 5 章 シングルサインオン認証
この章では、iPlanet Calendar Server に組み込まれているシングルサインオン認証メカニズムについて説明します。このスキームは、他の認証メカニズム、セッション管理、およびリソースアクセス制御から独立しています。この認証メカニズムを使用するには、クライアントで cookie をサポートし、サーバで HTTP をサポートしている必要があります。シングルサインオンは、アプリケーションのパフォーマンスに影響を与えません。このスキームでは、セッションの一元管理は必要ありません。アプリケーションは独自のセッションを管理するため、個別のタイムアウトおよび取り消しポリシーを持つことができます。
シングルサインオンとは
シングルサインオンとは
シングルサインオンでは、ユーザは 1 度サインオンすると複数のアプリケーションを使用できます。これらのアプリケーションは権限の検証に相互の cookie を使用する信頼サークルを形成するので、ユーザは各アプリケーションで個別にサインオンする必要はありません。各アプリケーションでは、必要に応じて独自の検証インタフェースを使用できます。ただし、各検証機関には、他のアプリケーションの検証機関ルーチンで認識できる cookie を格納する必要があります。この章のcookie 情報を参照してください。
シングルサインオンの制限
シングルサインオンには、前述の利点がありますが、使用に関して次の制限があります。
アプリケーションに検証プロトコルを実装する必要があります。この章の「問題点」を参照してください。
各アプリケーションは、同じドメインに属し、相互のシングルサインオン検証 URL にアクセスできるようにする必要があります。
ユーザが別の ID に切り替える場合は、ブラウザを再起動する必要があります。
クライアントが cookie をサポートしている必要があります。
- これは、各ブラウザセッションで 1 つのユーザ ID しかサポートできないためです。
プロセスフロー
次の図に示すように、アプリケーションがアクセスリクエストを受信した時点でフローが開始されます。信頼アプリケーションのサークルは、同じ接頭辞を共有するため、プログラムは接頭辞が一致するすべての cookie を取り込みます。自身の cookie が見つからない場合は、アプリケーションは他の信頼アプリケーションで利用できる cookie があるかを確認します。有効な cookie が見つかると、プログラムはこれらの cookie 情報を使用して権限を検証し、セッションを確立します。アクセスを許可する場合は、アプリケーション固有の cookie を返送します。
このサークルの接頭辞で利用できる cookie がない場合、または使用できる cookie が無効な場合は、ログイン画面が表示されます。
図 5-1 に、シングルサインオンのプロセスフローを示します。
図 5-1    シングルサインオンのプロセスフロー
実装の条件
このシングルサインオンスキームにするには、サークルのすべてのアプリケーションが次の条件を満たしている必要があります。
cookie の読み込みおよび書き込みが可能なこと
HTTP 上でシングルサインオン検証プロトコルを実装していること
リクエスト
構成ファイル ics.conf を編集して、信頼サークルの構成データを設定すること。構成ファイルの詳細は、『iPlanet Calendar Server 管理者ガイド』を参照してください。シングルサインオン構成パラメータは、接頭辞 sso で始まります。
キーが有効な場合の応答
- リクエストには、ヘッダー内にシングルサインオン cookie が含まれ、URL のパラメータとしてクライアント IP アドレスがある。
- GET verificationurl client=clientIPHTTP/1.0
キーが無効な場合の応答
- 各キー値のペアが別々の行に示された text / plain ASCII 応答。timeremaining はオプション。
- fquid= ユーザ id @完全修飾ドメイン名
authtype=plaintext | cert | ...
timeremaining=[このセッションのタイムアウトまでの残り時間]
信頼アプリケーションレコード
追加構成パラメータの記憶域および形式は、アプリケーションに固有ですが、各レコードには次の事項が含まれている必要があります。
シングルサインオフパラメータ
シングルサインオフパラメータは、このアプリケーションがシングルサインオフを実行するかどうかを示す論理値です。デフォルトは true です。
値が true の場合、アプリケーションはユーザがログオフした時点で、信頼サークルの接頭辞に一致するすべてのシングルサインオン cookie を削除します。
値が false の場合、アプリケーションはユーザがログオフした時点で、自身のシングルサインオン cookie のみを削除します。
接頭辞の文字列
これは、信頼サークルのすべてのアプリケーションが共有する共通の文字列です。別の接頭辞を選択すると、1 つのドメイン内で複数の信頼サークルを作成できます。
シングルサインオンの例
この例は、シングルサインオンのサイクルが完了するまでの手順を示しています。
例
参加するアプリケーションは、この信頼サークルの接頭辞として ssogrp1 を使用します。このサークルの信頼アプリケーションは、WebMail、WebCal、および HRapp です。
John がメールをチェックします。
次に、John がカレンダーをチェックします。
- WebMail は、208.12.60.3 で実行中の jsmith からログインリクエストを受け取ります。WebMail は、名前の中に ssogrp1 が含まれているcookie を検索します。該当する cookie がありません。WebMail は、ユーザに認証を求めるプロンプトを表示し、接頭辞の文字列 ikey-、この WebMail の一意識別子 (3fr7d)、およびセッション ID となるシングルサインオンキー (l3khj5l3k9ldh) が含まれている cookie を返送します。
- 返される cookie は、ssogrp13fr7d=l3khj5l3k9ldh です。
WebCal は、208.12.60.3 で実行中の jsmith からログインリクエストを受け取ります。WebCal で見つかった ssogrp1* cookie は、ssogrp13fr7d=l3khj5l3k9ldh だけでした。WebCal は、構成ファイルで次のエントリを検索します。
John は、しばらくインターネットを検索した後で、もう一度カレンダーをチェックします。WebCal は次の HTTP GET を発行します。
WebMail は、これが有効なキーであることを認識して、次の応答を返します。
WebCal は、John に対してシングルサインオンキー a97ads64 を生成し、cookie ssogrp1lkj87f=a97ads64 を返送します。
WebCal は、208.12.60.3 で実行中の jsmith からログインリクエストを受け取ります。
John は、会社の人事アプリケーションにアクセスする必要があります。このアプリケーションは、証明書認証を必要とします。WebCal は、いくつかの ssogrp1 cookie を見つけました。そのうちの 1 つが、WebCal の一意のアプリケーション ID (lkj87f) に一致します。
WebCal はセッション ID をシングルサインオンキーとして使用するため、セッションデータベースからセッション a97ads64 を検索し、セッションの有効性を確認して、ユーザに処理を許可します。
HRapp は、208.12.60.3 で実行中の jsmith からログインリクエストを受け取ります。
John はもう一度メールをチェックしてログオフします。HRapp は、ssogrp1* cookie の確認は行いません。
HRapp は John に対してセッション ID B53P997KD を生成し、cookie ssogrp1adf38=lka79jy5d3l3r を返送します。
WebMail は、208.12.60.3 で実行中の jsmith からログオフリクエストを受け取ります。
John がいづれかのアプリケーションにアクセスする場合は、もう一度ログインする必要があります。WebMail は、John の WebMail セッションを無効にし、ssogrp1* cookie もすべて削除します。
問題点
この節では、次の 4 つの領域に関する問題点、想定、および条件について説明します。
シングルサインオンキーとクライアント IP アドレスの正しい組み合わせを推測することは、非常に困難であると想定しているため、検証プロトコルに対して認証を要求する必要はありません。
プロキシを使用してクライアント接続を確立する場合は、シングルサインオンキーは唯一の防衛手段になります。そのため、予測しにくいキーを設定することが大変重要です。
セキュリティで保護されたシングルサインオンキーは、アプリケーションで生成する必要があります。
アプリケーションでセッションタイムアウトを短時間に設定して、各シングルサインオンキーの有効期間が長くならないようにすることも有効です。
HTTP は、通信を保護する目的で使用できます。アプリケーションでクライアント証明書認証が必要な場合は、必ずクライアントに証明書を要求する必要があります。ただし、このアプリケーションは引き続き他のアプリケーションの検証機関として機能します。
すべてのアプリケーションは、信頼アプリケーションリストを保持する必要があります。各アプリケーションは、異なるメカニズムを使用してそのリストの格納および管理を行うことができます。
シングルサインオンキーを生成したアプリケーションのみが、そのキーを無効にすることができます。管理者は、すべてのアプリケーションに対するユーザのアクセスを簡単に無効にできません。
合計で 300 の cookie
サーバまたはドメインごとに 20 の cookie。完全指定のホストおよびドメインは別のエントリとして計算され、それぞれの cookie の数は 20 に制限されます。
他のアプリケーションに対する検証リクエストは、一度しか行われません。アプリケーションセッションがいったん確立されると、検証プロトコルは不要になります。
ブラウザに無効な cookie (無効なシングルサインオンキーを持つ cookie) が多数保存されている場合は、新しいアプリケーションへのログオンに時間がかかることがあります。
前へ 目次 索引 DocHome 次へ
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
最終更新日: 2002 年 1 月 30 日