JP2005202923A - 情報処理装置、情報処理システム、情報処理方法、情報処理プログラム及び記録媒体 - Google Patents

Abstract

【課題】 一度のユーザ情報の入力で複数のサービスの利用を可能とする情報処理装置、情報処理システム、情報処理方法、情報処理プログラム及び記録媒体の提供を目的とする。
【解決手段】 それぞれ所定のサービスを提供する複数の外部装置と、外部装置のサービスを利用するユーザを認証するための認証手段を有する一つ以上の認証装置とネットワークを介して接続する情報処理装置であって、それぞれ異なる外部装置のサービスに対するインタフェースをユーザに提供する複数のサービス提供手段と、サービス提供手段からの認証要求に応じ、ユーザ情報の入力を要求し、入力されたユーザ情報に基づく認証の要求を認証手段に送信する認証制御手段と、認証の要求を送信した認証手段を一意に識別する要求先識別情報と、ユーザ情報と、サービス提供手段を識別するための要求元識別情報とを関連付けて管理する認証情報管理手段とを有することにより上記課題を解決する。
【選択図】 図４

Description

本発明は、情報処理装置、情報処理システム、情報処理方法、情報処理プログラム及び記録媒体に関し、特にユーザの認証を所定のサーバに要求する情報処理装置、情報処理システム、情報処理方法、情報処理プログラム及び記録媒体に関する。

ＰＣ等のユーザ端末から所定のサーバにおいて提供されている機能（サービス）を利用する際には、ユーザ名及びパスワード等のユーザ情報の入力が求められるのが一般である。入力されたユーザ情報に基づいてサーバにおいてユーザの認証を行い、認証されたユーザに対してのみサービスを提供することで、不正なユーザによる不正利用を防止するためである。

ここで、ユーザの認証を行うためには、認証処理を実現する認証エンジンと呼ばれるプログラムと、ユーザ情報を管理するためのデータベース（以下、「ユーザ情報ＤＢ（データベース）」という。）とからなる認証機能をサーバに実装する必要がある。しかし、複数のサーバが接続されるシステムにおいて、サーバごとに認証機能を実装していたのでは、記憶装置等の資源を不要に消費するだけでなく、保守作業等を煩雑化させる。

そこで、認証機能を一つのサーバだけに実装し、他のサーバは認証機能の実装されたサーバにユーザの認証を依頼するといったシステム形態が従来から採用されている。

図１は、認証機能を一つのサーバに集約したシステムの概念図である。図１において、端末５０１はユーザが利用するＰＣ（Personal Computer）等の端末である。文書管理サーバ５０２及び文書管理サーバ５０３は、それぞれ別個の文書管理ＤＢ（データベース）を有するいわゆる文書管理サーバである。認証サーバ５０４は、認証機能が実装されているサーバである。図１においては、端末５０１のユーザが文書管理サーバ５０２及び文書管理サーバ５０３のいずれにログオンする場合も同一の認証サーバ５０４によってユーザの認証が実行されることが示されている。

しかしながら、図１のようなシステム形態は、確かに認証機能の保守の容易化等を図ることはできるが、端末５０１のエンドユーザから見た場合、認証先は同じ認証サーバ５０４であるにもかかわらず、各文書管理サーバにアクセスするにごとにログオン、すなわちユーザ名及びパスワード等の入力といった煩雑な作業が要求されるという問題があった。

例えば、一つの画面上にそれぞれの文書管理サーバにアクセスするためのアイコンが配置されている場合等、文書管理サーバ５０２に対してアクセスするためのＧＵＩ（Graphical User Interface）部品と、文書管理サーバ５０３に対してアクセスするためのＧＵＩ部品とが、統合化された環境において提供されている場合に、一方にアクセスする際に既にログオンしているにもかかわらず、他方にアクセスする際に再びログオンが要求されるのは、煩雑なだけでなく、不自然ささえ感じられる。

本発明は、上記の点に鑑みてなされたものであって、一度のユーザ情報の入力で複数のサービスの利用を可能とする情報処理装置、情報処理システム、情報処理方法、情報処理プログラム及び記録媒体の提供を目的とする。

そこで上記課題を解決するため、本発明は、それぞれ所定のサービスを提供する複数の外部装置と、前記外部装置のサービスを利用するユーザを認証するための認証手段を有する一つ以上の認証装置とネットワークを介して接続する情報処理装置であって、それぞれ異なる前記外部装置のサービスに対するインタフェースを前記ユーザに提供する複数のサービス提供手段と、前記サービス提供手段からの認証要求に応じ、前記ユーザに該ユーザを認証するためのユーザ情報の入力を要求し、入力された前記ユーザ情報に基づく認証の要求を前記認証手段に送信する認証制御手段と、前記認証制御手段が前記認証の要求を送信した前記認証手段を一意に識別する要求先識別情報と、前記ユーザによって入力されたユーザ情報と、前記認証要求に係る前記サービス提供手段を識別するための要求元識別情報とを関連付けて管理する認証情報管理手段とを有することを特徴とする。

このような情報処理装置では、ユーザによって入力されたユーザ名及びパスワード等のユーザ情報を保持しておくことができるため、再度ユーザの認証が必要となった場合でも、ユーザに入力を要求することなく、保持されているユーザ情報を用いてユーザの認証を認証装置に要求することができる。

また、上記課題を解決するため、本発明は、上記情報処理装置における情報処理方法、前記情報処理方法を前記情報処理装置に実行させるための情報処理プログラム、又は前記情報処理プログラムを記録した記録媒体としてもよい。

本発明によれば、一度のユーザ情報の入力で複数のサービスの利用を可能とする情報処理装置、情報処理システム、情報処理方法、情報処理プログラム及び記録媒体を提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図２は、第一の実施の形態における文書管理システムの構成例を示す図である。第一の形態における文書管理システム１は、クライアント装置１０、認証サーバ２０、文書管理サーバ３０ａ及び３０ｂ（以下、総称する場合「文書管理サーバ３０」という。）等がＬＡＮ又はインターネット等のネットワーク４０（有線又は無線の別は問わない。）を介して接続されることにより構成されている。

クライアント装置１０は、文書管理システム１のユーザが直接利用する各種アプリケーションが実装されているＰＣ（Personal Computer）、ＰＤＡ（Personal Digital(Data) Assistants）、又は携帯電話等の端末である。

認証サーバ２０は、ユーザの認証機能が実装されているコンピュータであり、その認証機能をネットワーク４０上に提供している。

文書管理サーバ３０は、文書情報（文書の実データ及び文書の書誌情報等）の管理機能（文書情報管理機能）が実装されているコンピュータであり、その文書情報管理機能をネットワーク４０上に提供している。文書管理サーバ３０は、認証サーバ２０の認証機能によって認証されたクライアントに対してのみその文書情報管理機能を提供する。したがって、ユーザによって文書管理サーバ３０からの文書情報の検索等が指示されたクライアント装置１０の各種アプリケーションは、文書管理サーバ３０にアクセスする前に認証サーバ２０によって当該ユーザの認証を受けておく必要がある。

なお、図２においては、文書管理サーバ３０は２台のみ表示されているが、３台以上の文書管理サーバ３０がネットワーク４０に接続していてもよい。また、クライアント装置１０や認証サーバ２０についても複数台がネットワーク４０に接続していてもよい。

次に、クライアント装置１０の詳細について説明する。図３は、本発明の実施の形態におけるクライアント装置のハードウェア構成例を示す図である。図３のクライアント装置１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、演算処理装置１０４と、ネットワークＩ／Ｆ（インタフェース）装置１０５と、入力装置１０６と、表示装置１０７とを有するように構成される。

クライアント装置１０での処理を実現するプログラムは、CD―ROM等の記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。演算処理装置１０４は、メモリ装置１０３に格納されたプログラムに従ってクライアント装置１０に係る機能を実行する。ネットワークＩ／Ｆ装置１０５は例えばモデム、ルータ等で構成され、図１のネットワーク３０に接続するために用いられる。

入力装置１０６はキーボード及びマウス等で構成され、様々な操作指示を入力するために用いられる。表示装置１０７はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。

次に、文書管理システム１の機能構成例について説明する。図４は、本発明の実施の形態におけるクライアント装置の機能構成例を示す図である。図４に示されるように、クライアント装置１０は、クライアントアプリケーション１１、認証制御モジュール１２、認証管理モジュール１３、ＳＯＡＰプロキシ１４、及び文書管理モジュール１５等より構成される。

クライアントアプリケーション１１は、アプリ１１ａ、アプリ１１ｂ、アプリ１１ｃ及びアプリ１１ｄ等の複数のプラグインとしてのアプリケーションを統合した環境（ユーザインタフェース）を提供するものである。すなわち、クライアントアプリケーション１１には、アプリ１１ａ等のようなアプリケーションを必要に応じて追加又は削除（着脱）することが可能である。なお、プロセスの単位としては、アプリ１１ａ等を含むクライアントアプリケーション１１で一つのプロセスとしてもよいし、アプリ１１ａ等のそれぞれを一つのプロセスとしてもよい。

