JP2004303202A - 情報提供装置、情報提供方法、情報提供プログラム及び記録媒体、並びにユーザ認証装置、ユーザ認証方法、ユーザ認証プログラム及び記録媒体 - Google Patents

Abstract

【課題】 それぞれ独立して管理されているユーザ情報を統合的に提供することのできる情報提供装置、情報提供方法、情報提供プログラム及び記録媒体の提供を目的とする。
【解決手段】 ユーザに係る情報の提供を行う情報提供手段を連携させる連携手段を有する情報提供装置であって、前記連携手段は、ユーザに係る情報の提供要求に応じ、第一の情報管理手段において管理されているユーザに係る第一の情報を第一の情報提供手段に取得させ、第二の情報管理手段において所定の識別情報によって前記第一の情報に予め対応付けられて管理されているユーザに係る第二の情報を第二の情報提供手段に取得させ、前記第一及び第二の情報を前記所定の識別情報に基づいて統合した情報を提供することにより上記課題を解決する。
【選択図】 図１８

Description

本発明は、情報提供装置、情報提供方法、情報提供プログラム及び記録媒体に関し、特にそれぞれ独立して管理されているユーザ情報を統合的に提供する情報提供装置、情報提供方法、情報提供プログラム及び記録媒体に関する。

また、本発明は、ユーザ認証装置、ユーザ認証方法、ユーザ認証プログラム及び記録媒体に関し、特に複数の認証手段を連携させるユーザ認証装置、ユーザ認証方法、ユーザ認証プログラム及び記録媒体に関する。

情報システムの不正利用を防ぐために、各種アプリケーションは、ユーザの認証機能を有しているのが一般である。認証機能を実現するシステムの具体例としてアプリケーションの起動時にユーザＩＤとパスワードの入力を要求するパスワードシステムが挙げられる。ユーザＩＤとパスワードとを正しく入力したユーザには、アプリケーションの利用が許可され、以降、ユーザは、アプリケーションが提供する様々な機能を利用することができる。

しかしながら、ユーザの正当性がアプリケーションの起動時において確認できただけで、そのアプリケーションが提供するすべてのサービスに対する利用権限を与えるのは危険である。例えば、ユーザがアプリケーションを起動したまま席をはずすことがよくある。この場合、悪意を持った他のユーザが、正当なユーザに成りすましてアプリケーションを利用することも考えられる。

かかる不正利用を防ぐため、例えば企業内の情報システムおいて管理されている機密情報に対するアクセスが要求された際に、ユーザの認証を再度実行することにより、かかる機密情報に対するセキュリティを高めることができる。

この場合、起動時における認証の際に利用した認証エンジン（ユーザ認証を行うためのプログラム）と同一の認証エンジンを利用するよりも、例えば、起動時にはパスワード認証、機密情報へのアクセスの際には指紋認証といったように、全く別の認証エンジンを利用して認証を行ったほうが、より高度なセキュリティを確保することができる。

但し、二つ以上の認証エンジンを利用する場合、それぞれがお互いに独立していたのでは意味がない。即ち、一方において認証されたユーザと他方において認証されたユーザとが同一人物であるという保証がないからである。

従って、アプリケーションには、複数の認証エンジンを関連付けるための機能の実装が必要となるが、かかる機能を個々のアプリケーションに実装するのは、各アプリケーションの開発工数を不要に増加させる。

ところで、ネットワーク上の資源を管理し、その検索手段を提供するシステムとしてディレクトリサービスが知られているが、かかるディレクトリサービスは、認証機能と密接な関係にあり、ディレクトリサービスとしての機能も実装されている認証エンジンが一般的に見受けられる。したがって、複数の認証機能によってユーザの認証を行うシステムを構築するにあたり、それぞれのディレクトリサービスも連携させることができれば、非常に便宜である。

本発明は、上記の点に鑑みてなされたものであって、ユーザの同一性を保証しつつ複数の認証機能によってユーザを認証することができるユーザ認証装置、ユーザ認証方法、ユーザ認証プログラム及び記録媒体の提供を目的とする。

また、本発明は、それぞれ独立して管理されているユーザ情報を統合的に提供することのできる情報提供装置、情報提供方法、情報提供プログラム及び記録媒体の提供を目的とする。

そこで上記課題を解決するため、本発明は、請求項１に記載されるように、ユーザに係る情報の提供を行う情報提供手段を連携させる連携手段を有する情報提供装置であって、前記連携手段は、ユーザに係る情報の提供要求に応じ、第一の情報管理手段において管理されているユーザに係る第一の情報を第一の情報提供手段に取得させ、第二の情報管理手段において所定の識別情報によって前記第一の情報に予め対応付けられて管理されているユーザに係る第二の情報を第二の情報提供手段に取得させ、前記第一及び第二の情報を前記所定の識別情報に基づいて統合した情報を提供することを特徴とする。

このような情報提供装置では、複数の情報提供手段によって取得されたユーザに係る情報を統合的に提供することができる。

また上記課題を解決するため、本発明は、上記情報提供装置における情報提供方法、又はその方法をコンピュータに行なわせるためのプログラム及び前記プログラムを記録した記録媒体としてもよい。

また上記課題を解決するため、本発明は、請求項１２に記載されるように、ユーザの認証を行う認証手段を連携させる連携手段を有するユーザ認証装置であって、前記連携手段は、ユーザに関する第一の認証要求に応じ、該第一の認証要求において指定された第一のユーザ識別情報に基づく認証を第一の認証手段に行わせ、前記第一の認証手段に認証されているユーザに関する第二の認証要求に応じ、前記第一のユーザ識別情報に予め対応づけられている第二のユーザ識別情報に基づく認証を第二の認証手段に行わせることを特徴とする。

このようなユーザ認証装置では、第一の認証手段における第一のユーザ識別情報（ユーザＩＤ等）に予め対応づけられた第二のユーザ識別情報に基づいて、第二の認証手段にユーザの認証をさせるため、ユーザの同一性を保証しつつ複数の認証機能によってユーザを認証することができる。

また上記課題を解決するため、本発明は、上記ユーザ認証装置におけるユーザ認証方法、又はその方法をコンピュータに行なわせるためのプログラム及び前記プログラムを記録した記録媒体としてもよい。

本発明によれば、それぞれ独立して管理されているユーザ情報を統合的に提供することができる。また、本発明によれば、ユーザの同一性を保証しつつ複数の認証機能によってユーザを認証することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態における認証システムの構成例を示す図である。図１に示されるように、第一の実施の形態における認証システム１は、お互いにインターネットやＬＡＮ等のネットワークを介して接続されている認証サーバ１０と端末２０とを有している。

端末２０はユーザが利用するＰＣ（Personal Computer）等の端末であり、ＳＯＡＰプロキシ２２、クライアントアプリケーション２３、及び指紋読み取り装置ドライバ２４等と有している。ＳＯＡＰプロキシ２２は、認証サーバ１０との間でＳＯＡＰ（Simple Object Access Protocol）による通信を実現するためのモジュールであり、クライアントアプリケーション２３に対して、認証サーバ１０の機能を関数インタフェースとして透過的に提供するためのものである。

指紋読み取り装置ドライバ２４は、端末２０に接続された指紋読み取り装置２５に対するインタフェースをクライアントアプリケーション２３に提供するためのいわゆるドライバである。指紋読み取り装置２５は、ユーザの指紋を読み取るための装置である。

クライアントアプリケーション２３は、ユーザが直接操作するアプリケーションである。クライアントアプリケーション２３は、その起動時やその他のタイミングでユーザの認証が必要になった際に、ユーザに対して認証情報の入力を要求する。ユーザによって認証情報が入力されると、クライアントアプリケーション２３は、ＳＯＡＰプロキシ２２を介して認証サーバ１０にユーザの認証を要求する。

クライアントアプリケーション２３の種類については、特に限定されないが、少なくとも利用する際に認証を必要とするものである。本実施の形態においては、一般的なものと同様にメール機能等を有するグループウェアのクライアントアプリケーションを想定する。

なお、端末２０の位置づけ（認証サーバ１０のクライアント）としてＷｅｂサーバを想定してもよい。この場合、当該Ｗｅｂサーバは、Ｗｅｂアプリケーションとして実装されているクライアントアプリケーション２３と、ＳＯＡＰプロキシ２２を有し、ＳＯＡＰプロキシ２２によって認証サーバ１０との通信を行う。当該ＷｅｂサーバのＷｅｂクライアントとしてユーザが利用する端末には、Ｗｅｂブラウザと、指紋読み取り装置ドライバ２４が実装され、更に、指紋読み取り装置２５が接続されていればよい。こうすることによって、ユーザは、クライアントアプリケーション２３の機能を、端末のＷｅｂブラウザに表示されたＷｅｂページを通して利用することができる。

ユーザがクライアントアプリケーション２３を起動すると、クライアントアプリケーション２３は、まずユーザＩＤ（ユーザ識別情報）とパスワードの入力を要求する。ユーザがユーザＩＤとパスワードとを入力すると、クライアントアプリケーション２３は、ＳＯＡＰプロキシ２２を介して認証サーバ１０に対しユーザの認証を要求する。また、ユーザがクライアントアプリケーション２３上において、指紋認証が必要とされるセキュリティレベルの高い操作を行うとすると、クライアントアプリケーション２３は、ユーザに対して指紋の入力を要求する。ユーザが指紋読み取りデバイス２５によって指紋を入力すると、クライアントアプリケーション２３は、認証サーバ１０に対し、ユーザの認証を要求する。

一方、認証サーバ１０は、ユーザ認証のサービスをＷｅｂサービスとして提供するコンピュータであり、認証サービスモジュール１１がインストールされている。

認証サービスモジュール１１は、認証サーバ１０をユーザ認証サービスの提供をするための装置として機能させるためのソフトウェアであり、本実施の形態においては、ＳＯＡＰスタブ１２、プロバイダ呼び分け手段１３、認証プロバイダＡ１４、認証プロバイダＢ１５、パスワード・指紋マージプロバイダ１６、パスワード認証プロバイダ１７、指紋認証プロバイダ１８、及びマージ情報管理ＤＢ１９等から構成されている。

ＳＯＡＰスタブ１２は、端末２０との間でＳＯＡＰによる通信を実現するためのモジュールである。より詳しくは、ＳＯＡＰスタブ１２は、プロバイダ呼び分け手段１３のメソッドインタフェースをＳＯＡＰインタフェースとしてネットワーク上に公開するためのモジュールである。すなわち、ＳＯＡＰスタブ１２は、クライアントＰＣ２０等より受信したＳＯＡＰメッセージ（ＳＯＡＰリクエスト）に基づいて、当該ＳＯＡＰメッセージおいて呼び出しが要求されているプロバイダ呼び分け手段１３のメソッドを呼び出し、当該メソッドの返却情報をＳＯＡＰレスポンスとしてクライアントＰＣ２０等に送信する。

プロバイダ呼び分け手段１３は、端末２０に対して後述する各種認証プロバイダに対する共通のインタフェースを提供するためのモジュールである。プロバイダ呼び分け手段１３は、端末２０からユーザの認証要求を受けると、当該認証要求において指定された認証プロバイダを呼び出す。

認証プロバイダＡ１４、認証プロバイダＢ１５、パスワード・指紋マージプロバイダ１６、パスワード認証プロバイダ１７、及び指紋認証プロバイダ１８等は、「認証プロバイダ」と呼ばれるモジュールである。ここで、認証プロバイダとは、様々な認証エンジンを認証サービスモジュール１１に組み込むためのアダプタ、又は仲介者のような役割を果たすものである。なお、認証エンジンとは、ここでは実際にパスワードの照合や、指紋の照合等の認証処理を行うシステムをいう。

