JP2005157571A - 情報処理装置、機器、情報処理システム、認証プログラム及び記録媒体 - Google Patents

Abstract

【課題】 機器に接続できない認証デバイスを用いて前記機器のユーザの認証を可能とする情報処理装置、機器、情報処理システム、認証プログラム及び記録媒体の提供を目的とする。
【解決手段】 認証デバイスを接続可能な情報処理装置であって、ネットワークを介して接続している機器からの要求に応じ、前記認証デバイスを制御する認証デバイス制御手段を有することにより上記課題を解決する。
【選択図】 図４

Description

本発明は、情報処理装置、機器、情報処理システム、認証プログラム及び記録媒体に関し、特にユーザの認証を行うための情報処理装置、機器、情報処理システム、認証プログラム及び記録媒体に関する。

情報システムのセキュリティにおいて、ユーザ認証は極めて重要な機能になっている。最近ではスマートカード、ＵＳＢトークンなどの所有物認証デバイスや、指紋認証デバイス、虹彩認証デバイス、顔面認証デバイスなど、様々な生体認証デバイスも普及し始めている。

これらの認証デバイスは、一般ユーザが利用するクライアントＰＣ（Personal Computer）用に設計されており、クライアントＰＣに標準的に搭載されているインタフェース、例えば、ＲＳ−２３２Ｃのシリアルインタフェースや、ＰＳ／２マウスポート、ＵＳＢインタフェース、ＰＣＭＣＩＡカードインタフェースなどに接続するようになっているのが一般である。また、認証デバイスを駆動するためのドライバソフトについても、クライアントＰＣのＯＳとしてデファクトスタンダードとなっているＷｉｎｄｏｗｓ（登録商標）用のものしか提供されていないものがほとんどである。
一方で、最近では、コピー機、ファクス、プリンタ、スキャナ、デジタル複合機などのいわゆる周辺機器でもセキュリティ確保のためのユーザ認証機能が求められるようになってきている。例えば、デジタル複合機では、電子文書を内部ＨＤＤに保管することが可能であるが、かかる電子文書を正当なユーザにだけ印刷可能とする機能がある。また、プリンタで機密文書を印刷する際に印刷者本人であることを確認してから紙を出力するといった機能がある。

かかる機能において、上述した様々な認証デバイスを利用することができれば、より高度なセキュリティの確保が期待できる。

なお、特許文献１には、バイトメトリクス認証デバイスと、それを利用する装置との間で認証データを安全にやり取りする発明が開示されている。しかし当該発明は、バイオメトリクス認証デバイス以外の認証デバイスへの対応は考慮されていない。
特開２０００−２７６４４５号公報

しかしながら、周辺機器には一般のクライアントＰＣが備えているような標準インタフェースがハードウェアとして搭載されていないケースが圧倒的に多い。従って、認証デバイスを接続するにしてもインタフェースコンバータのようなものを必要とするか，又は結局のところ接続できないという問題がある。

また、接続できたとしても、周辺機器の内部では独自のＯＳや、ＵＮＩＸ（登録商標）ベースのＯＳ等が稼動していることが一般的である。したがって、Ｗｉｎｄｏｗｓ（登録商標）用のドライバソフトをそのままで周辺機器の内部で稼動させることは不可能であり、やはり認証デバイスは利用することができない。

ハードウェアとしてインタフェースが用意されていないのは周辺機器特有の問題であるが、対応するドライバソフトがないのはＷｉｎｄｏｗｓ（登録商標）以外のＯＳが稼動している機器一般に共通する問題である。

本発明は、上記の点に鑑みてなされたものであって、機器に接続できない認証デバイスを用いて前記機器のユーザの認証を可能とする情報処理装置、機器、情報処理システム、認証プログラム及び記録媒体の提供を目的とする。

そこで上記課題を解決するため、本発明は、請求項１に記載されるように、認証デバイスを接続可能な情報処理装置であって、ネットワークを介して接続している機器からの要求に応じ、前記認証デバイスを制御する認証デバイス制御手段を有することを特徴とする。