図５は、クライアントアプリケーションのメイン画面の表示例を示す図である。図５に示されるように、メイン画面１１０は、一般的な文書管理アプリケーションにおいてよく見受けられるようにツリー表示領域１１１と文書一覧表示領域１１２とから構成される。ツリー表示領域１１１には、文書情報の格納場所がツリー形式におけるノードとして表示されている。
ツリー表示領域１１１におけるノード１１３は、文書管理サーバ３０ａの文書管理サービス３１（以下、「文書管理サービス３１ａ」という。）に対応したノードであり、一つのアプリケーション（ここでは、アプリ１１ａ）に対応している。すなわち、ユーザがノード１１３をクリックするとアプリ１１ａが呼び出され、アプリ１１ａが実行する処理によって文書管理サービス３１ａに格納されている文書情報が文書一覧表示領域１１２に表示される。

同様に、ノード１１４は、文書管理サーバ３０ｂの文書管理サービス３１（以下、「文書管理サービス３１ｂ」という。）に対応したノードであり、アプリ１１ｂに対応している。したがって、アプリ１１ａ及びアプリ１１ｂによって文書管理サーバ３０ａ及び文書管理サーバ３０ｂに対するインタフェースがユーザに提供される。

一方、文書一覧表示領域１１２には、ツリー表示領域１１１において選択されているノード（フォルダ）に保存されている文書情報のアイコン（文書アイコン）の一覧がサムネール形式によって表示されている。ユーザは、文書一覧表示領域１１２に表示された文書アイコンを操作することによって、当該文書情報を削除したり、他のフォルダにコピー若しくは移動したりすることができる。

認証制御モジュール１２は、アプリ１１ａ等から認証要求を受け付け、当該認証要求に基づいて実行される処理の制御を行うためのモジュールである。認証制御モジュール１２は、認証情報テーブル１２１を有しており、認証情報テーブル１２１に基づいて処理の制御を行う。

認証管理モジュール１３は、認証制御モジュール１２からの要求に応じて認証サーバ２０に対して認証の要求等を行うためのモジュールである。認証管理モジュール１３は、ＳＯＡＰプロキシ１４を介して認証サーバ２０に対する要求を行う。

ＳＯＡＰプロキシ１４は、認証サーバ２０における認証サービス２１（後述される）のインタフェースを上位モジュール（ここでは認証管理モジュール１３）に対して透過的に提供するためのモジュールである。すなわち、ＳＯＡＰプロキシ１４は、上位モジュールより呼び出されたインタフェースに応じた要求をＳＯＡＰメッセージとして認証サービス２１に対して送信し、それに対応して認証サービス２１より返信されるＳＯＡＰメッセージに含まれている情報を上位モジュールに返却する。

文書管理モジュール１５は、文書管理サーバ３０における文書管理サービス３１（後述される）を利用するための各種インタフェースが実装されているモジュールである。すなわち、文書管理モジュール１５は、上位モジュール（ここではアプリ１１ａ等）から呼び出されたインタフェースに応じた要求を文書管理サービス３１に対して送信し、それに対して文書管理サービス３１より返信された情報を上位モジュールに返却する。

認証サーバ２０には、認証サービス２１が実装されている。認証サービス２１は、ユーザの認証機能をＷｅｂサービスとして提供するためのモジュール群である。認証サービス２１は、ＳＯＡＰ（Simple Object Access Protocol）インタフェースによってクライアント（ここでは、クライアント装置１０）からの要求を受け付けることが可能である。

また、文書管理サーバ３０には、文書管理サービス３１が実装されている。文書管理サービス３１は、文書情報管理機能をＷｅｂサービスとして提供するためのモジュール群である。文書管理サービス３１は、ＳＯＡＰインタフェースによってクライアント（ここでは、クライアント装置１０）からの要求を受け付けることが可能である。

なお、図４においては、クライアントアプリケーション１１と認証制御モジュール１２とが一対一の関係にあり、クライアントアプリケーション１１内の複数アプリケーション（アプリ１１ａ等）によって、認証制御モジュール１２が共通的に利用されるように示されているが、認証制御モジュール１２は、クライアントアプリケーション１１内のアプリケーションだけでなく、クライアントアプリケーション１１とは全く独立した関係にあるアプリケーションからも共通的に利用可能である。

以下、図２及び図４の文書管理システムの処理手順について説明する。図６及び図７は、認証サービス２１によって認証を受けていない場合の認証処理を説明するためのシーケンス図である。図６の初期状態において、クライアントアプリケーション１１は起動直後であるとする。したがって、メイン画面１１１におけるノード１１３及び１１４は閉じた状態であり、文書一覧表示領域１１２には、文書アイコンは全く表示されていない。ここで、ユーザが、文書管理サービス３１ａにアクセスすべく、ノード１１３をクリックすると処理が開始される。

ステップＳ１１において、アプリ１１ａは、ユーザによるノード１１３のクリックに基づいて、文書管理サービス３１ａにアクセスするためにはどの認証サービスによって認証されている必要があるか等、文書管理サービス３１ａにアクセスするために必要な情報（以下、「接続情報」という。）の文書管理サービス３１ａへの問い合わせを文書管理モジュール１５に対して要求する。

ステップＳ１１に続いてステップＳ１２に進み、文書管理モジュール１５が文書管理サービス３１ａに対して接続情報の問い合わせを行うと、文書管理サービス３１ａより接続情報が返信され（Ｓ１３）、その接続情報がアプリ１１ａに通知される（Ｓ１４）。

ここで得られた接続情報には、例えば、認証を受けるべき認証サービスのＵＲＩとして認証サービス２１のＵＲＩ、認証を受けるドメインのドメイン名及び認証プロバイダの種別等が含まれている。

ここで、認証プロバイダについて説明する。本実施の形態における認証サービス２１は、Ｗｉｎｄｏｗｓ（登録商標）のネットワーク認証や、ユーザが独自に開発した認証エンジン等、様々な認証エンジンに対応することが可能となっている。但し、各認証エンジンに対応するためには、各認証エンジンの有する独自のインタフェースを吸収し、上位モジュールに対して予め定められた統一されたインタフェースを提供するためのモジュールの実装が認証エンジンごとに必要とされる。その統一されたインタフェースを提供するためのモジュールを認証プロバイダと呼ぶ。また、認証プロバイダの種別（以下、「プロバイダ種別」という。）とは、各認証プロバイダを識別するための識別情報であり、例えば、各認証プロバイダに付けられた名前等が相当する。

したがって、接続情報に含まれている認証サービス２１のＵＲＩとプロバイダ種別とにより、アプリ１１ａは、文書管理サービス３１ａにアクセスするためにはどの認証サービスのどの認証プロバイダによって認証されている必要があるかということを判断することができる。

なお、本実施の形態においては、一つに認証サービス２１内に一つ以上の認証プロバイダが実装されている場合を考慮してプロバイダ種別という概念を導入しているが、一つの認証サービス２１には一つの認証エンジンしか実装されていない場合は、認証サービス２１が一意に定まれば認証エンジンは一意に定まるため、プロバイダ種別という概念を用いて認証エンジンを特定する必要はない。

ステップＳ１４に続いて、アプリ１１ａは、認証サービス２１に認証を受けるための準備として、認証制御モジュール１２の初期化を行う（Ｓ１５、Ｓ１６）。

ステップＳ１６に続いてステップＳ１７に進み、アプリ１１ａは、インスタンスハンドル、認証サービス２１のＵＲＩ、ドメイン名、及びプロバイダ種別等を引数に指定して、認証サービス２１によってユーザの認証を受けるよう認証制御モジュール１２に要求する。ここで、インスタンスハンドルとは詳細については後述されるが、当該認証要求に対する戻り値として認証制御モジュール１２から返却される情報であり、認証制御モジュール１２は、主に各アプリケーションを識別するための情報（要求元識別情報）として用いる。したがって、最初に認証要求を行う際には、まだインスタンスハンドルは発行されていないためこの引数には空値（ＮＵＬＬ）が指定される。

ステップＳ１７に続いてステップＳ１８に進み、認証制御モジュール１２は、認証サービス２１による認証は既に行われているか否か等を判断する。なお、ここでの判断処理の詳細については後述する。ここでは、ユーザがまだ認証を受けていない場合の処理であるため、認証制御モジュール１２は、認証は行われていないものと判断し、認証を受けるための処理を開始する。