即ち、個々の認証エンジンは、それぞれ独自のインタフェース（プロトコル）を有している。一方、それぞれの認証エンジンにおける認証機能をＷｅｂサービスとして端末２０等に提供するにはプロバイダ呼び分け手段１３との間で規定される所定のインタフェースに従う必要がある。かかる個々の認証エンジンによる独自のプロトコルを吸収し、プロバイダ呼び分け手段１３に対して共通のインタフェースを提供するのが、認証プロバイダである。従って、新たな認証エンジンを認証サービスモジュール１１に組み込むには、認証プロバイダを一つ実装することになる。但し、認証プロバイダ自身が、認証エンジンとしての機能を有していてもよい。

具体的には、パスワード認証プロバイダ１７は、パスワード認証を行うための認証エンジンが実装されているサーバである外部認証サーバ４０の認証機能をＷｅｂサービスとして提供するための認証プロバイダである。また、指紋認証プロバイダ１８は、指紋認証ライブラリ１８１と指紋ＤＢ１８２とによる指紋認証機能をＷｅｂサービスとして提供するための認証プロバイダである。指紋認証ライブラリ１８１は、指紋認証に関する機能を提供する関数群である。また、指紋ＤＢ１８２は、ユーザ毎の指紋特徴データ等が登録されているデータベースである。

認証プロバイダＡ１４及び認証プロバイダＢ１５は、様々な認証プロバイダを実装することが可能であることを示すための例示である。

パスワード・指紋マージプロバイダ１６は、認証プロバイダの一つであるが、認証エンジンに対する直接の仲介役として機能するものではないという点において、他の認証プロバイダとは異なる。即ち、パスワード・指紋マージプロバイダ１６は、パスワード認証プロバイダ１７と指紋認証プロバイダ１８とを連携させるための機能を提供する認証プロバイダである。なお、パスワード・指紋マージプロバイダ１６のように複数の認証プロバイダを連携させるための認証プロバイダを、以下「マージプロバイダ」と呼ぶ。

マージプロバイダによって連携される認証プロバイダは、それぞれ対等な関係ではなく主従関係を持つ。ここで、「主」となる認証プロバイダを「プライマリ（ｐｒｉｍａｒｙ）プロバイダ」と呼び、「従」となる認証プロバイダを「追加（ａｄｄｉｔｉｏｎａｌ）プロバイダ」と呼ぶこととする。連携された認証プロバイダの中で、プライマリプロバイダは一つであり、それ以外は全て追加プロバイダとなる。

ここで、主従の関係と表現したのは、追加プロバイダによって認証する際には、プライマリプロバイダによって既に認証されていることが前提となるからである。逆に、プライマリプロバイダによって認証する際は、追加プロバイダによって認証されていることは前提とならない。即ち、最初の認証に利用されるのがプライマリプロバイダであり、プライマリプロバイダによって認証が済んでいる場合において、更に特別な認証が必要な際に利用されるのが追加プロバイダというわけである。即ち、「連携」とは、複数の認証プロバイダを、上記の主従関係を持たせて結合することをいう。

本実施の形態においては、パスワード認証プロバイダ１７をプライマリプロバイダとし、指紋認証プロバイダ１８を追加プロバイダとした例について説明する。なお、マージプロバイダも、他の認証プロバイダと同様に、複数存在させてもよく、マージプロバイダによってマージする認証プロバイダの組み合わせは自由である。例えば、認証プロバイダＡ１４と認証プロバイダＢ１５とをマージする新たなマージプロバイダを定義してもよいし、パスワード・指紋マージプロバイダ１６に認証プロバイダＡ１４を更にマージさせてもよい。

マージ情報管理ＤＢ１９は、認証サーバ１０に実装されている認証プロバイダの一覧や、認証プロバイダ同士のマージの関係が登録されているデータベースである。

ここで、マージ情報管理ＤＢ１９を構成する各種テーブルについて説明する。図２は、マージ情報管理ＤＢを構成する認証プロバイダ管理テーブルの構成例を示す図である。図２の認証プロバイダ管理テーブル１９１（呼び出し情報管理手段）は、認証サーバ１０に登録されている認証プロバイダの一覧を管理しているテーブルであり、認証プロバイダ毎に、プロバイダ名、実装名、及び実装依存の初期化情報等が登録されている。

プロバイダ名は、認証プロバイダを一意に識別するための名前である。実装名は、例えば認証プロバイダの実装されているファイル名（ＥＸＥ名、ＤＬＬ名）、及び関数名等、認証プロバイダを呼び出すために、あるいは起動するために必要となる情報である。実装依存の初期化情報は、認証プロバイダの呼び出し時、又は起動時に必要となる情報である。

このように、認証プロバイダ管理テーブル１９１によって、各認証プロバイダの呼び出し情報を管理することにより、プロバイダ呼び分け手段１３と認証プロバイダ、及びマージプロバイダと当該マージプロバイダにマージされる認証プロバイダとの間の結合を動的なものとすることができる。即ち、プロバイダ呼び分手段１３やマージプロバイダのソースコードには、呼び出し情報に依存する定義（例えば、ロードするＤＬＬ名や、呼び出す関数名等）をハードコーディングしておく必要はない。従って、新たな認証プロバイダを追加した場合でも、当該認証プロバイダが所定のインタフェースに従っている限り、プロバイダ呼び分け手段１３やマージプロバイダのソースコードを修正する必要はない。

本実施の形態においては、上述したように、認証プロバイダＡ１４、認証プロバイダＢ１５、パスワード・指紋マージプロバイダ１６、パスワード認証プロバイダ１７、及び指紋認証プロバイダ１８等が存在するため、それぞれのレコードが認証プロバイダ管理テーブル１９１に登録されている。認証プロバイダ管理テーブル１９１によって、例えばプロバイダ呼び分け手段１３は、端末２０からユーザの認証要求があった際に、対応する認証プロバイダを呼び出すための手続きを知ることができる。

また、図３は、マージ情報管理ＤＢを構成するマージプロバイダ管理テーブルの構成例を示す図である。図３のマージプロバイダ管理テーブル１９２（第一の認証手段識別情報管理手段）は、認証プロバイダ管理テーブル１９１に登録されている認証プロバイダのうち、マージプロバイダである認証プロバイダを管理するテーブルであり、マージプロバイダ毎に、マージプロバイダ名及びプライマリプロバイダ名等が登録されている。

マージプロバイダ名は、マージプロバイダのプロバイダ名である。プライマリプロバイダ名は、当該マージプロバイダにおいてプライマリプロバイダとなっている認証プロバイダのプロバイダ名である。

マージプロバイダ管理テーブル１９２によって、マージプロバイダを識別することができる。また、マージプロバイダは、マージプロバイダ管理テーブル１９２によって、自身におけるプライマリプロバイダを識別する。従って、新たにマージプロバイダを定義する場合や、既存のマージプロバイダのプライマリプロバイダを他の認証プロバイダに変更する場合は、マージプロバイダ管理テーブル１９２を変更すればよく、マージプロバイダのソースコードを修正する必要はない。

本実施の形態においては、パスワード・指紋マージプロバイダ１６がマージプロバイダであるため、パスワード・指紋マージプロバイダ１６に対応するレコードが登録されている。また、パスワード・指紋マージプロバイダ１６のプライマリプロバイダは、上述したようにパスワード認証プロバイダ１７であるため、パスワード・指紋マージプロバイダ１６のプライマリプロバイダのプロバイダ名として、パスワード認証プロバイダ１７のプロバイダ名が登録されている。

また、図４は、マージ情報管理ＤＢを構成する追加プロバイダ管理テーブルの構成例を示す図である。図４の追加プロバイダ管理テーブル１９３（第二の認証手段識別情報管理手段）は、各マージプロバイダに属する追加プロバイダを識別するためのテーブルであり、マージプロバイダ名及び追加プロバイダ名等のデータ項目を有する。マージプロバイダ名は、マージプロバイダのプロバイダ名である。追加プロバイダ名は、当該マージプロバイダにおいて追加プロバイダとなっているプロバイダ名である。

本実施の形態においては、パスワード・指紋マージプロバイダ１６の追加プロバイダは、指紋認証プロバイダ１８であるため、その旨が追加プロバイダ管理テーブル１９３に登録されている。なお、パスワード・指紋マージプロバイダ１６に更に追加プロバイダを追加する場合は、パスワード・指紋マージプロバイダ１６のプロバイダ名をマージプロバイダ名とし、更に追加プロバイダとして登録する認証プロバイダのプロバイダ名を追加プロバイダ名とした新たなレコードを、追加プロバイダ管理テーブル１９３に登録すればよい。

また、図５は、マージ情報管理ＤＢを構成する認証プロバイダマージテーブルの構成例を示す図である。図５の認証プロバイダマージテーブル１９４（ユーザＩＤ対応管理手段）は、プライマリプロバイダにおけるユーザの識別情報（ユーザＩＤ等）と、追加プロバイダにおけるユーザＩＤとを対応づけるテーブルであり、マージプロバイダ名、プライマリＩＤ、追加プロバイダ名、及び追加ＩＤ等のデータ項目を有する。

マージプロバイダ名は、マージプロバイダのプロバイダ名である。プライマリＩＤとは、プライマリプロバイダに対応する認証エンジンにおいて、各ユーザに一意に割り当てられたユーザＩＤである。追加プロバイダ名は、追加プロバイダのプロバイダ名である。追加プロバイダ名の項目は、上述したように一つのマージプロバイダに複数の追加プロバイダを登録することが可能なため、後述する追加ＩＤがどの追加プロバイダにおけるものかを識別するために設けてあるものである。追加ＩＤは、追加プロバイダ名によって識別される追加プロバイダに対応する認証エンジンにおいて、各ユーザに一意に割り当てられたユーザＩＤである。

即ち、各ユーザを識別するためのコード体系は、各認証エンジンで異なるのが一般である。従って、それぞれの認証エンジンを有機的に連携させるためには、一方の認証エンジンにおけるユーザＩＤによって特定されるユーザの他方の認証エンジンにおけるユーザＩＤを特定するための手段が必要とされる。かかる手段を提供するのが認証プロバイダマージテーブル１９４である。なお、認証プロバイダマージテーブル１９４は、認証サービスモジュール１１に対して一つ実装してもよいし、マージプロバイダ一つに対して一つ、即ちマージプロバイダが有するように実装してもよい。

認証プロバイダマージテーブル１９４について更に具体的に説明する。本実施の形態においては、パスワード・指紋マージプロバイダ１６のプライマリプロバイダであるパスワード認証プロバイダ１７は、上述したように外部認証サーバ４０に対応する認証プロバイダである。ここで、外部認証サーバ４０は、パスワード認証を行う認証エンジンを実装したサーバであるため、例えば、図６に示されるユーザ管理テーブルを有している。

図６は、外部認証サーバにおけるユーザ管理テーブルの構成例を示す図である。図６のユーザ管理テーブル４１は、ユーザ毎に、ユーザＩＤ、パスワード、及び氏名等のユーザ情報を管理している。ここでユーザＩＤが、認証プロバイダマージテーブル１９４におけるプライマリＩＤに該当する。

一方、パスワード・指紋マージプロバイダ１６の追加プロバイダである指紋認証プロバイダ１８は、上述したように、指紋認証ライブラリ１８１と指紋ＤＢ１８２による指紋認証エンジンに対応する認証プロバイダである。ここで、指紋ＤＢ１８２は、例えば、図７に示される指紋特徴データ管理テーブルを有している。

図７は、指紋ＤＢを構成する指紋特徴データ管理テーブルの構成例を示す図である。図７の指紋特徴データ管理テーブル１８２１は、ユーザＩＤと指紋特徴データとをデータ項目として有する。ユーザＩＤは、指紋特徴データを一意に識別するための識別情報である。指紋特徴データは、指紋特徴データの実体である。ここで、ユーザＩＤが、マージテーブル１９４における追加ＩＤに該当する。