このような情報処理装置では、機器と認証デバイスとの仲介役を果たすことができる。したがって、機器に接続できない認証デバイスであっても、当該機器のユーザの認証に当該認証デバイスを利用することができる。

また、上記課題を解決するため、本発明は、認証デバイスの接続された情報処理装置とネットワークを介して接続している機器であって、前記認証デバイスに入力された情報に基づく当該機器のユーザの認証の要求を前記情報処理装置に送信し、前記情報処理装置より返信される該認証の結果を示す情報に基づいて、前記ユーザに対する当該機器の所定の機能の提供の可否を判断するユーザ確認手段を有することを特徴とする。

このような機器では、ネットワークを介して接続している情報処理装置を介して認証デバイスを利用することができる。したがって、当該認証デバイスを用いて認証されたユーザにのみ機器の機能を提供することができる。

また、上記課題を解決するため、本発明は、上記情報処理装置と上記機器とを有する情報処理システム、前記情報処理装置に実行させるための認証プログラム、又は前記認証プログラムを記録した記録媒体としてもよい。

本発明によれば、機器に接続できない認証デバイスを用いて前記機器のユーザの認証を可能とする情報処理装置、機器、情報処理システム、認証プログラム及び記録媒体の提供を目的とする。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における認証システムの構成例を示す図である。図１に示されるように認証システム１は、ＬＡＮ等のネットワーク４０によって接続されたデバイスアダブタ１０及び周辺機器４０と、デバイスアダプタ１０に接続された認証デバイス２０とによって構成されている。

デバイスアダプタ１０は、認証デバイス２０のドライバソフトが稼動可能なＷｉｎｄｏｗｓ（登録商標）等のＯＳがインストールされたＰＣ（Personal Computer）等のコンピュータである。

認証デバイス２０は、ユーザが認証情報を入力するための装置であり、例えば、スマートカード、ＵＳＢトークンなどの所有物認証デバイスや、指紋認証デバイス、虹彩認証デバイス、顔面認証デバイス等、様々な認証デバイスが該当する。認証デバイス２０は、ＲＳ−２３２Ｃのシリアルインタフェースや、ＰＳ／２マウスポート、ＵＳＢインタフェース、ＰＣＭＣＩＡカードインタフェース等、デバイスアダプタ１０に標準に搭載されているインタフェースを介してデバイスアダプタ１０と接続されている。

周辺機器２０は、コピー機、ファクス、プリンタ、スキャナ、又はデジタル複合機等のいわゆる周辺機器である。なお、近年の周辺機器は、直接ネットワークに接続できる機能を有しているのが一般的であるため、ネットワークによる通信のための特別なソフトウェアは必要としない。

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

デバイスアダプタ１０での処理を実現する認証プログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。認証プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、認証プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。

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

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

図３は、第一の実施の形態における認証システムの機能構成例を示す図である。図３に示されるように、デバイスアダプタ１０は、ドライバプログラム１１、スケルトンプログラム１２及びＯＲＢサーバプログラム１３等より構成されている。

ドライバプログラム１１は、認証デバイス２０を制御するためのいわゆるデバイスドライバである。スケルトンプログラム１２は、ドライバプログラム１１のインタフェース関数を透過的に提供するためのサーバ側のモジュールである。ＯＲＢサーバプログラム１３は、ＣＯＲＢＡ（Common Object Request Broker Architecture）環境を実現するためのサーバ機能が実装されているプログラムである。

一方、周辺機器２０は、アプリケーションプログラム３１、プロクシプログラム３２、及びＯＲＢクライアントプログラム３３等より構成されている。

アプリケーションプログラム３１は、ユーザに対して周辺機器の機能を提供するためのプログラムである。但し、アプリケーションプログラム３１は、認証されたユーザにのみそのサービスを提供する。