ステップＳ１８に続いてステップＳ１９に進み、認証制御モジュール１２は、認証管理モジュール１３に対し認証サービス２１のＵＲＩを引数としてインスタンスの生成を要求する。ここで、インスタンスとは、認証管理モジュール１３において、各アプリケーション（アプリ１１ａ等）と各文書管理サービス３１とのそれぞれの接続を識別するために、各接続に対して割り当てられる管理単位に対する概念である。本実施の形態においては、各アプリケーションと各文書管理サービスとは１対１の関係にあるため、インスタンスは実質的にはアプリケーションごとに一つずつ管理される。そして、かかるインスタンスを一意に識別するための情報が、インスタンスハンドルである。なお、インスタンスの実装上の実体としては、オブジェクト、構造体、又はテーブルにおけるレコード等としてもよい。

認証管理モジュール１３は、認証制御モジュール１２からの要求に基づいて、インスタンスを生成し、生成したインスタンスに認証サービス２１のＵＲＩをセットする。なお、ここで生成されたインスタンスを以下「インスタンスＡ」という。

ステップＳ１９に続いてステップＳ２０に進み、認証管理モジュール１３は、インスタンスＡのインスタンスハンドル（以下、「インスタンスハンドルＡ」という。）を認証制御モジュール１２に対して返却する。ここで返却されたインスタンスハンドルは、認証制御モジュール１２が各アプリケーションを識別するために用いられる。

ステップＳ２０に続いてステップＳ２１に進み、認証制御モジュール１２は、インスタンスＡのインスタンスハンドルＡとプロバイダ種別とを引数として、認証先となる認証プロバイダのプロバイダ種別のインスタンスＡへのセットを認証管理モジュール１３に対して要求する。認証管理モジュール１３は、インスタンスＡにプロバイダ種別をセットし、セットした旨を認証制御モジュール１２に通知する（Ｓ２２）。

ステップＳ２２に続いてステップＳ２３に進み、認証制御モジュール１２は、ユーザ名及びパスワード等のユーザ情報をユーザに入力させるためのログオン画面を表示させる。ユーザがログオン画面に認証サービス２１に対するユーザ名及びパスワードを入力すると、認証制御モジュール１２は、インスタンスハンドルＡと、ログオン画面に入力されたユーザ名及びパスワードと、ドメイン名と、認証の有効期限とを引数として認証管理モジュール１３に対して認証を要求する（Ｓ２４）。

ステップＳ２４に続いてステップＳ２５に進み、認証管理モジュール１３は、インスタンスＡにセットされているＵＲＩによって識別される認証サービス２１に対し、認証を要求する。なお、認証サービス２１に対する認証の要求には、ユーザ名、パスワード、ドメイン名、プロバイダ種別及び有効期限等が引数として指定される。プロバイダ種別は、既にインスタンスＡにセットされているものである。

ステップＳ２５に続いて認証サービス２１は、引数に指定されたプロバイダ種別によって識別される認証プロバイダを用いて、ユーザ名及びパスワードに基づいてユーザの認証を行う。ユーザが認証された場合は、認証サービス２１は、ユーザが認証された旨を示す証明書としてのデータ（以下、「チケット」という。）を生成し、生成したチケットを認証管理モジュール１３に返信する（Ｓ２６）。なお、ここで生成されるチケットには、引数に指定された有効期限等が記録されている。

ここで、チケットについて説明する。本実施の形態においてはマスタチケットと認証チケットとの二種類のチケットが定義されている。それぞれのチケットは、ユーザが認証された旨を示す証明書としての役割を果たすという点において共通するが、用途が大きく異なる。

認証チケットは、限られた範囲のみで有効なチケットである。例えば、文書管理サーバ３０ａを対象として発行された認証チケットは、文書管理サーバ３０ｂに対しては利用できない。他のサーバ装置は、自分を対象としていない認証チケットを伴った要求を認めないからである。

これに対しマスタチケットは、チケットを用いた認証に対応している全てのサーバ装置において有効な万能のチケットである。また、マスタチケットを提示することによって認証チケットの発行を受けることができる。

これら２種類のチケットが定義されているのは、セキュリティ上の観点によるところが大きい。すなわち、認証チケットは、マスタチケットをネットワーク上に頻繁に流通させないために定義されたチケットである。したがって、マスタチケットは、認証チケットの発行要求時等、限られた際にしか用いられない。

なお、ステップＳ２５に基づいて生成されるチケットはマスタチケットである。したがって、ステップＳ２６においてはマスタチケットが認証管理モジュール１３に対して送信される。

ステップＳ２６に続いてステップＳ２７に進み、認証管理モジュール１３は、認証サービス２１に対してマスタチケットを引数として認証チケットの発行を要求する。ステップＳ２７に続いてステップＳ２８に進み、認証サービス２１は、有効期限等、マスタチケットの正当性を確認し、正当性が確認された場合は認証管理モジュール１３に対して認証チケットを発行する。認証管理モジュール１３は、認証サービス２１より受信した認証チケットをインスタンスＡに関連付けて保持しておく。

ステップＳ２８に続いてステップＳ２９に進み、認証管理モジュール１３は、認証結果（ここでは認証された旨）を認証要求（Ｓ２４）に対する応答として認証制御モジュール１２に対して返却する。

ステップＳ２９に続いてステップＳ３０（図７）に進み、認証制御モジュール１２は、認証が成功したことに基づいて認証情報テーブル１２１に新たなエントリを追加する。

図８は、認証情報テーブルの構成例を示す図である。図８に示されるように、認証情報テーブル１２１は、認証が成功した場合の認証先に関する情報及びその際に利用されたユーザ情報等（以下、「認証情報」という。）を管理しておくためのテーブルであり、認証サービスのＵＲＩ（要求先識別情報）、プロバイダ種別、ユーザ名、パスワード、ドメイン名、インスタンスハンドル（要求元識別情報）、及び参照カウンタ等の項目より構成される。

認証情報テーブル１２１は、認証サービスのＵＲＩ及びプロバイダ種別によって一意に定まるエントリごとに認証情報を管理する。本実施の形態においては、一つのクライアント装置１０は、一人のユーザによって利用されているという前提にある。すなわち、認証先ごとにユーザ情報（ユーザ名及びパスワード）は一つであるという関係が成り立つ。したがって、各エントリは、ユーザ情報を考慮するまでもなく認証サービスのＵＲＩ及びプロバイダ種別、すなわち、認証先によって一意に定まるのである。但し、同一ユーザであっても認証先が異なればユーザ情報も異なる可能性がある。ユーザは、認証先ごとに異なるアカウントを登録している可能性があるからである。各エントリのユーザ名及びパスワードが異なるのは、それを表現したものである。

認証情報テーブル１２１においては、認証先を同じくするインスタンス（認証管理モジュール１３において管理されているインスタンス）であれば、文書管理サービス３１が異なっていたとしても同一のエントリ内において管理される。

図９は、エントリとインスタンスとの関係を説明するための概念図である。図９においては以下のことが示されている。すなわち、アプリ１１ａは文書管理サービス３１ａに、アプリ１１ｂは文書管理サービス３１ｂにそれぞれアクセスするアプリケーションであり、文書管理サービス３１ａと文書管理サービス３１ｂとは共に、認証サービス２１を認証先とする。一方、アプリ１１ｃは、文書管理サービス３１ｃにアクセスするアプリケーションであり、文書管理サービス３１ｃは、認証サービス２１ｂを認証先とする。

図９において、符号Ｉ−１、Ｉ−２、及びＩ−３によって示された各アプリケーションと文書管理サービスとの接続が、各インスタンスに対応する。ここで、アプリ１１ａ、アプリ１１ｂ及びアプリ１１ｃのユーザが同一人物であると仮定すると、インスタンスＩ−１とインスタンスＩ−２とは認証先が同じ認証サービス２１であるため同一のエントリ（エントリＥ−１）に属する。一方、Ｉ−３は、インスタンスＩ−１及びインスタンスＩ−２とは認証先を別にするため異なるエントリ（エントリＥ−２）に属する。

したがって、図８において、エントリ１には複数のインスタンスハンドルが登録されているが、これは、エントリ１には認証先を同じにする複数のインスタンスが属していることを意味している。

参照カウンタは、一つのエントリ内のインスタンスの数を示すものである。

なお、ステップＳ３０において新たに追加されたエントリは、図８においてエントリ３が該当する。すなわち、認証サービスのＵＲＩは、「￥￥Ｄｏｍａｉｎ￥ｕｓＡ」であり、プロバイダ種別は、「オリジナル認証」である。

ステップＳ３０に続いてステップＳ３１に進み、認証制御モジュール１２は、アプリ１１ａからの認証要求（Ｓ１７）に対する応答として、インスタンスハンドルＡをアプリ１１ａに対して返却する。すなわち、アプリ１１ａは、認証制御モジュール１２に対して認証要求（Ｓ１７）を行った後、ユーザによるユーザ情報の入力の要否の判断等に関与することなく、単に認証要求に対する戻り値としてインスタンスハンドルＡを取得しただけである。