従って、認証プロバイダマージテーブル１９４より、外部認証サーバ４０においてユーザＩＤが０００１のユーザの指紋特徴データを特定することが可能となる。また、ユーザＩＤの対応づけを認証プロバイダマージテーブル１９４によって管理することにより、ユーザＩＤの対応づけに変更がある場合においても容易に対応することができる。

上述した、認証プロバイダ管理テーブル１９１、マージプロバイダ管理テーブル１９２、追加プロバイダ管理テーブル１９３、及び認証プロバイダマージテーブル１９４によって、マージプロバイダの動作に必要な情報が管理されることにより、マージプロバイダのソースコードを汎用的なものとすることができる。即ち、唯一のソースコードから複数の異なるマージプロバイダを実現させることができる。

図８は、本発明の実施の形態における認証サーバのハードウェア構成例を示す図である。図８の認証サーバ１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、演算処理装置１０４と、インタフェース装置１０５とを有するように構成される。

認証サーバ１０において認証サービスモジュール１１を実現するユーザ認証プログラムは、CD―ROM等の記憶媒体１０１によって提供される。ユーザ認証プログラムを記録した記憶媒体１０１は、ドライブ装置１００にセットされると、ユーザ認証プログラムが記憶媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。

補助記憶装置１０２は、インストールされたユーザ認証プログラムを格納すると共に、必要なファイルやデータ等を格納する。例えば補助記憶装置１０２は、ユーザ認証プログラムの処理に必要な、上述した各種テーブルを格納している。

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

以下、図１の認証サーバ１０の処理手順について説明する。なお、以下の説明において、プライマリプロバイダを利用した認証を「プライマリ認証」と、追加プロバイダを利用した認証を「追加認証」という。図９は、プライマリ認証の際の認証サーバの処理を説明するためのシーケンス図である。

ユーザがクライアントアプリケーション２３を利用すべくクライアントアプリケーション２３を起動すると、クライアントアプリケーション２３は、ユーザに対しユーザＩＤ及びパスワードの入力を要求する。ユーザがユーザＩＤ及びパスワードを入力すると、クライアントアプリケーション２３は、プロバイダ呼び分け手段１３が提供する認証関数（Authenticate( プロバイダ名、ドメイン名、ユーザＩＤ、パスワード)）をＳＯＡＰのＲＰＣで呼び出すことにより、認証サーバ１０に対しユーザの認証を要求する（Ｓ１１）。なお、認証関数の各引数の意味は以下の通りである。

プロバイダ名は、認証に利用する認証プロバイダのプロバイダ名であり、ここではパスワード・指紋マージプロバイダ１６のプロバイダ名が指定される。ドメイン名は端末２０が属するドメインのドメイン名である。ユーザＩＤ以降は、認証に利用する認証プロバイダによって、指定する値が異なる。本実施の形態では、パスワード・指紋マージプロバイダ１６のプライマリプロバイダは、パスワード認証プロバイダ１７であるため、パスワード認証に必要な情報としてユーザに入力させたユーザＩＤとパスワードが指定される。

ステップＳ１１に続いてステップＳ１２に進み、ＲＰＣによって認証関数が呼び出されたプロバイダ呼び分け手段１３は、認証関数の引数のプロバイダ名によって指定されている認証プロバイダを呼び出すために必要な情報を認証プロバイダ管理テーブル１９１から取得し、当該認証プロバイダを呼び出す。ここでは、パスワード・指紋マージプロバイダ１６が呼び出される。

ステップＳ１２に続いてステップＳ１３に進みパスワード・指紋マージプロバイダ１６は、自己のプライマリプロバイダとして登録されている認証プロバイダをマージプロバイダ管理テーブル１９２に基づいて識別し、当該プライマリプロバイダの認証関数（Authenticate（ドメイン名、ユーザＩＤ、パスワード））を呼び出す。ここでは、パスワード認証プロバイダ１７の認証関数呼び出される。なお、プライマリプロバイダの認証関数の各引数の値は、ディパッチャ１３の認証関数が呼び出される際に指定された値が引き継がれる。

ステップＳ１３に続いてステップＳ１４に進み、パスワード認証プロバイダ１７は、外部認証サーバ４０を利用してパスワード認証を実行する。ユーザが正当であることが確認されたらステップＳ１５に進み、パスワード認証プロバイダ１７はチケットを生成する。

ここで、チケットについて説明する。本実施の形態におけるチケットとは、認証にパスしたユーザ（クライアント）に対して認証プロバイダが発行する、当該ユーザが認証されたことを証明する電子的な証明書をいう。チケットを発行されたクライアントは、文書管理サーバ等、所定のサーバを利用する際にチケットを提示することにより当該サーバを利用する権限を得ることができる。

図１０は、通常のチケットのデータ構造の例を示す図である。図１０に示されるようにチケット５０１は、チケットＩＤ、有効範囲、認証プロバイダ名、有効期限、認証ドメイン名、認証ユーザＩＤ、主なユーザ属性のリスト、及びＭＩＣ等から構成される。

チケットＩＤは、発行されたチケットを一意に識別するためのコードである。有効範囲については後述する。認証プロバイダ名は、実際に認証を行った（チケットを発行した）認証プロバイダのプロバイダ名である。有効期限は、当該チケットが有効な期限である。認証ドメイン名及び認証ユーザＩＤは、認証を受けユーザに対応するドメイン名及びユーザＩＤである。主なユーザ属性リストは、認証を受けたユーザの様々な属性（例えば、所属、役職等）である。ＭＩＣは、当該チケットが途中で改竄されていないかを確認するためのコードである。

なお、チケットには、認証チケットとマスタチケットとがある。認証チケットとは、限られた範囲でのみ利用可能なチケットである。限られた範囲とは、所定のドメイン内でのみ利用可能であることや、所定のシステム又はサーバのみで利用可能であることを意味する。例えば、文書管理システムのみで利用可能な認証チケットは、他のシステムでは利用できない。従って、万が一認証チケットを盗まれた場合は、ユーザが受ける被害盗まれた認証チケットが有効な範囲のみに限られる。

これに対し、マスタチケットとは、チケットに対応しているシステムの全範囲に渡って利用可能な万能のチケットである。認証チケットの発行を要求する際には、マスタチケットを提示する必要がある。但し、その万能性ゆえ、マスタチケットを盗まれた場合には、被害はチケットに対応しているシステムの全範囲に及ぶ可能性がある。従って、マスタチケットは、認証チケットの発行要求等、マスタチケットの提示が必須の場合のみ利用し、通常のサービスを受ける際には、認証チケットを利用するといった使い分けをすることにより、より高度なセキュリティを確保することができる。

上記の説明において保留にした、チケットの構成要素である有効範囲は、かかる分類を識別するためのものである。即ち、当該チケットがマスタチケットである場合は、有効範囲には「マスタ」と記録され、認証チケットである場合は、当該認証チケットが有効な範囲を識別するための名称（ドメイン名、サーバ名等）が記録される。

なお、図９において、ステップＳ１１からステップＳ１９まではマスタチケットを発行するための処理に係り、ステップＳ２０からステップＳ２９まではマスタチケットを提示して認証チケットを得るための処理に係る。

また、別の観点から、チケットにはｉｎｎｅｒチケットとｏｕｔｅｒチケットとがある。ｉｎｎｅｒチケットとは、その名の通り内部のチケット、即ち、認証サーバ１０の内部におけるチケットに対する呼び名である。これに対しｏｕｔｅｒチケットとは、認証管理サーバ１０の外部におけるチケットに対する呼び名である。即ち、ｉｎｎｅｒチケットとｏｕｔｅｒチケットとの違いは、記録されている情報の内容が異なるといった本質的なものではない。認証サーバ１０から端末２０等へチケットが送信される際等に、チケットは、ｉｎｎｅｒチケットからｏｕｔｅｒチケットに変換される。一方、認証サーバ１０が端末２０等からｏｕｔｅｒチケットを受信した際には、チケットは、ｏｕｔｅｒチケットからｉｎｎｅｒチケットへと変換される。ここで変換の具体例としては、暗号化が挙げられる。即ち、ｉｎｎｅｒチケットを暗号化したものがｏｕｔｅｒチケットという関係である。チケットを暗号化することにより、例えチケットが盗まれた場合でも、その内容が不正に利用されることを防止することができる。

更に、本実施の形態においては、チケットをその発行元によって、プライマリチケットと追加チケットとに呼び分ける。プライマリチケットとは、プライマリプロバイダが発行したチケットをいい、追加チケットとは、追加プロバイダが発行したチケットをいう。

ステップＳ１５においてパスワード認証プロバイダ１７は、ｉｎｎｅｒ型のマスタチケットを生成する。また、パスワード認証プロバイダ１７は、プライマリプロバイダであるため、生成したチケットはプライマリチケットに分類される。よって、以下、ステップＳ１５においてパスワード認証プロバイダ１７が生成したチケットを「マスタプライマリチケット」という。

マスタプライマリチケットの各項目には以下のような値が記録されている。

有効範囲：「マスタ」
認証プロバイダ名：「パスワード認証プロバイダ」
有効期限：２００２/MM/ＤＤ
認証ドメイン名：＜認証関数の引数に指定されたドメイン名＞
認証ユーザＩＤ：＜認証関数の引数に指定されたユーザＩＤ＞
ステップＳ１５に続いてステップＳ１６に進み、パスワード認証プロバイダ１７は、認証関数の戻り値として、生成したマスタプライマリチケットをパスワード・指紋マージプロバイダ１６に出力する。ステップＳ１６に続いてステップＳ１７に進み、パスワード・指紋マージプロバイダ１６は、マージ（Ｍｅｒｇｅ）チケットを生成し、マージチケットにマスタプライマリチケットをマージ（統合）する。

図１１は、マージチケットのデータ構造の例を示す図である。図１１に示されるマージチケット５０２は、複数のチケットをマージするためのチケットであり、チケット種別、認証プロバイダ名、有効期限、プライマリプロバイダ名、プライマリチケット、追加チケットのリスト、及びＭＩＣ等から構成される。

チケット種別は、図１０に示される通常のチケット５０１における「有効範囲」と同義である。認証プロバイダ名は、当該マージチケットを発行した認証プロバイダ名である。従って、ここでは認証プロバイダ名にはパスワード・指紋マージプロバイダ１６のプロバイダ名が記録される。有効期限は、当該マージチケットの有効期限である。プライマリプロバイダ名は、当該マージチケットにマージされたプライマリチケットを発行したプライマリプロバイダのプロバイダ名である。従って、ここではパスワード認証プロバイダ１６のプロバイダ名が記録される。プライマリチケットは、プライマリプロバイダが発行した、プライマリチケットそのものが記録される。従って、ここではパスワード認証プロバイダ１６が発行したマスタプライマリチケットが記録される。追加チケットのリストは、追加プロバイダの発行する追加チケットが記録される。但し、この時点では、まだ追加プロバイダによる認証は実行されていないため、追加チケットのリストは空である。ＭＩＣは、通常のチケット５０１におけるＭＩＣと同義である。

なお、マージチケットについても、マスタチケット／認証チケットの区別と、ｉｎｎｅｒチケット／ｏｕｔｅｒチケットの区別とがあるが、ステップＳ１７で生成されるのは、ｉｎｎｅｒ型でかつマスタ型のマージチケットである。従って、ステップＳ１７においてパスワード・指紋マージプロバイダ１６が生成したチケットを、以下「マスタマージチケット」という。

ステップＳ１７に続いてステップＳ１８に進み、パスワード・指紋マージプロバイダ１６は、生成したマスタマージチケットをプロバイダ呼び分け手段１３に対して出力する。ステップＳ１８に続いてステップＳ１９に進み、プロバイダ呼び分け手段１３は、ｉｎｎｅｒ型のマスタマージチケットをｏｕｔｅｒ型に変換（例えば暗号化）し、ｏｕｔｅｒ型に変換されたマスタマージチケットをクライアントアプリケーション２３に送信する。

