認証代行装置、認証代行プログラム、及び認証代行システム
【課題】認証システム下のクライアントが、認証システム下の別のクライアントとの通信するためには、そのクライアントに認証システムに対応する設定を行う必要がある。
【解決手段】認証サーバ１００のクライアントである画像処理装置１０は、認証エージェント７０に対し、同じ認証サーバ１００の別のクライアントである文書サーバ１１０にデータを送信したい旨の要求を行う。この場合、認証エージェント７０は、認証サーバ１００に対して、画像処理装置１０の認証要求を行う認証要求を行った後、画像処理装置１０と文書サーバ１１０の通信可能化を要求する。そして、認証エージェント７０は、認証サーバ１００から取得した可能化データ（サービスチケット）を利用して、文書サーバ１１０へ送信すべきデータを生成する。
【解決手段】認証サーバ１００のクライアントである画像処理装置１０は、認証エージェント７０に対し、同じ認証サーバ１００の別のクライアントである文書サーバ１１０にデータを送信したい旨の要求を行う。この場合、認証エージェント７０は、認証サーバ１００に対して、画像処理装置１０の認証要求を行う認証要求を行った後、画像処理装置１０と文書サーバ１１０の通信可能化を要求する。そして、認証エージェント７０は、認証サーバ１００から取得した可能化データ（サービスチケット）を利用して、文書サーバ１１０へ送信すべきデータを生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証代行装置、認証代行プログラム、または認証代行システムに関する。
【背景技術】
【０００２】
近年、ディレクトリサーバ等を用いて、ネットワークを介した認証やアクセス制御を行うシステムが普及している。ここでは、そのような認証技術の一つとして知られるＫｅｒｂｅｒｏｓの典型的な認証態様について説明する。
【０００３】
Ｋｅｒｂｅｒｏｓは、鍵配布センタＫＤＣ（ＫｅｙＤｉｓｔｒｉｂｕｔｉｏｎＣｅｎｔｅｒ）、認証サーバＡＳ（ＡｕｔｈｅｎｔｉｃａｔｉｏｎＳｅｒｖｅｒ）、チケット交付サーバＴＧＳ（ＴｉｃｋｅｔＧｒａｎｔｉｎｇＳｅｒｖｅｒ）の論理構成要素を利用して、クライアントの認証処理や、クライアントと別クライアントとの通信認可処理（通信可能化処理）を行うシステムである。この３つの論理構成要素は、通常一つにまとめられて実装されており、以下では、これらをまとめて単に認証サーバと呼ぶ。
【０００４】
認証サーバは、認証サーバのみが所有する鍵（Ｋ０と呼ぶ）を所有する他、クライアントのパスワードをシード（種）として生成した共通鍵（Ｋ１と呼ぶ）をこのクライアントと共有している。また、認証サーバは、別のクライアント（ここではアプリケーションサーバと呼ぶ）のパスワードを鍵のシードとして生成した共通鍵（Ｋ２と呼ぶ）をこのアプリケーションサーバと共有している。
【０００５】
クライアントは、アプリケーションサーバにアクセス（通信）したい場合、まず、認証サーバに認証要求を行う。そして、認証サーバは、認証に成功すると、セッション鍵（Ｋ３と呼ぶ）及びＴＧＴ（ＴｉｃｋｅｔＧｒａｎｔｉｎｇＴｉｃｋｅｔ；イニシャルチケットと呼ばれることもある）を生成する。ＴＧＴは、クライアントのＩＰ（インターネットプロトコル）アドレス、Ｋ３、有効期限などの情報をＫ０で暗号化して作成されたデータである。認証サーバは、Ｋ３及びＴＧＴをＫ１で暗号化してクライアントに送信する。クライアントは、Ｋ１による復号化を行って、ＴＧＴ及びＫ３を取り出す。
【０００６】
次に、クライアントは、アプリケーションサーバにアクセスしたいというアクセス認可要求（アクセス可能化要求）、Ｋ３で暗号化したタイムスタンプ、及び、ＴＧＴを認証サーバに送信する。認証サーバでは、ＴＧＴをＫ０で復号化して、クライアントのＩＰアドレス、Ｋ３、有効期限などの情報を取り出す。そして、認証サーバは、有効期限が到来していないことを確認した後、Ｋ３でタイムスタンプを復号化して、要求元が正当な権利をもつクライアントであることを検証し、さらに、アプリケーションサーバへのアクセス認可が要求されていることを把握する。
【０００７】
認証サーバでは、クライアントからのアクセス要求を認可する場合、クライアントとアプリケーションサーバとの通信用のセッション鍵（Ｋ４と呼ぶ）を生成する。そして、Ｋ４をＫ２で暗号化したもの（サービスチケットと呼ばれる）、及び、Ｋ４をＫ３で暗号化したものを作成し、クライアントに送信する。
【０００８】
クライアントでは、後者をＫ３で復号化して、Ｋ４を取り出す。そして、取り出したＫ４を用いて、アプリケーションサーバへのアクセス要求を暗号化し、これを、サービスチケット（Ｋ２で暗号化されたままのＫ４）と一緒にアプリケーションサーバに渡す。アプリケーションサーバは、サービスチケットをＫ２で復号化してＫ４を取り出すことができるので、クライアントが認証サーバから通信を認可されていることを検証できる。そして、取り出したＫ４で、クライアントからの要求を復号化する。こうして、クライアントとアプリケーションサーバ間で、Ｋ４を利用した安全な通信が行われるようになる。
【０００９】
このようにＫｅｒｂｅｒｏｓの認証システムでは、認証サーバによってクライアント認証が行われると、認証サーバはクライアントに対しＴＧＴを発行する。ＴＧＴは、認証を受けたクライアントに対して認証サーバが発行するデータであって、このクライアントに対して、他のクライアントへのアクセス（通信）の認可（可能化）を認証サーバに要求する権限を与える権限データであると言える。そして、クライアントが、ＴＧＴを用いて、認証サーバに対して、他のクライアントへのアクセス認可を要求すると、認証サーバはクライアントに対して、そのクライアントにアクセスするためのサービスチケットを発行する。サービスチケットは、アクセスを要求したクライアントに対して認証サーバが発行するデータであって、このクライアントに対して、アクセス先である他のクライアントへのアクセスを可能にする可能化データであると言える。
【００１０】
なお、認証サーバは、相互認証された複数のサーバ要素からなっていてもよい。複数のサーバ要素が、相互認証を行っている場合（共通鍵を所有する場合）には、信頼関係を連鎖させることで、異なるサーバ要素のクライアント同士の通信も可能となる。これは、クロスレルム認証（ある認証サーバが信頼するレルム（ネットワーク上の範囲）と別の認証サーバが信頼するレルムを跨いで相互に認証すること）と呼ばれる技術である。
【００１１】
Ｋｅｒｂｅｒｏｓの認証システムには、ＴＧＴやサービスチケット等を取り扱うことのできる装置であれば、特に制限されることなく各種の装置が参加可能である。
【００１２】
なお、下記特許文献１には、ネットワークを介して接続されたディレクトリサーバによって管理され、投入されたジョブ管理コマンドにしたがって、外部から入力されたジョブの管理を行う周辺機器（周辺装置）についての記載がある。この周辺機器は、ジョブに含まれるアクセスチケットを解読し、解読結果に基づいてジョブを管理する。
【００１３】
【特許文献１】特開２００２−２０２９４５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
本発明の目的は、クライアントが独自に認証システムに対応する設定を行わなくても認証システム下の別のクライアントとの通信が可能となる認証代行装置、認証代行プログラム、または認証代行システムを提供することにある。
【課題を解決するための手段】
【００１５】
本発明の認証代行装置の一態様においては、認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段と、を備える。
【００１６】
本発明の認証代行装置の一態様においては、前記送信データを前記クライアントＢに送信する送信手段を備える。
【００１７】
本発明の認証代行装置の一態様においては、前記送信データを前記クライアントＡに送信する送信手段を備える。
【００１８】
本発明の認証代行装置の一態様においては、前記認証要求の結果、前記認証サーバの別クライアントと前記クライアントＡとの通信の可能化を許可される権限を与える権限データを前記認証サーバから取得する権限データ取得手段と、前記権限データを保持する保持手段と、を備え、前記通信可能化要求手段は、前記権限データに基づいて前記通信の可能化を要求する。
【００１９】
本発明の認証代行装置の一態様においては、当該認証代行装置は、予め信頼関係が構築された外部装置と通信可能に設定され、当該認証代行装置は、さらに、前記可能化データ取得手段が前記可能化データを取得する前に、前記データ受信手段が前記送信すべきデータを受信した場合に、前記送信すべきデータを前記外部装置に送信して保管させる保管手段と、前記可能化データ取得手段が前記可能化データを取得した後に、前記外部装置から前記送信すべきデータを再受信するデータ再受信手段と、を備える。
【００２０】
本発明の認証代行装置の一態様においては、クライアントＡは、利用者の利用権限の下で処理を行う装置であり、当該認証代行装置は、前記利用者の利用権限の下で前記クライアントＢに対する通信についての処理を行う。
【００２１】
本発明の認証代行プログラムの一態様においては、認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段、としてコンピュータを機能させる。
【００２２】
本発明の認証代行システムの一態様においては、認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段と、を備える。
【発明の効果】
【００２３】
請求項１に記載の本発明によれば、クライアントＡでは、認証サーバを利用するための設定を行わなくても、認証代行装置への対応設定をすることで、認証サーバの別のクライアントＢとの通信が可能となる。また、クライアントＡでは、可能化データを利用して送信データの生成する処理が不要となる。
【００２４】
請求項２に記載の本発明によれば、クライアントＡでは、可能化データに基づき生成された送信データを送信する必要がなくなる。
【００２５】
請求項３に記載の本発明によれば、クライアントＡでは、可能化データに基づき生成された送信データを、自ら生成することなく取得することが可能となる。そして、この送信データに基づいて、クライアントＢと通信を行うことが可能となる。
【００２６】
請求項４に記載の本発明によれば、クライアントＡが権限データを保持しなくても、通信認可の要求を行うことが可能となる。
【００２７】
請求項５に記載の本発明によれば、クライアントＡでは、送信すべきデータを早期に認証代行装置に送信してしまうことができ、かつ、認証代行装置では、クライアントＢへの送信までの間、継続して送信すべきデータを保持する必要がなくなる。特に、送信すべきデータ量が比較的多い場合に、認証代行装置における負荷が軽減される。
【００２８】
請求項６に記載の本発明によれば、利用者毎に通信の制御を行うことが可能となる。
【００２９】
請求項７に記載の本発明によれば、クライアントＡでは、認証サーバを利用するための設定を行わなくても、認証代行装置への対応設定をすることで、認証サーバの別のクライアントＢとの通信が可能となり、また、クライアントＡでは、可能化データを利用して送信データの生成する処理が不要となるプログラムが提供される。
【００３０】
請求項８に記載の本発明によれば、クライアントＡでは、認証サーバを利用するための設定を行わなくても、認証代行装置への対応設定をすることで、認証サーバの別のクライアントＢとの通信が可能となり、また、クライアントＡでは、可能化データを利用して送信データの生成する処理が不要となるシステムが提供される。
【発明を実施するための最良の形態】
【００３１】
以下に本実施の形態について例示する。
【００３２】
本実施の形態では、認証サーバ、認証代行装置である認証エージェント、及び、認証サーバのクライアントである画像処理装置や文書サーバなどを示して説明を行う。画像処理装置や文書サーバなどは、上記クライアントＡやクライアントＢに対応する。また、本実施の形態では、主として、Ｋｅｒｂｅｒｏｓによる認証技術を前提とした説明を行う。なお、サーバとは、クライアントの要求に応じてサービスを提供する装置をいい、クライアントは、サーバの提供するサービスを享有する装置をいう。
【００３３】
まず、図１を用いて、コンピュータのハードウエア構成を説明する。図１は、本実施の形態にかかる画像処理装置１０のハードウエア構成を示す図である。画像処理装置１０は、コントローラボード１２を備えている。そして、コントローラボード１２上には、内部通信経路としてのバス１４が設けられ、バス１４に対しては、ＣＰＵ（中央処理装置）１６、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）１８、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）２０、ＮＶＲＡＭ（ＮｏｎＶｏｌａｔｉｌｅＲＡＭ）２２、ＨＤＤ（ＨａｒｄＤｉｓｃＤｒｉｖｅ）２４、画像処理部２６、ＵＩ＿ＩＦ（ユーザインタフェース＿インタフェース）２８、通信ＩＦ３６、ＤｅｖｉｃｅＩＦ４６が接続されている。
【００３４】
ＣＰＵ１６は画像処理装置の主たる制御を行う処理部であり、プログラムに従って動作する。ＣＰＵ１６には、プログラム構成に対応した様々な処理機能が構築される。ＲＯＭ１８は、書き換え不可能な不揮発性メモリであり、プログラムや固定データを格納する。ただし、ＲＯＭ１８を、フラッシュメモリによる書き換え可能な構成としてもよい。ＲＡＭ２０は、書き換え可能な揮発性メモリであり、プログラム動作のためのシステムメモリや、画像処理のためのページメモリとして使われる。ＮＶＲＡＭ２２は、書き換え可能な不揮発性メモリであり、不揮発性のデータ、画質調整、各種設定パラメータ、各種履歴の格納を行う。ＨＤＤ２４は、磁気ディスク等により構築された大容量記憶装置であり、画像データや各種履歴の格納を行う。画像処理部２６は、コプロセッサなどの画像処理専用回路を備え、画像データの伸張圧縮処理や各種画像処理を行う。
【００３５】
ＵＩ＿ＩＦ２８は、ＵＩ３０とのインタフェースである。ＵＩ＿ＩＦ２８には、コントローラボード１２外に設けられたＵＩ３０が接続されており、ＵＩ３０は、ディスプレイや発光ダイオード等の表示部３２とハードキーやタッチパネル等の操作部３４を含んでいる。
【００３６】
通信ＩＦ３６は、各種の外部装置やネットワークへのインタフェースである。通信ＩＦ３６には、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）３８、Ｓｅｒｉａｌ４０、ＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）４２、モデム４４の各種インタフェースが接続されている。ＬＡＮ３８は、１０／１００ＢＡＳＥ−Ｔなどによる有線形式や、無線形式でネットワークに接続する。Ｓｅｒｉａｌ４０は、各種外部周辺装置への直接的な接続に用いられ、ＵＳＢ４２は、ＵＳＢ１．１やＵＳＢ２．０などをサポートする装置への直接接続に使用される。また、モデム４４は、ＦＡＸなどの公衆回線への接続を行う。
【００３７】
ＤｅｖｉｃｅＩＦ４６には、コントローラボード１２外に設けられたスキャナ、プラテン、自動原稿読取装置(両面も可)等の読取装置部４８と、プリントエンジンなどを含む印刷装置部４９とが接続されている。読取装置部４８は、用紙を読み取って新たに画像データを生成する画像処理を行い、印刷装置部４９は画像データに基づいて用紙に画像を印刷する画像処理を行う。
【００３８】
なお、ＣＰＵ１６を制御するプログラムは、典型的には、製造段階でＲＯＭ１８に格納される。しかし、例えば、ＬＡＮ３８を用いてネットワークからプログラム信号を受信することで、ＮＶＲＡＭ２２にプログラムをインストールすることができる。また、プログラムのインストールは、ＣＤ（コンパクトディスク）をＵＳＢ４２に接続されたＣＤドライブで読み取るなど、記憶媒体を通じて行われてもよい。
【００３９】
以上においては、画像処理装置１０のハードウエア構成について説明したが、この構成は、一般的なコンピュータにおいてもほぼ同様である。一般的コンピュータは、画像処理装置１０と異なり、画像処理部２６、ＤｅｖｉｃｅＩＦ４６、読取装置部４８、印刷装置部４９などの画像処理に特化したハードウエア構成要素を備えないことが多いが、画像処理装置１０と同様に、プログラム制御されるＣＰＵ１６などを備える。本実施の形態で例示する認証エージェント、認証サーバ、文書サーバなどは、一般的なコンピュータをプログラム制御させることで構築可能である。
【００４０】
なお、ハードウエアの各構成要素は、必ずしも一体化している必要はなく、通信可能な複数の部分に分離されていてもよい。また、これらの部分は、ネットワーク上に分散され、分散処理システムを構成していてもよい。
【００４１】
続いて、画像処理装置１０の機能構成について説明する。図２は、図１に示した画像処理装置１０の機能構成例を示した概略ブロック図である。画像処理装置１０には、主たる機能要素として、制御部５０、ユーザ認証要求部５２、ユーザログアウト通知部５４、送受信部５６、転送処理部５８、画像生成部６０、及び印刷部６２が構築されている。
【００４２】
制御部５０は、各機能要素の制御を行う。ユーザ認証要求部５２は、画像処理装置１０にユーザ（利用者）がログイン（ログオン）を試みた場合に、認証エージェントを介して認証サーバに認証を要求する。ユーザログアウト通知部５４は、ユーザがログアウト（ログオフ）した場合、あるいは、そのユーザの指令にかかるジョブが終了した場合に、認証エージェントにその旨を通知する。送受信部５６は、通信ＩＦ３６を介して文書サーバや認証エージェントとデータの送受信を行う。転送処理部５８は、送受信部５６を制御して、受信したデータを転送先にそのまま送信させる転送処理を行う。画像生成部６０は、読取装置部４８を利用して構築されており、用紙を読み取って画像データを生成する。印刷部６２は、印刷装置部４９を利用して構築されており、画像データに基づいて用紙に印刷を行う。
【００４３】
図３は、認証エージェント７０の機能構成例を示した概略ブロック図である。認証エージェント７０には、ユーザ情報登録部７２、ユーザ認証要求受信部７４、ユーザ認証要求部７６、ＴＧＴ取得・記憶部７８、ＴＧＴ更新・無効化部８０、通信要求受信部８２、サービスチケット要求部８４、反復要求部８６、送信データ生成部８８、及び送受信部９０が構築されている。
【００４４】
ユーザ情報登録部７２では、ユーザの認証に必要となる認証情報の登録が行われる。認証情報としては、ユーザＩＤやパスワードなどが挙げられる。登録対象となるユーザは、典型的には、認証サーバ上に登録されたユーザであるが、認証サーバー上に登録されていないユーザであってもよい。後者の場合には、ユーザの属性情報として、認証サーバへの認証要求あるいはネットワークを通じた通信要求が許可されているか禁止されているかを表す情報を含めてもよい。登録は、あらかじめ行われてもよいし、ユーザ認証要求受信部７４が認証情報とともに認証要求を受信した場合に、この認証情報を利用して行われてもよい。登録された認証情報は、認証サーバにユーザの認証を要求するために使用されたり、認証サーバにネットワーク上の装置にアクセスするためのサービスチケット発行を要求するために使用されたりする。
【００４５】
ユーザ認証要求受信部７４は、通信要求受付手段の例であり、画像処理装置１０等のクライアントから、ユーザ認証要求を受信する。認証要求とともに、ユーザＩＤやパスワードなどを受信することもある。なお、ユーザ認証の要求は、明示的に行われてもよいが、暗黙の内に行われてもよい。
【００４６】
ユーザ認証要求部７６は、認証要求手段の例であり、ユーザ認証要求受信部７４の受信結果に従って、認証サーバに対しユーザ認証を要求する。ユーザ認証の要求にあたっては、クライアントから受信した認証情報、あるいは、ユーザ情報登録部７２に格納された認証情報も送信される。
【００４７】
ＴＧＴ取得・記憶部７８は、ユーザ認証要求部７６による認証要求の結果、認証サーバから権限データたるＴＧＴ（以下では、イニシャルチケットと呼ぶ場合もある）及びセッション鍵を取得し、記憶する。ＴＧＴは、サービスチケットを取得する権限を与えるデータである。一般に、ＴＧＴには、適当な有効期間が設定される。
【００４８】
ＴＧＴ更新・無効化部８０は、クライアントにおけるユーザの作業状態に応じて、ＴＧＴの更新や無効化（破棄や、認証サーバへの無効化依頼）を行う。例えば、クライアントとしての画像処理装置１０から、ユーザがログアウト（タイマーによるログアウトでもよい)した旨、あるいは、ログアウト後にユーザの残したジョブが終了した旨が伝えられた場合に、ＴＧＴ更新・無効化部８０は、当該認証エージェント７０におけるそのユーザについてのジョブ処理の終了を確認したうえで、ＴＧＴの無効化を行う。他方、ＴＧＴ更新・無効化部８０は、ユーザのログイン中や、ユーザによるジョブが残っている最中は、ＴＧＴを保持し続け、ＴＧＴの有効期限が切れる前に、認証サーバに対しチケットの更新を要求する。
【００４９】
通信要求受信部８２は、通信要求受信手段の例である。通信要求受信部８２は、クライアントから、ネットワーク上の他装置との通信（受信と送信の一方または両方）を行いたい旨の要求を受ける。要求は、明示的に行われてもよいが、暗黙の内に行われてもよい。
【００５０】
サービスチケット要求部８４は、可能化データ取得手段の例である。サービスチケット要求部８４は、通信要求受信部８２による受信結果に基づいて、通信相手となる装置との通信認可要求を認証サーバに要求するものであり、具体的には通信相手の装置と通信するためのサービスチケットの発行を認証サーバに要求する。要求は、ＴＧＴを利用して行われる。もちろん、認証サーバが許せば、ＴＧＴを用いずに、ユーザ認証に使用した認証情報を再度用いてサービスチケットを要求することも可能である。サービスチケットには、通信相手と認証エージェント７０との間で使用される通信用の共通鍵であるセッション鍵が埋め込まれており、このサービスチケットは通信相手（と認証サーバ）のみが保持する共通鍵によって暗号化されている。したがって、サービスチケットを取得した通信相手は、その復号化に成功した場合には、認証エージェント７０が通信認可を受けていると判断する。そして、取り出したセッション鍵を用いて、認証エージェント７０との間で、暗号化された安全な通信を行うことができる。このように、サービスチケットは、通信相手の装置との通信を可能化する可能化データである。
【００５１】
反復要求部８６は、通信相手の装置との通信に失敗した場合に、再度の通信を試みる。この場合、クライアントの処理を一旦終了させるために、例えば処理をクライアントから当該認証エージェント７０に移管する旨のステータスをクライアントに通知してもよい。なお、設定回数や設定時間を超過しても通信可能とならなかった場合には、反復処理を中止し、クライアントに処理が失敗した旨を通知する。
【００５２】
送信データ生成部８８は、生成手段の例であり、サービスチケット（通信用の共通鍵）を通信相手の装置に渡すための送信データや、通信対象となるデータを通信用の共通鍵で暗号化した送信データを生成する。なお、送信データのプロトコルは特に限定されるものではなく、設定に従い、あるいは、クライアントからの指示に従い決定すればよい。プロトコルの例としては、ＳＭＢ（ＳｅｒｖｅｒＭｅｓｓａｇｅＢｌｏｃｋ）、ＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）、ＩＰＰ（ＩｎｔｅｒｎｅｔＰｒｉｎｔｉｎｇＰｒｏｔｏｃｏｌ）などを挙げることができる。
【００５３】
送受信部９０は、データ受信手段、データ再受信手段、送信手段などの例であり、データの送受信を行う。送受信の相手としては、クライアントや、認証サーバの他、クライアントが要求する通信先を挙げることができる。
【００５４】
続いて、図４乃至図８を用いて、本実施の形態にかかるシステム構成について説明する。
【００５５】
［第１のシステム形態］ 図４は、第１のシステム形態の構成を説明する図である。このシステムには、画像処理装置１０、認証エージェント７０、認証サーバ１００、文書サーバ１１０、及び一時保管サーバ１１２が含まれている。
【００５６】
認証サーバ１００は、Ｋｅｒｂｅｒｏｓ認証技術における認証サーバ、鍵配布センタ、チケット交付サーバを兼ねる装置である。認証サーバ１００は、単体の認証システムを構築するものであっても、複数の認証システムの相互認証（クロスレルム認証）により構築されたものであってもよい。
【００５７】
画像処理装置１０は、認証サーバ１００のクライアントであり、図１に示したハードウエア構成及び図２に示した機能構成をもつ装置である。ここで、クライアントとは、認証サーバ１００が提供する認証サービスを享受する装置をいう。ただし、画像処理装置１０は、認証エージェント７０を通じて間接的に認証サーバ１００にサービスを要求し、サービスを享受している。
【００５８】
認証エージェント７０は、図３に示した機能構成をもつ装置であり、画像処理装置１０と認証サーバ１００の間に設置されている。そして、画像処理装置１０からの要求に基づいて認証サーバ１００にサービスを要求し、認証サーバ１００が提供するサービスを画像処理装置１０に還元している。
【００５９】
文書サーバ１１０は、文書データの保管などを行うサーバである。文書サーバ１１０は、認証サーバ１００のクライアントであり、認証サーバ１００による認証サービスを享有している。文書サーバ１１０には、認証サーバ１００と同じ共通鍵が保持されている。
【００６０】
一時保管サーバ１１２は、外部装置の例であり、文書サーバ１１０と同様に文書データなどを保管するサーバである。一時保管サーバ１１２には、認証エージェント７０に比べ大容量のデータを保管することができる。一時保管サーバ１１２は、認証サーバ１００のクライアントであってもよいし、なくてもよい。しかし、一時保管サーバ１１２は、認証エージェント７０と、認証サーバ１００の下で、あるいは、別の認証システムや適当な通信安全設定の下で、安全に通信できることが想定されている。
【００６１】
画像処理装置１０と認証エージェント７０の間の通信経路には、認証サーバが提供する認証システムとは別の設定に基づいて、通信安全性（通信セキュリティ）が確保されている。通信安全性の確保は、例えば、ケーブルの直接接続や、公開鍵認証方式によって行われる。これに対し、画像処理装置１０、認証サーバ１００、及び文書サーバ１１０の間の通信安全性は、認証サーバ１００が提供する方式に基づいて確保されている。
【００６２】
次に、図５のフローチャートを用いて、画像処理装置１０でスキャンされた文書データが、文書サーバ１１０に格納される処理の流れを説明する。
【００６３】
画像処理装置１０は、ユーザがユーザＩＤ、レルム（ネットワーク上の範囲を表す。典型的にはドメイン名が与えられる）、パスワードなどの認証情報を入力すると、その認証情報を認証エージェント７０に送信して外部認証の要求を行う（Ｓ１０）。認証エージェント７０は、認証サーバ１００の方式に従い、認証情報をプリンシパル（処理対象の身元を明らかにする情報であり、典型的にはユーザＩＤとレルムを組合せて作成される）とパスワードに変換して、認証サーバ１００に認証を要求する（Ｓ１２）。そして、認証サーバ１００は、予め登録されたパスワードに基づいてユーザ認証を行う（Ｓ１４）。その結果、認証に失敗すると、その旨が認証エージェント７０に伝えられ（Ｓ１６）、さらに、認証エージェント７０から画像処理装置１０に伝えられ（Ｓ１８）、処理が終了する（Ｓ２０）。他方、認証に成功した場合には、権限データたるＴＧＴが発行されて（Ｓ２２）、認証エージェント７０に送信される。認証エージェント７０は、このＴＧＴを記憶領域に格納し（Ｓ２４）、画像処理装置１０に対して認証に成功した旨を通知する（Ｓ２６）。
【００６４】
ここでは、ログインに成功したユーザは、画像処理装置１０において、文書のスキャンと、これにより生成された文書データの転送先の入力、及び転送指示を行っている（Ｓ２８）。画像処理装置１０では、文書データ、転送先、及びログインユーザのユーザ情報を認証エージェント７０に送信して、転送要求を行う（Ｓ３０）。ユーザ情報は、先に認証したユーザと同一であることを示す情報である。ユーザ情報の例としては、ユーザＩＤとレルムの組み合わせを挙げることができる。
【００６５】
認証エージェント７０は、ＴＧＴと転送先を認証サーバ１００に送信して、転送先へのアクセス認可の要求、すなわち、転送先へのアクセスを可能化するサービスチケットの発行の要求を行う（Ｓ３２）。認証サーバ１００は、ＴＧＴの検証を行い（Ｓ３４）、検証に失敗した場合には、認証エージェント７０にその旨を伝える。そして、認証エージェント７０では、転送が失敗に終わり（Ｓ３６）、その旨が画像処理装置１０に伝えられる。この結果、画像処理装置１０では、文書転送についてのジョブが失敗のまま終了することになる（Ｓ３８，Ｓ４０）。他方、ＴＧＴの検証に成功した場合には、サービスチケットが発行され（Ｓ４２）、認証エージェント７０に送信される。このサービスチケットは、文書サーバ１１０がもつ鍵で暗号化されている。認証エージェント７０は、サービスチケットを記憶領域に格納する（Ｓ４４）。さらに、認証エージェント７０は、文書データとサービスチケットを用いて送信データを生成し、転送先に送信する（Ｓ４６）。送信データの生成は、文書データが転送先によって受け付けられるように、例えば、サービスチケットを添付したり、文書データを暗号化したりして行われる。
【００６６】
転送先である文書サーバ１１０は、送信データを受信すると、送信データに含まれるサービスチケットの復号化を行い、その有効性、つまり、送信データが認証サーバ１００によって通信が認可された相手から送信されたか否かを検証する（Ｓ４８）。そして、検証に失敗した場合には、認証エージェント７０に対しその旨を伝達する。この結果、認証エージェント７０では転送が失敗に終わり（Ｓ５０）、画像処理装置１０は、転送に失敗したままジョブを終了する（Ｓ５２，Ｓ５４）。これに対し、サービスチケットが有効であると判断された場合には、文書サーバ１１０は、送信データから文書データを取り出して格納する（Ｓ５６）。そして、認証エージェント７０は転送成功の報告を受け（Ｓ５８）、画像処理装置１０は成功裡にジョブを終了する（Ｓ６０，Ｓ６２）。
【００６７】
この一連の処理において、認証エージェント７０がサービスチケットを取得する前に、画像処理装置１０から認証エージェント７０に文書データが送信される場合が考えられる。この場合に、認証エージェント７０では、受信した文書データを一時保管サーバ１１２に一時的に保管する。そして、サービスチケットが発行された後で、一時保管サーバ１１２から文書データを再取得する。
【００６８】
また、この一連の処理において、認証エージェント７０がサービスチケットを取得していながら文書サーバ１１０が受信可能状態で無い場合が考えられる。しかし、この場合においても、認証エージェント７０が受信した文書データを一時保管サーバ１１２に一時保管し、文書サーバ１１０が受信可能状態になった後で、一時保管サーバ１１２から文書データを再取得するようにしても良い。
【００６９】
なお、一般に、ＴＧＴには、有効期限が設定されている。そこで、認証エージェント７０は、有効期限を監視し、期限が切れる前にＴＧＴの更新を行うことができる。また、画像処理装置１０においてユーザがログアウトした場合や、ログアウトかつユーザの全ジョブが終了した場合に、画像処理装置１０は、その旨を認証エージェント７０に通知する。そして、認証エージェント７０は、このユーザについてのジョブ実行を委託されたものがないことを確認し、ユーザのＴＧＴを破棄する。
【００７０】
［第２のシステム形態］ 図６は、第２のシステム形態にかかる構成を説明する図である。このシステムには、画像処理装置１０、認証エージェント７０、認証サーバ１００、及びＰＣ（パーソナルコンピュータ）１２０が含まれている。画像処理装置１０、認証エージェント７０、及び認証サーバ１００は、第１のシステム形態と同様の装置である。すなわち、画像処理装置１０は認証サーバ１００のクライアントであり、認証エージェント７０は画像処理装置１０の認証処理の少なくとも一部を代行する装置である。また、画像処理装置１０と認証エージェント７０の通信は、独自の方式で、安全化が図られている。ＰＣ１２０は、認証サーバ１００のクライアントである。
【００７１】
次に、図７のフローチャートを用いて、ＰＣ１２０から画像処理装置１０に対し文書データの印刷が要求される場合の処理の流れを説明する。ＰＣ１２０では、まず、認証サーバ（ＫＤＣ）１００に対し認証情報を送信してユーザ認証を求め、ＴＧＴを獲得する（Ｓ７２）。続いて、ＰＣ１２０は、認証サーバ１００に対し、ＴＧＴと転送先の情報を送信して、画像処理装置１０にアクセスするためのサービスチケットを要求する（Ｓ７４）。認証サーバ１００は、ＴＧＴを検証してサービスチケット発行の可否を判定し（Ｓ７６）、発行不可能な場合にはその旨をＰＣ１２０に伝達し、発行可能な場合にはサービスチケットを発行してＰＣ１２０に送信する（Ｓ７８）。そして、ＰＣ１２０は、取得したサービスチケットを記憶領域に格納する（Ｓ８０）。なお、ＰＣ１２０が既にＴＧＴやサービスチケットを獲得している場合には、これらのステップを繰り返す必要はない。
【００７２】
続いて、ＰＣ１２０は、ユーザが文書データの印刷を指示する（Ｓ８２）。これを受けて、ＰＣ１２０は、通信用のコンテキストを初期化し（Ｓ８４）、画像処理装置１０に対し、サービスチケットを含むメッセージを送信する。このメッセージは、画像処理装置１０によって、認証エージェント７０にリダイレクトされる（Ｓ８６）。
【００７３】
認証エージェント７０では、画像処理装置１０がまだ認証を受けていない場合には、認証サーバ１００に対し、画像処理装置１０のプリンシパル名やパスワードを送信して、ＴＧＴの発行を要求する処理が行われる（Ｓ８８）。そして、認証サーバ１００は、ＴＧＴの検証を行い（Ｓ９０）、発行可能な場合には、ＴＧＴ（イニシャルチケット）を発行して認証エージェント７０に送信する（Ｓ９２）。
【００７４】
認証エージェント７０は、このＴＧＴを記憶領域に格納する（Ｓ９４）。そして、ＰＣ１２０から送られたサービスチケットを、画像処理装置１０と共有している共有鍵で復号化し、時刻検証処理などを行う。アクセスが正当なものであると判断した場合、認証エージェント７０は、コンテキストを受け入れ、さらに、ＰＣ１２０に通知すべきプロトコル情報などについての応答メッセージを作成する（Ｓ９６）。画像処理装置１０は、受信した応答メッセージをＰＣ１２０に送信し（Ｓ９８）、これにより画像処理装置１０においてコンテキストが確立する（Ｓ１００）。
【００７５】
ＰＣ１２０は、印刷対象となる文書データ及び印刷指示データを通信用の鍵で暗号化して画像処理装置１０に送信し、画像処理装置１０は、それを認証エージェント７０にリダイレクトする。また、認証エージェント７０は、文書データ及び印刷指示データを復号化し、画像処理装置１０に渡す（Ｓ１０２）。この過程は、画像処理装置１０が、全データを獲得するまで繰り返される。
【００７６】
最後に、ＰＣ１２０は、セッションを閉じて、サービスチケットを破棄し（Ｓ１０４）、処理を終了する（Ｓ１０６）。また、認証エージェント７０は、セッションを閉じて、ＴＧＴを破棄し（Ｓ１０８）、処理を終了する（Ｓ１１０）。そして、画像処理装置１０は、印刷指示データに基づいて文書データの印刷を行い（Ｓ１１２）、処理を終了する（Ｓ１１４）。
【００７７】
［第３のシステム形態］ 図８は、第３のシステム形態にかかる構成を説明する図である。このシステムには、第１のシステム形態と同様に、画像処理装置１０、認証エージェント７０、認証サーバ１００、文書サーバ１１０、及び一時保管サーバ１１２が含まれている。
【００７８】
ここでは、画像処理装置１０から文書サーバ１１０へ文書データを送信する処理について説明する。処理では、まず、画像処理装置１０において、ユーザが認証情報を入力する。そして、画像処理装置１０は、認証エージェント７０に対し、認証情報を送信して認証を要求し、認証エージェント７０は、外部の認証サーバ１００に対し、認証情報を送信してユーザ認証を要求する。認証に成功した場合、認証サーバ１００においてＴＧＴが発行され、認証エージェント７０に送信されて保存される。
【００７９】
画像処理装置１０のユーザは、文書の読み取りにより文書データを生成させるとともに、この文書データを文書サーバ１１０に送信する指示を行う。この場合、画像処理装置１０は、設定に従って、認証エージェントに対し、文書データとプロトコル情報をリダイレクト送信する。認証エージェント７０は、プロトコル情報に基づいて、文書サーバ１１０へ文書データを送信するための送信データを生成し、デバイスに通知する。
【００８０】
この過程で、認証エージェント７０は、サービスチケットが必要であれば、認証サーバ１００に対してＴＧＴを用いてサービスチケットの発行を要求する。そして認証サーバ１００は、文書サーバ１１０の共通鍵で暗号化されたサービスチケットを発行する。また、認証エージェント７０は、文書サーバ１１０との通信用に作成された鍵を用いて、電子文書の暗号化等を行う。
【００８１】
こうして、作成された送信データは、画像処理装置１０に送信され、さらに画像処理装置１０によって文書サーバ１１０へと転送される。なお、認証エージェント７０は、文書サーバ１１０とのネゴーシエーションや、文書サーバ１１０からの送信データの復号化なども同じ経路を利用して行う。すなわち、本システム形態では、画像処理装置１０が、認証サーバ１００の配下にある文書サーバ１１０と通信を行う場合、全ての送受信データ（あるいは認証、暗号化、複合化等が必要なデータ）を認証エージェント７０にリダイレクト送信し、認証、暗号化、復号化等の処理を行わせる。なお、一時保管サーバ１１２の役割は、第１のシステム形態と同様である。すなわち、認証エージェントによる認証処理を待つ間、認証エージェント７０が保持すべきデータが一時保管サーバ１１２に一時的に保管される。
【００８２】
以上の説明では、通信を行う一方のクライアントのみが認証エージェントを使用している態様について示したが、両方のクライアントが認証エージェントを使用してもよい。両方のクライアントが異なる認証エージェントを使用する場合には、認証エージェントは上述の通りの処理を行えばよい。しかし、両方のクライアントが同じ認証エージェントを使用する場合には、暗号化と復号化が同じ認証エージェントで行われることになる。つまり、暗号化及び復号化を行う必要がなくなり、ゆえに、認証サーバにサービスチケットの発行を求める必要もなくなる。したがって、同じ認証エージェントを使用するクライアント同士が通信を行う場合には、認証エージェントでは、認証サーバの認可をうけることなく両者の通信を許すことが可能となる。
【００８３】
また、以上の説明においては、共通鍵を用いるＫｅｒｂｅｒｏｓの認証技術を前提としたが、本実施の形態は、他の認証システムにも適用可能である。例えば、Ｋｅｒｂｅｒｏｓの認証技術における共通鍵を用いた処理の一部または全部に対し、公開鍵暗号方式を導入することが考えられる。
【図面の簡単な説明】
【００８４】
【図１】本実施の形態にかかる画像処理装置のハードウエア構成例を示す図である。
【図２】本実施の形態にかかる画像処理装置の機能構成例を示す図である。
【図３】本実施の形態にかかる認証エージェントの機能構成例を示す図である。
【図４】第１のシステム形態における構成を示す図である。
【図５】第１のシステム形態における処理の流れを示すフローチャートである。
【図６】第２のシステム形態における構成を示す図である。
【図７】第２のシステム形態における処理の流れを示すフローチャートである。
【図８】第３のシステム形態における構成を示す図である。
【符号の説明】
【００８５】
１０ 画像処理装置、１２ コントローラボード、１４ バス、１６ ＣＰＵ、１８ ＲＯＭ、２０ ＲＡＭ、２２ ＮＶＲＡＭ、２４ ＨＤＤ、２６ 画像処理部、２８ ＵＩ＿ＩＦ、３０ ＵＩ、３２ 表示部、３４ 操作部、３６ 通信ＩＦ、３８ ＬＡＮ、４０ Ｓｅｒｉａｌ、４２ ＵＳＢ、４４ モデム、４６ ＤｅｖｉｃｅＩＦ、４８ 読取装置部、４９ 印刷装置部、５０ 制御部、５２ ユーザ認証要求部、５４ ユーザログアウト通知部、５６ 送受信部、５８ 転送処理部、６０ 画像生成部、６２ 印刷部、７０ 認証エージェント、７２ ユーザ情報登録部、７４ ユーザ認証要求受信部、７６ ユーザ認証要求部、７８ ＴＧＴ取得・記憶部、８０ ＴＧＴ更新・無効化部、８２ 通信要求受信部、８４ サービスチケット要求部、８６ 反復要求部、８８ 送信データ生成部、９０ 送受信部、１００ 認証サーバ、１１０ 文書サーバ、１１２ 一時保管サーバ、１２０ ＰＣ。
【技術分野】
【０００１】
本発明は、認証代行装置、認証代行プログラム、または認証代行システムに関する。
【背景技術】
【０００２】
近年、ディレクトリサーバ等を用いて、ネットワークを介した認証やアクセス制御を行うシステムが普及している。ここでは、そのような認証技術の一つとして知られるＫｅｒｂｅｒｏｓの典型的な認証態様について説明する。
【０００３】
Ｋｅｒｂｅｒｏｓは、鍵配布センタＫＤＣ（ＫｅｙＤｉｓｔｒｉｂｕｔｉｏｎＣｅｎｔｅｒ）、認証サーバＡＳ（ＡｕｔｈｅｎｔｉｃａｔｉｏｎＳｅｒｖｅｒ）、チケット交付サーバＴＧＳ（ＴｉｃｋｅｔＧｒａｎｔｉｎｇＳｅｒｖｅｒ）の論理構成要素を利用して、クライアントの認証処理や、クライアントと別クライアントとの通信認可処理（通信可能化処理）を行うシステムである。この３つの論理構成要素は、通常一つにまとめられて実装されており、以下では、これらをまとめて単に認証サーバと呼ぶ。
【０００４】
認証サーバは、認証サーバのみが所有する鍵（Ｋ０と呼ぶ）を所有する他、クライアントのパスワードをシード（種）として生成した共通鍵（Ｋ１と呼ぶ）をこのクライアントと共有している。また、認証サーバは、別のクライアント（ここではアプリケーションサーバと呼ぶ）のパスワードを鍵のシードとして生成した共通鍵（Ｋ２と呼ぶ）をこのアプリケーションサーバと共有している。
【０００５】
クライアントは、アプリケーションサーバにアクセス（通信）したい場合、まず、認証サーバに認証要求を行う。そして、認証サーバは、認証に成功すると、セッション鍵（Ｋ３と呼ぶ）及びＴＧＴ（ＴｉｃｋｅｔＧｒａｎｔｉｎｇＴｉｃｋｅｔ；イニシャルチケットと呼ばれることもある）を生成する。ＴＧＴは、クライアントのＩＰ（インターネットプロトコル）アドレス、Ｋ３、有効期限などの情報をＫ０で暗号化して作成されたデータである。認証サーバは、Ｋ３及びＴＧＴをＫ１で暗号化してクライアントに送信する。クライアントは、Ｋ１による復号化を行って、ＴＧＴ及びＫ３を取り出す。
【０００６】
次に、クライアントは、アプリケーションサーバにアクセスしたいというアクセス認可要求（アクセス可能化要求）、Ｋ３で暗号化したタイムスタンプ、及び、ＴＧＴを認証サーバに送信する。認証サーバでは、ＴＧＴをＫ０で復号化して、クライアントのＩＰアドレス、Ｋ３、有効期限などの情報を取り出す。そして、認証サーバは、有効期限が到来していないことを確認した後、Ｋ３でタイムスタンプを復号化して、要求元が正当な権利をもつクライアントであることを検証し、さらに、アプリケーションサーバへのアクセス認可が要求されていることを把握する。
【０００７】
認証サーバでは、クライアントからのアクセス要求を認可する場合、クライアントとアプリケーションサーバとの通信用のセッション鍵（Ｋ４と呼ぶ）を生成する。そして、Ｋ４をＫ２で暗号化したもの（サービスチケットと呼ばれる）、及び、Ｋ４をＫ３で暗号化したものを作成し、クライアントに送信する。
【０００８】
クライアントでは、後者をＫ３で復号化して、Ｋ４を取り出す。そして、取り出したＫ４を用いて、アプリケーションサーバへのアクセス要求を暗号化し、これを、サービスチケット（Ｋ２で暗号化されたままのＫ４）と一緒にアプリケーションサーバに渡す。アプリケーションサーバは、サービスチケットをＫ２で復号化してＫ４を取り出すことができるので、クライアントが認証サーバから通信を認可されていることを検証できる。そして、取り出したＫ４で、クライアントからの要求を復号化する。こうして、クライアントとアプリケーションサーバ間で、Ｋ４を利用した安全な通信が行われるようになる。
【０００９】
このようにＫｅｒｂｅｒｏｓの認証システムでは、認証サーバによってクライアント認証が行われると、認証サーバはクライアントに対しＴＧＴを発行する。ＴＧＴは、認証を受けたクライアントに対して認証サーバが発行するデータであって、このクライアントに対して、他のクライアントへのアクセス（通信）の認可（可能化）を認証サーバに要求する権限を与える権限データであると言える。そして、クライアントが、ＴＧＴを用いて、認証サーバに対して、他のクライアントへのアクセス認可を要求すると、認証サーバはクライアントに対して、そのクライアントにアクセスするためのサービスチケットを発行する。サービスチケットは、アクセスを要求したクライアントに対して認証サーバが発行するデータであって、このクライアントに対して、アクセス先である他のクライアントへのアクセスを可能にする可能化データであると言える。
【００１０】
なお、認証サーバは、相互認証された複数のサーバ要素からなっていてもよい。複数のサーバ要素が、相互認証を行っている場合（共通鍵を所有する場合）には、信頼関係を連鎖させることで、異なるサーバ要素のクライアント同士の通信も可能となる。これは、クロスレルム認証（ある認証サーバが信頼するレルム（ネットワーク上の範囲）と別の認証サーバが信頼するレルムを跨いで相互に認証すること）と呼ばれる技術である。
【００１１】
Ｋｅｒｂｅｒｏｓの認証システムには、ＴＧＴやサービスチケット等を取り扱うことのできる装置であれば、特に制限されることなく各種の装置が参加可能である。
【００１２】
なお、下記特許文献１には、ネットワークを介して接続されたディレクトリサーバによって管理され、投入されたジョブ管理コマンドにしたがって、外部から入力されたジョブの管理を行う周辺機器（周辺装置）についての記載がある。この周辺機器は、ジョブに含まれるアクセスチケットを解読し、解読結果に基づいてジョブを管理する。
【００１３】
【特許文献１】特開２００２−２０２９４５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
本発明の目的は、クライアントが独自に認証システムに対応する設定を行わなくても認証システム下の別のクライアントとの通信が可能となる認証代行装置、認証代行プログラム、または認証代行システムを提供することにある。
【課題を解決するための手段】
【００１５】
本発明の認証代行装置の一態様においては、認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段と、を備える。
【００１６】
本発明の認証代行装置の一態様においては、前記送信データを前記クライアントＢに送信する送信手段を備える。
【００１７】
本発明の認証代行装置の一態様においては、前記送信データを前記クライアントＡに送信する送信手段を備える。
【００１８】
本発明の認証代行装置の一態様においては、前記認証要求の結果、前記認証サーバの別クライアントと前記クライアントＡとの通信の可能化を許可される権限を与える権限データを前記認証サーバから取得する権限データ取得手段と、前記権限データを保持する保持手段と、を備え、前記通信可能化要求手段は、前記権限データに基づいて前記通信の可能化を要求する。
【００１９】
本発明の認証代行装置の一態様においては、当該認証代行装置は、予め信頼関係が構築された外部装置と通信可能に設定され、当該認証代行装置は、さらに、前記可能化データ取得手段が前記可能化データを取得する前に、前記データ受信手段が前記送信すべきデータを受信した場合に、前記送信すべきデータを前記外部装置に送信して保管させる保管手段と、前記可能化データ取得手段が前記可能化データを取得した後に、前記外部装置から前記送信すべきデータを再受信するデータ再受信手段と、を備える。
【００２０】
本発明の認証代行装置の一態様においては、クライアントＡは、利用者の利用権限の下で処理を行う装置であり、当該認証代行装置は、前記利用者の利用権限の下で前記クライアントＢに対する通信についての処理を行う。
【００２１】
本発明の認証代行プログラムの一態様においては、認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段、としてコンピュータを機能させる。
【００２２】
本発明の認証代行システムの一態様においては、認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段と、を備える。
【発明の効果】
【００２３】
請求項１に記載の本発明によれば、クライアントＡでは、認証サーバを利用するための設定を行わなくても、認証代行装置への対応設定をすることで、認証サーバの別のクライアントＢとの通信が可能となる。また、クライアントＡでは、可能化データを利用して送信データの生成する処理が不要となる。
【００２４】
請求項２に記載の本発明によれば、クライアントＡでは、可能化データに基づき生成された送信データを送信する必要がなくなる。
【００２５】
請求項３に記載の本発明によれば、クライアントＡでは、可能化データに基づき生成された送信データを、自ら生成することなく取得することが可能となる。そして、この送信データに基づいて、クライアントＢと通信を行うことが可能となる。
【００２６】
請求項４に記載の本発明によれば、クライアントＡが権限データを保持しなくても、通信認可の要求を行うことが可能となる。
【００２７】
請求項５に記載の本発明によれば、クライアントＡでは、送信すべきデータを早期に認証代行装置に送信してしまうことができ、かつ、認証代行装置では、クライアントＢへの送信までの間、継続して送信すべきデータを保持する必要がなくなる。特に、送信すべきデータ量が比較的多い場合に、認証代行装置における負荷が軽減される。
【００２８】
請求項６に記載の本発明によれば、利用者毎に通信の制御を行うことが可能となる。
【００２９】
請求項７に記載の本発明によれば、クライアントＡでは、認証サーバを利用するための設定を行わなくても、認証代行装置への対応設定をすることで、認証サーバの別のクライアントＢとの通信が可能となり、また、クライアントＡでは、可能化データを利用して送信データの生成する処理が不要となるプログラムが提供される。
【００３０】
請求項８に記載の本発明によれば、クライアントＡでは、認証サーバを利用するための設定を行わなくても、認証代行装置への対応設定をすることで、認証サーバの別のクライアントＢとの通信が可能となり、また、クライアントＡでは、可能化データを利用して送信データの生成する処理が不要となるシステムが提供される。
【発明を実施するための最良の形態】
【００３１】
以下に本実施の形態について例示する。
【００３２】
本実施の形態では、認証サーバ、認証代行装置である認証エージェント、及び、認証サーバのクライアントである画像処理装置や文書サーバなどを示して説明を行う。画像処理装置や文書サーバなどは、上記クライアントＡやクライアントＢに対応する。また、本実施の形態では、主として、Ｋｅｒｂｅｒｏｓによる認証技術を前提とした説明を行う。なお、サーバとは、クライアントの要求に応じてサービスを提供する装置をいい、クライアントは、サーバの提供するサービスを享有する装置をいう。
【００３３】
まず、図１を用いて、コンピュータのハードウエア構成を説明する。図１は、本実施の形態にかかる画像処理装置１０のハードウエア構成を示す図である。画像処理装置１０は、コントローラボード１２を備えている。そして、コントローラボード１２上には、内部通信経路としてのバス１４が設けられ、バス１４に対しては、ＣＰＵ（中央処理装置）１６、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）１８、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）２０、ＮＶＲＡＭ（ＮｏｎＶｏｌａｔｉｌｅＲＡＭ）２２、ＨＤＤ（ＨａｒｄＤｉｓｃＤｒｉｖｅ）２４、画像処理部２６、ＵＩ＿ＩＦ（ユーザインタフェース＿インタフェース）２８、通信ＩＦ３６、ＤｅｖｉｃｅＩＦ４６が接続されている。
【００３４】
ＣＰＵ１６は画像処理装置の主たる制御を行う処理部であり、プログラムに従って動作する。ＣＰＵ１６には、プログラム構成に対応した様々な処理機能が構築される。ＲＯＭ１８は、書き換え不可能な不揮発性メモリであり、プログラムや固定データを格納する。ただし、ＲＯＭ１８を、フラッシュメモリによる書き換え可能な構成としてもよい。ＲＡＭ２０は、書き換え可能な揮発性メモリであり、プログラム動作のためのシステムメモリや、画像処理のためのページメモリとして使われる。ＮＶＲＡＭ２２は、書き換え可能な不揮発性メモリであり、不揮発性のデータ、画質調整、各種設定パラメータ、各種履歴の格納を行う。ＨＤＤ２４は、磁気ディスク等により構築された大容量記憶装置であり、画像データや各種履歴の格納を行う。画像処理部２６は、コプロセッサなどの画像処理専用回路を備え、画像データの伸張圧縮処理や各種画像処理を行う。
【００３５】
ＵＩ＿ＩＦ２８は、ＵＩ３０とのインタフェースである。ＵＩ＿ＩＦ２８には、コントローラボード１２外に設けられたＵＩ３０が接続されており、ＵＩ３０は、ディスプレイや発光ダイオード等の表示部３２とハードキーやタッチパネル等の操作部３４を含んでいる。
【００３６】
通信ＩＦ３６は、各種の外部装置やネットワークへのインタフェースである。通信ＩＦ３６には、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）３８、Ｓｅｒｉａｌ４０、ＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）４２、モデム４４の各種インタフェースが接続されている。ＬＡＮ３８は、１０／１００ＢＡＳＥ−Ｔなどによる有線形式や、無線形式でネットワークに接続する。Ｓｅｒｉａｌ４０は、各種外部周辺装置への直接的な接続に用いられ、ＵＳＢ４２は、ＵＳＢ１．１やＵＳＢ２．０などをサポートする装置への直接接続に使用される。また、モデム４４は、ＦＡＸなどの公衆回線への接続を行う。
【００３７】
ＤｅｖｉｃｅＩＦ４６には、コントローラボード１２外に設けられたスキャナ、プラテン、自動原稿読取装置(両面も可)等の読取装置部４８と、プリントエンジンなどを含む印刷装置部４９とが接続されている。読取装置部４８は、用紙を読み取って新たに画像データを生成する画像処理を行い、印刷装置部４９は画像データに基づいて用紙に画像を印刷する画像処理を行う。
【００３８】
なお、ＣＰＵ１６を制御するプログラムは、典型的には、製造段階でＲＯＭ１８に格納される。しかし、例えば、ＬＡＮ３８を用いてネットワークからプログラム信号を受信することで、ＮＶＲＡＭ２２にプログラムをインストールすることができる。また、プログラムのインストールは、ＣＤ（コンパクトディスク）をＵＳＢ４２に接続されたＣＤドライブで読み取るなど、記憶媒体を通じて行われてもよい。
【００３９】
以上においては、画像処理装置１０のハードウエア構成について説明したが、この構成は、一般的なコンピュータにおいてもほぼ同様である。一般的コンピュータは、画像処理装置１０と異なり、画像処理部２６、ＤｅｖｉｃｅＩＦ４６、読取装置部４８、印刷装置部４９などの画像処理に特化したハードウエア構成要素を備えないことが多いが、画像処理装置１０と同様に、プログラム制御されるＣＰＵ１６などを備える。本実施の形態で例示する認証エージェント、認証サーバ、文書サーバなどは、一般的なコンピュータをプログラム制御させることで構築可能である。
【００４０】
なお、ハードウエアの各構成要素は、必ずしも一体化している必要はなく、通信可能な複数の部分に分離されていてもよい。また、これらの部分は、ネットワーク上に分散され、分散処理システムを構成していてもよい。
【００４１】
続いて、画像処理装置１０の機能構成について説明する。図２は、図１に示した画像処理装置１０の機能構成例を示した概略ブロック図である。画像処理装置１０には、主たる機能要素として、制御部５０、ユーザ認証要求部５２、ユーザログアウト通知部５４、送受信部５６、転送処理部５８、画像生成部６０、及び印刷部６２が構築されている。
【００４２】
制御部５０は、各機能要素の制御を行う。ユーザ認証要求部５２は、画像処理装置１０にユーザ（利用者）がログイン（ログオン）を試みた場合に、認証エージェントを介して認証サーバに認証を要求する。ユーザログアウト通知部５４は、ユーザがログアウト（ログオフ）した場合、あるいは、そのユーザの指令にかかるジョブが終了した場合に、認証エージェントにその旨を通知する。送受信部５６は、通信ＩＦ３６を介して文書サーバや認証エージェントとデータの送受信を行う。転送処理部５８は、送受信部５６を制御して、受信したデータを転送先にそのまま送信させる転送処理を行う。画像生成部６０は、読取装置部４８を利用して構築されており、用紙を読み取って画像データを生成する。印刷部６２は、印刷装置部４９を利用して構築されており、画像データに基づいて用紙に印刷を行う。
【００４３】
図３は、認証エージェント７０の機能構成例を示した概略ブロック図である。認証エージェント７０には、ユーザ情報登録部７２、ユーザ認証要求受信部７４、ユーザ認証要求部７６、ＴＧＴ取得・記憶部７８、ＴＧＴ更新・無効化部８０、通信要求受信部８２、サービスチケット要求部８４、反復要求部８６、送信データ生成部８８、及び送受信部９０が構築されている。
【００４４】
ユーザ情報登録部７２では、ユーザの認証に必要となる認証情報の登録が行われる。認証情報としては、ユーザＩＤやパスワードなどが挙げられる。登録対象となるユーザは、典型的には、認証サーバ上に登録されたユーザであるが、認証サーバー上に登録されていないユーザであってもよい。後者の場合には、ユーザの属性情報として、認証サーバへの認証要求あるいはネットワークを通じた通信要求が許可されているか禁止されているかを表す情報を含めてもよい。登録は、あらかじめ行われてもよいし、ユーザ認証要求受信部７４が認証情報とともに認証要求を受信した場合に、この認証情報を利用して行われてもよい。登録された認証情報は、認証サーバにユーザの認証を要求するために使用されたり、認証サーバにネットワーク上の装置にアクセスするためのサービスチケット発行を要求するために使用されたりする。
【００４５】
ユーザ認証要求受信部７４は、通信要求受付手段の例であり、画像処理装置１０等のクライアントから、ユーザ認証要求を受信する。認証要求とともに、ユーザＩＤやパスワードなどを受信することもある。なお、ユーザ認証の要求は、明示的に行われてもよいが、暗黙の内に行われてもよい。
【００４６】
ユーザ認証要求部７６は、認証要求手段の例であり、ユーザ認証要求受信部７４の受信結果に従って、認証サーバに対しユーザ認証を要求する。ユーザ認証の要求にあたっては、クライアントから受信した認証情報、あるいは、ユーザ情報登録部７２に格納された認証情報も送信される。
【００４７】
ＴＧＴ取得・記憶部７８は、ユーザ認証要求部７６による認証要求の結果、認証サーバから権限データたるＴＧＴ（以下では、イニシャルチケットと呼ぶ場合もある）及びセッション鍵を取得し、記憶する。ＴＧＴは、サービスチケットを取得する権限を与えるデータである。一般に、ＴＧＴには、適当な有効期間が設定される。
【００４８】
ＴＧＴ更新・無効化部８０は、クライアントにおけるユーザの作業状態に応じて、ＴＧＴの更新や無効化（破棄や、認証サーバへの無効化依頼）を行う。例えば、クライアントとしての画像処理装置１０から、ユーザがログアウト（タイマーによるログアウトでもよい)した旨、あるいは、ログアウト後にユーザの残したジョブが終了した旨が伝えられた場合に、ＴＧＴ更新・無効化部８０は、当該認証エージェント７０におけるそのユーザについてのジョブ処理の終了を確認したうえで、ＴＧＴの無効化を行う。他方、ＴＧＴ更新・無効化部８０は、ユーザのログイン中や、ユーザによるジョブが残っている最中は、ＴＧＴを保持し続け、ＴＧＴの有効期限が切れる前に、認証サーバに対しチケットの更新を要求する。
【００４９】
通信要求受信部８２は、通信要求受信手段の例である。通信要求受信部８２は、クライアントから、ネットワーク上の他装置との通信（受信と送信の一方または両方）を行いたい旨の要求を受ける。要求は、明示的に行われてもよいが、暗黙の内に行われてもよい。
【００５０】
サービスチケット要求部８４は、可能化データ取得手段の例である。サービスチケット要求部８４は、通信要求受信部８２による受信結果に基づいて、通信相手となる装置との通信認可要求を認証サーバに要求するものであり、具体的には通信相手の装置と通信するためのサービスチケットの発行を認証サーバに要求する。要求は、ＴＧＴを利用して行われる。もちろん、認証サーバが許せば、ＴＧＴを用いずに、ユーザ認証に使用した認証情報を再度用いてサービスチケットを要求することも可能である。サービスチケットには、通信相手と認証エージェント７０との間で使用される通信用の共通鍵であるセッション鍵が埋め込まれており、このサービスチケットは通信相手（と認証サーバ）のみが保持する共通鍵によって暗号化されている。したがって、サービスチケットを取得した通信相手は、その復号化に成功した場合には、認証エージェント７０が通信認可を受けていると判断する。そして、取り出したセッション鍵を用いて、認証エージェント７０との間で、暗号化された安全な通信を行うことができる。このように、サービスチケットは、通信相手の装置との通信を可能化する可能化データである。
【００５１】
反復要求部８６は、通信相手の装置との通信に失敗した場合に、再度の通信を試みる。この場合、クライアントの処理を一旦終了させるために、例えば処理をクライアントから当該認証エージェント７０に移管する旨のステータスをクライアントに通知してもよい。なお、設定回数や設定時間を超過しても通信可能とならなかった場合には、反復処理を中止し、クライアントに処理が失敗した旨を通知する。
【００５２】
送信データ生成部８８は、生成手段の例であり、サービスチケット（通信用の共通鍵）を通信相手の装置に渡すための送信データや、通信対象となるデータを通信用の共通鍵で暗号化した送信データを生成する。なお、送信データのプロトコルは特に限定されるものではなく、設定に従い、あるいは、クライアントからの指示に従い決定すればよい。プロトコルの例としては、ＳＭＢ（ＳｅｒｖｅｒＭｅｓｓａｇｅＢｌｏｃｋ）、ＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）、ＩＰＰ（ＩｎｔｅｒｎｅｔＰｒｉｎｔｉｎｇＰｒｏｔｏｃｏｌ）などを挙げることができる。
【００５３】
送受信部９０は、データ受信手段、データ再受信手段、送信手段などの例であり、データの送受信を行う。送受信の相手としては、クライアントや、認証サーバの他、クライアントが要求する通信先を挙げることができる。
【００５４】
続いて、図４乃至図８を用いて、本実施の形態にかかるシステム構成について説明する。
【００５５】
［第１のシステム形態］ 図４は、第１のシステム形態の構成を説明する図である。このシステムには、画像処理装置１０、認証エージェント７０、認証サーバ１００、文書サーバ１１０、及び一時保管サーバ１１２が含まれている。
【００５６】
認証サーバ１００は、Ｋｅｒｂｅｒｏｓ認証技術における認証サーバ、鍵配布センタ、チケット交付サーバを兼ねる装置である。認証サーバ１００は、単体の認証システムを構築するものであっても、複数の認証システムの相互認証（クロスレルム認証）により構築されたものであってもよい。
【００５７】
画像処理装置１０は、認証サーバ１００のクライアントであり、図１に示したハードウエア構成及び図２に示した機能構成をもつ装置である。ここで、クライアントとは、認証サーバ１００が提供する認証サービスを享受する装置をいう。ただし、画像処理装置１０は、認証エージェント７０を通じて間接的に認証サーバ１００にサービスを要求し、サービスを享受している。
【００５８】
認証エージェント７０は、図３に示した機能構成をもつ装置であり、画像処理装置１０と認証サーバ１００の間に設置されている。そして、画像処理装置１０からの要求に基づいて認証サーバ１００にサービスを要求し、認証サーバ１００が提供するサービスを画像処理装置１０に還元している。
【００５９】
文書サーバ１１０は、文書データの保管などを行うサーバである。文書サーバ１１０は、認証サーバ１００のクライアントであり、認証サーバ１００による認証サービスを享有している。文書サーバ１１０には、認証サーバ１００と同じ共通鍵が保持されている。
【００６０】
一時保管サーバ１１２は、外部装置の例であり、文書サーバ１１０と同様に文書データなどを保管するサーバである。一時保管サーバ１１２には、認証エージェント７０に比べ大容量のデータを保管することができる。一時保管サーバ１１２は、認証サーバ１００のクライアントであってもよいし、なくてもよい。しかし、一時保管サーバ１１２は、認証エージェント７０と、認証サーバ１００の下で、あるいは、別の認証システムや適当な通信安全設定の下で、安全に通信できることが想定されている。
【００６１】
画像処理装置１０と認証エージェント７０の間の通信経路には、認証サーバが提供する認証システムとは別の設定に基づいて、通信安全性（通信セキュリティ）が確保されている。通信安全性の確保は、例えば、ケーブルの直接接続や、公開鍵認証方式によって行われる。これに対し、画像処理装置１０、認証サーバ１００、及び文書サーバ１１０の間の通信安全性は、認証サーバ１００が提供する方式に基づいて確保されている。
【００６２】
次に、図５のフローチャートを用いて、画像処理装置１０でスキャンされた文書データが、文書サーバ１１０に格納される処理の流れを説明する。
【００６３】
画像処理装置１０は、ユーザがユーザＩＤ、レルム（ネットワーク上の範囲を表す。典型的にはドメイン名が与えられる）、パスワードなどの認証情報を入力すると、その認証情報を認証エージェント７０に送信して外部認証の要求を行う（Ｓ１０）。認証エージェント７０は、認証サーバ１００の方式に従い、認証情報をプリンシパル（処理対象の身元を明らかにする情報であり、典型的にはユーザＩＤとレルムを組合せて作成される）とパスワードに変換して、認証サーバ１００に認証を要求する（Ｓ１２）。そして、認証サーバ１００は、予め登録されたパスワードに基づいてユーザ認証を行う（Ｓ１４）。その結果、認証に失敗すると、その旨が認証エージェント７０に伝えられ（Ｓ１６）、さらに、認証エージェント７０から画像処理装置１０に伝えられ（Ｓ１８）、処理が終了する（Ｓ２０）。他方、認証に成功した場合には、権限データたるＴＧＴが発行されて（Ｓ２２）、認証エージェント７０に送信される。認証エージェント７０は、このＴＧＴを記憶領域に格納し（Ｓ２４）、画像処理装置１０に対して認証に成功した旨を通知する（Ｓ２６）。
【００６４】
ここでは、ログインに成功したユーザは、画像処理装置１０において、文書のスキャンと、これにより生成された文書データの転送先の入力、及び転送指示を行っている（Ｓ２８）。画像処理装置１０では、文書データ、転送先、及びログインユーザのユーザ情報を認証エージェント７０に送信して、転送要求を行う（Ｓ３０）。ユーザ情報は、先に認証したユーザと同一であることを示す情報である。ユーザ情報の例としては、ユーザＩＤとレルムの組み合わせを挙げることができる。
【００６５】
認証エージェント７０は、ＴＧＴと転送先を認証サーバ１００に送信して、転送先へのアクセス認可の要求、すなわち、転送先へのアクセスを可能化するサービスチケットの発行の要求を行う（Ｓ３２）。認証サーバ１００は、ＴＧＴの検証を行い（Ｓ３４）、検証に失敗した場合には、認証エージェント７０にその旨を伝える。そして、認証エージェント７０では、転送が失敗に終わり（Ｓ３６）、その旨が画像処理装置１０に伝えられる。この結果、画像処理装置１０では、文書転送についてのジョブが失敗のまま終了することになる（Ｓ３８，Ｓ４０）。他方、ＴＧＴの検証に成功した場合には、サービスチケットが発行され（Ｓ４２）、認証エージェント７０に送信される。このサービスチケットは、文書サーバ１１０がもつ鍵で暗号化されている。認証エージェント７０は、サービスチケットを記憶領域に格納する（Ｓ４４）。さらに、認証エージェント７０は、文書データとサービスチケットを用いて送信データを生成し、転送先に送信する（Ｓ４６）。送信データの生成は、文書データが転送先によって受け付けられるように、例えば、サービスチケットを添付したり、文書データを暗号化したりして行われる。
【００６６】
転送先である文書サーバ１１０は、送信データを受信すると、送信データに含まれるサービスチケットの復号化を行い、その有効性、つまり、送信データが認証サーバ１００によって通信が認可された相手から送信されたか否かを検証する（Ｓ４８）。そして、検証に失敗した場合には、認証エージェント７０に対しその旨を伝達する。この結果、認証エージェント７０では転送が失敗に終わり（Ｓ５０）、画像処理装置１０は、転送に失敗したままジョブを終了する（Ｓ５２，Ｓ５４）。これに対し、サービスチケットが有効であると判断された場合には、文書サーバ１１０は、送信データから文書データを取り出して格納する（Ｓ５６）。そして、認証エージェント７０は転送成功の報告を受け（Ｓ５８）、画像処理装置１０は成功裡にジョブを終了する（Ｓ６０，Ｓ６２）。
【００６７】
この一連の処理において、認証エージェント７０がサービスチケットを取得する前に、画像処理装置１０から認証エージェント７０に文書データが送信される場合が考えられる。この場合に、認証エージェント７０では、受信した文書データを一時保管サーバ１１２に一時的に保管する。そして、サービスチケットが発行された後で、一時保管サーバ１１２から文書データを再取得する。
【００６８】
また、この一連の処理において、認証エージェント７０がサービスチケットを取得していながら文書サーバ１１０が受信可能状態で無い場合が考えられる。しかし、この場合においても、認証エージェント７０が受信した文書データを一時保管サーバ１１２に一時保管し、文書サーバ１１０が受信可能状態になった後で、一時保管サーバ１１２から文書データを再取得するようにしても良い。
【００６９】
なお、一般に、ＴＧＴには、有効期限が設定されている。そこで、認証エージェント７０は、有効期限を監視し、期限が切れる前にＴＧＴの更新を行うことができる。また、画像処理装置１０においてユーザがログアウトした場合や、ログアウトかつユーザの全ジョブが終了した場合に、画像処理装置１０は、その旨を認証エージェント７０に通知する。そして、認証エージェント７０は、このユーザについてのジョブ実行を委託されたものがないことを確認し、ユーザのＴＧＴを破棄する。
【００７０】
［第２のシステム形態］ 図６は、第２のシステム形態にかかる構成を説明する図である。このシステムには、画像処理装置１０、認証エージェント７０、認証サーバ１００、及びＰＣ（パーソナルコンピュータ）１２０が含まれている。画像処理装置１０、認証エージェント７０、及び認証サーバ１００は、第１のシステム形態と同様の装置である。すなわち、画像処理装置１０は認証サーバ１００のクライアントであり、認証エージェント７０は画像処理装置１０の認証処理の少なくとも一部を代行する装置である。また、画像処理装置１０と認証エージェント７０の通信は、独自の方式で、安全化が図られている。ＰＣ１２０は、認証サーバ１００のクライアントである。
【００７１】
次に、図７のフローチャートを用いて、ＰＣ１２０から画像処理装置１０に対し文書データの印刷が要求される場合の処理の流れを説明する。ＰＣ１２０では、まず、認証サーバ（ＫＤＣ）１００に対し認証情報を送信してユーザ認証を求め、ＴＧＴを獲得する（Ｓ７２）。続いて、ＰＣ１２０は、認証サーバ１００に対し、ＴＧＴと転送先の情報を送信して、画像処理装置１０にアクセスするためのサービスチケットを要求する（Ｓ７４）。認証サーバ１００は、ＴＧＴを検証してサービスチケット発行の可否を判定し（Ｓ７６）、発行不可能な場合にはその旨をＰＣ１２０に伝達し、発行可能な場合にはサービスチケットを発行してＰＣ１２０に送信する（Ｓ７８）。そして、ＰＣ１２０は、取得したサービスチケットを記憶領域に格納する（Ｓ８０）。なお、ＰＣ１２０が既にＴＧＴやサービスチケットを獲得している場合には、これらのステップを繰り返す必要はない。
【００７２】
続いて、ＰＣ１２０は、ユーザが文書データの印刷を指示する（Ｓ８２）。これを受けて、ＰＣ１２０は、通信用のコンテキストを初期化し（Ｓ８４）、画像処理装置１０に対し、サービスチケットを含むメッセージを送信する。このメッセージは、画像処理装置１０によって、認証エージェント７０にリダイレクトされる（Ｓ８６）。
【００７３】
認証エージェント７０では、画像処理装置１０がまだ認証を受けていない場合には、認証サーバ１００に対し、画像処理装置１０のプリンシパル名やパスワードを送信して、ＴＧＴの発行を要求する処理が行われる（Ｓ８８）。そして、認証サーバ１００は、ＴＧＴの検証を行い（Ｓ９０）、発行可能な場合には、ＴＧＴ（イニシャルチケット）を発行して認証エージェント７０に送信する（Ｓ９２）。
【００７４】
認証エージェント７０は、このＴＧＴを記憶領域に格納する（Ｓ９４）。そして、ＰＣ１２０から送られたサービスチケットを、画像処理装置１０と共有している共有鍵で復号化し、時刻検証処理などを行う。アクセスが正当なものであると判断した場合、認証エージェント７０は、コンテキストを受け入れ、さらに、ＰＣ１２０に通知すべきプロトコル情報などについての応答メッセージを作成する（Ｓ９６）。画像処理装置１０は、受信した応答メッセージをＰＣ１２０に送信し（Ｓ９８）、これにより画像処理装置１０においてコンテキストが確立する（Ｓ１００）。
【００７５】
ＰＣ１２０は、印刷対象となる文書データ及び印刷指示データを通信用の鍵で暗号化して画像処理装置１０に送信し、画像処理装置１０は、それを認証エージェント７０にリダイレクトする。また、認証エージェント７０は、文書データ及び印刷指示データを復号化し、画像処理装置１０に渡す（Ｓ１０２）。この過程は、画像処理装置１０が、全データを獲得するまで繰り返される。
【００７６】
最後に、ＰＣ１２０は、セッションを閉じて、サービスチケットを破棄し（Ｓ１０４）、処理を終了する（Ｓ１０６）。また、認証エージェント７０は、セッションを閉じて、ＴＧＴを破棄し（Ｓ１０８）、処理を終了する（Ｓ１１０）。そして、画像処理装置１０は、印刷指示データに基づいて文書データの印刷を行い（Ｓ１１２）、処理を終了する（Ｓ１１４）。
【００７７】
［第３のシステム形態］ 図８は、第３のシステム形態にかかる構成を説明する図である。このシステムには、第１のシステム形態と同様に、画像処理装置１０、認証エージェント７０、認証サーバ１００、文書サーバ１１０、及び一時保管サーバ１１２が含まれている。
【００７８】
ここでは、画像処理装置１０から文書サーバ１１０へ文書データを送信する処理について説明する。処理では、まず、画像処理装置１０において、ユーザが認証情報を入力する。そして、画像処理装置１０は、認証エージェント７０に対し、認証情報を送信して認証を要求し、認証エージェント７０は、外部の認証サーバ１００に対し、認証情報を送信してユーザ認証を要求する。認証に成功した場合、認証サーバ１００においてＴＧＴが発行され、認証エージェント７０に送信されて保存される。
【００７９】
画像処理装置１０のユーザは、文書の読み取りにより文書データを生成させるとともに、この文書データを文書サーバ１１０に送信する指示を行う。この場合、画像処理装置１０は、設定に従って、認証エージェントに対し、文書データとプロトコル情報をリダイレクト送信する。認証エージェント７０は、プロトコル情報に基づいて、文書サーバ１１０へ文書データを送信するための送信データを生成し、デバイスに通知する。
【００８０】
この過程で、認証エージェント７０は、サービスチケットが必要であれば、認証サーバ１００に対してＴＧＴを用いてサービスチケットの発行を要求する。そして認証サーバ１００は、文書サーバ１１０の共通鍵で暗号化されたサービスチケットを発行する。また、認証エージェント７０は、文書サーバ１１０との通信用に作成された鍵を用いて、電子文書の暗号化等を行う。
【００８１】
こうして、作成された送信データは、画像処理装置１０に送信され、さらに画像処理装置１０によって文書サーバ１１０へと転送される。なお、認証エージェント７０は、文書サーバ１１０とのネゴーシエーションや、文書サーバ１１０からの送信データの復号化なども同じ経路を利用して行う。すなわち、本システム形態では、画像処理装置１０が、認証サーバ１００の配下にある文書サーバ１１０と通信を行う場合、全ての送受信データ（あるいは認証、暗号化、複合化等が必要なデータ）を認証エージェント７０にリダイレクト送信し、認証、暗号化、復号化等の処理を行わせる。なお、一時保管サーバ１１２の役割は、第１のシステム形態と同様である。すなわち、認証エージェントによる認証処理を待つ間、認証エージェント７０が保持すべきデータが一時保管サーバ１１２に一時的に保管される。
【００８２】
以上の説明では、通信を行う一方のクライアントのみが認証エージェントを使用している態様について示したが、両方のクライアントが認証エージェントを使用してもよい。両方のクライアントが異なる認証エージェントを使用する場合には、認証エージェントは上述の通りの処理を行えばよい。しかし、両方のクライアントが同じ認証エージェントを使用する場合には、暗号化と復号化が同じ認証エージェントで行われることになる。つまり、暗号化及び復号化を行う必要がなくなり、ゆえに、認証サーバにサービスチケットの発行を求める必要もなくなる。したがって、同じ認証エージェントを使用するクライアント同士が通信を行う場合には、認証エージェントでは、認証サーバの認可をうけることなく両者の通信を許すことが可能となる。
【００８３】
また、以上の説明においては、共通鍵を用いるＫｅｒｂｅｒｏｓの認証技術を前提としたが、本実施の形態は、他の認証システムにも適用可能である。例えば、Ｋｅｒｂｅｒｏｓの認証技術における共通鍵を用いた処理の一部または全部に対し、公開鍵暗号方式を導入することが考えられる。
【図面の簡単な説明】
【００８４】
【図１】本実施の形態にかかる画像処理装置のハードウエア構成例を示す図である。
【図２】本実施の形態にかかる画像処理装置の機能構成例を示す図である。
【図３】本実施の形態にかかる認証エージェントの機能構成例を示す図である。
【図４】第１のシステム形態における構成を示す図である。
【図５】第１のシステム形態における処理の流れを示すフローチャートである。
【図６】第２のシステム形態における構成を示す図である。
【図７】第２のシステム形態における処理の流れを示すフローチャートである。
【図８】第３のシステム形態における構成を示す図である。
【符号の説明】
【００８５】
１０ 画像処理装置、１２ コントローラボード、１４ バス、１６ ＣＰＵ、１８ ＲＯＭ、２０ ＲＡＭ、２２ ＮＶＲＡＭ、２４ ＨＤＤ、２６ 画像処理部、２８ ＵＩ＿ＩＦ、３０ ＵＩ、３２ 表示部、３４ 操作部、３６ 通信ＩＦ、３８ ＬＡＮ、４０ Ｓｅｒｉａｌ、４２ ＵＳＢ、４４ モデム、４６ ＤｅｖｉｃｅＩＦ、４８ 読取装置部、４９ 印刷装置部、５０ 制御部、５２ ユーザ認証要求部、５４ ユーザログアウト通知部、５６ 送受信部、５８ 転送処理部、６０ 画像生成部、６２ 印刷部、７０ 認証エージェント、７２ ユーザ情報登録部、７４ ユーザ認証要求受信部、７６ ユーザ認証要求部、７８ ＴＧＴ取得・記憶部、８０ ＴＧＴ更新・無効化部、８２ 通信要求受信部、８４ サービスチケット要求部、８６ 反復要求部、８８ 送信データ生成部、９０ 送受信部、１００ 認証サーバ、１１０ 文書サーバ、１１２ 一時保管サーバ、１２０ ＰＣ。
【特許請求の範囲】
【請求項１】
認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、
前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、
前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、
前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、
前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、
前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段と、
を備えることを特徴とする認証代行装置。
【請求項２】
請求項１に記載の認証代行装置において、
前記送信データを前記クライアントＢに送信する送信手段を備えることを特徴とする認証代行装置。
【請求項３】
請求項１に記載の認証代行装置において、
前記送信データを前記クライアントＡに送信する送信手段を備えることを特徴とする認証代行装置。
【請求項４】
請求項１に記載の認証代行装置において、
前記認証要求の結果、前記認証サーバの別クライアントと前記クライアントＡとの通信の可能化を許可される権限を与える権限データを前記認証サーバから取得する権限データ取得手段と、
前記権限データを保持する保持手段と、
を備え、
前記通信可能化要求手段は、前記権限データに基づいて前記通信の可能化を要求することを特徴とする認証代行装置。
【請求項５】
請求項１に記載の認証代行装置において、
当該認証代行装置は、予め信頼関係が構築された外部装置と通信可能に設定され、
当該認証代行装置は、さらに、
前記可能化データ取得手段が前記可能化データを取得する前に、前記データ受信手段が前記送信すべきデータを受信した場合に、前記送信すべきデータを前記外部装置に送信して保管させる保管手段と、
前記可能化データ取得手段が前記可能化データを取得した後に、前記外部装置から前記送信すべきデータを再受信するデータ再受信手段と、
を備えることを特徴とする認証代行装置。
【請求項６】
請求項１乃至５のいずれか１項に記載の認証代行装置において、
クライアントＡは、利用者の利用権限の下で処理を行う装置であり、
当該認証代行装置は、前記利用者の利用権限の下で前記クライアントＢに対する通信についての処理を行うことを特徴とする認証代行装置。
【請求項７】
認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、
前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、
前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、
前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、
前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、
前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段、
としてコンピュータを機能させることを特徴とする認証代行プログラム。
【請求項８】
認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、
前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、
前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、
前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、
前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、
前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段と、
を備えることを特徴とする認証代行システム。
【請求項１】
認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、
前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、
前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、
前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、
前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、
前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段と、
を備えることを特徴とする認証代行装置。
【請求項２】
請求項１に記載の認証代行装置において、
前記送信データを前記クライアントＢに送信する送信手段を備えることを特徴とする認証代行装置。
【請求項３】
請求項１に記載の認証代行装置において、
前記送信データを前記クライアントＡに送信する送信手段を備えることを特徴とする認証代行装置。
【請求項４】
請求項１に記載の認証代行装置において、
前記認証要求の結果、前記認証サーバの別クライアントと前記クライアントＡとの通信の可能化を許可される権限を与える権限データを前記認証サーバから取得する権限データ取得手段と、
前記権限データを保持する保持手段と、
を備え、
前記通信可能化要求手段は、前記権限データに基づいて前記通信の可能化を要求することを特徴とする認証代行装置。
【請求項５】
請求項１に記載の認証代行装置において、
当該認証代行装置は、予め信頼関係が構築された外部装置と通信可能に設定され、
当該認証代行装置は、さらに、
前記可能化データ取得手段が前記可能化データを取得する前に、前記データ受信手段が前記送信すべきデータを受信した場合に、前記送信すべきデータを前記外部装置に送信して保管させる保管手段と、
前記可能化データ取得手段が前記可能化データを取得した後に、前記外部装置から前記送信すべきデータを再受信するデータ再受信手段と、
を備えることを特徴とする認証代行装置。
【請求項６】
請求項１乃至５のいずれか１項に記載の認証代行装置において、
クライアントＡは、利用者の利用権限の下で処理を行う装置であり、
当該認証代行装置は、前記利用者の利用権限の下で前記クライアントＢに対する通信についての処理を行うことを特徴とする認証代行装置。
【請求項７】
認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、
前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、
前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、
前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、
前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、
前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段、
としてコンピュータを機能させることを特徴とする認証代行プログラム。
【請求項８】
認証サーバのクライアントＡから、前記認証サーバのクライアントＢとの通信要求を受信する通信要求受信手段と、
前記クライアントＡから、前記クライアントＢへ送信すべきデータを受信するデータ受信手段と、
前記認証サーバに対して、前記クライアントＡについての認証要求を行う認証要求手段と、
前記認証サーバに対して、前記クライアントＡと前記クライアントＢの通信の可能化を要求する通信可能化要求手段と、
前記認証サーバから、前記クライアントＢとの通信を可能にする可能化データを取得する可能化データ取得手段と、
前記可能化データ及び前記送信すべきデータに基づいて、前記クライアントＢに送信する送信データを生成する生成手段と、
を備えることを特徴とする認証代行システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００８−１１７０６９（Ｐ２００８−１１７０６９Ａ）
【公開日】平成２０年５月２２日（２００８．５．２２）
【国際特許分類】
【出願番号】特願２００６−２９８０９１（Ｐ２００６−２９８０９１）
【出願日】平成１８年１１月１日（２００６．１１．１）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
【公開日】平成２０年５月２２日（２００８．５．２２）
【国際特許分類】
【出願日】平成１８年１１月１日（２００６．１１．１）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
[ Back to top ]