ステップＳ３１に続いてステップＳ３２に進み、アプリ１１ａが、インスタンスハンドルＡを引数として、認証チケットをシリアライズしたデータ（以下、「シリアライズデータ」という。）を認証管理モジュール１３に対して要求すると、認証管理モジュール１３は、インスタンスＡに関連付けておいた認証チケットをシリアライズし、そのシリアライズデータをアプリ１１ａに対して返却する（Ｓ３３）。これで、アプリ１１ａは、認証サービス２１によって認証された旨を証明する情報（認証チケットのシリアライズデータ）を得たことになる。そこで、アプリ１１ａは、改めて文書管理サービス３１ａに対するアクセスを開始する。

ステップＳ３３に続いてステップＳ３４に進み、アプリ１１ａは、文書管理モジュール１５に対し、シリアライズデータを引数として文書管理サービス３１ａへの接続を要求する。

ステップＳ３４に続いてステップＳ３５に進み、文書管理モジュール１５が、シリアライズデータを引数として認証管理モジュール１３に対して認証チケットを要求すると、認証管理モジュール１３は、対応する認証チケットを文書管理モジュール１５に対して返却する（Ｓ３６）。

ステップＳ３６に続いてステップＳ３７に進み、文書管理モジュール１５は、認証チケットを引数として文書管理サービス３１ａに対して接続を要求する。文書管理サービス３１ａが、認証サービス２１に対して認証チケットの正当性の確認を要求すると（Ｓ３８）、認証サービス２１は、認証チケットの有効期限等、正当性を確認し、その結果を文書管理サービス３１ａに対して送信する（Ｓ３９）。

ステップＳ３９に続いてステップＳ４０に進み、認証チケットの正当性が確認された場合は、文書管理サービス３１ａは、接続を許可する旨を文書管理モジュール１５に対して送信する。文書管理モジュール１５は、アプリ１１ａに対して接続が許可された旨を返却する（Ｓ４１）
ステップＳ４１に続いてステップＳ４２に進み、アプリ１１ａが、文書管理モジュール１５を介して文書管理サービス３１ａに対してセッションＩＤを要求すると（Ｓ４３）、文書管理サービス２１によってセッションが開設され、そのセッションＩＤがアプリ１１ａに対して送信される（Ｓ４４、Ｓ４５）。

以降は、アプリ１１ａは、開設されたセッションにおいて文書管理サービス３１ａの各種サービス（文書情報の検索等）を受けることができる。

以上の処理によって、ユーザは、認証サービス２１によって認証されたことになる。また、認証情報テーブル１２１には、ユーザが認証サービス２１によって認証を受けた際の認証情報がエントリとして登録されている。かかる状態において、ユーザが、例えばアプリ１１ｂを利用しようとした場合、すなわち、文書管理サービス３１ａとは別の文書管理サーバ３０ｂにおける文書管理サービス３１ｂにアクセスしようとした場合の処理について次に説明する。

図１０及び図１１は、第一の実施の形態において少なくとも一回認証を受けた後の認証処理を説明するためのシーケンス図である。

ユーザが、文書管理サービス３１ｂにアクセスすべく、メイン画面１１０（図５）のノード１１４をクリックすると処理が開始される。アプリ１１ｂが、ユーザによるノード１１４のクリックに基づいて、文書管理サービス３１ｂより接続情報を取得するのは（Ｓ５１〜Ｓ５４）、上述した場合（Ｓ１１〜Ｓ１４）と同様である。

なお、ここで得られた接続情報に含まれている認証を受けるべき認証サービスのＵＲＩ、認証を受けるドメイン及び認証プロバイダの種別等は、上述した文書管理サービス２１ａにアクセスする場合の接続情報におけるものと同じ値であったとする。すなわち、第一の実施の形態においては、文書管理サービス２１ｂにアクセスするためには、文書管理サービス２１ａにアクセスする場合と同じ認証サービス（認証サービス２１）、同じ認証プロバイダ（オリジナル認証）によって認証されている必要があることとする。

ステップＳ５４に続いてステップＳ５５に進み、アプリ１１ｂは、インスタンスハンドル（ＮＵＬＬ値）、認証サービス２１のＵＲＩ、ドメイン名、及びプロバイダ種別等を引数に指定して、認証制御モジュール１２に対して認証サービス２１によって認証を受けるよう要求する。

なお、仮に、ここでの認証要求を行うのがアプリ１１ｂではなく、アプリ１１ａである場合は、引数としてのインスタンスハンドルには、既にアプリ１１ａに対して発行されているインスタンスハンドルＡが指定される。

ステップＳ５５に続いてステップＳ５６に進み、認証制御モジュール１２は、認証要求元のアプリケーションについて認証サービス２１による認証は既に行われているか否かを認証情報テーブル１２１を参照して判断する。上述したように、認証を受けた場合には、その際の認証情報が認証情報テーブル１２１にエントリとして追加される。したがって、ステップＳ５５の認証要求の引数として指定されたインスタンスハンドル、認証サービスＵＲＩ及びプロバイダ種別と同一のインスタンスハンドル、認証サービスＵＲＩ及びプロバイダ種別が登録されたエントリが存在すれば、認証要求元のアプリケーションについては既に認証を受けていることが分かる。

したがって、仮に、認証要求元がアプリ１１ａであった場合には、認証制御モジュール１２は、エントリ３の存在によって既に認証は済んでいるものと判断し、以降のステップＳ５７からステップＳ６６までの処理は実行せずにステップＳ６７に進み、エントリ３に登録されているアプリ１１ａに対するインスタンスハンドルＡを認証要求に対する応答として返却する。

しかし、ここでの認証要求元はまだ認証を受けていないアプリ１１ｂであり、それに対するエントリは存在しない。そこで、認証制御モジュール１２は、アプリ１１ｂについても認証を行うべくステップＳ５７以降の処理を実行する。ただし、アプリ１１ｂからの認証要求において指定された認証先（認証サービス及び認証プロバイダ）は、過去にアプリ１１ａについて認証を受けた際における認証先と同じである。そうすると、仮に、ログイン画面を表示させてユーザ情報の入力を求めたとしても、入力されるユーザ情報は、アプリ１１ａが利用された際のログオン画面に入力されたユーザ情報と同じであると考えられる。そこで、認証制御モジュール１２は、アプリ１１ａが利用された際に入力されたユーザ情報を再利用することにより、ユーザに負担をかけないように以降の処理を実行する。

ステップＳ５７に進み、認証制御モジュール１２が、エントリ３に登録されているインスタンスハンドル、すなわち、インスタンスハンドルＡを引数として認証管理モジュール１３に対してシリアライズデータを要求すると、認証管理モジュール１３は、インスタンスＡに対するシリアライズデータを認証制御モジュール１２に対して返却する（Ｓ５８）。

ステップＳ５８に続いてステップＳ５９に進み、認証制御モジュール１２は、エントリ３に登録されているユーザ名、パスワード、ドメイン名を取得し、それらをステップＳ５８で取得したシリアライズデータと共に引数に指定して、認証管理モジュール１３に対してインスタンスＡの継承を要求する。ここで、インスタンスの継承とは、既に存在するインスタンスの属性をそのまま継承させて新たなインスタンスを生成することをいう。

ステップＳ５９に続いてステップＳ６０に進み、認証管理モジュール１３は、インスタンスＡの属性を継承したインスタンスとしてインスタンスＢを生成する。インスタンスの継承は、例えば、インスタンスをオブジェクトや構造体によって実施している場合は、オブジェクトや構造体のコピーとして実装してもよいし、インスタンスをテーブル上のレコードとして実装している場合は、当該テーブルにおけるレコードのコピーとして実装してもよい。

ステップＳ６０に続いてステップＳ６１からステップＳ６４にかけて、認証管理モジュール１３は、インスタンスＢについて認証サービス２１に対して認証を要求し、インスタンスＢに対するマスタチケット及び認証チケットを取得する。

ステップＳ６４に続いてステップＳ６５に進み、認証管理モジュール１３は、インスタンスＢのインスタンスハンドル（以下、「インスタンスハンドルＢ」という。）をインスタンスの継承要求（Ｓ５９）に対する応答として認証制御モジュール１２に対して返却する。

ステップＳ６５に続いてステップＳ６６（図１１）に進み、認証制御モジュール１２は、インスタンスハンドルＢをエントリ３に登録し、エントリ３の参照カウンタをインクリメントする。

ステップＳ６６に続いてステップＳ６７に進み、認証制御モジュール１２は、アプリ１１ｂからの認証要求（Ｓ５５）に対する応答として、インスタンスハンドルＢをアプリ１１ｂに対して返却する。

ステップＳ６７に続いてステップＳ６８以降は、上述したステップＳ３２以降と同様である。すなわち、アプリ１１ｂは、認証チケットのシリアライズデータを入手し（Ｓ６８、Ｓ６９）、シリアライズデータに基づいて文書管理サービス３１ｂとの接続を行う（Ｓ７０〜Ｓ８１）。