ステップＳ１９が完了した時点で、クライアントアプリケーション２３は、マスタマージチケットを取得したことになる。上述したようにマスタチケットは、万能のチケットであるため、このままマスタマージチケットを利用して他のシステムを利用することも可能であるが、マスタチケットをネットワーク上に頻繁に流通させるのは、セキュリティ上好ましくない。従って、クライアントアプリケーション２３は、プロバイダ呼び分け手段１３の認証チケット生成関数（createAuthTicket（マスタマージチケット））をＳＯＡＰのＲＰＣで呼び出すことにより、利用対象とするシステムに対してのみ有効な認証チケットの生成を認証サーバ１０に要求する（Ｓ２０）。なお、認証チケット生成関数の引数には、ステップＳ１９で取得した、ｏｕｔｅｒ型のマスタマージチケットを指定する。

ステップＳ２０に続いてステップＳ２１に進み、認証チケット生成関数が呼び出されたプロバイダ呼び分け手段１３は、ｏｕｔｅｒ型のマスタマージチケットをｉｎｎｅｒ型に変換（暗号化を解除）する。更に、プロバイダ呼び分け手段１３は、マスタマージチケットの「認証プロバイダ名」を確認することにより、マスタマージチケットを発行した認証プロバイダを判別する。

ステップＳ２１に続いてステップＳ２２に進み、プロバイダ呼び分け手段１３は、マスタマージチケットの発行元である認証プロバイダを呼び出す。従って、ここではパスワード・指紋マージプロバイダ１６が呼び出される。ステップＳ２２に続いてステップＳ２３に進み、パスワード・指紋マージプロバイダ１６は、マスタマージチケットの正当性を有効期限及びＭＩＣ等により確認する。

ステップＳ２３に続いてステップＳ２４に進み、パスワード・指紋マージプロバイダ１６は、マスタマージチケットにマージされているプライマリチケットを発行したプライマリプロバイダの認証チケット生成関数（createAuthTicket（マスタプライマリチケット））を呼び出す。従って、ここではパスワード認証プロバイダ１７の認証チケット生成関数が呼び出される。なお、パスワード認証プロバイダ１７の認証チケット生成関数の引数には、マスタマージチケットから取り出したマスタプライマリチケットが指定される。

ステップＳ２４に続いてステップＳ２５に進み、パスワード認証プロバイダ１７は、引数に指定されたマスタプライマリチケットの正当性を有効期限及びＭＩＣ等により確認し、認証チケットを生成する。認証チケットのデータ構造は、図１０において説明した通りであり、マスタプライマリチケットと同様に各項目に値が記録される。但し、「有効範囲」については、マスタプライマリチケットと異なり、当該認証チケットが有効なサーバ名又はドメイン名等が記録される。

なお、ここで生成された認証チケットについても、プライマリプロバイダであるパスワード認証プロバイダ１７が生成したものであるという意味で、プライマリチケットに分類される。従って、以下、ステップＳ２５においてパスワード認証プロバイダ１７が生成した認証チケットを「認証プライマリチケット」という。

ステップＳ２５に続いてステップＳ２６に進み、パスワード認証プロバイダ１７は、認証チケット生成関数の戻り値として、生成した認証プライマリチケットをパスワード・指紋マージプロバイダ１６に出力する。ステップＳ２６に続いてステップＳ２７に進み、パスワード・指紋マージプロバイダ１６は、マージチケットを生成し、マージチケットに認証プライマリチケットをマージする。

ここで、パスワード・指紋マージプロバイダ１６が生成するマージチケットは、有効範囲が限定された認証チケットである。よって、ステップＳ２７においてパスワード・指紋マージプロバイダ１６が生成したマージチケットを、以下「認証マージチケット」という。

ステップＳ２７に続いてステップＳ２８に進み、パスワード・指紋マージプロバイダ１６は、生成した認証マージチケットをプロバイダ呼び分け手段１３に対して出力する。ステップＳ２８に続いてステップＳ２９に進み、プロバイダ呼び分け手段１３は、ｉｎｎｅｒ型の認証マージチケットをｏｕｔｅｒ型に変換し、ｏｕｔｅｒ型に変換された認証マージチケットをクライアントアプリケーション２３に送信する。

以上により、クライアントアプリケーション２３は、マスタマージチケットに次いで認証マージチケットを取得したことになる。従って、クライアントアプリケーション２３は、認証マージチケットの有効なサーバに対して認証マージチケットを提示することにより、当該サーバのサービスを利用することができる。但し、上記においては、プライマリプロバイダ（パスワード認証プロバイダ１７）による認証しか受けていないため、クライアントアプリケーション２３に与えられた権限は、プライマリプロバイダによって認証を受けた範囲に限られる。

ここでいう「認証を受けた範囲」における「範囲」とは、チケット５０１のデータ項目である「有効範囲」における「範囲」と異なる概念である。「有効範囲」における範囲は、例えば、当該チケットは、サーバＡとサーバＢとで有効であるというように、利用可能な対象を示す意味での範囲である。一方、「認証を受けた範囲」における範囲は、当該チケットは、プライマリプロバイダのみに認証を受けており、追加プロバイダには認証されていないといったように、認証を受けたレベルを示すものである。たとえていえば、前者は平面的な広がりにおける範囲をいい、後者は深さ方向における範囲をいう。

以下、ユーザが、更に"深い"、即ち、本人であることを更に保証するための追加認証を受ける際の処理について説明する。図１２及び図１３は、追加認証の際の認証サーバの処理を説明するためのシーケンス図である。クライアントアプリケーション２３のユーザが、パスワード認証プロバイダ１７によって認証を受けただけでは、利用できないサービスを利用しようとした場合を想定する。例えば、重要な機密情報にアクセスしようとした場合、又は、部下の承認要求に対して承認を実行しようとした場合などがいい例である。ユーザがかかる処理要求を行った場合に、本実施の形態におけるクライアントアプリケーション２３は、ユーザに対し指紋の入力を要求する。

但し、ここではユーザＩＤの入力は必要とされない。一般に、認証を受ける際には、ユーザＩＤ等のユーザを一意に特定するための情報と、パスワード、指紋等のユーザが本人であることを保証するための情報とを入力することが必要とされる。ユーザＩＤの入力のみでは、ユーザが本人であるかを判断することができず、パスワードや指紋の入力のみでは、誰のパスワード又は指紋であるのか判断することができないからである。従って、通常であれば、ここにおいて、ユーザは、指紋と共にユーザＩＤの入力が要求されるはずである。しかし、本実施の形態におけるパスワード・指紋マージプロバイダ１６は、詳細については後述されるが、既にプライマリ認証の際に入力されたユーザＩＤ（プライマリＩＤ）に基づいて、当該ユーザの追加認証におけるユーザＩＤ（追加ＩＤ）を特定するため、ユーザに、追加認証の際にユーザＩＤの入力を要求する必要がないのである。

ユーザが指紋読み取りデバイス２５に指紋を読み取らせると、クライアントアプリケーション２３は、プロバイダ呼び分け手段１３の追加認証関数（addAuthenticate（マスタマージチケット、追加認証プロバイダ名、指紋特徴データ）をＳＯＡＰのＲＰＣによって呼び出すことにより、認証サーバ１０に対して追加認証を要求する（Ｓ４１）。

なお、追加認証関数の引数の意味は、以下の通りである。マスタマージチケットには、マスタプライマリチケットがマージされている既に取得済みのマスタマージチケットを指定する。追加認証プロバイダ名には、追加認証を要求する追加プロバイダのプロバイダ名を指定する。従って、ここでは指紋認証プロバイダ１８のプロバイダ名を指定する。指紋特徴データには、指紋読み取りデバイス２５で読み取った指紋特徴データを指定する。

ステップＳ４１に続いてステップＳ４２に進み、追加認証関数が呼び出されたプロバイダ呼び分け手段１３は、マスタマージチケットの「認証プロバイダ名」を確認することにより、マスタマージチケットを発行した認証プロバイダを判別する。なお、本ステップ以降の説明においては、チケットについてのｏｕｔｅｒ形、ｉｎｎｎｅｒ型の区別については省略する。

ステップＳ４２に続いてステップＳ４３に進み、プロバイダ呼び分け手段１３は、マスタマージチケットの発行元である認証プロバイダを呼び出す。従って、ここではパスワード・指紋マージプロバイダ１６が呼び出される。ステップＳ４３に続いてステップＳ４４に進み、パスワード・指紋マージプロバイダ１６が、マスタマージチケットからマスタプライマリチケットを取り出し、マスタプライマリチケットの所有者であるユーザのユーザＩＤ（プライマリＩＤ）の取得をプライマリプロバイダであるパスワード認証プロバイダ１７に要求すると、パスワード認証プロバイダ１７は、マスタプライマリチケットの正当性を確認すると共に、マスタプライマリチケットから認証ユーザＩＤを取り出し、パスワード・指紋マージプロバイダ１６に対して取り出した認証ユーザＩＤをプライマリＩＤとして出力する。

ステップＳ４４に続いてステップＳ４５に進み、パスワード・指紋マージプロバイダ１６は、パスワード認証プロバイダ１７から取得したプライマリＩＤをキーとして、認証プロバイダマージテーブル１９４を検索し、プライマリＩＤに対応する追加ＩＤを取得する。なお、ここで取得された追加ＩＤは、指紋ＤＢ１８２の指紋特徴データ管理テーブル１８２１におけるユーザＩＤに該当する。

ステップＳ４５に続いてステップＳ４６に進み、パスワード・指紋マージプロバイダ１６は、追加認証関数の引数に指定された追加認証プロバイダ名によって特定される追加プロバイダの認証関数（Authenticate（追加ＩＤ、指紋特徴データ））を呼び出す。従って、ここでは指紋認証プロバイダ１８の認証関数が呼び出される。

ステップＳ４６に続いてステップＳ４７に進み、認証関数が呼び出された指紋認証プロバイダ１８は、引数に指定された追加ＩＤ（ユーザＩＤ）をキーに指紋ＤＢ１８２から指紋特徴データを取り出し、取り出した指紋特徴データと、認証関数の引数に指定された指紋特徴データとを照合する。

ここで、認証関数の引数に指定された指紋特徴データは、追加認証を要求したユーザのものである。一方、ステップＳ４７において指紋ＤＢ１８２から取り出された指紋特徴データは、プライマリ認証を受けたユーザのユーザＩＤであるプライマリＩＤをキーとして認証プロバイダマージテーブル１９４から検索した追加ＩＤに対応するものである。

従って、二つの指紋特徴データが一致することにより、追加認証を要求したユーザが、指紋ＤＢ１８２登録されているユーザであることと共に、プライマリ認証を受けたユーザと追加認証を受けたユーザとが同一人物であることが保証される。

また、二つの認証をパスしたことで、クライアントアプリケーション２３のユーザが本人であることの保証がより高まったといえる。

従って、指紋認証プロバイダ１８は、自らが認証したことを証明するマスタチケットを生成する（Ｓ４８）。なお、指紋認証プロバイダ１８は、追加プロバイダであるため、指紋認証プロバイダ１８が発行するチケットは追加チケットであるといえる。よって、ステップＳ４８において指紋認証プロバイダ１８が生成したマスタチケットを、以下「マスタ追加チケット」という。

なお、ここで生成されたマスタ追加チケットの「認証プロバイダ名」には、指紋認証プロバイダ１８の認証プロバイダ名が記録され、認証ユーザＩＤには、指紋ＤＢ１８２におけるユーザＩＤが記録される。

