前へ     目次     索引     DocHome     次へ     
iPlanet Calendar Server プログラマリファレンス



第 8 章   シングルサインオン認証


この章では、iPlanet Calendar Server 5.0 に組み込まれているシングルサインオン認証メカニズムについて説明します。この方式は、ほかの認証メカニズム、セッション管理、およびリソースアクセスコントロールから独立しています。この認証メカニズムを使用するには、クライアントで cookie をサポートし、サーバで HTTP をサポートしている必要があります。シングルサインオンは、アプリケーションのパフォーマンスに影響を与えません。この方式では、セッションの一元管理は必要ありません。アプリケーションは独自のセッションを管理するので、別個のタイムアウトおよび取り消しポリシーを使用できます。

この章には、次のトピックが含まれます。



シングルサインオンとは

シングルサインオンでは、ユーザは一度署名すると複数のアプリケーションを使用できます。これらのアプリケーション間には、それぞれに設定した cookie を互いに認証として使用できる共通の検証システムがあるため、ユーザは各アプリケーションで別々に署名する必要はありません。

各アプリケーションでは、必要に応じて独自の照合インタフェースを使用できます。ただし、各照合機関には、ほかのアプリケーションの照合機関ルーチンが認識できる cookie を保存しておく必要があります。この章の「cookie 情報」を参照してください。



シングルサインオンの制限


シングルサインオンには前述した利点がありますが、使用に関して次のようないくつかの制限があります。

  • アプリケーションに照合プロトコルを実装する必要があります。この章の「留意点」を参照してください。

  • この方式は、マシンを共有する状況には適しません。

  • 各アプリケーションは、同じドメインに属し、相互のシングルサインオン照合 URL にアクセスできる必要があります。

  • 別のユーザに代わる場合は、ブラウザを再起動する必要があります。

    これは、各ブラウザセッションで 1 つのユーザ ID しかサポートできないためです。

  • クライアントが cookie をサポートしている必要があります。



処理の流れ

次の図に示すように、アプリケーションがアクセス要求を受信した時点で処理の流れが開始されます。共通の検証システムを持つ信頼された一連のアプリケーションは、同じ接頭辞を共有するため、プログラムは接頭辞が一致するすべての cookie を取り込みます。

そのアプリケーションに固有の cookie が見つからない場合、アプリケーションは、ほかの信頼されたアプリケーションに利用できる cookie があるかどうかを確認します。有効な cookie が見つかると、プログラムはこれらの cookie の情報を使用して、認証を照合し、セッションを確立します。アクセスを許可した場合は、アプリケーション固有の cookie を返送します。

信頼できるアプリケーションの接頭辞を持つ cookie がない場合、または利用可能な cookie が無効な場合は、ログイン画面を表示します。

図 8-1 に、シングルサインオンの処理の流れを示します。

図 8-1    シングルサインオンの処理の流れ



実装の要件


このシングルサインオンスキーマを使用するには、すべてのアプリケーションが次の要件を満たしている必要があります。

  • cookie の読み込みおよび書き込みができること

  • 次の追加構成パラメータをサポートしていること

    • 信頼されたアプリケーションのリスト

    • シングルサインオフ

    • 接頭辞の文字列

  • HTTP を経由したシングルサインオン照合プロトコルを実装していること

    • 要求 :

      要求には、ヘッダーにシングルサインオン cookie が含まれ、URL のパラメータとしてクライアント IP アドレスが指定されます。

      GET verificationurl client=clientIP HTTP/1.0

    • キーが有効な場合の応答 :

      各キーと値のペアが別々の行に示されたtext/plain 形式の ASCII 応答。timeremaining は、オプションです。

      fquid=ユーザ ID@完全修飾ドメイン名
      authtype=plaintext | cert | ...
      timeremaining=[このセッションのタイムアウトまでの残り時間]

    • キーが無効な場合の応答 :

      text/plain 形式の ASCII メッセージ :エラー :ユーザのセッションが無効です。

  • 構成ファイル ics.conf を編集して、一連の信頼されたアプリケーションの構成データを設定すること。構成ファイルの詳細は、『iPlanet Calendar Server 管理ガイド』を参照してください。シングルサインオン構成パラメータは、接頭辞 sso で始まります。