プロクシプログラム３２は、アプリケーションプログラム３１に対してドライバプログラム１１のインタフェース関数を透過的に提供するためのモジュールである。

ＯＲＢクライアントプログラム３３は、ＣＯＲＢＡ環境を実現するためのクライアント用のモジュールである。

このように、図３においてはＣＯＲＢＡによる分散オブジェクト環境が実現されている。従って、アプリケーションプログラム３１は、プロクシプログラム３２、ＯＲＢクライアントプログラム３３、ＯＲＢサーバプログラム１３及びスケルトンプログラム１２を介してドライバプログラム１１のインタフェース関数（例えば、ｏｐｅｎ＿ｄｅｖｉｃｅ（））を遠隔手続き呼び出し（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ：ＲＰＣ）によって透過的に呼び出すことができ、あたかも周辺機器に認証デバイス２０が直接接続されているかのように認証デバイス２０を利用することができる。

特に、ＣＯＲＢＡで利用するプロトコルであるＩＩＯＰはプロットフォームから中立であるため、異なるＯＳが稼動しているデバイスアダプタ１０と周辺機器２０との通信に有効である。また、ＳＯＡＰ（Simple Object Access Protocol）を用いても同様の効果を得ることができる。

ところで、第一の実施の形態においては、デバイスアダプタ１０と周辺機器３０との間をネットワーク４０によって接続するため、ネットワーク４０に接続されている他の機器によって、デバイスアダプタ１０と周辺機器３０との間に流れるデータを盗聴、改ざんされる可能性がある。ユーザ認証の際に秘密のデータや重要なデータをやり取りすることもあるため、これは防がなければならない。

また、周辺機器３０から見れば物理的に「隣」に設置されているデバイスアダプタ１０を利用しなければならないが、複数のデバイスアダプタ１０がネットワーク４０上にある場合、実は物理的に遠くにある認証デバイスを間違えて使う可能性もある。更に、故意に違う認証デバイスを使わせることで他人に成りすますことが可能になるかもしれない。そのような成りすましを防がなければならない。

また、第一の実施の形態によれば、周辺機器３０には認証デバイスごとに異なるドライバソフトのインタフェース関数（図３の場合、ｏｐｅｎ＿ｄｅｖｉｃｅ（））を使って認証デバイスごとに異なる呼び出し手順でアプリケーションプログラムを開発があるが、周辺機器において稼動するプログラムの開発は、当該周辺機器内部に関する高度な専門知識を必要とするため、一般的に開発工数がかかる。

そこで、これらの課題を解決した例として、第二の実施の形態を次に説明する。

図４は、第二の実施の形態における認証システムの機能構成例を示す図である。図４中、図３と同一部分には同一符号を付し、その説明は省略する。図４を図３と比較すると、図４の周辺機器３０とデバイスアダプタ１０には、ＳＳＬモジュール３４、ＳＳＬモジュール１５がそれぞれ追加されている。

ＳＳＬモジュール３４及びＳＳＬモジュール１５は、ＳＳＬ（Secure Sockets Layer）による通信を実現するためのモジュールである。ＳＳＬモジュール３４及びＳＳＬモジュール１５を介して通信を行うことで、ＩＩＯＰやＳＯＡＰによる通信を相互認証モードを用いたトランスポート層の上で行うことができる。したがって、遠隔手続き呼び出しを暗号化することが出来ると共に、周辺機器３０とデバイスアダプタ１０との間でやりとりされるデータの改ざんを検知することができ、悪意のあるユーザによる成りすまし等を防止することができる。なお、ＳＳＬモジュール３４及びＳＳＬモジュール１５は、ＯｐｅｎＳＳＬ（ｈｔｔｐ／／ｗｗｗ．ｏｐｅｎｓｓｌ．ｏｒｇ）のライブラリモジュールを組み込むことで実現することができる。