ステップＳ４８に続いてステップＳ４９に進み、指紋認証プロバイダ１８は、生成したマスタ追加チケットをパスワード・指紋マージプロバイダ１６に出力する。ステップＳ４９に続いてステップＳ５０に進み、パスワード・指紋マージプロバイダ１６は、既にマスタプライマリチケットがマージされているマスタマージチケットにマスタ追加チケットをマージする。

ステップＳ５０に続いてステップＳ５１に進み、パスワード・指紋マージプロバイダ１６は、マスタ追加チケットを更にマージしたマスタマージチケットをプロバイダ呼び分け手段１３に出力する。ステップＳ５１に続いてステップＳ５２に進み、プロバイダ呼び分け手段１３は、クライアントアプリケーション２３に対してマスタマージチケットを送信する。この時点でクライアントアプリケーション２３は、追加チケットがマージされた（追加認証を受けた）更に信頼性の高いマスタマージチケットを入手したことになる。

ステップＳ５２に続いて図１３のステップＳ５３に進み、以降は図９のステップＳ２０以降の処理と同様に、クライアントアプリケーション２３が認証チケットを取得するための処理である。従って、ステップＳ５３からステップＳ５９までは、図９のステップＳ２０からステップＳ２６までの処理と同様である。即ち、クライアントアプリケーション２３によるプロバイダ呼び分け手段１３の認証チケット生成関数（createAuthTicket（マスタマージチケット））の呼び出しに基づいて（Ｓ５３）、パスワード認証プロバイダ１７によって認証プライマリチケットが生成され、パスワード・指紋マージプロバイダ１６に出力される（Ｓ５４〜Ｓ５９）。

ここで、認証プライマリチケットを受け取ったパスワード・指紋マージプロバイダ１６は、マスタマージチケットが追加認証されたものであるのか、即ち、マスタマージチケットにマスタ追加チケットがマージされているか否かを判断する。

マスタマージチケットにマスタ追加チケットがマージされていない場合は、図９の場合と同様に認証プライマリチケットがマージされた認証マージチケットがクライアントアプリケーション２３に送信される（Ｓ６０）。しかし、今回は、既にマスタマージチケットについて追加認証を受けている。従って、パスワード・指紋マージプロバイダ１６は、追加プロバイダからも認証チケットを取得するため、マスタマージチケットにマージされている追加チケットを発行した追加プロバイダの認証チケット生成関数（createAuthTicket（マスタ追加チケット））を呼び出す（Ｓ６１）。従って、ここでは指紋認証プロバイダ１８の認証チケット生成関数が呼び出される。なお、指紋認証プロバイダ１８の認証チケット生成関数の引数には、マージチケットから取り出したマスタ追加チケットが指定される。

ステップＳ６１に続いてステップＳ６２に進み、指紋認証プロバイダ１８は、引数に指定されたマスタ追加チケットの正当性を有効期限及びＭＩＣ等により確認し、正当である場合は、認証チケット（以下、「認証追加チケット」という。）を生成する。

ステップＳ６２に続いてステップＳ６３に進み、指紋認証プロバイダ１８は、認証チケット生成関数の戻り値として、生成した認証追加チケットをパスワード・指紋マージプロバイダ１６に出力する。ステップＳ６３に続いてステップＳ６４に進み、パスワード・指紋マージプロバイダ１６は、認証マージチケットを生成し、ステップＳ５９で取得した認証プライマリチケットと、ステップＳ６３で取得した認証追加チケットとを認証マージチケットにマージする。

ステップＳ６４に続いてステップＳ６５に進み、以降、認証マージチケットがクライアントアプリケーション２３に送信される（Ｓ６６）。

以上により、クライアントアプリケーション２３は、図９のステップＳ２９において入手した認証マージチケットよりも信頼性が高い、追加認証された認証マージチケットを取得したことになる。従って、クライアントアプリケーション２３は、認証マージチケットの有効なサーバに対して認証マージチケットを提示することにより、更にセキュリティレベルの高いサービスを利用することができる。

なお、図１２のステップＳ４１においてクライアントアプリケーション２３が呼び出すプロバイダ呼び分け手段１３の追加認証関数（addAuthenticate）は、引数として追加認証プロバイダ名の指定を要求している。これは、クライアント主導で次に追加認証を行わせる追加プロバイダが決定されることを示している。

即ち、上述においては、パスワード・指紋マージプロバイダ１６の追加プロバイダとして指紋認証プロバイダ１８一つのみが定義されている例について説明したが、追加プロバイダ管理テーブル１９３と認証プロバイダマージテーブル１９４に新たな認証プロバイダの情報を追加すれば、パスワード・指紋マージプロバイダ１６に複数の追加プロバイダを定義することも可能である。

かかる追加プロバイダが複数ある場合に、上述の例では、追加認証を行わせる追加プロバイダの順番は、追加認証関数を呼び出すクライアントの指定に従うことになる。

しかし、追加認証を行わせる追加プロバイダの順番は、マージプロバイダ（パスワード・指紋マージプロバイダ１６）に判断させるようにしてもよい。例えば、追加プロバイダ管理テーブル１９３に新たなデータ項目として「順番」を追加し、「順番」項目に追加認証を行わせる順番を登録しておく。クライアントアプリケーション２３から追加認証の要求があった場合は、マージプロバイダが追加プロバイダ管理テーブル１９３の「順番」項目を確認することにより、次に呼び出す追加プロバイダを決定する。

この場合は、追加認証関数の引数から追加プロバイダ名を削除してしまってもよいし、そのまま指定させるようにしてもよい。そのまま指定させるようにした場合は、追加認証関数の引数に指定された追加プロバイダ名と、マージプロバイダが判断した追加プロバイダ名とを比較することにより、サーバ側とクライアント側とのフェーズが一致しているか否かを確認することができる。

次に、認証サーバ１０が発行したチケットがどのように利用されるかについて説明する。図１４は、チケットの第一の利用方法を説明するためのシーケンス図である。図１４において、クライアント３０は、クライアントアプリケーション２３でもよいが、ここでは、クライアントアプリケーション２３等に所定のサービスを提供するサーバであるとする。そして、クライアント３０がクライアントアプリケーション２３からサービスの利用要求と共に認証マージチケットの提示を受けた場合を想定する。なお、クライアント３０は、クライアントアプリケーション２３に対してはサーバであるが、認証サーバ３０に対しては「クライアント」であるため、図１４においてクライアント３０と表現している。

認証マージチケットの提示を受けたクライアント３０は、自分自身ではチケットの中身を解釈することができない。クライアントアプリケーション２３から提示された認証マージチケットは暗号化（ｏｕｔｅｒ型）されており、また、クライアント３０は、チケットの構造については関知しないからである。

よって、クライアント３０は、ステップＳ１０１において、プロバイダ呼び分け手段１３の提供するチケット解読関数（decodeTicket（認証マージチケット））を呼び出すことにより、認証マージチケットの解読を認証サーバ１０に要求する。なお、チケット解読関数の引数には、クライアントアプリケーション２３から提示（送信）された認証マージチケットを指定する。

ステップＳ１０１に続いてステップＳ１０２に進み、チケット解読関数が呼び出されたプロバイダ呼び分け手段１３は、認証マージチケットを発行した認証プロバイダを判別する。

ステップＳ１０２に続いてステップＳ１０３に進み、プロバイダ呼び分け手段１３は、認証マージチケットの発行元であるパスワード・指紋マージプロバイダ１６を呼び出す。ステップＳ１０３に続いてステップＳ１０４に進み、パスワード・指紋マージプロバイダ１６は、認証マージチケットの正当性を有効期限及びＭＩＣ等により確認し、認証マージチケットにマージされているプライマリチケットを発行したパスワード認証プロバイダ１７のチケット解読関数（decodeTicket（認証プライマリチケット））を呼び出す（Ｓ１０５）。なお、パスワード認証プロバイダ１７のチケット解読関数の引数には、認証マージチケットから取り出した認証プライマリチケットが指定される。

ステップＳ１０５に続いてステップＳ１０６に進み、パスワード認証プロバイダ１７は、引数に指定された認証プライマリチケットの正当性を有効期限及びＭＩＣ等により確認するとともに認証プライマリチケットの内容を解釈し、プライマリチケットの内容をクライアント３０が解釈可能な形式、例えばテキスト形式にした認証情報データ（以下、「プライマリ認証情報データ」という。）を生成する。

ステップＳ１０６に続いてステップＳ１０７に進み、パスワード認証プロバイダ１７は、生成したプライマリ認証情報データをパスワード・指紋マージプロバイダ１６に出力する。ここで、プライマリ認証情報データを受け取ったパスワード・指紋マージプロバイダ１６は、認証マスタマージチケットが追加認証されたものであるのかを判断する。追加認証されていなければ、認証マスタマージチケットにはこれ以上認証情報は含まれていないため、プライマリ認証情報データがクライアント３０に送信される（Ｓ１０８）。

一方、既に認証マージチケットについて追加認証を受けている場合は、パスワード・指紋マージプロバイダ１６は、認証マージチケットにマージされている追加チケットを発行した指紋認証プロバイダ１８からも認証情報データを取得するため、指紋認証プロバイダ１８のチケット解読関数（decodeTicket（認証追加チケット））を呼び出す（Ｓ１０９）。

ステップＳ１０９に続いてステップＳ１１０に進み、指紋認証プロバイダ１８は、引数に指定された認証追加チケットの正当性を有効期限及びＭＩＣ等により確認するとともに認証追加チケットの内容を解釈し、認証情報データ（以下、「追加認証情報データ」という。）を生成する。

ステップＳ１１０に続いてステップＳ１１１に進み、指紋認証プロバイダ１８は、生成した追加認証情報データをパスワード・指紋マージプロバイダ１６に出力する。ステップＳ１１１に続いてステップＳ１１２に進み、パスワード・指紋マージプロバイダ１６は、パスワード認証プロバイダ１７から取得した追加認証情報データと、指紋認証プロバイダ１８から取得した追加認証情報データとをマージする（以下、マージされた認証情報データを「マージ認証情報データ」という。）。

図１５は、マージ認証情報データの構成例を示す図である。例えば、マージ認証情報データは、図１５に示されるように、認証サービス名、有効期限、有効範囲、認証プロバイダ、ユーザ識別子、所属グループ、及び主要属性等から構成される。

認証サービス名は、認証サービスモジュール１１に付けられた名前である。有効期限は、マージチケットに記録されている有効期限である。有効範囲は、プライマリチケット及び追加チケットに記録されている有効範囲をマージしたものである。即ち、「サーバＡ」と「サーバＢ」とがカンマで区切られているが、これは、プライマリチケットはサーバＡで有効であり、追加チケットはサーバＢで有効であることを示している。

認証プロバイダは、チケットを発行した認証プロバイダの名前の羅列である。「パスワード認証プロバイダ」と「指紋認証プロバイダ」がカンマで区切られているが、これは、パスワード認証プロバイダ１７と指紋認証プロバイダ１８に認証を受けていることを示している。ユーザ識別子は、チケットの発行を受けたユーザを一意に識別するための情報である。所属グループ及び主要属性は、プライマリチケット及び追加チケットの「主なユーザ属性リスト」から抽出した情報をマージしたものである。

ステップＳ１１２に続いてステップＳ１１３に進み、マージ認証情報データがクライアント３０に送信される（Ｓ１１４）。

以降、クライアント３０は、取得したマージ認証情報データを確認することにより、クライアントアプリケーション２３のユーザに対して提供可能なサービスを判断することができる。

更に、図１６は、チケットの第二の利用方法を説明するためのシーケンス図である。図１４においては、クライアント３０がチケットの解読結果を認証情報データとして受け取る例について説明したが、図１６においては、チケットの正当性の確認と、チケットが誰に認証されたのか、あるいはどの程度まで（プライマリ認証まで、又は追加認証まで）認証されているのかを問い合わせる例について説明する。なお、図１６におけるクライアント３０の位置づけは、図１４におけるそれと同じである。