cookie 情報

cookie の形式は、次のとおりです。

構成可能な接頭辞-アプリケーションインストールの一意の識別子 =シングルサインオンキー


その他の推奨設定

  • ドメインを .domain name に設定する

  • パスを / に設定する

  • expires フィールドを設定しない


信頼されたアプリケーションレコード

追加構成パラメータの記憶域および形式はアプリケーション固有ですが、各レコードには次の内容が含まれている必要があります。

  • この特定の信頼されたプリケーションのインストールに一意の識別子

  • アプリケーションのホストになるマシンの完全修飾ドメイン名または IP アドレス

  • シングルサインオン照合プロトコルをサポートする URL

    例 :http://domain.com/VerifySSO?


シングルサインオフパラメータ

シングルサインオフパラメータは、このアプリケーションがシングルサインオフを実行するかどうかを示すブール値です。デフォルトは、true です。

  • true の場合、アプリケーションはユーザがログアウトした時点で、一連の信頼されたアプリケーションの接頭辞に一致するすべてのシングルサインオン cookie を削除します。

  • false の場合、アプリケーションはユーザがログアウトした時点で、独自のシングルサインオン cookie のみを削除します。


接頭辞の文字列

これは、一連の信頼されたアプリケーションのすべてのアプリケーションによって共有される共通の文字列です。別の接頭辞を選択することで、ドメイン内で複数の一連の信頼されたアプリケーションを作成することができます。



シングルサインオンの例


この例は、シングルサインオンのサイクルが達成される手順を示しています。


例

参加するアプリケーションは、この一連の信頼されたアプリケーションの接頭辞として ssogrp1 を使用します。このサークルの信頼されたアプリケーションは、WebMail、WebCal、および HRapp です。

  1. John はメールをチェックします。

    WebMail は、208.12.60.3 上で作業している jsmith からログイン要求を受信します。WebMail は、名前の一部に ssogrp1 が含まれる cookie を検索しますが、該当する cookie は存在しません。WebMail はユーザに認証を求めるプロンプトを表示し、接頭辞文字列 ikey-、この WebMail インストールの一意の識別子 (3fr7d)、およびシングルサインオンキー (l3khj5l3k9ldh) を含む cookie を返送します。これらの接頭辞文字列、一意の識別子、およびシングルサインオンキーが、セッション ID となります。

    返される cookie は、ssogrp13fr7d=l3khj5l3k9ldh です。

  2. John は、次にカレンダーをチェックします。

    • WebCal は、208.12.60.3 上で作業している jsmith からログイン要求を受信します。WebCal で見つかった ssogrp1* cookie は、
      ssogrp13fr7d=l3khj5l3k9ldh だけでした。WebCal は、構成ファイルで次のエントリを見つけました。

      3fr7d.verificationurl=http://webmail host/VerifySSO?

    • WebCal は、次の HTTP GET を発行します。

      GET http://webmail host/VerifySSO?client=208.12.60.3 HTTP/1.0

      Cookie: ssogrp13fr7d=l3khj5l3k9ldh

    • WebMail は、これが有効なキーであることを確認して、次の応答を返します。

      fquid=jsmith@example.com
      authtype=plaintext
      timeremaining=1000

    • WebCal は、John 用のシングルサインオンキー a97ads64 を生成し、cookie として ssogrp1lkj87f=a97ads64 を返送します。

  3. John は、しばらくの間ネットサーフィンをしたあとで、もう一度カレンダーをチェックします。

    • WebCal は、208.12.60.3 上で作業している jsmith からログイン要求を受信します。

    • WebCal は、いくつかの ssogrp1 cookieを見つけました。そのうちの 1 つが、WebCal の一意のアプリケーション ID (lkj87f) に一致しました。

      WebCal は、cookie として ssogrp1lkj87f=a97ads64 を返送します。

    • WebCal は、セッション ID をシングルサインオンキーとして使用しているので、自身のセッションデータベースからセッション a97ads64 を得て、セッションが依然として有効であることを確認して、ユーザにアクセスを許可します。

  4. John は、会社の HR アプリケーションにアクセスする必要があります。このアプリケーションは、証明書による認証を必要とします。

    HR アプリケーションは、社内で開発されたもので、照合プロトコルをサポートするように変更されています。

    • HRapp は、208.12.60.3 上で作業している jsmith からログイン要求を受信します。

      このアプリケーションは証明書による認証を必要としているため、クライアントに証明書の送信を求めます。

    • HRapp は、ssogrp1* cookie の確認は行いません。

    • HRapp は、John 用のセッション ID B53P997KD を生成し、cookie として
      ssogrp1adf38=lka79jy5d3l3r を返送します。

      この cookie により、ほかの参加アプリケーションは HRapp を照合機関として使用できるようになります。

  5. John はもう一度メールをチェックして、ログアウトすることにしました。

    • WebMail は、208.12.60.3 上で作業している jsmith からログアウト要求を受信します。

    • WebMail は、John の WebMail セッションを無効にすると同時に、すべての
      ssogrp1* cookie を削除します。

  6. この時点では、John がアプリケーションにアクセスする場合は、もう一度ログインする必要があります。