デバイスアダプタ１０には、更に、ユーザ認証プログラム１４が追加されている。ユーザ認証プログラム１４は、認証デバイスごとに異なるドライバプログラム１１のインタフェース関数の差違を吸収し、各種のドライバプログラム１１の間で共通化されたインタフェース関数を提供するためのモジュールである。

共通化されたインタフェース関数（以下、「共通インタフェース関数」という。）のインタフェース仕様は、共通インタフェース関数において以下の機能が実現できるように定めるとよい。
（１）ユーザを認証する機能。
（２）ユーザ認証を行った結果としてユーザの情報を取得し提供する機能。
（３）ユーザに成り代わってアクセスするためのユーザの認証データ（電子署名）を取得し提供する機能。

そこで、本実施の形態においては、共通インタフェース関数のインタフェース仕様を図５のように定めることとする。図５は、本発明の実施の形態における共通インタフェース関数のインタフェース仕様を示す図である。

図５において、符号１４１ａに示される領域に、インタフェース仕様が示されている。これより、共通インタフェース関数の関数名は「ａｕｔｈｅｎｔｉｃａｔｅ」であり、Ｓｔｒｉｎｇ（文字列）型の引数ｉｎＳｔｒｉｎｇをとり、ＡｕｔｈＲｅｓｕｌｔ型の戻り値を返却することが分かる。

ｉｎＳｔｒｉｎｇは、ユーザによって周辺機器３０のオペレーションパネルを介して入力される暗証番号等が入力情報として指定される引数である。

ＡｕｔｈＲｅｓｕｌｔ型は、ｏｕｔＳｔｒｉｎｇ、ｆａｉｌｕｒｅ及びｕｓｅｒＩｎｆｏの３つのメンバ変数を有する構造体である（符号１４１ｂ参照）。ｏｕｔＳｔｒｉｎｇは、処理結果を表現するメッセージ文字列が格納される変数である。ｆａｉｌｕｒｅは、ユーザ認証の成否を示す真偽値が格納される変数である。ｕｓｅｒＩｎｆｏは、ユーザ認証の結果取得されたユーザ情報等が格納されるＵｓｅｒＩｎｆｏ型の変数である。

ＵｓｅｒＩｎｆｏ型は、ｕｓｅｒＩｄ、ｕｓｅｒＮａｍｅ、ｇｒｏｕｐｓ及びｃｅｒｔｉｆｉｃａｔｅ等の４つのメンバ変数を有する構造体である（符号１４１ｃ参照）。ｕｓｅｒＩｄは、認証されたユーザのユーザＩＤが格納される変数である。ｕｓｅｒＮａｍｅは、認証されたユーザのユーザ名が格納される変数である。ｇｒｏｕｐｓは、認証されたユーザの所属グループ名のリスト（所属グループリスト）が格納される変数である。ｃｅｒｔｉｆｉｃａｔｅは、ユーザＩＤ、ユーザ名、所属グループリストに対する電子署名（又はメッセージ認証子）が格納される変数である。なお、当該電子署名は、ユーザが認証された際に、ユーザ認証プログラム１４の有する秘密鍵によって生成される。

上記のような共通インタフェース関数が、スケルトンプログラム１２及びＯＲＢサーバプログラム１３を介してネットワーク４０上に公開されることにより、アプリケーションプログラム３１は、プロクシプログラム３２及びＯＲＢクライアントプログラム３３等を介して共通インタフェース関数を透過的に呼び出すことが可能となる。ここで、共通インタフェース関数はｏｐｅｎ＿ｄｅｖｉｄｅ（）のように認証デバイスに依存したインタフェースでないため、仮に、デバイスアダプタ１０に接続される認証デバイスが認証デバイス２０と異なるものとなっても、アプリケーションプログラム３１の実施にはなんら影響を及ぼさない。

図６は、異なる認証デバイスをデバイスアダプタに接続した場合の認証システムの機能構成例を示す図である。図６中、図４と同一部分には同一符号を付し、その説明は省略する。