ステップＳ１２１においてクライアント３０は、プロバイダ呼び分け手段１３の提供するチケット確認関数（ValidateTicket（認証マージチケット））を呼び出すことにより、認証マージチケットの正当性の確認等を認証サーバ１０に要求する。なお、チケット確認関数の引数には、クライアントアプリケーション２３から提示（送信）された認証マージチケットを指定する。

ステップＳ１２１に続いてステップＳ１２２に進み、チケット確認関数が呼び出されたプロバイダ呼び分け手段１３は、認証マージチケットを発行した認証プロバイダを判別する。

ステップＳ１２２に続いてステップＳ１２３に進み、プロバイダ呼び分け手段１３は、認証マージチケットの発行元であるパスワード・指紋マージプロバイダ１６を呼び出す。ステップＳ１２３に続いてステップＳ１２４に進み、パスワード・指紋マージプロバイダ１６は、認証マージチケットの正当性を有効期限及びＭＩＣ等により確認し、認証マージチケットにマージされているプライマリチケットを発行したパスワード認証プロバイダ１７のチケット確認関数（ValidateTicket（認証プライマリチケット））を呼び出す（Ｓ１２５）。なお、パスワード認証プロバイダ１７のチケット確認関数の引数には、マージチケットから取り出した認証プライマリチケットが指定される。

ステップＳ１２５に続いてステップＳ１２６に進み、パスワード認証プロバイダ１７は、引数に指定された認証プライマリチケットの正当性を有効期限及びＭＩＣ等により確認し、確認結果をパスワード・指紋マージプロバイダ１６に出力する（Ｓ１２７）。ここで確認結果とは、例えば、ＴＲＵＥの場合は正当であり、ＦＡＬＳＥの場合は不正であるといったＢＯＯＬ値などでも良い。

続いて、パスワード・指紋マージプロバイダ１６は、認証マスタマージチケットが追加認証されたものであるのかを判断する。追加認証されていなければ、確認結果がクライアント３０に送信される（Ｓ１２８）。ここでの確認結果とは、例えば、認証を行った認証プロバイダのプロバイダ名の羅列でもよいし、プライマリプロバイダまでは認証されているといったように、レベルを示すものでもよい。

一方、既に認証チケットについて追加認証を受けている場合は、パスワード・指紋マージプロバイダ１６は、認証マージチケットにマージされている追加チケットを発行した指紋認証プロバイダ１８に対してもチケットの確認を依頼するため、指紋認証プロバイダ１８のチケット確認関数（ValidateTicket（認証追加チケット））を呼び出す（Ｓ１２９）。

ステップＳ１２９に続いてステップＳ１３０に進み、指紋認証プロバイダ１８は、引数に指定された認証追加チケットの正当性を有効期限及びＭＩＣ等により確認し、確認結果（例えばＢＯＯＬ値）をパスワード・指紋マージプロバイダ１６に出力する（Ｓ１３１）。ステップＳ１３１に続いてステップＳ１３２に進み、パスワード・指紋マージプロバイダ１６は、パスワード認証プロバイダ１７と指紋認証プロバイダ１８とから取得した確認結果をマージしたものをクライアント３０に対する確認結果としてプロバイダ呼び分け手段１３に出力する。例えば、ここでの確認結果とは、認証を行った認証プロバイダのプロバイダ名の羅列でもよいし、追加プロバイダまでは認証されているといったように、レベルを示すものでもよい。

ステップＳ１３２に続いてステップＳ１３３に進み、プロバイダ呼び分け手段１３は、確認結果をクライアント３０に送信する。確認結果を受信したクライアント３０、確認結果に基づいて、クライアントアプリケーション２３のユーザに対して提供可能なサービスを判断することができる。

上述したように、本実施の形態における認証サーバ１０によれば、マージプロバイダが、認証プロバイダマージテーブル１９４によって、プライマリＩＤから追加ＩＤを導出し、かかる追加ＩＤに基づいて追加認証をおこなうため、プライマリ認証を受けたユーザと追加認証を受けようとしているユーザの同一性を保証し、当該ユーザが本人であることの保証をより高めることができる認証サービスを提供することができる。

また、認証した結果は、チケットとして発行され、当該チケットは、有効範囲、有効期限、改竄チェック用のコードを有しているため、より高度なセキュリティを確保することができる。即ち、有効範囲で、利用可能なシステム等が制限され、有効期限によって、利用可能な期間が制限され、改竄チェック用のコードによって、チケットの正当性が担保されるからである。

また、プライマリプロバイダや追加プロバイダが発行したチケットは、マージプロバイダによってマージチケットにマージされて発行されるため、チケットを発行された側は、各チケットの関連付けについて関与する必要はなく、チケットの取り扱いを容易にすることができる。

なお、本実施の形態においては、認証サービスモジュール１１が、ネットワークを介して接続されている端末２０に配置されているクライアントアプリケーション２３に対して認証機能を提供する例について説明したが、本発明は、かかるクライアント・サーバ型のシステムに限定されるものではない。

図１７は、内部アプリケーションに認証機能を提供する場合の認証サーバの機能構成例を示す図である。図１７中、図１と同一部分には同一符号を付し、その説明は省略する。図１７においては、アプリケーション４１、４２、４３、及び４４が、ＳＯＡＰ経由ではなく、プロバイダ呼び分け手段１３の関数を直接呼び出すように構成されている。このように、認証サーバ１０の内部に構築したアプリケーションからも、認証サービスモジュール１１を利用することができる。

ところで、ネットワーク上の資源を管理し、その検索手段を提供するシステムとしてディレクトリサービスが知られている。ここで、資源とは、ネットワークを利用するユーザや組織に関する情報や、利用可能なサーバ、サービス及びプリンタなどの機器を意味するが、かかるディレクトリサービスは、認証機能と共に実装されているのが一般的である。そこで、第二の実施の形態として、認証システム１にディレクトリサービスとしての機能を実装した例について説明する。

図１８は、第二の実施の形態における認証システムの構成例を示す図である。図１８中、図１と同一部分には同一符号を付し、その説明は省略する。

図１８の認証システム２において認証サーバ１０の認証サービスモジュール１１には、ＳＯＡＰスタブ１２ａ、ディレクトリサービスインタフェース部１３ａ、ディレクトリプロバイダＡ１４ａ、ディレクトリプロバイダＢ１５ａ、パスワード・指紋マージディレクトリプロバイダ１６ａ、パスワードディレクトリプロバイダ１７ａ、及び指紋ディレクトリプロバイダ１８ａ等が更に追加されている。

ＳＯＡＰスタブ１２ａは、ディレクトリサービスインタフェース部１３ａのメソッドインタフェースをＳＯＡＰインタフェースとしてネットワーク上に公開するためのモジュールである。ディレクトリサービスインタフェース部１３ａは、認証機能におけるプロバイダ呼び分け手段１３に相当するモジュールであり、各種認証プロバイダにおけるディレクトリサービスとしての機能に対する共通のメソッドインタフェースを提供するためのモジュールである。

ディレクトリプロバイダＡ１４ａ、ディレクトリプロバイダＢ１５ａ、パスワードディレクトリプロバイダ１７ａ、及び指紋ディレクトリプロバイダ１８ａ等の各種ディレクトリプロバイダは、ユーザに関する各種属性情報（内線番号やメールアドレス等の当該ユーザにアクセスするための情報に加え、所属や役職に関する情報等、以下、「ユーザ情報」という。）を提供するためのモジュールである。例えば、パスワードディレクトリプロバイダ１７ａは、外部認証サーバ４０において管理されているユーザ情報を提供するためのモジュールである。また、指紋ディレクトリプロバイダ１８ａは、指紋ＤＢ１８２において管理されているユーザ情報を提供するためのモジュールである。

また、パスワード・指紋マージディレクトリプロバイダ１６ａ、パスワードディレクトリプロバイダ１７ａ（プライマリプロバイダ）と指紋ディレクトリプロバイダ１８ａ（追加プロバイダ）を連携させるためのマージプロバイダである。すなわち、ディレクトリプロバイダ間においても、第一の実施の形態における認証プロバイダと同様のマージの概念が適用されている。これら各種ディレクトリプロバイダの情報や、ディレクトリプロバイダ間のマージに関する情報等は、第一の実施の形態と同様のテーブル構成によってマージ情報管理ＤＢ１９に管理されている。第二の実施の形態においては、パスワードディレクトリプロバイダ１７ａがプライマリプロバイダとして、指紋ディレクトリプロバイダ１８ａが追加プロバイダとしてマージ情報管理ＤＢ１９に定義されているものとする。

以下、図１８の認証サーバ１０の処理手順について説明する。図１９は、ユーザ情報の提供が要求された際の認証サーバの処理を説明するためのシーケンス図である。図１９においては、クライアント３０より、ユーザ情報の要求があった場合を例に説明する。なお、クライアント３０は、図９、図１２及び図１３おいて説明した処理によって発行された認証マージチケットを既に保有しているものとする。

ここで、図１９における処理は、図１４における処理、すなわち、クライアント３０が認証サーバ１０に対してチケットの解読を要求することにより、当該チケットに含まれているユーザ（チケットの所有者）に関する情報を取得する処理とは本質的に異なることに注意を要する。すなわち、図１９における処理は、チケットの所有者に関する情報を取得するのではなく、チケットを用いて他のユーザのユーザ情報を参照するための処理である。したがって、図１９における処理は、ユーザ情報の参照が許可されているユーザに対してのみ実行され得る。以下、ステップごとに処理を説明する。

ステップＳ２０１において、クライアント３０は、ディレクトリサービスインタフェー
部１３ａの提供するユーザ一覧取得関数（queryUser）を呼び出すことにより、ユーザ情報の一覧（以下、「ユーザ一覧」という。）の提供を認証サーバ１０に要求する。なお、ユーザ一覧取得関数の引数には、認証マージチケット、対象プロバイダ名及び取得条件等が指定される。対象プロバイダとは、ユーザ情報の提供の要求先のディレクトリプロバイダのプロバイダ名（ここでは、パスワード・指紋マージディレクトリプロバイダ１６ａ）である。また、取得条件とは、検索対象とするユーザ情報を絞り込むための条件（いわゆる検索条件）である。

ステップＳ２０１に続いてステップＳ２０２に進み、ユーザ一覧取得関数が呼び出されたディレクトリサービスインタフェース部１３ａは、まず、引数に指定された認証マージチケットの正当性を確認すべく、プロバイダ呼び分け手段１３のチケット確認関数（ValidateTicket（認証マージチケット））を呼び出す。チケット確認関数が呼び出されることにより、図１６において説明した処理が実行され、認証マージチケットの正当性及び当該認証マージチケットの所有者に対するユーザ一覧の参照権限の有無等が判断され、その判断結果がプロバイダ呼び分け手段１３よりディレクトリサービスインタフェース部１３ａに返却される（Ｓ２０３）。

チケットの正当性が確認された場合は、ステップＳ２０４に進み、ディレクトリサービスインタフェース部１３ａは、パスワード・指紋マージディレクトリプロバイダ１６ａのユーザ一覧取得関数（queryUser）を呼び出すことにより、パスワード・指紋マージディレクトリプロバイダ１６ａに対してユーザ一覧の提供を要求する。ステップＳ２０４に続いてステップＳ２０５に進み、パスワード・指紋マージディレクトリプロバイダ１６ａは、プライマリプロバイダであるパスワードディレクトリプロバイダ１７ａのユーザ一覧取得関数（queryUser）を呼び出すことにより、パスワードディレクトリプロバイダ１７ａに対してユーザ一覧の提供を要求する。なお、パスワード・指紋マージディレクトリプロバイダ１６ａは、パスワードディレクトリプロバイダ１７ａがプライマリプロバイダであること、及びパスワードディレクトリプロバイダ１７ａを呼び出すための手順等については、マージプロバイダ管理テーブル１９２及び認証プロバイダ管理テーブル１９１等を参照して判断する。