上述したように、第一の実施の形態におけるクライアント装置１０によれば、一度入力されたユーザ情報は保持され、その後に認証が必要とされる際に再利用されるため、ユーザは、サーバにアクセスするごとにユーザ情報の入力が要求されるといった煩雑な作業から解放される。

次に、第二の実施の形態として、文書管理サーバ３０（文書管理サービス３１）ごとに、認証を受けるべき認証サーバ２０（認証サービス２１）が異なる場合について説明する。図１２は、第二の実施の形態における文書管理システムの構成例を示す図である。図１２中、図２と同一部分には同一符号を付し、その説明は省略する。図１２に示されるように、第二の実施の形態における文書管理システム２には、認証サーバ２０ａ及び２０ｂ等の２台以上の認証サーバがネットワーク４０に接続されている。認証サーバ２０ａは、文書管理サーバ３０ａ（文書管理サービス３１ａ）を利用するユーザの認証機能（認証サービス２０ａ）が実装されているコンピュータである。認証サーバ２０ｂは、文書管理サーバ３０ｂ（文書管理サービス３１ｂ）を利用するユーザの認証機能（認証サービス２０ｂ）が実装されているコンピュータである。その他、図示はされていないが、文書管理サーバ３０ｃ及び３０ｄ等（文書管理サービス３１ｃ及び３１ｄ等）、並びにそれらにそれぞれ対応する認証サーバ２０ｃ及び２０ｄ等（認証サービス２１ｃ及び２１ｄ等）が接続されているものとする。

図１３は、第二の実施の形態における文書管理システムの概念図である。図１３において、文書管理サービス３１ａを利用するためには、認証サービス２１ａによって認証を受ける必要があり、文書管理サービス３１ｂを利用するためには、認証サービス２１ｂによって認証を受ける必要がある旨が示されている。但し、認証サービス２１ｂは、自らにされた認証要求に基づく認証処理を認証サービス２１ａに委譲することができる。認証処理を委譲された認証サービス２１ａは、自らの管理しているユーザ情報に基づいて認証を行い、その処理結果を認証サービス２１ｂに返信する。認証サービス２１ｂは、認証サービス２１ａより返信された認証結果を自らが行った認証処理の結果として認証要求元に返信する。

本実施の形態において、認証処理を委譲できる関係を「信頼関係」と呼ぶこととする。したがって、「認証サービス２１ｂは、認証サービス２１ａと信頼関係にある。」ということができる。信頼関係は、具体的には、委譲元（認証サービス２１ｂ）における設定ファイル等において、認証処理の委譲先とし得る認証サービス（認証サービス２１ａ）のＵＲＩ等が登録されることにより設定される。なお、設定ファイル等の操作は、システムの管理者等、責任のあるユーザによってなされることがセキュリティの観点上望ましい。

各認証サービス２１の間に信頼関係を設定することで、各認証サーバ２０に重複してユーザ情報を管理させる必要がなくなる。例えば、図１３において、認証サービス２１ａは、部門Ａの従業員のユーザ情報を管理している認証サービスであり、認証サービス２１ｂは、部門Ｂの従業員のユーザ情報を管理している認証サービスであるとする。仮に、認証サービス２１ｂが認証サービス２１ａと信頼関係になかったら、部門Ａの従業員は、文書管理サービス３１ｂを利用することができないということになる。上述したように、文書管理サービス３１ｂを利用するためには認証サービス２１ｂによって認証されている必要があるところ、認証サービス２１ｂには、部門Ａの従業員のユーザ情報は管理されていないため、不正なアカウントとして認証を拒否されてしまうからである。したがって、この場合、部門Ａの従業員のユーザ情報を認証サービス３１ｂに管理させる必要がある。しかし、認証サービス２１ｂと認証サービス２１ａとの間に信頼関係を設定すれば、認証サービス３１ｂのユーザ情報はそのままで、部門Ａの従業員が文書管理サービス３１ｂを利用することが可能になるというわけである。

第二の実施の形態における文書管理システム２においては、認証サービス２１ａをはじめ、認証サービス２１ｂ以外の認証サービス２１によって既に認証を受けているユーザが、文書管理サービス３１ｂ、すなわち、認証サービス２１ｂによって認証を受けないと利用することができない文書管理サービス２１を利用しようとした場合について説明する。なお、第二の実施の形態においていずれの認証サービス２１によっても認証を受けていない場合の処理は、第一の実施の形態における図６及び図７において説明した処理と同様である。したがって、第二の実施の形態における処理が開始される時点において、認証情報テーブル１２１には、既に一つ以上のエントリが登録されている。ここでは、図１４のようなエントリが登録されているものとする。

図１４は、第二の実施の形態における処理の開始時に認証情報テーブルに登録されているエントリの例を示す図である。図１４に示される認証情報テーブル１２１において、エントリ１、エントリ２、エントリ３は、クライアント装置１０のユーザが、認証サービス２１ｄ、認証サービス２１ｃ、認証サービス２１ａに認証を受けた際に登録されたエントリであるとする。上述したように、認証サービス２１ｂによってはまだ認証を受けていないため、認証サービス２１ｂに対応するエントリは登録されていない。

以下、第二の実施の形態における文書管理システム２の処理手順について説明する。図１５及び図１６は、第二の実施の形態において少なくとも一回認証を受けた後の認証処理を説明するためのシーケンス図である。

アプリ１１ｂが、ユーザによるノード１１４（図５）のクリックに基づいて、文書管理サービス３１ｂより接続情報を取得するのは（Ｓ１０１〜Ｓ１０４）、図１０におけるステップＳ５１〜Ｓ５４と同様である。但し、取得された接続情報において、認証を受けるべき認証サービスのＵＲＩは、認証サービス２１ｂのＵＲＩが指定されている。ステップＳ１０４に続いてステップＳ１０５に進み、アプリ１１ｂは、インスタンスハンドル（ＮＵＬＬ値）、認証サービス２１ｂのＵＲＩ、ドメイン名、及びプロバイダ種別等を引数に指定して、認証制御モジュール１２に対して認証サービス２１によって認証を受けるよう要求する。

ステップＳ１０５に続いてステップＳ１０６に進み、認証制御モジュール１２は、認証要求元のアプリケーションについて認証サービス２１ｂによる認証は既に行われているか否か等を認証情報テーブル１２１を参照して判断する。すなわち、ステップＳ５６において説明したように、ステップＳ１０５の認証要求の引数として指定されたインスタンスハンドル、認証サービスＵＲＩ及びプロバイダ種別と同一のインスタンスハンドル、認証サービスＵＲＩ及びプロバイダ種別が登録されたエントリが存在するか（ケース１）、又は、インスタンスハンドルは異なっていても同一の認証サービスＵＲＩ及びプロバイダ種別が登録されたエントリが存在するか（ケース２）が判断される。ケース１の場合は、更に認証を行う必要はないため、ユーザに対して改めてユーザ情報の入力を要求する必要はない。また、ケース２の場合は、以降においてステップＳ５７以降の処理が実行される（図１０及び図１１）ため、この場合もユーザに対してユーザ情報の入力を要求する必要はない。しかし、ここでは、そもそも認証サービス２１ｂに対するエントリは存在しないため（図１４）、ケース１及びケース２のいずれにも該当しない。但し、ユーザに対する負担を軽減すべく、ユーザ名等の入力はできるだけ要求したくはない。そこで、以降において他の認証サービス２１に認証を受ける際に入力されたユーザ情報を用いて、認証サービス２１ｂにより認証を受けるための処理が実行される。

ステップＳ１０６に続いてステップＳ１０７に進み、認証制御モジュール１２は、認証情報テーブル１２１に既に登録されている各エントリに属しているインスタンスハンドルに基づいて、当該インスタンスハンドルに対応するシリアライズデータを認証管理モジュール１３より取得する（Ｓ１０８）。この処理は、認証情報テーブル１２１に登録されている全てのインスタンスハンドルについて行われる（Ｓ１０９）。したがって、ここでは、エントリ１におけるｈａｎｄｌｅ−ａ、エントリ２におけるｈａｎｄｌｅ−ｂ、及びエントリ３におけるｈａｎｄｌｅ−ｃに対応するシリアライズデータが取得される。ステップＳ１０９に続いてステップＳ１１０に進み、認証制御モジュール１２は、取得した各シリアライズデータを要素とする配列を生成する（Ｓ１１０）。

ステップＳ１１０に続いてステップＳ１１１に進み、認証制御モジュール１２は、シリアライズデータの配列、その配列の要素数、認証の要求先とする認証サービス２１ｂのＵＲＩ及びプロバイダ種別を引数として、各シリアライズデータの有効性のチェックを認証管理モジュール１３に要求する。ここで、シリアライズデータの有効性のチェックとは、例えば、当該シリアライズデータに対応する認証チケットの有効期限のチェック等が相当する。