図６を図４と比較すると、図６の認証デバイスを示す符号は図４における認証デバイスの符号（２０）に「ａ」が付加されたものとなっている。これは、両者が異なる認証デバイスであることを示す意図である。認証デバイスが異なることによって、ドライバプログラム１１ａも必然的に図４におけるものと異なっている。例えば、ドライバプログラム１１ａは、「ｖｅｒｉｆｙ＿ｐｉｎ（）」といったインタフェース関数でその機能を提供するものであるとする。

また、ドライバプログラム１１ａのインタフェース関数が異なることに伴って、ユーザ認証プログラム１４ａも図４におけるものと異なっている。但し、ドライバプログラムにおけるインタフェース関数の差違は、ユーザ認証プログラム１４ａによって吸収されている。すなわち、ユーザ認証プログラム１４ａは、ユーザ認証プログラム１４（図４）と全く同一の共通インタフェース関数（ａｕｔｈｅｎｔｉｃａｔｅ（））によってその機能を提供するものである。

したがって、それ以外のモジュールについては、図４のものと全く同一のものを利用することができる。すなわち、アプリケーションプログラム３１の実装は、認証デバイスに全く依存しないものとすることができる。

なお、図６のユーザ認証プログラム１４ａは、ＬＤＡＰ（Lightweight Directory Access Protocol ）サーバ５０にユーザ情報を問い合わせるようになっている。これは、認証デバイスを変更したことに基づく必然的な相違ではなく、ユーザ情報の管理について単なるバリエーションを示したものである。すなわち、図４におけるユーザ認証プログラム１４は、自らユーザ情報データベースを有している場合の例を示し、図６のユーザ認証プログラム１４ａは、ユーザ情報データベースは有しておらず、ユーザ情報はＬＤＡＰサーバ５０に問い合わせる場合の例を示したものである。したがって、ユーザ認証プログラム１４ａがユーザ認証プログラム１４と同様にユーザ情報データベースを有するようにしてもよいし、ユーザ認証プログラム１４がＬＤＡＰサーバ５０にユーザ情報を問い合わせるようにしてもよい。

以下、図６に基づいて、ユーザ認証プログラム１４ａ及びアプリケーションプログラム３１の処理手順について説明する。

図７は、ユーザ認証プログラムにおける共通インタフェース関数の処理を説明するための図である。

共通インタフェース関数が呼び出されると、ユーザ認証プログラム１４ａは、ドライバプログラム１１ａを用いて認証デバイス２０ａ（ここでは、カードリーダであるとする。）にスマートカード等のカードが挿入されているか否かを確認する（Ｓ１０１）。

認証デバイス２０ａにカードが挿入されていない場合は、エラー処理を実行して処理を終了する。すなわち、ＡｕｔｈＲｅｓｕｌｔ型の戻り値のｏｕｔＳｔｒｉｎｇに「カードを挿入してください」という文字列を代入（Ｓ１０２ａ）し、ｆａｉｌｕｒｅにｆａｌｓｅを代入する（Ｓ１０２ｂ）。更に、ｕｓｅｒＩｎｆｏを空にし（Ｓ１０２ｃ）、戻り値を返却する（Ｓ１０２ｄ）。

カードが挿入されている場合は、引数のｉｎＳｔｒｉｎｇにユーザのＰＩＮ（Ｐｅｒｓｏｎａｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ：暗証番号）が指定されているかどうかを確認する（Ｓ１０３）。なお、ｉｎＳｔｒｉｎｇに指定される暗証番号は、後述されるように、周辺機器３０のオペレーションパネルを介してユーザによって入力されたものが渡ってきたものである。

ｉｎＳｔｒｉｎｇにＰＩＮが指定されていない場合は、ｏｕｔＳｔｒｉｎｇに「暗証番号を入力してください」という文字列を代入し（Ｓ１０３ａ）、その他は上記（Ｓ１０２ｂ〜Ｓ１０２ｄ）と同様のエラー処理を実行して（Ｓ１０３ｂ〜Ｓ１０３ｄ）処理を終了する。

