(57)【要約】【課題】  複数のコンピュータによって分散されているユーザ情報を統合的に扱うことのできるユーザ情報取扱い装置、ユーザ情報取扱いプログラム及び記録媒体の提供を目的とする。【解決手段】  複数のユーザのユーザ情報を取り扱うユーザ情報取扱い装置であって、クライアントからの第一のユーザ情報の取得要求を受信し、該取得要求に含まれているユーザ特定情報に基づいて該第一のユーザ情報の取得先を判定する取得先判定手段と、前記取得先判定手段によって判定された取得先として前記第一のユーザ情報を取得する一つ以上のユーザ情報取得手段とを有し、少なくとも一部の前記ユーザ情報取得手段は、前記第一のユーザ情報の取得要求をネットワークを介して接続する他のユーザ情報取扱い装置に送信することにより上記課題を解決する。【選択図】  図５
2005259111.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザのユーザ情報を取り扱うユーザ情報取扱い装置であって、
クライアントからの第一のユーザ情報の取得要求を受信し、該取得要求に含まれているユーザ特定情報に基づいて該第一のユーザ情報の取得先を判定する取得先判定手段と、
前記取得先判定手段によって判定された取得先として前記第一のユーザ情報を取得する一つ以上のユーザ情報取得手段とを有し、
少なくとも一部の前記ユーザ情報取得手段は、前記第一のユーザ情報の取得要求をネットワークを介して接続する他のユーザ情報取扱い装置に送信することを特徴とする第一のユーザ情報取扱い装置。
【請求項２】
前記少なくとも一部のユーザ情報取得手段は、前記他のユーザ情報取扱い装置を識別するための委譲先識別情報を有することを特徴とする請求項１記載の第一のユーザ情報取扱い装置。
【請求項３】
前記クライアントからの前記第一のユーザ情報の取得要求に含まれている前記ユーザ特定情報は、該ユーザ特定情報によって特定されるユーザが属するドメインのドメイン名を含んでおり、
前記取得先判定手段は、前記ドメイン名に基づいて前記第一のユーザ情報の取得先を判定することを特徴とする請求項１又は２記載の第一のユーザ情報取扱い装置。
【請求項４】
前記ドメイン名ごとに前記第一のユーザ情報の取得先を識別する取得先識別情報を管理する取得先識別情報管理手段を有し、
前記取得先判定手段は、前記ユーザ特定情報に含まれている前記ドメイン名と前記取得先識別情報管理手段とに基づいて、前記第一のユーザ情報の取得先を判定することを特徴とする請求項３記載の第一のユーザ情報取扱い装置。
【請求項５】
前記第一のユーザ情報の取得要求は、前記ユーザ特定情報によって特定されるユーザの認証要求であることを特徴とする請求項１乃至４いずれか一項記載の第一のユーザ情報取扱い装置。
【請求項６】
前記少なくとも一部のユーザ情報取得手段は、前記他のユーザ情報取扱い装置に送信した前記認証要求に対する応答として、前記ユーザが認証された旨を示す第一の証明情報を前記他のユーザ情報取扱い装置より受信し、
前記取得先判定手段は、前記少なくとも一部のユーザ情報取得手段が受信した前記第一の証明情報を、前記クライアントからの前記第一のユーザ情報の取得要求に対する応答として前記クライアントに送信することを特徴とする請求項５記載の第一のユーザ情報取扱い装置。
【請求項７】
請求項６記載の第一のユーザ情報取扱い装置からの前記認証要求に応じ、該認証要求に含まれている前記ユーザ特定情報に基づいて前記ユーザの認証を行い、前記ユーザが認証された場合に前記第一の証明情報を提供する第一の証明情報提供手段と、
前記第一のユーザ情報取扱い装置より前記第一の証明情報を受信した前記クライアントからの前記第一の証明情報を伴った第二のユーザ情報の取得要求に応じ、前記クライアントに所定のサービスを利用させる際に、該所定のサービスに対して提示が要求される第二の証明情報を提供する第二の証明情報提供手段とを有することを特徴とする第二のユーザ情報取扱い装置。
【請求項８】
前記第二の証明情報提供手段は、前記第二のユーザ情報の取得要求に伴う前記第一の証明情報が、前記第一のユーザ情報取扱い装置より前記ユーザの認証要求を受けた際に提供したものである場合は、前記第二の証明情報を提供することを特徴とする請求項７記載の第二のユーザ情報取扱い装置。
【請求項９】
前記第一の証明情報提供手段が提供した前記第一の証明情報を保持する証明情報保持手段を有し、
前記第二の証明情報提供手段は、前記第二のユーザ情報の取得要求に伴う前記第一の証明情報が前記証明情報保持手段に保持されている場合は、前記第二の証明情報を提供することを特徴とする請求項７又は８記載の第二のユーザ情報取扱い装置。
【請求項１０】
前記第二の証明情報提供手段は、前記第一の証明情報について前記第二の証明情報を提供するための有効期限が切れていない場合は、前記第二の証明情報を提供することを特徴とする請求項７乃至９いずれか一項記載の第二のユーザ情報取扱い装置。
【請求項１１】
前記第二のユーザ情報の取得要求は、前記クライアントに利用させるサービスを識別するサービス識別情報を伴っており、
前記第二の証明情報提供手段は、前記サービス識別情報によって識別されるサービスに対応した前記第二の証明情報を提供することを特徴とする請求項７乃至１０いずれか一項記載の第二のユーザ情報取扱い装置。
【請求項１２】
クライアントからのユーザの認証要求に応じ、該認証要求に含まれているユーザ特定情報に基づいて前記ユーザの認証を行い、前記ユーザが認証された場合に前記ユーザが認証された旨を示す第一の証明情報を提供する第一の証明情報提供手段と、
前記クライアントから第二のユーザ情報の取得要求を前記第一の証明情報と共に受信した請求項６記載の第一のユーザ情報取扱い装置からの前記第二のユーザ情報の取得要求に応じ、前記クライアントに所定のサービスを利用させる際に前記所定のサービスに対して提示が要求される第二の証明情報を提供する第二の証明情報提供手段とを有することを特徴とする第三のユーザ情報取扱い装置。
【請求項１３】
前記第二の証明情報提供手段は、前記第一のユーザ情報取扱い装置からの前記第二のユーザ情報の取得要求に伴う前記第一の証明情報が、前記クライアントより前記ユーザの認証要求を受けた際に提供したものである場合は、前記第二の証明情報を提供することを特徴とする請求項１２記載の第三のユーザ情報取扱い装置。
【請求項１４】
前記第一の証明情報提供手段が提供した前記第一の証明情報を保持する証明情報保持手段を有し、
前記第二の証明情報提供手段は、前記第二のユーザ情報の取得要求に伴う前記第一の証明情報が前記証明情報保持手段に保持されている場合は、前記第二の証明情報を提供することを特徴とする請求項１２又は１３記載の第三のユーザ情報取扱い装置。
【請求項１５】
前記第二の証明情報提供手段は、前記第一の証明情報について前記第二の証明情報を提供するための有効期限が切れていない場合は、前記第二の証明情報を提供することを特徴とする請求項１２乃至１４いずれか一項記載の第三のユーザ情報取扱い装置。
【請求項１６】
前記第一のユーザ情報取扱い装置からの前記第二のユーザ情報の取得要求は、前記クライアントに利用させるサービスを識別するサービス識別情報を伴っており、
前記第二の証明情報提供手段は、前記サービス識別情報によって識別されるサービスに対応した前記第二の証明情報を提供することを特徴とする請求項１２乃至１５いずれか一項記載の第三のユーザ情報取扱い装置。
【請求項１７】
コンピュータに、複数のユーザのユーザ情報を取り扱わせるユーザ情報取扱いプログラムであって、
クライアントからの第一のユーザ情報の取得要求を受信し、該取得要求に含まれているユーザ特定情報に基づいて該第一のユーザ情報の取得先を判定する取得先判定手順と、
前記取得先判定手順において判定された取得先に応じて、前記ユーザ情報を取得するユーザ情報取得手順とを有し、
前記ユーザ情報取得手順において、少なくとも一部の前記ユーザ情報の取得要求は、ネットワークを介して接続する他のコンピュータに送信されることを特徴とする第一のユーザ情報取扱いプログラム。
【請求項１８】
前記クライアントからの前記第一のユーザ情報の取得要求に含まれている前記ユーザ特定情報は、該ユーザ特定情報によって特定されるユーザが属するドメインのドメイン名を含んでおり、
前記取得先判定手順は、前記ドメイン名に基づいて前記第一のユーザ情報の取得先を判定することを特徴とする請求項１７記載の第一のユーザ情報取扱いプログラム。
【請求項１９】
前記取得先判定手順は、前記ユーザ特定情報に含まれている前記ドメイン名と、前記ドメイン名ごとに前記第一のユーザ情報の取得先を識別する取得先識別情報とに基づいて、前記第一のユーザ情報の取得先を判定することを特徴とする請求項１８記載の第一のユーザ情報取扱いプログラム。
【請求項２０】
前記第一のユーザ情報の取得要求は、前記ユーザ特定情報によって特定されるユーザの認証要求であることを特徴とする請求項１７乃至１９いずれか一項記載の第一のユーザ情報取扱いプログラム。
【請求項２１】
前記ユーザ情報取得手順において前記他のコンピュータに送信された前記認証要求に対する応答として、前記ユーザが認証された旨を示す第一の証明情報を前記他のコンピュータより受信する第一の証明情報受信手順と、
前記第一の証明情報受信手順において受信された前記第一の証明情報を、前記クライアントからの前記第一のユーザ情報の取得要求に対する応答として前記クライアントに送信する第一の証明情報送信手順とを有することを特徴とする請求項２０記載の第一のユーザ情報取扱いプログラム。
【請求項２２】
請求項６記載の第一のユーザ情報取扱い装置からの前記認証要求に応じ、該認証要求に含まれている前記ユーザ特定情報に基づいて前記ユーザの認証を行い、前記ユーザが認証された場合に前記第一の証明情報を提供する第一の証明情報提供手順と、
前記第一のユーザ情報取扱い装置より前記第一の証明情報を受信した前記クライアントからの前記第一の証明情報を伴った第二のユーザ情報の取得要求に応じ、前記クライアントに所定のサービスを利用させる際に、該所定のサービスに対して提示が要求される第二の証明情報を提供する第二の証明情報提供手順とをコンピュータに実行させるための第二のユーザ情報取扱いプログラム。
【請求項２３】
前記第二の証明情報提供手順は、前記第二のユーザ情報の取得要求に伴う前記第一の証明情報が、前記第一のユーザ情報取扱い装置より前記ユーザの認証要求を受けた際に提供したものである場合は、前記第二の証明情報を提供することを特徴とする請求項２２記載の第二のユーザ情報取扱いプログラム。
【請求項２４】
前記第一の証明情報提供手順が提供した前記第一の証明情報を保存する証明情報保存手順を有し、
前記第二の証明情報提供手順は、前記第二のユーザ情報の取得要求に伴う前記第一の証明情報が前記証明情報保存手順において保存されたものである場合は、前記第二の証明情報を提供することを特徴とする請求項２２又は２３記載の第二のユーザ情報取扱いプログラム。
【請求項２５】
前記第二の証明情報提供手順は、前記第一の証明情報について前記第二の証明情報を提供するための有効期限が切れていない場合は、前記第二の証明情報を提供することを特徴とする請求項２２乃至２４いずれか一項記載の第二のユーザ情報取扱いプログラム。
【請求項２６】
前記第二のユーザ情報の取得要求は、前記クライアントに利用させるサービスを識別するサービス識別情報を伴っており、
前記第二の証明情報提供手順は、前記サービス識別情報によって識別されるサービスに対応した前記第二の証明情報を提供することを特徴とする請求項２２乃至２５いずれか一項記載の第二のユーザ情報取扱いプログラム。
【請求項２７】
クライアントからのユーザの認証要求に応じ、該認証要求に含まれているユーザ特定情報に基づいて前記ユーザの認証を行い、前記ユーザが認証された場合に前記ユーザが認証された旨を示す第一の証明情報を提供する第一の証明情報提供手順と、
前記クライアントから第二のユーザ情報の取得要求を前記第一の証明情報と共に受信した請求項６記載の第一のユーザ情報取扱い装置からの前記第二のユーザ情報の取得要求に応じ、前記クライアントに所定のサービスを利用させる際に前記所定のサービスに対して提示が要求される第二の証明情報を提供する第二の証明情報提供手順とをコンピュータに実行させるためのる第三のユーザ情報取扱いプログラム。
【請求項２８】
前記第二の証明情報提供手順は、前記第一のユーザ情報取扱い装置からの前記第二のユーザ情報の取得要求に伴う前記第一の証明情報が、前記クライアントより前記ユーザの認証要求を受けた際に提供したものである場合は、前記第二の証明情報を提供することを特徴とする請求項２７記載の第三のユーザ情報取扱いプログラム。
【請求項２９】
前記第一の証明情報提供手順が提供した前記第一の証明情報を保存する証明情報保存手順を有し、
前記第二の証明情報提供手順は、前記第二のユーザ情報の取得要求に伴う前記第一の証明情報が前記証明情報保存手順において保存されたものである場合は、前記第二の証明情報を提供することを特徴とする請求項２７又は２８記載の第三のユーザ情報取扱いプログラム。
【請求項３０】
前記第二の証明情報提供手順は、前記第一の証明情報について前記第二の証明情報を提供するための有効期限が切れていない場合は、前記第二の証明情報を提供することを特徴とする請求項２７乃至２９いずれか一項記載の第三のユーザ情報取扱いプログラム。
【請求項３１】
前記第一のユーザ情報取扱い装置からの前記第二のユーザ情報の取得要求は、前記クライアントに利用させるサービスを識別するサービス識別情報を伴っており、
前記第二の証明情報提供手順は、前記サービス識別情報によって識別されるサービスに対応した前記第二の証明情報を提供することを特徴とする請求項２７乃至３０いずれか一項記載の第三のユーザ情報取扱いプログラム。
【請求項３２】
請求項１７乃至２１いずれか一項記載の第一のユーザ情報取扱いプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項３３】
請求項２２乃至２６いずれか一項記載の第二のユーザ情報取扱いプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項３４】
請求項２７乃至３１いずれか一項記載の第三のユーザ情報取扱いプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザに関する情報を管理するユーザ情報取扱い装置、ユーザ情報取扱いプログラム及び記録媒体に関する。
【背景技術】
【０００２】
ネットワーク上に接続されたサーバのサービスを利用するためには、サーバに対する不正なアクセスを防止するため、クライアントはサーバに対してユーザ名及びパスワード等（以下、「ユーザ名等」という。）の提示が要求されるのが一般である。
【０００３】
図１は、クライアントが文書管理サーバの利用を開始する場合の例を示す図である。図１において、文書管理サーバ５０１は、文書情報の管理機能が実装されているコンピュータである。クライアント５０２は、文書管理サーバ５０１の機能を利用するコンピュータである。ユーザ管理サーバ５０３は、ユーザ名及びパスワードに基づいてユーザの認証を行ったり、ユーザ情報の提供等を行ったりする機能が実装されているコンピュータである。すなわち、ユーザ管理サーバ５０３は、各ユーザのユーザ名とパスワードとの対応表からなるデータベース（以下、「ユーザＤＢ」という。）を有しており、ユーザＤＢに基づいてユーザの認証等を行う。
【０００４】
例えば、クライアント５０２が、文書管理サーバ５０１の機能を利用するべくログイン画面等においてユーザによって入力されたユーザ名等を文書管理サーバ５０１に送信する（Ｓ１）。
【０００５】
ユーザ名等を受信した文書管理サーバ５０１は、ユーザ名等を伴って予め認証の要求先として指定されているユーザ管理サーバ５０３にユーザの認証を要求する（Ｓ２）。
【０００６】
ユーザ管理サーバ５０３は、ユーザ名等に基づいてユーザの認証を行い、その結果を文書管理サーバ５０１に送信する（Ｓ３）。
【０００７】
ユーザが認証された場合は、文書管理サーバ５０１は、クライアント５０２に対してそのサービスを提供する（Ｓ４）。
【０００８】
このように、図１においては、ユーザ管理サーバ５０３にユーザ名等が管理されているユーザに対してのみ、文書管理サーバ５０１のサービスが提供されることとなり、不正ユーザによる利用、及び機密情報の漏洩や改竄等を有効に防止することができる。
【０００９】
なお、図１においては、文書管理サーバ５０１とユーザ管理サーバ５０３とが別々のハードウェアによって構成されている例を示したが、文書管理サーバ５０１にユーザ管理サーバ５０３の機能が包含されている構成も従来より採用されている。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、保守作業の容易性等の観点より、ユーザ管理サーバがサービスごと（ここでは、文書管理サーバごと）に設置される場合がある。図２は、サービスごとにユーザ管理サーバが設置された例を示す図である。図２において、ユーザ管理サーバ５０３ａ、５０３ｂ、５０３ｃは、それぞれ文書管理サーバ５０１ａ、５０２ｂ、５０１ｃに対応するユーザ管理サーバである。文書管理サーバ５０１ａを利用するためには、クライアント５０２は、ユーザ管理サーバ５０３ａによって認証される必要がある。同様に、文書管理サーバ５０２ｂを利用するためには、ユーザ管理サーバ５０３ｂによって、また、文書管理サーバ５０１ｃを利用するためには、ユーザ管理サーバ５０３ｃによって認証される必要がある。
【００１１】
すなわち、図２のようなシステム形態において、クライアント５０２は、利用するサービス（文書管理サーバ）を切り替えるたびに、それぞれ異なるユーザ管理サーバによって認証を受けなければならない。かかる事態は、各サービスを利用するユーザが同一人物であって、かつ、当該ユーザのユーザ名等が各ユーザ管理サーバにおいて同一の値によって管理されている場合であっても、利用するサービスを切り替えるたびにユーザ名及びパスワード等の入力をユーザに要求する必要があることを意味する。
【００１２】
かかる状況は、システム負荷を不必要に高めるだけでなく、ユーザにとっても非常に煩雑さを感じさせる。
【００１３】
本発明は、上記の点に鑑みてなされたものであって、複数のコンピュータによって分散されているユーザ情報を統合的に扱うことのできるユーザ情報取扱い装置、ユーザ情報取扱いプログラム及び記録媒体の提供を目的とする。
【課題を解決するための手段】
【００１４】
そこで上記課題を解決するため、本発明は、請求項１に記載されるように、複数のユーザのユーザ情報を取り扱うユーザ情報取扱い装置であって、クライアントからの第一のユーザ情報の取得要求を受信し、該取得要求に含まれているユーザ特定情報に基づいて該第一のユーザ情報の取得先を判定する取得先判定手段と、前記取得先判定手段によって判定された取得先として前記第一のユーザ情報を取得する一つ以上のユーザ情報取得手段とを有し、少なくとも一部の前記ユーザ情報取得手段は、前記第一のユーザ情報の取得要求をネットワークを介して接続する他のユーザ情報取扱い装置に送信することを特徴とする。
【００１５】
また、上記課題を解決するため、本発明は、請求項７に記載されるように、請求項６記載の第一のユーザ情報取扱い装置からの前記認証要求に応じ、該認証要求に含まれている前記ユーザ特定情報に基づいて前記ユーザの認証を行い、前記ユーザが認証された場合に前記第一の証明情報を提供する第一の証明情報提供手段と、前記第一のユーザ情報取扱い装置より前記第一の証明情報を受信した前記クライアントからの前記第一の証明情報を伴った第二のユーザ情報の取得要求に応じ、前記クライアントに所定のサービスを利用させる際に、該所定のサービスに対して提示が要求される第二の証明情報を提供する第二の証明情報提供手段とを有することを特徴とする。
【００１６】
また、上記課題を解決するため、本発明は、請求項１２に記載されるように、クライアントからのユーザの認証要求に応じ、該認証要求に含まれているユーザ特定情報に基づいて前記ユーザの認証を行い、前記ユーザが認証された場合に前記ユーザが認証された旨を示す第一の証明情報を提供する第一の証明情報提供手段と、前記クライアントから第二のユーザ情報の取得要求を前記第一の証明情報と共に受信した請求項６記載の第一のユーザ情報取扱い装置からの前記第二のユーザ情報の取得要求に応じ、前記クライアントに所定のサービスを利用させる際に前記所定のサービスに対して提示が要求される第二の証明情報を提供する第二の証明情報提供手段とを有することを特徴とする。
【００１７】
このようなユーザ情報取扱い装置によれば、請求項１記載のユーザ情報取扱い装置は、自らの管理下にないユーザ属性情報についての処理は、他のユーザ情報取扱い装置に委譲することができ、請求項７又は１２記載のユーザ情報取扱い装置は、第一のユーザ情報取扱い装置より委譲された処理を実行することができるため、複数のコンピュータによって分散されているユーザ情報を統合的に扱うことができる。
【００１８】
また、上記課題を解決するため、本発明は、上記ユーザ情報取扱い装置におけるユーザ情報取扱い方法、前記ユーザ情報取扱い方法を前記ユーザ情報取扱い装置に実行させるためのユーザ情報取扱いプログラム、又は前記ユーザ情報取扱いプログラムを記録した記録媒体としてもよい。
【発明の効果】
【００１９】
本発明によれば、複数のコンピュータによって分散されているユーザ情報を統合的に扱うことのできるユーザ情報取扱い装置、ユーザ情報取扱いプログラム及び記録媒体を提供することができる。
【発明を実施するための最良の形態】
【００２０】
以下、図面に基づいて本発明の実施の形態を説明する。図３は、本発明の実施の形態における文書管理システムの構成例を示す図である。図３に示されるように、本実施の形態における文書管理システム１は、認証サーバ１０ａ及び１０ｂ等（以下、総称する場合「認証サーバ１０」という。）と、文書管理サーバ２０ａ及び２０ｂ等（以下、総称する場合「文書管理サーバ２０」という。）と、Ｗｅｂサーバ３０と、一台以上の端末４０とから構成されており、各構成要素は、インターネットやＬＡＮ等のネットワーク５０を介して接続されている。
【００２１】
認証サーバ１０は、ユーザ名、パスワード、及びドメイン名等のユーザを特定するための情報（以下、「ユーザ特定情報」という。）に基づいてユーザの認証を実行するための機能やユーザ情報の提供機能（認証サービス１００ａ及び１００ｂ、以下、総称する場合「認証サービス１００」という。）が実装されているコンピュータである。認証サービス１００は、ユーザの認証機能をＷｅｂサービスとしてネットワーク５０上に提供する。なお、本実施の形態において、ユーザ情報とは、後述するチケットや、ユーザ属性情報等、ユーザに関する様々な情報を含む。
【００２２】
文書管理サーバ２０は、文書情報の管理機能（文書管理サービス２１ａ及び２１ｂ、以下、総称する場合「文書管理サービス２１」という。）が実装されたコンピュータである。文書管理サービス２１は、文書情報の登録、検索、及び更新等の諸機能をＷｅｂサービスとしてネットワーク５０上に提供する。文書管理サーバ２０の機能を利用するクライアントは、認証サーバ１０によって認証されている必要がある。但し、認証サーバ１０であればどれでもよいわけではなく、各文書管理サーバ２０は、それぞれが信頼する認証サーバ１０によって認証を受けたクライアントに対してその機能を提供する。本実施の形態において、文書管理サーバ２０ａは、認証サーバ１０ａを、文書管理サーバ２０ｂは、認証サーバ１０ｂをそれぞれ信頼しているものとする。したがって、文書管理サーバ２０ａを利用するクライアントは認証サーバ１０ａに認証されている必要があり、文書管理サーバ２０ｂを利用するクライアントは認証サーバ１０ｂに認証されている必要がある。
【００２３】
Ｗｅｂサーバ３０は、端末４０が要求する情報を表示するＷｅｂページを端末４０に提供するための機能を有するコンピュータである。ここでＷｅｂページとは、汎用的なＷｅｂブラウザで表示可能なＨＴＭＬ，ＸＭＬ形式等のデータをいう。Ｗｅｂサーバ３０は、端末４０に対するＷｅｂページの提供に際し、必要に応じて文書管理サーバ２０又は認証サーバ１０等の機能を利用する。
【００２４】
端末４０は、Ｗｅｂサーバ３０が提供するＷｅｂページを閲覧するためのＷｅｂブラウザを備えたＰＣ、ＰＤＡ（Personal Digital(Data) Assistants）、又は携帯電話等の通信端末である。
【００２５】
次に、認証サーバ１０の詳細について説明する。図４は、本発明の実施の形態における認証サーバのハードウェア構成例を示す図である。認証サーバ１０は、ＣＰＵ１０１１、ＲＯＭ１０１２、ＲＡＭ１０１３、補助記憶装置１０１４、ネットワークインタフェース（Ｉ／Ｆ）１０１５、ドライブ装置１０１６等から構成されている。
【００２６】
ＣＰＵ１０１１は、認証サーバ１０全体を制御する制御部であり、ＲＯＭ１０１２や補助記憶装置１０１４に格納された各種制御プログラムやアプリケーションプログラムを実行して装置の制御、通信の制御、データの取得及び編集等の動作を行う。ＲＯＭ１０１２は、主に装置の制御プログラムを記憶する記憶手段であり、ＲＡＭ１０１３はＣＰＵ１０１１のワークメモリや一時的なデータの記憶に用いる記憶手段である。補助記憶装置１０１４は、各種アプリケーションプログラムやデータを記憶する記憶手段である。ネットワークＩ／Ｆ１０１５は、認証サーバ１０をネットワーク５０に接続するためのインタフェースである。ドライブ装置１０１６は、本発明の機能を実行するプログラムが記録されたＣＤ−ＲＯＭ等の記録媒体１０１７を読み取るための装置である。
【００２７】
なお、図４には操作部や表示部を示していないが、キーボードやマウス等による操作部や、液晶やブラウン管（ＣＲＴ）による表示部を設け、ユーザからの入力の受付や動作結果の表示を行うことができるようにしてもよい。
【００２８】
文書管理サーバ２０やＷｅｂサーバ３０についても、図４と同様に構成することができる。
【００２９】
図５は、本発明の実施の形態における認証サービスの機能構成例を示す図である。図５に示されるように、認証サービス１００は、ディスパッチャ１１、ルーティング情報管理テーブル１２、Ｗプロバイダ１３、Ｎプロバイダ１４、ローカルプロバイダ１５、リモートプロバイダＡ１６、リモートプロバイダＢ１７、ローカルユーザＤＢ（Ｄａｔａ  Ｂａｓｅ）１８、チケット管理テーブル１９、及び信頼関係リスト１１１等から構成されている。
【００３０】
Ｗプロバイダ１３、Ｎプロバイダ１４、ローカルプロバイダ１５、リモートプロバイダＡ１６、及びリモートプロバイダＢ１７等（以下、総称する場合「認証プロバイダ」という。）は、それぞれが対応する認証エンジンの独自のプロトコルを吸収し、統一されたインタフェースによって、各認証エンジンの認証機能を提供するためのモジュールである。認証プロバイダが統一されたインタフェースを提供することにより、認証プロバイダの呼び出し側である上位モジュール（ディスパッチャ１１）は、認証エンジンごとに異なるプロトコルを意識する必要がない。したがって、上位モジュールの実装が簡便化されるというメリットがある。
【００３１】
Ｗプロバイダ１３は、Ｗｉｎｄｏｗｓ（登録商標）のドメインコントローラにおけるパスワード認証に対応した認証プロバイダである。Ｎプロバイダ１４は、Ｎｏｔｅｓ（登録商標）サーバ（図中、「Ｎサーバ」として表示）におけるパスワード認証に対応した認証プロバイダである。
【００３２】
ローカルプロバイダ１５は、独自の認証機能が実装されている認証プロバイダである。したがって、ローカルプロバイダ１５は、それ自身がローカルユーザ情報ＤＢ１８を有しおり、ローカルユーザ情報ＤＢ１８に管理されている情報に基づいてユーザの認証を行う。ローカルユーザ情報ＤＢ１８は、ローカルプロバイダ１５のドメインに属するユーザのユーザ名及びパスワード等をはじめとする、ユーザに関する各種属性情報（以下、「ユーザ属性情報」という。）を管理しているデータベースである。
【００３３】
リモートプロバイダＡ１６及びリモートプロバイダＢ１７は、認証処理を他の認証サーバ１０へ委譲するための認証プロバイダである。例えば、図５における認証サーバ１０が、認証サーバ１０ａであるとした場合、リモートプロバイダＡ１６は、認証サーバ１０ｂに対して認証処理を委譲する認証プロバイダであり、リモートプロバイダＢ１７は、非図示の認証サーバ１０に対して認証処理を委譲する認証プロバイダである。
【００３４】
ディスパッチャ１１は、上述した各認証プロバイダを呼び分けるためのモジュールである。ルーティング情報管理テーブル１２は、ディスパッチャ１１が各認証プロバイダを呼び分けるために必要な情報を管理するテーブルである。したがって、ディスパッチャ１１は、クライアント（本実施の形態においてはＷｅｂサーバ３０、又は他の認証サーバ１０のリモートプロバイダＡ１６等）より認証要求を受信すると、ルーティング情報管理テーブル１２を参照して、当該認証要求に対応した認証プロバイダを判断し、その認証プロバイダを呼び出す。
【００３５】
チケット管理テーブル１９は、ユーザが認証された際に当該ユーザを認証した認証プロバイダ又はディスパッチャ１１によって発行される電子的な証明書（チケット）を管理しておくためのテーブルである。
【００３６】
なお、信頼関係リスト１１１については、後述する。
【００３７】
図５においては、認証サービス１００ａ及び１００ｂについて共通化して説明したが、以降において各認証サービスにおける各構成要素を区別する場合、各構成要素の符号に「ａ」又は「ｂ」という接尾子を付加することとする。
【００３８】
ところで、上述したように、各認証プロバイダは、それぞれ異なる認証エンジンに対応している。したがって、本実施の形態においては認証プロバイダごとにそれぞれ異なるドメインが形成されることになる。ここで、ドメインとは、一般に、ユーザドメイン又は単にドメインと呼ばれる概念と同様、ユーザ管理における一つの論理的な管理範囲を意味する。一つのドメイン内においてユーザ名は一意であることが保証される。
【００３９】
以下、図３の文書管理システムにおける処理手順について説明する。文書管理システムにおける処理手順については、第一の実施の形態と第二の実施の形態とに分けて説明する。第一の実施の形態においては、ユーザが、文書管理サービス２１ａを利用した後に文書管理サービス２１ｂを利用する場合について説明する。また、第二の実施の形態においては第一の実施の形態とは逆に、ユーザが、文書管理サービス２１ｂを利用した後に文書管理サービス２１ａを利用する場合について説明する。
【００４０】
図６及び図７は、第一の実施の形態における文書管理サービス２１ａを利用する際の処理を説明するためのシーケンス図である。図６においては、クライアント６０が、文書管理サービス２１ａによって管理されている文書情報の一覧情報（以下「文書一覧」という。）を取得する処理について説明する。なお、クライアント６０は、文書管理サービス２１や認証サービス１００等を利用する装置やソフトウェアを意味し、例えば、Ｗｅｂサーバ３０や端末４０、又はＷｅｂサーバ３０若しくは端末４０において動作するソフトウェアでもよい。
【００４１】
ステップＳ１０１において、クライアント６０は、文書管理サービス２１ａにおける接続情報問い合わせメソッドを呼び出すことにより、文書管理サービス２１ａを利用するために必要な情報（接続情報）の送信を要求する。
【００４２】
ステップＳ１０１に続いてステップＳ１０２に進み、文書管理サービス２１ａは、接続情報問い合わせメソッドに対する応答として、接続情報をクライアント６０に対して送信する。ここで送信される接続情報には、文書管理サービス２１ａを一意に識別するための名前（以下、「ターゲットサービス名」という。）と、文書管理サービス２１ａが信頼している認証サービス１００ａ（以下、「ターゲット認証サービス」という。）のＵＲＩとが含まれている。ここで、文書管理サービス２１ａが信頼している認証サービス１００ａとは、文書管理サービス２１ａのサービスを利用するクライアント６０が認証を受ける必要がある認証サービス１００のことをいう。
【００４３】
ステップＳ１０２に続いてステップＳ１０３に進み、クライアント６０は、ターゲット認証サービスである認証サービス１００ａの認証メソッドをＳＯＡＰのＲＰＣによって呼び出すことにより、ユーザの認証の要求（ＳＯＡＰメッセージ）を認証サービス１００ａに対して送信する。
【００４４】
図８は、認証メソッドを呼び出す際のＳＯＡＰメッセージの例を示す図である。図８のＳＯＡＰメッセージ６１において、符号６１１によって示される部分が認証メソッドに対する呼び出し情報である。すなわち、タグ６１２のタグ名である「authenticateByPassword」は、認証メソッドのメソッド名であり、記述６１３、６１４及び６１５は、認証メソッドの引数情報である。すなわち、記述６１３には、＜ｕｓｅｒＮａｍｅ＞タグに囲まれてユーザ名（ａａａ）が指定されている。また、記述６１４には、＜ｐａｓｓｗｏｒｄ＞タグに囲まれてパスワード（ａｂｃ！）が指定されている。また、記述６１５には、＜ｄｏｍａｉｎｎａｍｅ＞タグに囲まれてドメイン名（ＤｏｍＡ）が指定されている。更に、記述６１６には、＜ｄｕｒａｔｉｏｎ＞タグに囲まれてチケットの有効期限が指定されている。なお、引数に指定されるユーザ名、パスワード、及びドメイン名等は、ユーザによって入力されたものである。
【００４５】
ステップＳ１０３に続いてステップＳ１０４に進み、ＳＯＡＰメッセージ６１を受信したディスパッチャ１１ａは、ルーティング情報管理テーブル１２を参照して、認証処理の振分け先とする認証プロバイダを判断する。
【００４６】
図９は、認証サービス１００ａにおけるルーティング情報管理テーブルの構成例を示す図である。図９に示されるように、ルーティング情報管理テーブル１２ａは、ドメイン名ごとに当該ドメインに対応した認証プロバイダのプロバイダ名が登録されている。したがって、ディスパッチャ１１ａは、ルーティング情報管理テーブル１２ａに基づいて認証メソッドの引数に指定されているドメイン名に対応する認証プロバイダを判断し、当該認証プロバイダを呼び出す（Ｓ１０５）。本実施の形態においては、ドメイン名として「ＤｏｍＡ」が指定されているため、ディスパッチャ１１ａは、ＤｏｍＡドメインに対応するリモートプロバイダＡ１６ａを呼び出す。
【００４７】
ステップＳ１０５に続いてステップＳ１０６に進み、リモートプロバイダＡ１６ａは、自らが対応している認証サービス１００ｂの認証メソッドをＳＯＡＰのＲＰＣによって呼び出すことにより、認証サービス１００ｂにおける一の認証プロバイダに対してユーザの認証を要求する。リモートプロバイダＡ１６ａには、対応している認証サービスのＵＲＩが予め設定されており、リモートプロバイダＡ１６ａは、設定されているＵＲＩに基づいて認証メソッドの呼び出し先の認証サービス１００を判断する。なお、ここでは、図８において説明したＳＯＡＰメッセージ６１と同様のＳＯＡＰメッセージが、リモートプロバイダＡ１６ａから認証サービス１００ｂに対して送信される。
【００４８】
ステップＳ１０６に続いてステップＳ１０７に進み、ＳＯＡＰメッセージを受信したディスパッチャ１１ｂは、認証サービス１００ｂにおけるルーティング情報管理テーブル１２ｂを参照して、認証処理を要求する認証プロバイダを判断する。
【００４９】
図１０は、認証サービス１００ｂにおけるルーティング情報管理テーブルの構成例を示す図である。図１０に示されるように、ルーティング情報管理テーブル１２ｂにおいては、ローカルプロバイダがＤｏｍＡドメインに対応する認証プロバイダとして登録されている。すなわち、ＤｏｍＡドメインは、認証サービス１００ｂによって管理されているドメインだったことになる。したがって、ディスパッチャ１１ｂは、ＤｏｍＡドメインに対応する認証プロバイダとして、認証サービス１００ｂにおけるローカルプロバイダ１５ｂを呼び出す（Ｓ１０８）。
【００５０】
ステップＳ１０８に続いてステップＳ１０９に進み、ローカルプロバイダ１５ｂは、認証要求に係るユーザのユーザ名に対するパスワードが正しい否かをユーザ情報ＤＢ１８ｂに管理されているユーザ名及びパスワードを参照して判断する。ユーザ名及びパスワードが正しい場合は、ステップＳ１１０に進み、ローカルプロバイダ１５ｂは、ユーザが認証された旨を示すチケットを生成する。
【００５１】
ここで、チケットについて説明する。本実施の形態においてはマスタチケットと認証チケットとの二種類のチケットが定義されている。マスタチケットは、ユーザが認証されていること、すなわち、正当なユーザであることを証明する電子的な証明書であり、認証サービス１００が、認証されたユーザに対して発行するものである。一方、認証チケットは、所定のサービス（本実施の形態においては、文書管理サービス２１）の利用に際し、当該サービスに対して提示が要求されるデータであり、利用対象とするサービスを限定して認証サービス１００より発行を受けるものである。したがって、所定のサービスの利用を希望するクライアントは、最終的には、認証チケットの発行を受ける必要がある。但し、そのためには、自らの正当性を証明するマスタチケットを提示する必要があるため、マスタチケットの発行を受けた後に認証チケットの発行を受けるという手順を踏む必要がある。
【００５２】
これら２種類のチケットが定義されているのは、セキュリティ上の観点によるところが大きい。すなわち、認証チケットは有効なサービスが限定されている。したがって、認証チケットが盗まれても被害はその範囲に限定される。一方、マスタチケットを有していれば、各種のサービスに対する認証チケットを入手することが可能となる。したがって、マスタチケットが盗まれれば、その被害は、チケットを用いたシステム全域に及ぶ可能性がある。そこで、認証チケットを定義し、普段の処理においては認証チケットを流通させることによって、マスタチケットがネットワーク上を頻繁に流通することを防止するというわけである。
【００５３】
図１１は、チケットのデータ構造例を示す図である。図１１に示されるようにチケットは、チケットＩＤ、有効範囲、有効期限、認証ユーザＩＤ及びＭＩＣ（Message Integrity Code）等から構成される。
【００５４】
チケットＩＤは、各チケットを一意に識別するためのコードである。有効範囲はマスタチケットと認証チケットとの種類の別と、当該チケットが認証チケットである場合は、当該チケットを利用可能な範囲を識別するための情報である。すなわち、当該チケットがマスタチケットである場合は、有効範囲には「マスタ」と記録され、当該チケットが認証チケットである場合は、当該認証チケットを利用可能な範囲を識別するための名称（ドメイン名、サーバ名等）が記録される。
【００５５】
有効期限は、当該チケットが有効な期限を示す。有効期限が切れたチケットは、無効なものとして扱われる。これによって、万が一チケットが盗まれた場合における被害が無限に拡大することを防止することができる。なお、マスタチケットにおける有効期限は、当該マスタチケットに基づいて認証チケットの発行をすることが可能な期限を意味する。また、認証チケットにおける有効期限は、当該認証チケットに基づいて、サービスの利用が可能な期限を意味する。
【００５６】
認証ユーザＩＤは、認証を受けたユーザのユーザＩＤである。ＭＩＣは、当該チケットが途中で改竄等されていないかを確認するためのコードである。
【００５７】
上述したように、ユーザが認証された際に発行されるのは、マスタチケットである。したがって、ステップＳ１１０においては、マスタチケットが生成される。
【００５８】
ステップＳ１１０に続いてステップＳ１１１に進み、ローカルプロバイダ１５ｂが、生成したマスタチケットをディスパッチャ１１ｂに対して出力すると、ディスパッチャ１１ｂは、チケット管理テーブルにマスタチケットを登録する（Ｓ１１２）。
【００５９】
図１２は、認証サービス１００ｂにおけるチケット管理テーブルの構成例を示す図である。図１２に示されるように、チケット管理テーブル１９ｂは、発行されたチケットごとに、チケット、チケット種別、発行プロバイダ名、発行認証サーバ及びチケット詳細情報等を管理するものである。チケットは、チケットの実体である。チケット種別は、当該チケットがマスタチケットであるか認証チケットであるかを示す情報である。発行プロバイダ名は、当該チケットを発行した認証プロバイダのプロバイダ名である。発行認証サーバは、当該チケットを発行した認証サーバ１０を識別する情報（例えば、マシン名）であり、自分自身が発行した場合は「ローカル」と記録される。チケット詳細情報は、当該チケットに係るユーザに関する各種情報である。なお、図１２において、チケットＣ（３つ目のレコード）がステップＳ１１２においてチケット管理テーブル１９ｂに登録されたマスタチケットである。
【００６０】
ステップＳ１１２に続いてステップＳ１１３に進み、ディスパッチャ１１ｂは、マスタチケットをシリアライズ及び暗号化し、暗号化されたマスタチケットを含むＳＯＡＰメッセージを認証メソッドの返却情報として認証サービス１００ａのリモートプロバイダＡ１６ａに対して送信する。
【００６１】
図１３は、認証メソッドの返却情報を含むＳＯＡＰメッセージの例を示す図である。図１３のＳＯＡＰメッセージ６２において、符号６２１で示される部分が、返却情報である。すなわち、記述６２１において＜ｒｅｔｕｒｎＶａｌｕｅ＞タグで囲まれ、符号６２２によって示される文字列が、暗号化されたマスタチケットである。
【００６２】
ステップＳ１１３に続いてステップＳ１１４に進み、ＳＯＡＰメッセージ６２を受信したリモートプロバイダＡ１６ａは、ＳＯＡＰメッセージ６２に含まれているマスタチケットを復号化及びデシリアライズし、デシリアライズされたマスタチケットをディスパチャ１１ａに出力する。ステップＳ１１４に続いてステップＳ１１５に進み、ディスパッチャ１１ａは、マスタチケットを認証サービス１００ａにおけるチケット管理テーブル１９ａに登録する。
【００６３】
図１４は、認証サービス１００ａにおけるチケット管理テーブルの構成例を示す図である。図１４のチケット管理テーブル１９ａにおいて、チケットＣが、ステップＳ１１５において登録されたマスタチケットである。なお、チケットＣの発行プロバイダは、厳密には、認証サービス１００ｂにおけるローカルプロバイダ１５ｂであるが、チケット管理テーブル１９ａにおいては、チケットＣの発行プロバイダ名として「リモートプロバイダＡが登録されている。これは、リモートプロバイダＡ１６ａによって認証サービス１１ｂに認証処理が委譲されることについては、ディスパッチャ１１ａの関知するところでないことを意味する。したがって、認証サービス１００ａにおいては、認証サービス１００ｂにおいて発行されたチケットであっても、認証サービス１００ａにおいて発行された他のチケットと同様に管理される。
【００６４】
ステップＳ１１５に続いてステップＳ１１６に進み、ディスパッチャ１１ａは、認証メソッドの返却情報として、図１３に示したＳＯＡＰメッセージ６２と同様のＳＯＡＰメッセージをクライアント６０に対して送信する。
【００６５】
以上で、クライアント６０は、マスタチケットを取得したことになる。但し、文書管理サービス２１ａを利用するためには、文書管理サービス２１ａを対象とした認証チケットを入手する必要がある。したがって、ステップＳ１１６に続いてステップＳ１１７（図７）に進み、クライアント６０は、ターゲット認証サービスである認証サービス１００ａの認証チケット発行メソッドをＳＯＡＰのＲＰＣによって呼び出すことにより、認証チケットの発行要求（ＳＯＡＰメッセージ）を認証サービス１００ａに対して送信する。
【００６６】
図１５は、認証チケット発行メソッドを呼び出す際のＳＯＡＰメッセージの例を示す図である。図１５のＳＯＡＰメッセージ６３において、符号６３１によって示される部分が認証チケット発行メソッドに対する呼び出し情報である。すなわち、タグ６３２のタグ名である「createAuthTicket」は、認証チケット発行メソッドのメソッド名であり、記述６３３、６３４及び６３５は、認証チケット発行メソッドの引数情報である。
【００６７】
すなわち、記述６３３には、＜ｍａｓｔｅｒＡｕｔｈＴｉｃｋｅｔ＞タグに囲まれて、シリアライズ及び暗号化されたマスタチケットが指定されている。また、記述６３４には、＜ｄｕｒａｔｉｏｎ＞タグに囲まれて、発行要求に係る認証チケットの有効期限（６０）が指定されている。更に、記述６３５には、＜ｔａｒｇｅｔｓ＞タグに囲まれたｉｔｅｍ要素として、発効要求に係る認証チケットの有効範囲としてのターゲットサービス名（ＲｅｐｏｓｉｔｏｒｙＡ）が指定されている。なお、ここで指定されるターゲットサービス名は、ステップＳ１０２において文書管理サービス２１ａの名前として受信したターゲットサービス名である。
【００６８】
ステップＳ１１７に続いてステップＳ１１８に進み、ＳＯＡＰメッセージ６３を受信したディスパッチャ１１ａは、認証チケット発行メソッドの引数に指定されたマスタチケットが、チケット管理テーブル１９ａ（図１４）に登録されているか否かを確認することにより、当該マスタチケットが確かに認証サービス１００ａによって発行されたものであることを確認する。更に、ディスパッチャ１１ａは、チケット管理テーブル１９ａを参照して当該マスタチケットに対して登録されている発行元プロバイダ名を確認することにより、当該マスタチケットの発行元プロバイダを特定する。
【００６９】
ステップＳ１１８に続いてステップＳ１１９に進み、ディスパッチャ１１ａは、発行元プロバイダであるリモートプロバイダＡ１６ａに対して認証チケットの発行を要求する。ステップＳ１１９に続いてステップＳ１２０に進み、リモートプロバイダＡ１６ａは、自らが対応している認証サービス１００ｂの認証チケット発行メソッドをＳＯＡＰのＲＰＣによって呼び出すことにより、認証サービス１００ｂに対して認証チケットの発行を要求する。したがって、ここでは、図１５において説明したＳＯＡＰメッセージ６３と同様のＳＯＡＰメッセージが、リモートプロバイダＡ１６ａから認証サービス１００ｂに対して送信される。
【００７０】
ステップＳ１２０に続いてステップＳ１２１に進み、ＳＯＡＰメッセージを受信したディスパッチャ１１ｂは、認証チケット発行メソッドの引数に指定されたマスタチケットが、チケット管理テーブル１９ｂ（図１２）に登録されているか否かを確認することにより、当該マスタチケットが確かに認証サービス１００ｂによって発行されたものであることを確認する。
【００７１】
更に、ディスパッチャ１１ｂは、チケット管理テーブル１９ｂを参照して、マスタチケットに対して登録されている発行元プロバイダ名を確認することにより、マスタチケットの発行元プロバイダを特定する。ここで、マスタチケットの発行元は、ローカルプロバイダ１５ｂ、すなわち、認証サービス１００ｂにおいてローカルな（他の認証サービス１００に処理を委譲しない）認証サービスである。
【００７２】
したがって、ステップＳ１２１に続いてステップＳ１２２に進み、ディスパッチャ１１ｂは、ターゲットサービス名にその名前が指定されている文書管理サービス２１ａを有効範囲とする認証チケットを生成し、当該認証チケット等をチケット管理テーブル１９ｂに登録する。なお、ディスパッチャ１１ｂは、チケット詳細情報についてはターゲットサービス名を暗号鍵として暗号化したものをチケット管理テーブル１９ｂに登録する。
【００７３】
なお、各認証プロバイダがローカルであるか否かは、認証プロバイダの名前に基づいて判断してもよいし、各認証プロバイダの名前に対応させてローカルか否かについて管理するテーブルを別途設け、当該テーブルを参照することにより判断するようにしてもよい。
【００７４】
ステップＳ１２２に続いてステップＳ１２３に進み、ディスパッチャ１１ｂは、認証チケットをシリアライズ及び暗号化し、暗号化された認証チケットを含むＳＯＡＰメッセージを認証チケット発行メソッドの呼び出し対する返却情報として認証サービス１００ａのリモートプロバイダＡ１６ａに対して送信する。
【００７５】
図１６は、認証チケット発行メソッドの返却情報を含むＳＯＡＰメッセージの例を示す図である。図１６のＳＯＡＰメッセージ６４において、符号６４１で示される部分が、返却情報である。すなわち、記述６４２における＜ｒｅｔｕｒｎＶａｌｕｅ＞タグで囲まれ文字列が、暗号化された認証チケットである。
【００７６】
ステップＳ１２４に続いてステップＳ１２５に進み、ディスパッチャ１１ａは、受信した認証チケットを認証サービス１００ａにおけるチケット管理テーブル１９ａに登録する。ステップＳ１２５に続いてステップＳ１２６に進み、ディスパッチャ１１ａは、認証チケット発行メソッドの返却情報として、図１６に示したＳＯＡＰメッセージ６４と同様のＳＯＡＰメッセージをクライアント６０に対して送信する。
【００７７】
以上で、クライアント６０は、文書管理サービス２１ａを利用するために必要な、文書管理サービス２１ａに対する認証チケットを入手したことになる。そこで、ステップＳ１２６に続いてステップＳ１２７に進み、クライアント６０は、文書管理サービス２１ａのセッション接続メソッドをＳＯＡＰのＲＰＣによって呼び出すことにより、文書管理サービス２１ａに対してセッションの接続を要求する。なお、セッション接続メソッドの引数には、認証チケットが指定される。
【００７８】
ステップＳ１２７に続いてステップＳ１２８に進み、文書管理サービス２１ａは、クライアント６０によって呼び出されたセッション接続メソッドの引数に指定されている認証チケットの正当性を確認すべく、認証サービス１００ａのチケット確認メソッドを呼び出す。チケット確認メソッドの引数には、認証チケットと、ターゲットサービス名として文書管理サービス２１ａ自身の名前とが指定される。
【００７９】
ステップＳ１２８に続いてステップＳ１２９に進み、認証サービス１００ａのディスパッチャ１１ａは、認証チケットの正当性を確認する。具体的には、ディスパッチャ１１ａは、認証チケットの存在をチケット管理テーブル１９ａに基づいて確認すると共に、認証チケットの有効期限を確認する。更に、ディスパッチャ１１ａは、チケット確認メソッドの引数に指定されているターゲットサービス名を復号鍵としてチケット詳細情報の復号を試みる。すなわち、チケット詳細情報は、認証チケットが発行された際（Ｓ１２２）に、認証チケットの有効範囲として指定されたターゲットサービス名によって暗号化されている。したがって、ここで、チケット確認メソッドの引数に指定されたターゲットサービス名を復号鍵としてチケット詳細情報を復号することができれば、両ターゲットサービス名の同一性が確認されたものとして、当該認証チケットが確かに文書管理サービス２１ａを対象（有効範囲）として発行されたものと確認できるというわけである。
【００８０】
ステップＳ１２９に続いてステップＳ１３０に進み、ディスパッチャ１１ａは、認証チケットの確認結果をチケット確認メソッドの返却情報として文書管理サービス２１ａに対して送信する。ステップＳ１３０に続いてステップＳ１３１に進み、チケット確認メソッドの返却情報において認証チケットが正当である旨が示されている場合は、文書管理サービス２１ａは、クライアント６０は正当なクライアントであるとしてクライアント６０とのセッションを接続する。ステップＳ１３１に続いてステップＳ１３２に進み、文書管理サービス２１ａは、セッションの接続の許否についてクライアント６０に対して応答する。例えば、セッションの接続が許可された場合は、当該セッションを識別するためのセッションＩＤ等がクライアント６０に対して送信される。
【００８１】
以降は、クライアント６０は、接続されたセッションに基づいて文書管理サービス２１ａに対して文書一覧の提供等を要求することとなる。
【００８２】
このように、本実施の形態における認証サーバ１０には、自らの管理外のユーザに対する認証要求については、他の認証サーバ１０に対応を委譲することができる。したがって、各認証サーバ１００間において連携を図ることができ、クライアントからは、分散管理されていることを意識することなく、統合化された環境として利用することができる。
【００８３】
なお、本発明は、認証処理以外にも適用可能である。例えば、それぞれが所定の情報を管理する情報管理装置である場合に、一の情報管理装置に対する検索要求を他の情報管理装置に委譲するようにすることで、複数の情報管理装置を統合化することもできる。
【００８４】
次に、文書管理サービス２１ａの機能を利用していたユーザが、文書管理サービス２１ｂの機能を利用しようとした場合の処理について説明する。図１７は、第一の実施の形態における文書管理サービス２１ｂを利用する際の処理を説明するためのシーケンス図である。
【００８５】
ステップＳ２０１及びＳ２０２は、上述したステップＳ１０１及びＳ１０２と同義の処理である。すなわち、クライアント６０は、文書管理サービス２１ｂにおける接続情報問い合わせメソッドを呼び出すことにより、文書管理サービス２１ｂよりその接続情報を取得する。この接続情報には、文書管理サービス２１ｂを一意に識別するための名前（ターゲットサービス名）と、文書管理サービス２１ｂが信頼している認証サービス１００ｂ（ターゲット認証サービス）のＵＲＩとが含まれている。
【００８６】
ステップＳ２０２に続いてステップＳ２０３に進み、クライアント６０は、既にいずれかの認証サービス１００から発行されたカレントユーザに対するマスタチケットを有しているか否かを判断する。ここでは、文書管理サービス２１ａを利用する際に認証サービス１００ａより発行を受けた（図６：Ｓ１１６）マスタチケットが保持されているため、クライアント６０は、マスタチケットを有している旨を判断する。
【００８７】
ステップＳ２０３に続いてステップＳ２０４に進み、クライアント６０は、マスタチケットを既に有していることから、このマスタチケットを用いてターゲット認証サービスである認証サービス１００ｂの認証チケット発行第２メソッドをＳＯＡＰのＲＰＣによって呼び出すことにより、認証チケットの発行要求（ＳＯＡＰメッセージ）を認証サービス１００ｂに対して送信する。一方、ここでマスタチケットを有していなかった場合は、クライアント６０は、ユーザに対してユーザ名及びパスワード等の入力を要求し、入力されたユーザ名及びパスワード等を引数として図６のステップＳ１０３と同様に、認証サービス１００ｂの認証メソッドを呼び出す。すなわち、ステップＳ２０３におけるマスタチケットの有無の判断処理は、図６のステップＳ１０３の直前においても実行されているものであるが、図６においては便宜上省略したものである。
【００８８】
図１８は、認証チケット発行第２メソッドを呼び出す際のＳＯＡＰメッセージの例を示す図である。図１８のＳＯＡＰメッセージ６５において、符号６５１によって示される部分が認証チケット発行第２メソッドに対する呼び出し情報である。すなわち、タグ６５２のタグ名である「createAuthTicketBySSO（Single Sign On）」は、認証チケット発行第２メソッドのメソッド名であり、記述６５３、６５４、６５５及び６５６は、認証チケット発行第２メソッドの引数情報である。
【００８９】
記述６５３、６５４、及び６５５については、認証チケット発行メソッド（createAuthTicket）を呼び出す際のＳＯＡＰメッセージ６３における記述６３３、６３４及び６３５と同じであるため説明は省略する。記述６５６には、＜ｕａ＿ｕｒｉ＞タグに囲まれて、引数に指定したマスタチケット（記述６５３）の発行元の認証サービス１００のＵＲＩが指定される。当該マスタチケットは、クライアント６０から見ると、直接的には認証サービス１００ａより発行を受けたものである。したがって、ここでは認証サービス１００ａのＵＲＩが指定されている。
【００９０】
なお、認証チケット発行第２メソッドの引数に指定されているマスタチケットは、クライアント６０から見た場合、認証チケットの発行の要求先である認証サービス１００ｂとは異なる認証サービス１００ａによって発行されたものである点に注意を要する。すなわち、認証チケット発行メソッドの場合は、当該メソッドの呼び出し対象となっている認証サービス１００において発行されたマスタチケットを指定する必要がある（図７：Ｓ１１７参照）。マスタチケットは、それを発行した認証サービス１００において有効だからである。ところが、認証チケット発行第２メソッドでは、いずれかの認証サービス１００に発行されているマスタチケットが既に有る場合に、そのマスタチケットで認証チケットの発行が受けられるか”試してみるため”に、クライアント６０から見た場合に他の認証サービス１００によって発行されたマスタチケットを指定することができるのである。
【００９１】
ステップＳ２０４に続いてステップＳ２０５に進み、ＳＯＡＰメッセージを受信したディスパッチャ１１ｂは、認証チケットを生成するための処理（認証チケット生成処理）を実行する。認証チケット生成処理の詳細については、フローチャートを用いて説明する。図１９は、認証チケット発行第２メソッドが呼び出された場合の認証チケット生成処理を説明するためのフローチャートである。
【００９２】
まず、ディスパッチャ１１ｂは、認証チケット発行第２メソッドの引数に指定されたマスタチケットが、チケット管理テーブル１９ｂ（図１２）に登録されているか否かを確認する（Ｓ２０５ａ）。ここで、認証チケット発行第２メソッドの引数に指定されたマスタチケットは、クライアント６０から見れば認証サービス１００ａによって発行されたものであるが、その裏側では、認証サービス１００ａから依頼を受けた認証サービス１００ｂのローカルプロバイダ１５ｂによって生成されたものであり（図６：Ｓ１１０）、その際に生成されたマスタチケットが「チケットＣ」としてチケット管理テーブル１９ｂに登録されている。
【００９３】
したがって、ステップＳ２０５ａに続いてステップＳ２０５ｂに進み、ディスパッチャ１１ｂは、チケット管理テーブル１９ｂを参照して、当該マスタチケット（ここではチケットＣ）の発行認証サーバが「ローカル」であるか、すなわち、当該マスタチケットの発行元が自分（認証サービス１００ｂ）であるかを判断する。マスタチケットの発行元が自分である場合は、ステップＳ２０５ｃに進み、ディスパッチャ１１ｂは、マスタチケットの有効期限を確認する。マスタチケットの有効期限が切れていない場合は、ディスパッチャ１１ｂは、ターゲットサービス名にその名前が指定されている文書管理サービス２１ｂを有効範囲とする認証チケットを生成し（Ｓ２０５ｄ）、当該認証チケット等をチケット管理テーブル１９ｂに登録する（Ｓ２０５ｅ）。チケット詳細情報についてはターゲットサービス名を暗号鍵として暗号化されたものがチケット管理テーブル１９ｂに登録されるのは、ステップＳ１２２（図７）等の場合と同様である。
【００９４】
なお、マスタチケットの有効期限が切れている場合（ステップＳ２０５ｃでＮｏの場合）は、認証チケット生成処理は異常終了する。また、マスタチケットはチケット管理テーブル１９ｂに登録されているが、発行元が自分（認証サービス１００ｂ）でない場合（ステップＳ２０５ｂでＮｏの場合）は、ディスパッチャ１１ｂは、発行元の認証サービス１００に対して認証チケットの発行を要求する（Ｓ２０５ｇ）。マスタチケットがチケット管理テーブル１９ｂに登録されていない場合（ステップＳ２０５ａでＮｏの場合）については後述する。
【００９５】
図１７に戻る。ステップＳ２０５に続いてステップＳ２０６に進み、ディスパッチャ１１ｂは、生成した認証チケットをシリアライズ及び暗号化し、暗号化された認証チケットを含むＳＯＡＰメッセージを認証チケット発行第２メソッドの呼び出し対する返却情報としてクライアント６０に対して送信する。
【００９６】
図２０は、認証チケット発行第２メソッドの返却情報を含むＳＯＡＰメッセージの例を示す図である。図２０のＳＯＡＰメッセージ６６の内容は、図１６のＳＯＡＰメッセージ６４の内容とほぼ同様であるため、その説明は省略する。
【００９７】
以上で、クライアント６０は、文書管理サービス２１ｂを利用するために必要な、文書管理サービス２１ｂに対する認証チケットを入手したことになる。したがって、その後は、ステップＳ１２７〜Ｓ１３２（図７）において説明したように、クライアント６０は、当該認証チケットを用いて文書管理サービス２１ｂとのセッションを接続し（Ｓ２０７〜Ｓ２１２）、文書管理サービス２１ｂの機能を利用することができる。
【００９８】
上述したように、第一の実施の形態における認証サーバ１０によれば、クライアント６０は、文書管理サーバ２０ａを利用する際に発行を受けたマスタチケットによって、文書管理サーバ２０ｂに対する認証チケットの発行を受けることができる。すなわち、クライアント６０は、文書管理サーバ２０ｂを利用する際に改めて認証サーバ１０ｂよりマスタチケットの発行を受ける必要はない。したがって、クライアント６０が利用する文書管理サーバ２０が切り替わるたびに各認証サーバ１０よりマスタチケットが発行されるという煩雑さが解消されると共に、ユーザは、利用する文書管理サーバ２０を切り替えるたびにユーザ名及びパスワード等を入力しなければならないという煩雑な作業から解放される。よって、複数のサービスのそれぞれを利用する際に必要とされる認証処理を効率化することができる。
【００９９】
次に、第二の実施の形態、すなわち、ユーザが、第一の実施の形態において使用したユーザ名、パスワード及びドメイン名と同じユーザ特定情報で文書管理サービス２１ｂを利用した後に文書管理サービス２１ａを利用する場合について説明する。第二の実施の形態の意義は、第一の実施の形態においては、最初の認証要求が認証サービス１００ａから１００ｂに委譲された場合の例であるのに対し、第二の実施の形態では、最初の認証要求はその認証要求を受けた認証サービス１００ｂによって処理されるという違いによって、全体の処理の流れがどのように変化するかという点を示すことにある。以下、シーケンス図に沿って説明する。
【０１００】
図２１及び図２２は、第二の実施の形態における文書管理サービス２１ｂを利用する際の処理を説明するためのシーケンス図である。図２１においては、クライアント６０が、文書管理サービス２１ｂによって管理されている文書一覧を取得する場合について説明する。なお、図２１の初期状態においては、カレントユーザは、いずれの認証サービス１００によっても認証を受けていない、すなわち、マスタチケットの発行を受けていないものとする。
【０１０１】
ステップＳ３０１及びステップＳ３０２において、クライアント６０は、文書管理サービス２１ｂにおける接続情報問い合わせメソッドを呼び出すことにより、文書管理サービス２１ｂよりその接続情報を取得する。この接続情報には、文書管理サービス２１ｂを一意に識別するための名前（ターゲットサービス名）と、文書管理サービス２１ｂが信頼している認証サービス１００ｂ（ターゲット認証サービス）のＵＲＩとが含まれている。
【０１０２】
ステップＳ３０２に続いてステップＳ３０３に進み、クライアント６０は、ターゲット認証サービスである認証サービス１００ｂの認証メソッドをＳＯＡＰのＲＰＣによって呼び出すことにより、ユーザの認証の要求（ＳＯＡＰメッセージ）を認証サービス１００ｂに対して送信する。
【０１０３】
ステップＳ３０３に続いてステップＳ３０４に進み、ＳＯＡＰメッセージを受信したディスパッチャ１１ｂは、認証サービス１００ｂにおけるルーティング情報管理テーブル１２ｂ（図１０）を参照して、認証処理を要求する認証プロバイダを判断する。ここでは、第一の実施の形態と同じドメイン名が指定されているため、ローカルプロバイダ１５ｂが呼び出される（Ｓ３０５）。したがって、ステップＳ３０６〜Ｓ３０９においては、ステップＳ１０９〜Ｓ１１２（図６）と同様の処理によって、ユーザの認証及びマスタチケットの生成が行われ、生成されたマスタチケットがチケット管理テーブル１９ｂに登録される。ステップＳ３０９に続いてステップＳ３１０に進み、ディスパッチャ１１ｂは、認証メソッドの返却情報として、生成されたマスタチケットを含むＳＯＡＰメッセージをクライアント６０に対して送信する。
【０１０４】
続いて、クライアント６０は、文書管理サービス２１ｂを対象とした認証チケットを入手するための処理を実行する（図２２）。すなわち、ステップＳ３１０に続いてステップＳ３１１に進み、クライアント６０は、ターゲット認証サービスである認証サービス１００ｂの認証チケット発行メソッドをＳＯＡＰのＲＰＣによって呼び出すことにより、認証チケットの発行要求（ＳＯＡＰメッセージ）を認証サービス１００ｂに対して送信する。
【０１０５】
ＳＯＡＰメッセージを受信したディスパッチャ１１ｂにおいては、ステップＳ１２１及びＳ１２２（図７）と同様に認証チケットの生成処理が実行され（Ｓ３１２、Ｓ３１３）、生成された認証チケットがディスパッチャ１１ｂからクライアント６０に対して送信される（Ｓ３１４）。
【０１０６】
以上で、クライアント６０は、文書管理サービス２１ｂを利用するために必要な、文書管理サービス２１ｂに対する認証チケットを入手したことになる。したがって、その後は、ステップＳ１２７〜Ｓ１３２（図７）において説明したように、クライアント６０は、当該認証チケットを用いて文書管理サービス２１ｂとのセッションを接続し（Ｓ３１５〜Ｓ３１６）、文書管理サービス２１ｂの機能を利用することができる。
【０１０７】
次に、文書管理サービス２１ｂの機能を利用していたユーザが、文書管理サービス２１ａの機能を利用しようとした場合の処理について説明する。図２３は、第二の実施の形態における文書管理サービス２１ａを利用する際の処理を説明するためのシーケンス図である。
【０１０８】
ステップＳ４０１及びステップＳ４０２において、クライアント６０は、文書管理サービス２１ａにおける接続情報問い合わせメソッドを呼び出すことにより、文書管理サービス２１ａよりその接続情報を取得する。この接続情報には、文書管理サービス２１ａを一意に識別するための名前（ターゲットサービス名）と、文書管理サービス２１ａが信頼している認証サービス１００ａ（ターゲット認証サービス）のＵＲＩとが含まれている。
【０１０９】
ステップＳ４０２に続いてステップＳ４０３に進み、クライアント６０は、既にいずれかの認証サービス１００から発行されたカレントユーザに対するマスタチケットを有しているか否かを判断する。ここでは、文書管理サービス２１ｂを利用する際に認証サービス１００ｂより発行を受けた（図２１：Ｓ３１０）マスタチケットが保持されているため、クライアント６０は、マスタチケットを有している旨を判断する。
【０１１０】
ステップＳ４０３に続いてステップＳ４０４に進み、クライアント６０は、マスタチケットを既に有していることから、このマスタチケットを用いてターゲット認証サービスである認証サービス１００ａの認証チケット発行第２メソッド（createAuthTicketBySSO）をＳＯＡＰのＲＰＣによって呼び出すことにより、認証チケットの発行要求（ＳＯＡＰメッセージ：図１８）を認証サービス１００ｂに対して送信する。一方、ここでマスタチケットを有していなかった場合は、クライアント６０は、ユーザに対してユーザ名及びパスワード等の入力を要求し、入力されたユーザ名及びパスワード等を引数として図２１のステップＳ３０３と同様に、認証サービス１００ａの認証メソッドを呼び出す。すなわち、ステップＳ４０３におけるマスタチケットの有無の判断処理は、図２１のステップＳ４０３の直前においても実行されているものであるが、図２１においては便宜上省略したものである。
【０１１１】
なお、認証チケット発行第２メソッドの引数に指定されているマスタチケットは、ステップＳ２０５（図１７）の場合と同様、クライアント６０から見た場合、認証チケットの発行の要求先である認証サービス１００ａとは異なる認証サービス１００ｂによって発行されたものである点に注意を要する。
【０１１２】
ステップＳ４０４に続いてステップＳ４０５に進み、ＳＯＡＰメッセージを受信したディスパッチャ１１ａは、認証チケット生成処理（図１９）を実行する。但し、ここでは、チケット管理テーブル１９ａには、マスタチケットは登録されていない。すなわち、これ以前に実行されている図２１及び図２２の処理においては、チケット管理テーブル１９ａに対するマスタチケットの登録処理は実行されていないからである。したがって、図１９のステップＳ２０５ａにおいて、ディスパッチャ１１ａは、マスタチケットは存在しない旨を判断し、ステップＳ２０５ｆに進む。
【０１１３】
ステップＳ２０５ｆにおいて、ディスパッチャ１１ａは、認証チケット発行第２メソッドの引数に指定されている、マスタチケットの発行元の認証サービスのＵＲＩが信頼関係リスト１１１に存在するか否かを判断する。
【０１１４】
図２４は、信頼関係リストの例を示す図である。図２４の信頼関係リスト１１１には、認証サービス１００ａが信頼している他の認証サービス１００のＵＲＩの一覧が登録されている。ここで「信頼している」とは、管理者の責任の下、マスタチケットの発行や認証チケットの発行を委譲させてもセキュリティ上問題ないと判断された関係をいう。したがって、客観的には、信頼関係リスト１１１には、マスタチケットの委譲先となり得る認証サービス１００のＵＲＩの一覧が登録されていることとなる。
【０１１５】
したがって、信頼関係リスト１１１にマスタチケットの発行元の認証サービス１００ｂのＵＲＩが登録されている場合は、ディスパッチャ１１ａは、認証サービス１００ｂの認証チケット発行メソッドをＳＯＡＰのＲＰＣによって呼び出すことにより、認証サービス１００ｂに対して認証チケットの発行を要求する（Ｓ２０５ｇ）。一方、信頼関係リスト１１１に認証サービス１００ｂのＵＲＩが登録されていない場合は、認証チケットの発行処理を、マスタチケットの発行元として指定されている認証サービス１００ｂに委譲することはできないため、認証チケット生成処理は異常終了する。
【０１１６】
図２３に戻る。図２３においてステップＳ４０６は、図１９において説明したステップＳ２０５ｇに相当する。ステップＳ４０６に続いてステップＳ４０７に進み、ＳＯＡＰメッセージを受信したディスパッチャ１１ｂは、ステップＳ３１２及びＳ３１３（図２２）と同様に認証チケットの生成処理を実行し（Ｓ４０８）、生成した認証チケットをクライアント６０に対して送信する（Ｓ４０９）。
【０１１７】
ステップＳ４０９に続いてステップＳ４１０に進み、ディスパッチャ１１ａは、受信した認証チケットをチケット管理テーブル１９ａに登録する。ステップＳ４１１に続いてステップＳ４１２に進み、ディスパッチャ１１ａは、認証チケット発行第２メソッドの返却情報として、認証チケットを含むＳＯＡＰメッセージをクライアント６０に対して送信する。
【０１１８】
以上で、クライアント６０は、文書管理サービス２１ａを利用するために必要な、文書管理サービス２１ａに対する認証チケットを入手したことになる。したがって、その後は、ステップＳ１２７〜Ｓ１３２（図７）において説明したように、クライアント６０は、当該認証チケットを用いて文書管理サービス２１ａとのセッションを接続し（Ｓ４１２〜Ｓ４１７）、文書管理サービス２１ａの機能を利用することができる。
【０１１９】
上述したように、第二の実施の形態における認証サーバ１０によれば、クライアント６０は、文書管理サーバ２０ｂを利用する際に発行を受けたマスタチケットによって、文書管理サーバ２０ａに対する認証チケットの発行を受けることができる。すなわち、クライアント６０は、文書管理サーバ２０ａを利用する際に改めて認証サーバ１０ａよりマスタチケットの発行を受ける必要はない。したがって、クライアント６０が利用する文書管理サーバ２０が切り替わるたびに各認証サーバ１０よりマスタチケットが発行されるという煩雑さが解消されると共に、ユーザは、利用する文書管理サーバ２０を切り替えるたびにユーザ名及びパスワード等を入力しなければならないという煩雑な作業から解放される。よって、複数のサービスのそれぞれを利用する際に必要とされる認証処理を効率化することができる。
【０１２０】
なお、認証サーバ１０を連携（認証処理の委譲）させることは、セキュリティの劣化につながることはない。認証サーバ１０の連携は、システム管理者の責任のもとに行われることであり、各認証サーバ１０の間には信頼関係があるものといえる。そして、その信頼関係によってセキュリティは維持されるものと考えられる。
【０１２１】
また、本実施の形態においては、ユーザ特定情報として、ユーザ名及びパスワード等を用いる例を示したが、ユーザ特定情報としてかかる情報に限定する趣旨ではない。認証技術の発達により指紋認証、カード認証等、各種の認証方法が近年においては採用されているが、ユーザ特定情報は、各認証方法に対応した情報に置き換えることが可能である。
【０１２２】
ところで、近年においては、ある特定の機能に特化した組み込み機器においてもＣＰＵが搭載され、コンピュータと同様にソフトウェアによって機能を実現するものが提供されている。例えば、融合機、又は複合機と呼ばれる、プリンタ、コピー、又はファクシミリ等の複数のアプリケーションを有する画像形成装置もかかる機器に該当する。そして、セキュリティ上の観点より、このような機器にも認証機能が必要とされる場合がある。
【０１２３】
したがって、このような機器に対して、本発明を適用してもよい。図２５は、本実施の形態における認証サービスを実装した機器の構成例を示す図である。図２５中、図５と同一部分には同一符号を付し、その説明は省略する。
【０１２４】
図２５において、機器４００は、認証サービス１００と、サービス４０１ａ、サービス４０１ｂ、サービス４０１ｃ及びサービス４０１ｄ（以下、総称する場合「サービス４０１」という。）とを有している。
【０１２５】
サービス４０１は、認証サービス１００によって認証された場合に利用が許可されるサービスを提供するプログラムモジュールである。例えば、複合機であれば、文書管理機能を提供する文書管理サービスや、印刷機能を提供する印刷サービス、文書配信機能を提供する配信サービス等が相当する。すなわち、機器４００は、図３の文書管理システム１において、認証サーバ１０ａ又は１０ｂと、文書管理サーバ２０ａ又は２０ｂとに分散されていた機能が一つの筐体内に実装されているものにも相当する。
【０１２６】
なお、図２５において、リモートプロバイダＢ１７による認証処理の委譲先としての「他の認証サービスＢ」は、例えば、認証サーバ１０ａ又は１０ｂ等でもよいし、機器４００と同様の機器でもよい。
【０１２７】
以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【０１２８】
【図１】クライアントが文書管理サーバの利用を開始する場合の例を示す図である。
【図２】サービスごとにユーザ管理サーバが設置された例を示す図である。
【図３】本発明の実施の形態における文書管理システムの構成例を示す図である。
【図４】本発明の実施の形態における認証サーバのハードウェア構成例を示す図である。
【図５】本発明の実施の形態における認証サービスの機能構成例を示す図である。
【図６】第一の実施の形態における文書管理サービス２１ａを利用する際の処理を説明するためのシーケンス図である。
【図７】第一の実施の形態における文書管理サービス２１ａを利用する際の処理を説明するためのシーケンス図である。
【図８】認証メソッドを呼び出す際のＳＯＡＰメッセージの例を示す図である。
【図９】認証サービス１００ａにおけるルーティング情報管理テーブルの構成例を示す図である。
【図１０】認証サービス１００ｂにおけるルーティング情報管理テーブルの構成例を示す図である。
【図１１】チケットのデータ構造例を示す図である。
【図１２】認証サービス１００ｂにおけるチケット管理テーブルの構成例を示す図である。
【図１３】認証メソッドの返却情報を含むＳＯＡＰメッセージの例を示す図である。
【図１４】認証サービス１００ａにおけるチケット管理テーブルの構成例を示す図である。
【図１５】認証チケット発行メソッドを呼び出す際のＳＯＡＰメッセージの例を示す図である。
【図１６】認証チケット発行メソッドの返却情報を含むＳＯＡＰメッセージの例を示す図である。
【図１７】第一の実施の形態における文書管理サービス２１ｂを利用する際の処理を説明するためのシーケンス図である。
【図１８】認証チケット発行第２メソッドを呼び出す際のＳＯＡＰメッセージの例を示す図である。
【図１９】認証チケット発行第２メソッドが呼び出された場合の認証チケット生成処理を説明するためのフローチャートである。
【図２０】認証チケット発行第２メソッドの返却情報を含むＳＯＡＰメッセージの例を示す図である。
【図２１】第二の実施の形態における文書管理サービス２１ｂを利用する際の処理を説明するためのシーケンス図である。
【図２２】第二の実施の形態における文書管理サービス２１ｂを利用する際の処理を説明するためのシーケンス図である。
【図２３】第二の実施の形態における文書管理サービス２１ａを利用する際の処理を説明するためのシーケンス図である。
【図２４】信頼関係リストの例を示す図である。
【図２５】本実施の形態における認証サービスを実装した機器の構成例を示す図である。
【符号の説明】
【０１２９】
１                        文書管理システム
１０ａ、１０ｂ、１０ｃ    認証サーバ
１１、１１ａ、１１ｂ      ディスパッチャ
１２、１２ａ、１２ｂ      ルーティング情報管理テーブル
１３              Ｗプロバイダ
１４              Ｎプロバイダ
１５              ローカルプロバイダ
１６              リモートプロバイダＡ
１７              リモートプロバイダＢ
１８              ユーザ情報ＤＢ
１９、１９ａ、１９ｂ      チケット管理テーブル
２０              文書管理サーバ
２１              文書管理サービス
３０              Ｗｅｂサーバ
４０              端末
５０              ネットワーク
６０              クライアント
１００ａ、１００ｂ、１００ｃ    認証サービス
１１１            信頼関係リスト
４００            機器
４０１、４０１ａ、４０１ｂ、４０１ｃ、４０１ｄ      サービス
５０１、５０１ａ、５０１ｂ、５０１ｃ            文書管理サーバ
５０２            クライアント
５０３、５０３ａ、５０３ｂ、５０３ｃ            ユーザ管理サーバ
１０１１          ＣＰＵ
１０１２          ＲＯＭ
１０１３          ＲＡＭ
１０１４          補助記憶装置
１０１５          ネットワークＩ／Ｆ
１０１６          ドライブ装置
１０１７          記録媒体
【図１】
2005259111.tif 000003
【図２】
2005259111.tif 000004
【図３】
2005259111.tif 000005
【図４】
2005259111.tif 000006
【図５】
2005259111.tif 000007
【図６】
2005259111.tif 000008
【図７】
2005259111.tif 000009
【図８】
2005259111.tif 000010
【図９】
2005259111.tif 000011
【図１０】
2005259111.tif 000012
【図１１】
2005259111.tif 000013
【図１２】
2005259111.tif 000014
【図１３】
2005259111.tif 000015
【図１４】
2005259111.tif 000016
【図１５】
2005259111.tif 000017
【図１６】
2005259111.tif 000018
【図１７】
2005259111.tif 000019
【図１８】
2005259111.tif 000020
【図１９】
2005259111.tif 000021
【図２０】
2005259111.tif 000022
【図２１】
2005259111.tif 000023
【図２２】
2005259111.tif 000024
【図２３】
2005259111.tif 000025
【図２４】
2005259111.tif 000026
【図２５】
2005259111.tif 000027