この例の構成パラメータ

  • 接頭辞 :sso.appprefix="ssogrp1"

  • シングルサインオフのブール値 :sso.singlesignoff="true"

  • アプリケーション情報 :

    • WebMail:

      appid=3fr7d

      3fr7d.ip=198.93.96.111

      3fr7d.verificationurl=http://Webmail ホスト/VerifySSO?

    • WebCal:

      lkj87f.ip=198.93.78.103

      lkj87f.verificationurl=http://Webcal ホスト/VerifySSO?

    • HRapp:

      adf38.ip=198.93.70.8

      adf38.verificationurl=http://HR ホスト/VerifySSO?



留意点

この節では、次の 4 つの領域に関する留意点、仮定、および要件について説明します。


セキュリティ

  • シングルサインオンキーとクライアント IP アドレスの正しい組み合わせを推測するのは非常に困難であると仮定しているので、照合プロトコルに対して認証を要求する必要はありません。

  • プロキシを使用してクライアント接続を確立する場合、シングルサインオンキーは唯一の防衛手段になります。そのため、キーの予測が非常に困難であることはきわめて重要です。

  • セキュリティ保護されたシングルサインオンキーは、アプリケーションで生成する必要があります。

  • 各シングルサインオンキーが長時間にわたって有効にならないように、アプリケーションでセッションタイムアウトを短時間に設定することも役に立ちます。

  • HTTPS は、通信を保護する目的で使用できます。アプリケーションでクライアントの証明書による認証が必要な場合は、常にクライアントに対して証明書を要求する必要があります。とはいうものの、このアプリケーションは依然としてほかのアプリケーションのための照合機関の役目をすることができます。


管理

  • すべてのアプリケーションは、信頼されたアプリケーションのリストを保持する必要があります。各アプリケーションは、異なるメカニズムを使用してそのリストの保管および管理を行うことができます。

  • シングルサインオンキーを生成したアプリケーションだけがそのキーを無効にすることができます。管理者は、すべてのアプリケーションに対するユーザのアクセス権を簡単に無効にすることはできません。


スケーラビリティ

cookie の数の制限 :

  • 合計で 300 の cookie

  • サーバまたはドメインごとに 20 の cookie。完全指定のホストおよびドメインは別のエントリとして計算され、それぞれの cookie の数は 20 に制限されます


パフォーマンス

  • ほかのアプリケーションに対する照合要求は、一度しか行われません。アプリケーションのセッションがいったん確立されると、照合プロトコルは行われません。

  • ブラウザに古い cookie (無効なシングルサインオンキーを持つ cookie) がたくさん記録されていると、新しいアプリケーションにログインするときに時間がかかることがあります。

    ただし、これは次の理由により、めったに起きません。

    • 各アプリケーションは、ユーザがログアウトする時点で自身の cookie を削除します (アプリケーションがシングルサインオフを実行する場合は、該当する接頭辞を含むシングルサインオン cookie をすべて削除します)。

    • アプリケーションは、cookie が複数のブラウザセッションにわたって持続しないように expires フィールドを空白のままにします。


前へ     目次     索引     DocHome     次へ     
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated June 04, 2001