ｉｎＳｔｒｉｎｇにＰＩＮが指定されている場合は、ＰＩＮを引数に指定してドライバプログラム１１ａのｖｅｒｉｆｙ＿ｐｉｎ関数を呼び出すことにより、ドライバプログラム１１ａに対してＰＩＮの照合を要求する（Ｓ１０４）。

ｖｅｒｉｆｙ＿ｐｉｎ関数の返却情報に基づいてＰＩＮの照合の成否を判断し（Ｓ１０５）、照合に失敗した場合は、エラー処理を実行した後、処理を終了する。すなわち、ｏｕｔＳｔｉｎｇに「暗証番号の照合に失敗しました」という文字列を代入し（Ｓ１０５ａ）、ｆａｉｌｕｒｅにはｔｒｕｅを代入する（Ｓ１０５ｂ）。更に、ｕｓｅｒＩｎｆｏを空にし（Ｓ１０５ｃ）、戻り値を返却する（Ｓ１０５ｄ）。

ＰＩＮの照合に成功した場合は、ドライバプログラム１１ａを通してカードからアカウント名及びパスワードを読み出し（Ｓ１０６）、読み出したアカウント名及びパスワードをＬＤＡＰサーバ５０に送信することにより、アカウント名及びパスワードの照合を実行する（Ｓ１０７）。

ＬＤＡＰサーバ５０からの応答に基づいて照合の成否を判断し（Ｓ１０８）、照合に失敗した場合は、エラー処理を実行した後、処理を終了する。すなわち、ｏｕｔＳｔｉｎｇに「認証に失敗しました」という文字列を代入し（Ｓ１０５ａ）、その他は上記（Ｓ１０５ｂ〜Ｓ１０５ｄ）と同様のエラー処理を実行する（Ｓ１０８ｂ〜Ｓ１０８ｄ）。

アカウント名及びパスワードの照合が成功した場合は、ＬＤＡＰサーバ５０に問い合わせてユーザ情報（ユーザＩＤ、ユーザ名、所属グループのリスト）を取得し（Ｓ１０９）、認証プログラム１４ａの有する秘密鍵によってユーザ情報に対する電子署名を生成する（Ｓ１１０）。

生成した電子署名をｃｅｒｔｉｆｉｃａｔｅに代入し（Ｓ１１１）、更に、ユーザＩＤ、ユーザ名及び所属グループリストをそれぞれが対応するメンバ変数に代入した後（Ｓ１１２〜Ｓ１１４）、戻り値を返却して処理を終了する（Ｓ１１５）。

続いて、上述したユーザ認証プログラム１４ａの共通インタフェース関数をＲＰＣによって透過的に利用する周辺機器３０におけるアプリケーションプログラム３１の処理手順について説明する。

図８は、アプリケーションプログラムの処理を説明するための図である。ユーザが周辺機器３０においてアプリケーションプログラム３１の提供する機能を利用しようとするとアプリケーションプログラム３１が起動される（Ｓ２０１）。

アプリケーションプログラム３１は、引数ｉｎＳｔｒｉｎｇを空にしてプロクシプログラム３２のａｕｔｈｅｎｔｉｃａｔｅ関数を呼び出して、戻り値ＡｕｔｈＲｅｓｕｌｔを受け取る（Ｓ２０２）。なお、プロクシプログラム３２のａｕｈｅｎｔｅｉｃａｔｅ関数の呼び出しによって、ユーザ認証プログラム１４ａのａｕｔｅｎｔｉｃａｔｅ関数が透過的に呼び出される。

続いて、戻り値ＡｕｔｈＲｅｓｕｌｔに基づいて認証処理を終了すべきか否かを判断する（Ｓ２０３）。