ステップＳ１１１に続いてステップＳ１１２に進み、認証管理モジュール１３は、シリアライズデータごとに、当該シリアライズデータに対応する認証チケットの発行元の認証サービス２１に対して認証チケットの有効性等のチェックを要求し、各シリアライズデータの有効性のチェック結果を各認証サービス２１より取得する（Ｓ１１３、Ｓ１１４）。ステップＳ１１５に進み、認証管理モジュール１３は、各シリアライズデータの有効性のチェック結果を要素とする配列を認証制御モジュール１２に対して出力する。

ステップＳ１１５に続いてステップＳ１１６に進み、認証制御モジュール１２は、有効性が確認されたシリアライズデータに対応するインスタンスハンドルが属するエントリのユーザ名、パスワード、ドメイン名及びプロバイダ種別と、現在認証先とされている認証サービス２１ｂのＵＲＩ及びプロバイダ種別とを引数に指定して、認証サービス２１ｂによって認証を受けるよう認証管理モジュール１３に要求する。すなわち、認証サービス２１ｂが他の認証サービス２１と信頼関係にあれば、当該他の認証サービス２１によって認証された際のユーザ名、パスワード及びドメイン名を用いて認証サービス２１ｂによって認証を受けることができる。そこで、認証制御モジュール１２は、認証サービス２１ｂが既に認証を受けた他の認証サービス２１と信頼関係にあることを期待して、他の認証サービス２１に認証を受ける際に入力されたユーザ名、パスワードおよびドメイン名等を用いて、認証サービス２１ｂに対する認証要求を試みるというわけである。

したがって、例えば、図１４のエントリ１、２及び３における全てのインスタンスハンドルに対応するシリアライズデータの有効性が確認されている場合は、エントリ１におけるユーザ情報、エントリ２におけるユーザ情報、エントリ３におけるユーザ情報を用いた認証要求が認証管理モジュール１３に対して順番になされる（Ｓ１２７）。

ステップＳ１１６に続いてステップＳ１１７に進み、認証制御モジュール１２からの認証要求を受けた認証管理モジュール１３は、当該認証要求の引数に指定されたユーザ名、パスワード、ドメイン名及びプロバイダ種別等を引数に指定して、認証サービス２１ｂに対して認証要求を送信する。ステップＳ１１７に続いてステップＳ１１８に進み、認証サービス２１ｂは、信頼関係にある認証サービス２１ａに対して認証処理を委譲する。ステップＳ１１８に続いてステップＳ１１９に進み、認証サービス２１ａは、ユーザ名、パスワード及びドメイン名等に基づいて認証を行い、認証された場合はマスタチケットを、認証が拒否された場合は認証に失敗した旨（エラー）を認証サービス２１ｂに返信する。ステップＳ１１９に続いてステップＳ１２０に進み、認証サービス２１ｂは、認証サービス２１ａより返信されたマスタチケット又はエラーを認証管理モジュール１３に返信する。

ここで、エントリ１、エントリ２及びエントリ３のユーザ情報を用いた認証要求のうち、認証処理を委譲された認証サービス２１ａにおいて認証が成功するのは、エントリ３のユーザ情報を用いた認証要求である。エントリ３のユーザ情報は、過去において認証サービス２１ａによって認証されたものだからである。一方、エントリ１及びエントリ２のユーザ情報は、認証サービス２１ａに対するユーザ情報ではないため、認証サービス２１ａによって認証を拒否される。

認証管理モジュール１３は、認証サービス２１よりエラーを返信された場合は、認証制御モジュール１２に対してエラーを返却する（Ｓ１２１）。一方、マスタチケットを返信された場合は、そのマスタチケットを用いて認証サービス２１ｂに対して認証チケットの発行を要求する（Ｓ１２２）。ステップＳ１２２に続いてステップＳ１２３に進み、認証サービス２１ｂは、認証サービス２１ａに対して認証チケットの発行を要求することにより、認証サービス２１ａより認証チケットを取得する（Ｓ１２４）。認証サービス２１ｂは、認証サービス２１ａより取得した認証チケットを、自らが発行したものとして認証管理モジュール１３に送信する（Ｓ１２５）。

ステップＳ１２５に続いてステップＳ１２６に進み、認証管理モジュール１３は、認証サービス２１ｂより発行された認証チケットに対応する新たなインスタンスを生成し、生成されたインスタンスのインスタンスハンドルを認証要求（Ｓ１１６）に対する応答として認証制御モジュール１２に出力する。

ステップＳ１２８（図１６）に進み、認証制御モジュール１２は、新たなインスタンスハンドルに対する新たなエントリを認証情報テーブル１２１に追加する。図１７は、新たなエントリが追加された認証情報テーブルの例を示す図である。図１７おいて、エントリ４が新たに追加されたエントリである。エントリ４のユーザ名、パスワード及びドメイン名は、再利用されたエントリ３のものがコピーされたものである。

ステップＳ１２８に続いてステップＳ１２９に進み、認証制御モジュール１２は、アプリ１１ｂからの認証要求（Ｓ１０５）に対する応答として、新たなインスタンスハンドル（エントリ４におけるインスタンスハンドル）をアプリ１１ｂに対して返却する（Ｓ１２９）。

ステップＳ１２９に続いてステップＳ１３０以降は、上述したステップＳ６８以降（図１１）と同様の処理手順によって、文書管理サービス２１ｂとのセッションが開設される。

上述したように、第二の実施の形態におけるクライアント装置１０によれば、各文書管理サービス３１を利用するための認証先が異なる場合であっても、当該認証先同士が信頼関係にあれば、一方の認証先に認証を受けた際のユーザ情報を再利用することにより、他方の認証先から認証を受けることができる。したがって、ユーザに対してユーザ情報の入力を要求する機会を低減させることができる。

なお、第一の実施の形態における図１０及び図１１の処理と、第二の実施の形態における図１５及び図１６の処理との関係をより明確にするために、アプリ１１ａやアプリ１１ｂからの認証要求（Ｓ１７、Ｓ５５及びＳ１０５）に基づいて認証制御モジュール１２において実行される処理についてフローチャートを用いて説明する。図１８は、アプリケーションからの認証要求に対する認証制御モジュールの処理を説明するためのフローチャートである。

まず、アプリ１１ａ又はアプリ１１ｂ等より認証要求を受け付ける（Ｓ２０１）。この処理は、ステップＳ２７（図６）、ステップＳ５５（図１０）、又はステップＳ１０５（図１５）が対応する。

続いてステップＳ２０２からステップＳ２０５にかけて、ステップＳ２８、ステップＳ５６、又はステップＳ１０６に対応した処理、すなわち、既に認証先となる認証サービス２１に認証を受けているか等を判断するための処理が実行される。

認証情報テーブル１２１よりエントリを一つずつ読み込み（Ｓ２０２）、各エントリの認証サービスのＵＲＩ及び認証プロバイダの種別が、認証要求において認証先として指定された認証サービスのＵＲＩ及び認証プロバイダの種別と同じであるか否かを判断する（Ｓ２０３）。

認証要求の引数に認証先として指定された認証サービスのＵＲＩ及び認証プロバイダの種別と同一のＵＲＩ及び種別が登録されているエントリ（以下、「対象エントリ」という。）が認証情報テーブル１２１に存在する場合（Ｓ２０３でＹｅｓ）は、更に、対象エントリに認証要求の引数として指定されたインスタンスハンドルが登録されているかを判断し（Ｓ２０５）、登録されている場合は、そのインスタンスハンドルを認証要求に対する応答として返却する（Ｓ２０６）。

一方、認証要求の引数として指定されたインスタンスハンドルがＮＵＬＬである場合等、当該インスタンスハンドルが対象エントリに登録されていない場合（Ｓ２０５でＮｏ）は、「再利用認証１」のための処理を実行する（Ｓ２０７）。ここで、「再利用認証１」のための処理とは、ステップＳ５７からステップＳ６５（図１０）までの処理をいう。すなわち、ログオン画面を表示させてユーザにユーザ情報を入力させるということは行わず、対象エントリに登録されているユーザ名及びパスワードに基づいて認証が行われる。

「再利用認証１」に成功した場合（Ｓ２０８でＹｅｓ）は、対象エントリにインスタンスハンドルを追加すると共に対象エントリの参照カウンタをインクリメントし（Ｓ２０９）（Ｓ６６（図１１）に対応）、認証要求に対する応答として継承したインスタンスハンドルを返却する（Ｓ２１０）。再利用認証に失敗した場合（Ｓ２０８でＮｏ）は、認証に失敗した旨を認証要求に対する応答として返却する。