ステップＳ２０５に続いてステップＳ２０６に進み、パスワードディレクトリプロバイダ１７ａは、ユーザ一覧取得関数の引数に指定された取得条件合致するユーザ情報を外部認証サーバ４０より検索し、検索されたユーザ情報の一覧（ユーザ一覧）をパスワード・指紋マージディレクトリプロバイダ１６ａに出力する（Ｓ２０７）。

図２０は、外部認証サーバより検索されたユーザ一覧の例を示す図である。図２０に示されるように、検索されたユーザ一覧には、ユーザ毎に社員ＩＤ、名前、所属、メールアドレス及び電話番号等が含まれている。

ステップＳ２０７に続いてステップＳ２０８に進み、パスワード・指紋マージディレクトリプロバイダ１６ａは、取得条件を参照し、追加プロバイダに対する検索が要求されているかを判断する。例えば、取得条件において、追加プロバイダに対する検索が不要とされている場合（すなわち、プライマリプロバイダのみが検索対象となっている場合）は、パスワード・指紋マージディレクトリプロバイダ１６ａは、プライマリプロバイダ（パスワードディレクトリプロバイダ１７ａ）より取得したユーザ一覧のみを、ディレクトリサービスサービスインタフェース部１３ａに対して出力する（Ｓ２０９）。当該ユーザ一覧は、ディレクトリサービスインタフェース部１３ａによって、クライアント３０に対して送信される（Ｓ２１０）。

一方、取得条件において、追加プロバイダに対する検索が不要とされていない場合は、ステップＳ２１１に進み、パスワード・指紋マージディレクトリプロバイダ１６ａは、追加プロバイダである指紋ディレクトリプロバイダ１８ａのユーザ一覧取得関数（queryUser）を呼び出すことにより、指紋ディレクトリプロバイダ１８ａに対してユーザ一覧の提供を要求する。なお、パスワード・指紋マージディレクトリプロバイダ１６ａは、指紋ディレクトリプロバイダ１８ａが追加プロバイダであること、及び指紋ディレクトリプロバイダ１８ａを呼び出すための手順等については、追加プロバイダ管理テーブル１９３及び認証プロバイダ管理テーブル１９１等を参照して判断する。

ステップＳ２１１に続いてステップＳ２１２に進み、指紋ディレクトリプロバイダ１８ａは、ユーザ一覧取得関数の引数に指定された取得条件に合致するユーザ情報を指紋ＤＢ１８２より検索し、検索されたユーザ情報の一覧（ユーザ一覧）をパスワード・指紋マージディレクトリプロバイダ１６ａに出力する（Ｓ２１３）。

図２１は、指紋ＤＢより検索されたユーザ一覧の例を示す図である。図２１に示されるように、検索されたユーザ一覧には、ユーザ毎に社員ＩＤ、指紋特徴データ及び指紋特徴データの登録年月日等が含まれている。ここで、社員ＩＤは、各ユーザを一意に識別するための情報である。すなわち、外部認証におけるユーザ情報と指紋ＤＢ１８２におけるユーザ情報とは、社員ＩＤによって予め対応づけられているということができる。

指紋ＤＢ１８２より検索されるユーザ一覧は、外部認証サーバ４０と指紋ＤＢ１８２とにおいてエントリされているユーザが同じ場合には、パスワードディレクトリプロバイダ１７ａより検索されたユーザ一覧と同一ユーザに係るものである。但し、外部認証サーバ４０と指紋ＤＢ１８２とにおいては、管理されている情報が異なるのが一般的である。したがって、ステップＳ２１３において、パスワード・指紋マージディレクトリプロバイダ１６ａは、同一ユーザについて、パスワードディレクトリプロバイダ１７ａからは得られなかった情報（例えば、指紋特徴データや、指紋特徴データが登録された年月日等）を、指紋ディレクトリプロバイダ１８ａから取得したことになる。

ステップＳ２１３に続いてステップＳ２１４に進み、パスワード・指紋マージディレクトリプロバイダ１６ａは、プライマリプロバイダ（パスワードディレクトリプロバイダ１７ａ）より取得したユーザ一覧と、追加プロバイダ（指紋ディレクトリプロバイダ１８ａ）より取得したユーザ一覧とを、社員ＩＤに基づいて各ユーザの同一性を判別してマージする（以下、マージされたユーザ一覧を「マージユーザ一覧」という。）。

図２２は、マージユーザ一覧の例を示す図である。図２２のマージユーザ一覧においては、プライマリプロバイダと追加プロバイダより取得された情報がユーザごとにマージされている。このように、単に、二つの情報を縦方向に連結するのではなく、ユーザごとにマージすることで、マージユーザ一覧を受け取った側（クライアント３０）においてマージ一覧の取り扱いを容易にすることができる。

ステップＳ２１４に続いてステップＳ２１５に進み、パスワード・指紋マージディレクトリプロバイダ１６ａがマージユーザ一覧をディレクトリサービスインタフェース部１３ａに対して出力すると、ディレクトリサービスインタフェース部１３ａは、マージユーザ情報をクライアント３０に送信する（Ｓ２１６）。

以上によって、クライアント３０は、マージユーザ情報を取得したことになる。ここでマージユーザ情報は、外部認証サーバ４０及び指紋ＤＢ１８２においてそれぞれ独立して管理されているユーザ情報が統合的に提供されたものであるため、いずれか一方より取得されたユーザ情報に比べより豊富な情報が含まれている。また、マージユーザ情報は、外部認証サーバ４０においてのみ管理されているユーザのユーザ情報及び指紋ＤＢ１８２においてのみ管理されているユーザのユーザ情報も含み得るため、クライアント３０は、取得条件に合致するより多くのユーザに関しての情報を取得することができる。

なお、上記においては、認証サーバ１０が汎用的なコンピュータによって実現された例について説明したが、認証サーバ１０を特定の用途に特化した機器、例えば、プリンタ等の画像処理装置等によって実現してもよい。近年の画像処理装置には、融合機、又は複合機と呼ばれる、プリンタ、コピー、又はファクシミリ等の複合サービスに固有の処理を行う複数のアプリケーションを有し、コンピュータと同等の情報処理を実行することができるものが存在する。したがって、このような融合機を用いて、本実施の形態における認証サーバ１０を実現しても本発明の効果を同様に得ることができる。

図２３は、本発明による融合機の一実施例の構成図を示す。融合機１０００は、白黒ラインプリンタ１０１５と、カラーラインプリンタ１０１６と、スキャナやファクシミリなどのハードウェアリソース１０１７と、ソフトウェア群１０２０と、融合機起動部１０５０とを有するように構成される。また、ソフトウェア群１０２０はアプリケーション１０３０とプラットフォーム１０４０とを有するように構成される。

プラットフォーム１０４０は、アプリケーション１０３０からの処理要求を解釈してハードウェア資源の獲得要求を発生するコントロールサービスと、１つ以上のハードウェア資源の管理を行ってコントロールサービスからの獲得要求を調停するシステムリソースマネージャ（以下、ＳＲＭという）１０４３と、オペレーティングシステム（以下、ＯＳという）１０４１とを有するように構成されている。

コントロールサービスは、システムコントロールサービス（以下、ＳＣＳという）１０４２、エンジンコントロールサービス（以下、ＥＣＳという）１０４４、メモリコントロールサービス（以下、ＭＣＳという）１０４５、オペレーションパネルコントロールサービス（以下、ＯＣＳという）１０４６、ファックスコントロールサービス（以下、ＦＣＳという）１０４７、ネットワークコントロールサービス（以下、ＮＣＳという）１０４８、ユーザ情報管理サービス（以下、ＵＣＳという）１０４９など一つ以上のサービスモジュールを有するように構成されている。

なお、プラットフォーム１０４０は予め定義されている関数によりアプリケーション１０３０からの処理要求を受信可能とするアプリケーションプログラムインタフェース（以下、ＡＰＩという）を有するように構成されている。

ＯＳ１０４１は、ユニックス（ＵＮＩＸ（登録商標））などのオペレーティングシステムであって、プラットフォーム１０４０及びアプリケーション１０３０の各ソフトウェアをプロセスとして並列実行する。

ＳＲＭ１０４３のプロセスは、ＳＣＳ１０４２と共にシステムの制御及びリソースの管理を行うものである。例えばＳＲＭ１０４３のプロセスは、スキャナ部やプリンタ部などのエンジン、メモリ、ハードディスク装置（ＨＤＤ）ファイル、ホストＩ／Ｏ（セントロインタフェース、ネットワークインタフェース、ＩＥＥＥ１０１３９４インタフェース、ＲＳ２１０３２Ｃインタフェースなど）のハードウェア資源を利用する上位層からの要求に従って調停を行い、実行制御する。

例えば、ＳＲＭ１０４３は、要求されたハードウェア資源が利用可能であるか（他の要求により利用されていないかどうか）を判定し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に通知する。また、ＳＲＭ１０４３は、上位層からの要求に対してハードウェア資源の利用スケジューリングを行い、例えばプリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成などの要求内容を直接実施している。

ＳＣＳ１０４２のプロセスは、アプリケーション管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、割り込みアプリケーション制御を行う。ＥＣＳ１０４４のプロセスは、白黒ラインプリンタ１０１５、カラーラインプリンタ１０１６、ハードウェアリソース１０１７のエンジンの制御を行う。

ＭＣＳ１０４５のプロセスは、画像メモリの取得及び解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮及び伸張などを行う。ＯＣＳ１０４６のプロセスは、オペレータと本体制御との間の情報伝達手段となるオペレーションパネルの制御を行う。

ＦＣＳ１０４７のプロセスは、システムコントローラの各アプリケーション層からＰＳＴＮまたはＩＳＤＮ網を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読み取り、ファクシミリ受信印刷、融合送受信を行うためのアプリケーションを提供する。

ＮＣＳ１０４８のプロセスは、ネットワークＩ／Ｏを必要とするアプリケーションに対し、共通に利用できるサービスを提供するものであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。

ＵＣＳ１０４９のプロセスは、ユーザ情報及び／又はユーザの所属するグループ情報の管理を行うものであり、要求に応じたユーザ情報及び／又はユーザの所属するグループ情報が格納されている記憶装置及び／又はネットワークを介して接続された他の装置を判定し、判定した記憶装置及び／又はネットワークを介して接続された他の装置からユーザ情報及び／又はユーザの所属するグループ情報を取得して各アプリケーションに供給する。

また、ＵＣＳ１０４９のプロセスは、ユーザ情報及び／又はユーザの所属するグループ情報の管理を行うとともに、ユーザの認証を行うようにしてもよい。

上述した各種認証プロバイダ（例えば、パスワード・指紋マージプロバイダ、パスワード認証プロバイダ、指紋認証プロバイダ等）は、ＵＣＳ１０４９に実装される。

また、アプリケーション１０３０は、プリンタ、コピー、ファクシミリ、スキャナなどの画像形成処理にかかるユーザサービスにそれぞれ固有の処理を行うものである。アプリケーション１０３０は、ページ記述言語（ＰＤＬ、ＰＣＬ）及びポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ１０３１と、コピー用アプリケーションであるコピーアプリ１０３２と、ファクシミリ用アプリケーションであるファックスアプリ１０３３と、スキャナ用アプリケーションであるスキャナアプリ１０３４とを有している。

融合機起動部１０５０は、融合機１０００の電源投入時に最初に実行され、アプリケーション１０３０やプラットフォーム１０４０を起動するものである。例えば融合機起動部１０５０は、コントロールサービスやアプリケーションのプログラムを後述するフラッシュメモリから読み出し、読み出した各プログラムをＳＲＡＭまたはＳＤＲＡＭ上に確保したメモリ領域に転送して起動するものである。