認証処理を継続する必要があると判断した場合は、ｗｈｉｌｅ文内のル−プ処理を実行する。すなわち、まずＡｕｔｈＲｅｓｕｌｔのｏｕｔＳｔｒｉｎｇをオペレーションパネルに表示する（Ｓ２０４）。この処理が初めて実行される段階では、認証デバイス２０ａにカードが挿入されている場合は、「暗証番号を入力してください」というメッセージがオペレーションパネルに表示され（図７のステップＳ１０３ａ参照）、カードが挿入されていない場合は「カードを挿入してください」というメッセージがオペレーションパネルに表示されることになる（図７のＳ１０２ａ参照）。

オペレーションパネルを介してユーザからのＰＩＮの入力を受け付け（Ｓ２０５）、入力されたＰＩＮをｉｎＳｔｒｉｎｇに代入する（Ｓ２０６）。

ＰＩＮが代入されたｉｎＳｔｒｉｎｇを引数として再度、ａｕｔｈｅｎｔｉｃａｔｅ関数を呼び出し、戻り値ＡｕｔｈＲｅｓｕｌｔを受け取る（Ｓ２０７）。ＡｕｔｈＲｅｓｕｌｔのｆａｉｌｕｒｅの値を確認し（Ｓ２０８）、ｆａｉｌｕｒｅがｔｒｕｅの場合は（Ｓ２０９）、認証に失敗したものとしてｏｕｔＳｔｒｉｎｇの値をオペレーションパネルに表示し（Ｓ２０９ａ）、処理を終了する（Ｓ２０９ｂ）。

この場合は、ＰＩＮの照合に失敗した場合やユーザ情報の照合に失敗した場合が該当する（図７のＳ１０５ｂ及びＳ１０８ｂを参照）。したがって、「暗証番号の照合に失敗しました」又は「認証に失敗しました」というメッセージがオペレーションパネルに表示される。

ｆａｉｌｕｒｅがｆａｌｓｅの場合は、ＡｕｔｈＲｅｓｕｌｔのｕｓｅｒＩｎｆｏの値が格納されているか否かを判断する（Ｓ２１０）。ｕｓｅｒＩｎｆｏの値が格納されているということは、認証が成功したこということである（図７のＳ１１１〜Ｓ１１５参照）。したがって、この場合は認証は成功したものとしてループを抜け（Ｓ２１０ａ）、以降において、ＡｕｔｈＲｅｓｕｌｔに格納されたユーザ情報や電子署名等を用いてアクセス制御等を行う。

一方、ｕｓｅｒＩｎｆｏの値が格納されていないということは、カードが挿入されていないということである。したがって、ステップＳ２０４以降の処理を継続する。

上述したように、ｉｎＳｔｒｉｎｇとｏｕｔＳｔｒｉｎｇとを用いたインタラクティブなやり取りが可能なインタフェースを介することにより、複写機等の周辺機器におけるアプリケーションプログラムは、図８に示されるような汎用的なフローによってユーザ認証の処理を実現することができる。

なお、上述においては、認証装置２０ａがカードリーダである場合を例として説明したが、本実施の形態を若干修正することにより様々な認証デバイスに対応することが可能である。例えば、指紋認証デバイスを用いる場合には、デバイスより取得した特徴データを別の検証プログラムに渡すことによりユーザ認証を行うようにしてもよい。このような若干の差違は、認証デバイスの違いに応じて適宜必要となるが、認証プログラム１４ａにおいて、これらの差違が吸収され、周辺機器３０からは共通的なインタフェースによって認証デバイスを利用できるといった効果は同様に得ることができる。

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

本発明の実施の形態における認証システムの構成例を示す図である。 本発明の実施の形態におけるデバイスアダプタのハードウェア構成例を示す図である。 第一の実施の形態における認証システムの機能構成例を示す図である。 第二の実施の形態における認証システムの機能構成例を示す図である。 本発明の実施の形態における共通インタフェース関数のインタフェース仕様を示す図である。 異なる認証デバイスをデバイスアダプタに接続した場合の認証システムの機能構成例を示す図である。 ユーザ認証プログラムにおける共通インタフェース関数の処理を説明するための図である。 アプリケーションプログラムの処理手順を説明するための図である。