認証サービスのＵＲＩ及び認証プロバイダの種別を同じくするエントリが一つも見つからなかった場合（Ｓ２０４でＹｅｓ）は、認証先の認証サービス２１が、他の認証サービス２１と信頼関係にあることを期待して「再利用認証２」のための処理を試みる（Ｓ２１１）。ここで、「再利用認証２」のための処理とは、ステップＳ１０７からステップＳ１２７（図１５）までの処理をいう。すなわち、ログオン画面を表示させてユーザにユーザ情報を入力させるということは行わず、既存のエントリに登録されているユーザ名及びパスワードに基づいて認証が試みられる。

「再利用認証２」に成功した場合（Ｓ２１２でＹｅｓ）は、認証情報テーブル１２１に新たなエントリを追加し（Ｓ２１３（Ｓ１２８（図１６）に対応）、認証要求に対する応答として新たに生成されたインスタンスのインスタンスハンドルを返却する（Ｓ２１４）。

「再利用認証２」に失敗した場合（Ｓ２１２でＮｏ）は、新規認証のための処理を実行する（Ｓ２１５）。ここで、新規認証のための処理とは、ステップＳ１９からステップＳ２９（図６）までの処理をいう。すなわち、ログオン画面を表示させ、ユーザによってログオン画面に入力されたユーザ名及びパスワードに基づいて認証が行われる。新規認証に成功した場合（Ｓ２１６でＹｅｓ）は、認証情報テーブル１２１に新たなエントリを追加し（Ｓ２１７）（Ｓ３０（図７）に対応）、認証要求に対する応答として新たに生成されたインスタンスのインスタンスハンドルを返却する（Ｓ２１８）。新規認証に失敗した場合（Ｓ２０７でＮｏ）は、認証に失敗した旨を認証要求に対する応答として返却する。

このように、第一の実施の形態における処理と第二の実施の形態における処理とは、状況に応じて選択されるものであり、いずれか一方の処理を実装することで、他方の処理の実装が不要となるものではない。

なお、上述においては、文書管理サーバ３０ａ又は３０ｂからログオフする際の処理については説明していないが、ログオフが実行された場合は、対応するインスタンスのインスタンスハンドルがエントリから削除され、参照カウンタがデクリメントされる。ここで、参照カウンタが０になった場合、すなわち、エントリ内に一つもインスタンスが属していない場合であるが、この場合は、認証情報管理テーブル１２１より当該エントリを削除してしまってもよいし、そのまま残しておいても良い。記憶領域に制限がある場合は前者の方が有利であるが、後者の場合は、当該エントリの認証先に再度認証を受ける際に、ユーザに対してユーザ情報の入力を要求する必要はないという利益を維持することができる。

また、本実施の形態においては、アプリ１１ａは、プラグインとしてのアプリケーションでありクライアントアプリケーション１１に対して着脱可能であると説明したが、認証情報テーブル１２１に既にエントリが登録されている状態で新たに追加されたアプリケーションについても、そのまま当該エントリに登録されているユーザ情報を再利用することが可能である。

ところで、近年においては、ある特定の機能に特化した組み込み機器においてもＷｅｂサーバとして機能するもの等、コンピュータと同等の情報処理を実行することができるものが提供されている。例えば、融合機、又は複合機と呼ばれる、プリンタ、コピー、又はファクシミリ等の複合サービスに固有の処理を行う複数のアプリケーションを有する画像形成装置もかかる機器に該当する。最近の画像形成装置には、コピーした情報又はＦＡＸ受信した情報等を文書データとして蓄積する文書管理機能を有しているものもある。

したがって、このような画像形成装置を用いて、本実施の形態における文書管理システムを構成しても本発明の効果を同様に得ることができる。図１９は、画像形成装置を用いて構成した文書管理システムの構成例を示す図である。図１９中、図２と同一部分には同一符号を付し、その説明は省略する。

図１９を図２と比較すると、図１９の文書管理システム３では、認証サーバ２０、文書管理サーバ３０の代わりに画像形成装置５０ａ、画像形成装置５０ｂが構成要素となっている。画像形成装置５０ａには、認証サーバ２０に実装されているものと同様の認証サービス５１が実装されている。また、画像形成装置５０ｂには、文書管理サーバ３０に実装されているものと同様の文書管理サービス５２が実装されている。したがって、かかる文書管理サービス３においても、第一及び第二の実施の形態において説明した機能と同様の機能を実現することができ、その効果を得ることができる。

以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

認証機能を一つのサーバに集約したシステムの概念図である。 第一の実施の形態における文書管理システムの構成例を示す図である。 本発明の実施の形態におけるクライアント装置のハードウェア構成例を示す図である。 本発明の実施の形態におけるクライアント装置の機能構成例を示す図である。 クライアントアプリケーションのメイン画面の表示例を示す図である。 認証サービスによって認証を受けていない場合の認証処理を説明するためのシーケンス図である。 認証サービスによって認証を受けていない場合の認証処理を説明するためのシーケンス図である。 認証情報テーブルの構成例を示す図である。 エントリとインスタンスとの関係を説明するための概念図である。 第一の実施の形態において少なくとも一回認証を受けた後の認証処理を説明するためのシーケンス図である。 第一の実施の形態において少なくとも一回認証を受けた後の認証処理を説明するためのシーケンス図である。 第二の実施の形態における文書管理システムの構成例を示す図である。 第二の実施の形態における文書管理システムの概念図である。 第二の実施の形態における処理の開始時に認証情報テーブルに登録されているエントリの例を示す図である。 第二の実施の形態において少なくとも一回認証を受けた後の認証処理を説明するためのシーケンス図である。 第二の実施の形態において少なくとも一回認証を受けた後の認証処理を説明するためのシーケンス図である。 新たなエントリが追加された認証情報テーブルの例を示す図である。 アプリケーションからの認証要求に対する認証制御モジュールの処理を説明するためのフローチャートである。 画像形成装置を用いて構成した文書管理システムの構成例を示す図である。

符号の説明

１、２，３ 文書管理システム
１０ クライアント装置
１１ａ、１１ｂ、１１ｃ、１１ｄ アプリケーション（アプリ）
１２ 認証制御モジュール
１３ 認証管理モジュール
１４ ＳＯＡＰプロキシ
１５ 文書管理モジュール
２０、２０ａ、２０ｂ 認証サーバ
２１、２１ｂ、５１ 認証サービス
３０、３０ａ、３０ｂ 文書管理サーバ
３１、３１ａ、３１ｂ、３１ｃ、５２ 文書管理サービス
５０ａ、５０ｂ 画像形成装置
１１ クライアントアプリケーション
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ 演算処理装置
１０５ ネットワークＩ／Ｆ装置
１０６ 入力装置
１０７ 表示装置
１２１ 認証情報テーブル
５０１ 端末
５０２、５０３ 文書管理サーバ
５０４ 認証サーバ
Ｂ バス

Claims (25)

1. それぞれ所定のサービスを提供する複数の外部装置と、前記外部装置のサービスを利用するユーザを認証するための認証手段を有する一つ以上の認証装置とネットワークを介して接続する情報処理装置であって、
   それぞれ異なる前記外部装置のサービスに対するインタフェースを前記ユーザに提供する複数のサービス提供手段と、
   前記サービス提供手段からの認証要求に応じ、前記ユーザに該ユーザを認証するためのユーザ情報の入力を要求し、入力された前記ユーザ情報に基づく認証の要求を前記認証手段に送信する認証制御手段と、
   前記認証制御手段が前記認証の要求を送信した前記認証手段を一意に識別する要求先識別情報と、前記ユーザによって入力されたユーザ情報と、前記認証要求に係る前記サービス提供手段を識別するための要求元識別情報とを関連付けて管理する認証情報管理手段とを有することを特徴とする情報処理装置。
