前へ     目次     索引     DocHome     次へ     
iPlanet Calendar Server 5.1 プログラマーズマニュアル



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


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

この章は、以下の節で構成されています。



シングルサインオンとは

シングルサインオンでは、ユーザは 1 度サインオンすると複数のアプリケーションを使用できます。これらのアプリケーションは権限の検証に相互の cookie を使用する信頼サークルを形成するので、ユーザは各アプリケーションで個別にサインオンする必要はありません。

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



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


シングルサインオンには、前述の利点がありますが、使用に関して次の制限があります。

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

  • このスキームは、マシンを共有する状況には適していません。

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

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

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

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



プロセスフロー

次の図に示すように、アプリケーションがアクセスリクエストを受信した時点でフローが開始されます。信頼アプリケーションのサークルは、同じ接頭辞を共有するため、プログラムは接頭辞が一致するすべての cookie を取り込みます。

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

このサークルの接頭辞で利用できる cookie がない場合、または使用できる cookie が無効な場合は、ログイン画面が表示されます。

図 5-1 に、シングルサインオンのプロセスフローを示します。

図 5-1    シングルサインオンのプロセスフロー



実装の条件


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

  • cookie の読み込みおよび書き込みが可能なこと

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

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

    • シングルサインオフ

    • 接頭辞の文字列

  • HTTP 上でシングルサインオン検証プロトコルを実装していること

    • リクエスト

      リクエストには、ヘッダー内にシングルサインオン cookie が含まれ、URL のパラメータとしてクライアント IP アドレスがある。

      GET verificationurl client=clientIPHTTP/1.0

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

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

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

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

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

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


cookie 情報

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

configurable prefix-application installation unique identifier=single sign-on key


その他の推奨設定

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

  • パスを / に設定する

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


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

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

  • 特定の信頼アプリケーションの一意識別子

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

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

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


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

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

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

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


接頭辞の文字列

これは、信頼サークルのすべてのアプリケーションが共有する共通の文字列です。別の接頭辞を選択すると、1 つのドメイン内で複数の信頼サークルを作成できます。



シングルサインオンの例


この例は、シングルサインオンのサイクルが完了するまでの手順を示しています。


例

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

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

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

    返される 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 は、会社の人事アプリケーションにアクセスする必要があります。このアプリケーションは、証明書認証を必要とします。

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

    • 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 host/VerifySSO?

    • WebCal:

      lkj87f.ip=198.93.78.103

      lkj87f.verificationurl=http://webcal host/VerifySSO?

    • HRapp:

      adf38.ip=198.93.70.8

      adf38.verificationurl=http://hr host/VerifySSO?



問題点

この節では、次の 4 つの領域に関する問題点、想定、および条件について説明します。


セキュリティ

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

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

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

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

  • HTTP は、通信を保護する目的で使用できます。アプリケーションでクライアント証明書認証が必要な場合は、必ずクライアントに証明書を要求する必要があります。ただし、このアプリケーションは引き続き他のアプリケーションの検証機関として機能します。


管理

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

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


スケーラビリティ

cookie の数の制限:

  • 合計で 300 の cookie

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


パフォーマンス

  • 他のアプリケーションに対する検証リクエストは、一度しか行われません。アプリケーションセッションがいったん確立されると、検証プロトコルは不要になります。

  • ブラウザに無効な cookie (無効なシングルサインオンキーを持つ cookie) が多数保存されている場合は、新しいアプリケーションへのログオンに時間がかかることがあります。

    ただし、この現象は次の 2 つ理由により、頻繁には発生しません。

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

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


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

最終更新日: 2002 年 1 月 30 日