符号の説明

１ 認証システム
１０ デバイスアダプタ
１１、１１ａ ドライバプログラム
１２ スケルトンプログラム
１３ ＯＲＢサーバプログラム
１４、１４ａ ユーザ認証プログラム
２０、２０ａ 認証デバイス
３０ 周辺機器
３１ アプリケーションプログラム
３２ プロクシプログラム
３３ ＯＲＢクライアントプログラム
４０ ネットワーク
５０ ＬＤＡＰサーバ
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ 演算処理装置
１０５ インタフェース装置
Ｂ バス

Claims (11)

1. 認証デバイスを接続可能な情報処理装置であって、
   ネットワークを介して接続している機器からの要求に応じ、前記認証デバイスを制御する認証デバイス制御手段を有することを特徴とする情報処理装置。
2. 前記認証デバイス制御手段は、前記機器からの要求に応じ、前記認証デバイスに入力された情報に基づいて前記機器のユーザを認証し、該認証の結果を示す情報を前記機器に送信することを特徴とする請求項１記載の情報処理装置。
3. 前記認証デバイス制御手段は、前記認証デバイスの種別に依存しない関数インタフェースによって、前記機器からの要求を受け付けることを特徴とする請求項１又は２記載の情報処理装置。
4. 前記機器からの要求は、前記関数インタフェースに対する遠隔手続き呼び出しの要求であることを特徴とする請求項１乃至３いずれか一項記載の情報処理装置。
5. 前記認証デバイス制御手段は、盗聴及び成りすましを防止し、改ざんの確認が可能なプロトコルに基づいて前記機器との通信を行うことを特徴とする請求項１乃至４いずれか一項記載の情報処理装置。
6. 認証デバイスの接続された情報処理装置とネットワークを介して接続している機器であって、
   前記認証デバイスに入力された情報に基づく当該機器のユーザの認証の要求を前記情報処理装置に送信し、前記情報処理装置より返信される該認証の結果を示す情報に基づいて、前記ユーザに対する当該機器の所定の機能の提供の可否を判断するユーザ確認手段を有することを特徴とする機器。
7. 前記ユーザ確認手段は、前記情報処理装置に実装されている所定の関数インタフェースを遠隔手続き呼び出しで呼び出すことにより、当該機器のユーザの認証を前記情報処理装置に送信することを特徴とする請求項６記載の機器。
8. 前記ユーザ確認手段は、盗聴及び成りすましを防止し、改ざんの確認が可能なプロトコルに基づいて前記情報処理装置との通信を行うことを特徴とする請求項６又は７記載の機器。
9. 認証デバイスを接続可能な情報処理装置と、前記情報処理とネットワークを介して接続している機器とを有する情報処理システムであって、
   前記機器は、前記認証デバイスに入力された情報に基づく当該機器のユーザの認証の要求を前記情報処理装置に送信し、
   前記情報処理装置は、前記認証の要求に応じ、前記認証デバイスに入力された情報に基づいて前記機器のユーザを認証し、該認証の結果を示す情報を前記機器に送信することを特徴とする情報処理システム。
10. 認証デバイスを接続可能な情報処理装置に、
    ネットワークを介して接続している機器から前記機器のユーザの認証の要求を受信する認証要求受信手順と、
    前記認証要求受信手順において受信された前記認証の要求に応じ、前記認証デバイスに入力された情報に基づいて前記ユーザを認証する認証手順と、
    前記認証手順における前記ユーザの認証の結果を示す情報を前記機器に送信する認証結果送信手順とを実行させるための認証プログラム。
11. 請求項１０記載の認証プログラムを記録したコンピュータ読み取り可能な記録媒体。
    

Images