2. 前記認証制御手段は、前記認証要求に応じ、前記認証情報管理手段を参照して前記ユーザは前記認証要求に応じた前記認証手段に既に認証されているかを判断することを特徴とする請求項１記載の情報処理装置。
3. 前記認証制御手段は、前記認証要求に応じた前記認証手段に対する前記要求先識別情報が前記認証情報管理手段に管理されている場合は、前記ユーザは該認証手段に認証されているものと判断することを特徴とする請求項２記載の情報処理装置。
4. 前記認証制御手段は、前記ユーザは前記認証要求に応じた前記認証手段に既に認証されていると判断した場合は、前記ユーザ情報の入力を要求しないことを特徴とする請求項３記載の情報処理装置。
5. 前記認証制御手段は、前記要求先識別情報が前記認証情報管理手段に管理されている前記認証手段に対する前記認証要求であって、前記要求元識別情報が該要求先識別情報に関連付けられていない前記サービス提供手段からの認証要求を受け付けた場合は、該要求先識別情報に関連付けられている前記ユーザ情報を用いて該認証手段に認証の要求を送信することを特徴とする請求項１乃至４いずれか一項記載の情報処理装置。
6. 前記認証制御手段は、前記要求先識別情報が前記認証情報管理手段に管理されている前記認証手段に対する前記認証要求であって、前記要求元識別情報が該要求先識別情報に関連付けられている前記サービス提供手段からの認証要求を受け付けた場合は、該認証手段に認証の要求を送信しないことを特徴とする請求項１乃至５いずれか一項記載の情報処理装置。
7. 前記認証制御手段は、前記要求先識別情報が前記認証情報管理手段に管理されていない前記認証手段に対する前記認証要求を受け付けた場合は、前記ユーザ情報の入力を要求することを特徴とする請求項１乃至６いずれか一項記載の情報処理装置。
8. 前記認証制御手段は、前記要求先識別情報が前記認証情報管理手段に管理されていない前記認証手段に対する前記認証要求を受け付けた場合は、前記認証情報管理手段に管理されている前記ユーザ情報を用いて該認証手段に認証の要求を送信することを特徴とする請求項１乃至６いずれか一項記載の情報処理装置。
9. 前記認証制御手段は、前記認証情報管理手段に管理されている前記ユーザ情報を用いて送信した認証の要求に応じて、前記要求先識別情報が前記認証情報管理手段に管理されていない前記認証手段によって前記ユーザが認証された場合は、前記ユーザ情報の入力を要求しないことを特徴とする請求項８記載の情報処理装置。
10. 前記認証制御手段は、前記認証情報管理手段に管理されているいずれの前記ユーザ情報を用いても前記要求先識別情報が前記認証情報管理手段に管理されていない前記認証手段によって前記ユーザが認証されない場合は、前記ユーザ情報の入力を要求することを特徴とする請求項８又は９記載の情報処理装置。
11. 前記認証情報管理手段は、同一の前記認証手段に対する前記認証要求に係る前記サービス提供手段に対する前記要求元識別情報は、同一の前記要求先識別情報に関連付けて管理することを特徴とする請求項１乃至１０いずれか一項記載の情報処理装置。
12. 前記認証制御手段は、複数の前記サービス提供手段より共通的に利用されることを特徴とする請求項１乃至１１いずれか一項記載の情報処理装置。
13. それぞれ所定のサービスを提供する複数の外部装置と、前記外部装置のサービスを利用するユーザを認証するための認証手段を有する一つ以上の認証装置と、該外部装置及び該認証装置とネットワークを介して接続する情報処理装置とを有する情報処理システムであって、
    前記情報処理装置は、
    それぞれ異なる前記外部装置のサービスに対するインタフェースを前記ユーザに提供する複数のサービス提供手段と、
    前記サービス提供手段からの認証要求に応じ、前記ユーザに該ユーザを認証するためのユーザ情報の入力を要求し、入力された前記ユーザ情報に基づく認証の要求を前記認証手段に送信する認証制御手段と、
    前記認証制御手段が前記認証の要求を送信した前記認証手段を一意に識別する要求先識別情報と、前記ユーザによって入力されたユーザ情報と、前記認証要求に係る前記サービス提供手段を識別するための要求元識別情報とを関連付けて管理する認証情報管理手段とを有することを特徴とする情報処理システム。
14. 前記認証制御手段は、前記要求先識別情報が前記認証情報管理手段に管理されている前記認証手段に対する前記認証要求であって、前記要求元識別情報が該要求先識別情報に関連付けられていない前記サービス提供手段からの認証要求を受け付けた場合は、該要求先識別情報に関連付けられている前記ユーザ情報を用いて該認証手段に認証の要求を送信することを特徴とする請求項１３記載の情報処理システム。
15. 前記認証制御手段は、前記要求先識別情報が前記認証情報管理手段に管理されていない前記認証手段に対する前記認証要求を受け付けた場合は、前記認証情報管理手段に管理されている前記ユーザ情報を用いて該認証手段に認証の要求を送信することを特徴とする請求項１３又は１４記載の情報処理システム。
16. それぞれ所定のサービスを提供する複数の外部装置と、前記外部装置のサービスを利用するユーザを認証するための認証手段を有する一つ以上の認証装置とネットワークを介して接続する情報処理装置における情報処理方法であって、
    前記外部装置のサービスに対するインタフェースを前記ユーザに提供する複数のサービス提供手段からの要求に応じ、前記ユーザに該ユーザを認証するためのユーザ情報の入力を要求するユーザ情報要求手順と、
    前記ユーザ情報要求手順における要求に応じて入力された前記ユーザ情報に基づく認証の要求を前記認証手段に送信する認証制御手順と、
    前記認証制御手順において認証の要求が送信された前記認証手段を一意に識別する要求先識別情報と、前記ユーザによって入力されたユーザ情報と、前記認証要求に係る前記サービス提供手段を識別するための要求元識別情報とを関連付けて所定の記憶領域に登録する認証情報登録手順とを有することを特徴とする情報処理方法。
17. 前記認証制御手順は、前記認証要求に応じ、前記所定の記憶領域を参照して前記ユーザは前記認証要求に応じた前記認証手段に既に認証されているかを判断することを特徴とする請求項１６記載の情報処理方法。
18. 前記認証制御手順は、前記認証要求に応じた前記認証手段に対する前記要求先識別情報が前記所定の記憶領域に登録されている場合は、前記ユーザは該認証手段に認証されているものと判断することを特徴とする請求項１７記載の情報処理方法。
19. 前記認証制御手順は、前記ユーザは前記認証要求に応じた前記認証手段に既に認証されていると判断した場合は、前記ユーザ情報の入力を要求しないことを特徴とする請求項１８記載の情報処理方法。
20. 前記認証制御手順は、前記要求先識別情報が前記所定の記憶領域に登録されている前記認証手段に対する前記認証要求であって、前記要求元識別情報が該要求先識別情報に関連付けられていない前記サービス提供手段からの認証要求を受け付けた場合は、該要求先識別情報に関連付けられている前記ユーザ情報を用いて該認証手段に認証の要求を送信することを特徴とする請求項１６乃至１９いずれか一項記載の情報処理方法。
21. 前記認証制御手順は、前記要求先識別情報が前記所定の記憶領域に登録されている前記認証手段に対する前記認証要求であって、前記要求元識別情報が該要求先識別情報に関連付けられている前記サービス提供手段からの認証要求を受け付けた場合は、該認証手段に認証の要求を送信しないことを特徴とする請求項１６乃至２０いずれか一項記載の情報処理方法。
22. 前記認証制御手順は、前記要求先識別情報が前記所定の記憶領域に登録されていない前記認証手段に対する前記認証要求を受け付けた場合は、前記ユーザ情報の入力を要求することを特徴とする請求項１６乃至２１いずれか一項記載の情報処理方法。
23. 前記認証情報登録手順は、同一の前記認証手段に対する前記認証要求に係る前記サービス提供手段に対する前記要求元識別情報は、同一の前記要求先識別情報に関連付けて前記所定の記憶領域に登録することを特徴とする請求項１６乃至２２いずれか一項記載の情報処理方法。
24. それぞれ所定のサービスを提供する複数の外部装置と、前記外部装置のサービスを利用するユーザを認証するための認証手段を有する一つ以上の認証装置とネットワークを介して接続する情報処理装置に、
    前記外部装置のサービスに対するインタフェースを前記ユーザに提供する複数のサービス提供手段からの要求に応じ、前記ユーザに該ユーザを認証するためのユーザ情報の入力を要求するユーザ情報要求手順と、
    前記ユーザ情報要求手順における要求に応じて入力された前記ユーザ情報に基づく認証の要求を前記認証手段に送信する認証制御手順と、
    前記認証制御手順において認証の要求が送信された前記認証手段を一意に識別する要求先識別情報と、前記ユーザによって入力されたユーザ情報と、前記認証要求に係る前記サービス提供手段を識別するための要求元識別情報とを関連付けて所定の記憶領域に登録する認証情報登録手順とを実行させるための情報処理プログラム。
25. それぞれ所定のサービスを提供する複数の外部装置と、前記外部装置のサービスを利用するユーザを認証するための認証手段を有する一つ以上の認証装置とネットワークを介して接続する情報処理装置に、
    前記外部装置のサービスに対するインタフェースを前記ユーザに提供する複数のサービス提供手段からの要求に応じ、前記ユーザに該ユーザを認証するためのユーザ情報の入力を要求するユーザ情報要求手順と、
    前記ユーザ情報要求手順における要求に応じて入力された前記ユーザ情報に基づく認証の要求を前記認証手段に送信する認証制御手順と、
    前記認証制御手順において認証の要求が送信された前記認証手段を一意に識別する要求先識別情報と、前記ユーザによって入力されたユーザ情報と、前記認証要求に係る前記サービス提供手段を識別するための要求元識別情報とを関連付けて所定の記憶領域に登録する認証情報登録手順とを実行させるための情報処理プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images