図２４は、本発明による融合機の一実施例のハードウェア構成図を示す。図２４の融合機１０００は、コントローラボード１０６０と、オペレーションパネル１０７０と、ファックスコントロールユニット（以下、ＦＣＵという）１０８０と、ＵＳＢデバイス１０９０と、ＩＥＥＥ１０１３９４デバイス１１００と、エンジン部１１１０とを有するように構成される。

オペレーションパネル１０７０は、コントローラボード１０６０のＡＳＩＣ１０６２に直接接続されている。また、ＦＣＵ１０８０、ＵＳＢデバイス１０９０、ＩＥＥＥ１０１３９４デバイス１１００及びエンジン部１１１０は、コントローラボード１０６０のＡＳＩＣ１０６２にＰＣＩバス（Peripheral Component Interconnect bus）などで接続されている。

また、コントローラボード１０６０は、ＣＰＵ１０６１と、ＡＳＩＣ１０６２と、ＳＲＡＭ（Static RAM）１０６３と、ＳＤＲＡＭ（Synchronous DRAM）１０６４と、フラッシュメモリ１０６５と、ＨＤＤ１０６６とを有するように構成される。コントローラボード１０６０は、ＣＰＵ１０６１、ＳＲＡＭ１０６３、ＳＤＲＡＭ１０６４、フラッシュメモリ１０６５、ＨＤＤ１０６６などをＡＳＩＣ１０６２に接続するように構成されている。

ＣＰＵ１０６１は、融合機１０００の全体制御を行うものである。ＣＰＵ１０６１は、ＯＳ１０４１上でプラットフォーム１０４０を形成するＳＣＳ１０４２、ＳＲＭ１０４３、ＥＣＳ１０４４、ＭＣＳ１０４５、ＯＣＳ１０４６、ＦＣＳ１０４７及びＮＣＳ１０４８をそれぞれプロセスとして起動して実行させると共に、アプリケーション１０３０を形成するプリンタアプリ１０３１、コピーアプリ１０３２、ファックスアプリ１０３３及びスキャナアプリ１０３４等を起動して実行させる。

ＡＳＩＣ１０６２は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。ＳＲＡＭ１０６３及びＳＤＲＡＭ１０６４の物理メモリ領域には、カーネルやプロセスなどの仮想メモリ領域がマッピングされる。

以下、図２５から図２７を用いて、ＵＣＳ１０４９の構成例について説明する。図２５は、ＵＣＳの構成を説明するための図（その１）である。

図２５に示すように、ＵＣＳ１０４９は、マージプロバイダ１０１３と、１つ以上のサブプロバイダ１０１４とから構成される。マージプロバイダ１０１３は、本実施の形態におけるパスワード・指紋マージプロバイダ１６及び１６ａ等のマージプロバイダを抽象的に表現したものである。サブプロバイダ１０１４は、マージプロバイダによって連携される認証プロバイダ、すなわち、本実施の形態におけるパスワード認証プロバイダ１７及び指紋認証プロバイダ１８等を抽象的に表現したものである。したがって、サブプロバイダ１０１４のうちの一つはプライマリプロバイダということになる。

図２５に示される構成をとることによって、ＵＣＳ１０４９は、上述したように、サブプロバイダ１０１４が提供するユーザ情報及び／又はユーザの所属するグループ情報等をマージプロバイダ１０１３においてマージし、例えば、融合機１０００のアプリケーション１０３０などに、マージしたユーザ情報及び／又はユーザの所属するグループ情報等を提供することができる。

図２６は、ＵＣＳの構成を説明するための図（その２）である。図２６に示すように、ＵＣＳ１０４９は、サブプロバイダ１０１４を含まず、マージプロバイダ１０１３のみから構成される。図２６に示される構成をとることによって、例えば他の装置に実装されているサブプロバイダ１０１４が提供するユーザ情報及び／又はユーザの所属するグループ情報をマージプロバイダ１０１３においてマージし、例えば、融合機１０００のアプリケーション１０３０などに、マージしたユーザ情報及び／又はユーザの所属するグループ情報を提供することができる。

図２７は、ＵＣＳの構成を説明するための図（その３）である。図２７に示すように、ＵＣＳ１０４９は、マージプロバイダ１０１３を含まず、少なくとも１つ以上のサブプロバイダ１０１４から構成される。図２７に示される構成をとることによって、例えば他の装置に実装されているマージプロバイダ１０１３からの要求に応じてユーザ情報及び／又はユーザの所属するグループ情報を提供することができる。

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

第一の実施の形態における認証システムの構成例を示す図である。 マージ情報管理ＤＢを構成する認証プロバイダ管理テーブルの構成例を示す図である。 マージ情報管理ＤＢを構成するマージプロバイダ管理テーブルの構成例を示す図である。 マージ情報管理ＤＢを構成する追加プロバイダ管理テーブルの構成例を示す図である。 マージ情報管理ＤＢを構成する認証プロバイダマージテーブルの構成例を示す図である。 外部認証サーバにおけるユーザ管理テーブルの構成例を示す図である。 指紋ＤＢを構成する指紋特徴データ管理テーブルの構成例を示す図である。 本発明の実施の形態における認証サーバのハードウェア構成例を示す図である。 プライマリ認証の際の認証サーバの処理を説明するためのシーケンス図である。 通常のチケットのデータ構造の例を示す図である。 マージチケットのデータ構造の例を示す図である。 追加認証の際の認証サーバの処理を説明するためのシーケンス図である。 追加認証の際の認証サーバの処理を説明するためのシーケンス図である。 チケットの第一の利用方法を説明するためのシーケンス図である。 マージ認証情報データの構成例を示す図である。 チケットの第二の利用方法を説明するためのシーケンス図である。 内部アプリケーションに認証機能を提供する場合の認証サーバの機能構成例を示す図である。 第二の実施の形態における認証システムの構成例を示す図である。 ユーザ情報の提供が要求された際の認証サーバの処理を説明するためのシーケンス図である。 外部認証サーバより検索されたユーザ一覧の例を示す図である。 指紋ＤＢより検索されたユーザ一覧の例を示す図である。 マージユーザ一覧の例を示す図である。 本発明による融合機の一実施例の構成図である。 本発明による融合機の一実施例のハードウェア構成図である。 ＵＣＳの構成を説明するための図（その１）である。 ＵＣＳの構成を説明するための図（その２）である。 ＵＣＳの構成を説明するための図（その３）である。

符号の説明

１、２ 認証システム
１０ 認証サーバ
１１ 認証サービスモジュール
１２、１２ａ ＳＯＡＰスタブ
１３ プロバイダ呼び分け手段
１３ａ ディレクトリサービスインタフェース部
１４、１４ａ 認証プロバイダＡ
１５、１５ａ 認証プロバイダＢ
１６、１６ａ パスワード・指紋マージプロバイダ
１７、１７ａ パスワード認証プロバイダ
１８、１８ａ 指紋認証プロバイダ
１９ マージ情報管理ＤＢ
２０ 端末
２２ ＳＯＡＰプロキシ
２３ クライアントアプリケーション
２４ 指紋読み取り装置ドライバ
２５ 指紋読み取り装置
４０ 外部認証サーバ
１００ ドライブ装置
１０１ 記憶媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ 演算処理装置
１０５ インタフェース装置
１８１ 指紋認証ライブラリ
１８２ 指紋ＤＢ
１０００ 融合機
１０１３ マージプロバイダ
１０１４ サブプロバイダ
１０１５ 白黒ラインプリンタ
１０１６ カラーラインプリンタ
１０１７ ハードウェアリソース
１０２０ ソフトウェア群
１０３０ アプリケーション
１０３１ プリンタアプリ
１０３２ コピーアプリ
１０３３ ファックスアプリ
１０３４ スキャナアプリ
１０４０ プラットフォーム
１０４１ オペレーティングシステム（ＯＳ）
１０４２ システムコントロールサービス（ＳＣＳ）
１０４３ システムリソースマネージャ（ＳＲＭ）
１０４４ エンジンコントロールサービス（ＥＣＳ）
１０４５ メモリコントロールサービス（ＭＣＳ）
１０４６ オペレーションパネルコントロールサービス（ＯＣＳ）
１０４７ ファックスコントロールサービス（ＦＣＳ）
１０４８ ネットワークコントロールサービス（ＮＣＳ）
１０４９ ユーザ情報管理サービス（ＵＣＳ）
１０５０ 融合機起動部
１０６０ コントローラボード
１０６１ ＣＰＵ
１０６２ ＡＳＩＣ（Application Specific Integrated Circuit）
１０６３ ＳＲＡＭ（Static RAM）
１０６４ ＳＤＲＡＭ（Synchronous DRAM）
１０６５ フラッシュメモリ
１０６６ ハードディスク装置（ＨＤＤ）
１０７０ オペレーションパネル
１０８０ ファックスコントロールユニット（ＦＣＵ）
１０９０ ＵＳＢデバイス
１１００ ＩＥＥＥ１３９４デバイス
１１１０ エンジン部
Ｂ バス

Claims (32)

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. 前記連携手段は、前記マージチケットの解読要求に応じ、前記マージチケットに統合されている前記第一のチケットについては前記第一の認証手段に解読させ、前記マージチケットに統合されている前記第二のチケットについては前記第二の認証手段に解読させることを特徴とする請求項１９乃至２４いずれか一項記載のユーザ認証装置。
26. 前記連携手段の機能は、ＳＯＡＰのＲＰＣによって呼び出すことが可能なことを特徴とする請求項１２乃至２５いずれか一項記載のユーザ認証装置。
27. ユーザの認証を行う認証手段を連携させるユーザ認証装置におけるユーザ認証方法であって、
    ユーザに関する第一の認証要求に応じ、該第一の認証要求において指定された第一のユーザ識別情報に基づく認証を第一の認証手段に行わせる第一の認証手順と、
    前記第一の認証手段に認証されているユーザに関する第二の認証要求に応じ、前記第一のユーザ識別情報に予め対応づけられている第二のユーザ識別情報に基づく認証を第二の認証手段に行わせる第二の認証手順とを有することを特徴とするユーザ認証方法。
28. 前記第二の認証手順は、前記第一のユーザ識別情報に基づいて前記第一のユーザ識別情報と前記第二のユーザ識別情報とを対応づけて管理するユーザ識別情報対応管理手段より前記第二のユーザ識別情報を検索することを特徴とする請求項２７記載のユーザ認証方法。
29. 前記第一の認証手順は、複数の前記認証手段の中から前記第一の認証手段を識別する情報を管理する第一の認証手段識別情報管理手段に基づいて前記第一の認証手段を識別し、
    前記第二の認証手順は、複数の前記認証手段の中から前記第二の認証手段を識別する情報を管理する第二の認証手段識別情報管理手段に基づいて前記第二の認証手段を識別することを特徴とする請求項２７又は２８記載のユーザ認証方法。
30. 前記第一及び第二の認証手順は、前記認証手段の呼び出し情報が登録された呼び出し情報管理手段に基づいて、前記第一又は第二の認証手段を呼び出すことにより、該認証手段に前記ユーザを認証させることを特徴とする請求項２７乃至２９いずれか一項記載のユーザ認証方法。
31. ユーザの認証を行う認証手段を連携させるユーザ認証装置に、
    ユーザに関する第一の認証要求に応じ、該第一の認証要求において指定された第一のユーザ識別情報に基づく認証を第一の認証手段に行わせる第一の認証手順と、
    前記第一の認証手段に認証されているユーザに関する第二の認証要求に応じ、前記第一のユーザ識別情報に予め対応づけられている第二のユーザ識別情報に基づく認証を第二の認証手段に行わせる第二の認証手順とを実行させるためのユーザ認証プログラム。
32. 請求項３１記載のユーザ認証プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images