JP2005149341A - 認証方法および装置、サービス提供方法および装置、情報入力装置、管理装置、認証保証装置、並びにプログラム - Google Patents

Abstract

【課題】秘密情報の事前共有が不要で、アカウントを所持しないネットワークからでも認証処理やサービス提供要求に対するアクセス制御を行なうことができるようにする。
【解決手段】ユーザがログイン要求しているサービス提供サーバは、先ず、ユーザの認証情報と管理装置情報（認証サーバ情報）を受け付け（Ｓ１０２）、管理装置情報に基づいて問合せ先の管理装置である認証サーバを特定し（Ｓ１０４）、この特定した問合せ先の認証サーバにユーザの認証情報を送付し（Ｓ１０６）、ユーザのアカウントを管理している問合せ先の認証サーバにおいて認証処理を行なう（Ｓ１０８〜Ｓ１１６）。サービス提供サーバは、問合せ先の認証サーバから返送される認証結果を参照して、ログイン要求しているユーザについての認証処理を実行する（Ｓ１２０〜Ｓ１２６）。このユーザ認証を経た後に、ユーザが希望するサービス要求に応答する（Ｓ１２８〜Ｓ１３２）。
【選択図】図４

Description

本発明は、ネットワークに配置されたクライアント装置（たとえばユーザ端末）とサーバ装置との間において、クライアント装置を使用するユーザの認証を行ないアクセスを許可してサービスを提供するための認証方法および装置、サービス提供方法および装置、並びにこれらに用いられる情報入力装置、管理装置、および認証保証装置、並びにプログラムに関する。

より詳細には、１回の認証処理によって通信ネットワークの複数のサーバ装置にアクセスすることができるようにする、いわゆるシングルサインオン（single signon ）技術に関する。

コンピュータのネットワーク化に伴い、コンピュータは端末装置（クライアント装置、ユーザ端末）として使用され、たとえば、個人や企業内で、外部ネットワークへアクセスして、情報提供を受ける機会が増大している。そして、サーバ装置とクライアント装置とをネットワーク接続し、クライアント装置を使用するユーザにサービスを提供することを目的としたシステム（サービス提供システム）も構築されている。

このサービス提供システムにおいて、情報提供などのサービスを行なう際には、通常、アクセス者を認証する認証処理を行なって、登録されたユーザにのみサービスを提供するようにしており、従来、サーバ装置では、個別にアクセス者の情報を管理していた。

ここで、複数のサーバ装置が個々に認証を行なうと、ユーザはサーバ装置ごとに認証を受ける手続きを実行しなければならず、また様々なユーザＩＤやパスワードを使い分ける必要が生じるし、複数パスワードの更新の手間などの管理上の問題も生じる。

このため、ユーザの利便性や管理機能を改善するため、複数サーバの認証とユーザのアクセス制御を一元管理する仕組みとして、ユーザが１回のログインで、複数のサーバにアクセスできるようにするシングルサインオンという仕組みが提案されている。

図１８および図１９は、従来のシングルサインオンの仕組みの一例を示す図である。たとえば、図１８に示す第１例のシングルサインオンでは、本人性を確認する認証処理部２９２を有する認証サーバ２００を１つ設置し、問合せ処理部１２０およびアクセス可否判断処理部１３４を有する各サービス提供サーバ１００と認証サーバ２００とをネットワーク接続する。サービス提供サーバ１００の問合せ処理部１２０は、認証サーバ２００の認証処理部２９２に認証情報を問い合わせることにより認証を行なう（本人性を確認する）。アクセス可否判断処理部１３４は、この認証に成功した場合にサービス提供を開始し、認証に失敗した場合にはアクセスを不可にする。これにより、認証サーバ２００は、ユーザ情報を一元的に管理できるようになり、ユーザは、各サービス提供サーバ１００（図ではＡ，Ｂ，Ｃの３つ）に対して、１つの（共通の）認証サーバ２００での認証情報のみを保持すればよいので、利便性が向上する。

しかしながら、この第１例の仕組みでは、利用するサービス提供サーバ１００が管理主体の異なるネットワークに属している場合には、自身が属するネットワーク外の、管理主体の異なる認証サーバで認証情報を運用することが起こり得るが、セキュリティ上問題がある。たとえば、Ａ社の認証情報と、Ｂ社の認証情報と、Ｃ社の認証情報とを、共通の認証サーバ２００に預けるようなケースであるが、このようなことは、不可能ではないが、社内の個人情報の管理の観点から、運用上問題が生じ得る。各システムでパスワードなどの個人情報を共通に利用することは、問題だからである。

この問題を解消する方法として、図１９に示す第２例のシングルサインオンのように、管理主体が異なるネットワーク（図では９１ａ，９１ｂ，９１ｃ）ごとに認証サーバ（図では２００ａ，２００ｂ，２００ｃ）を設け、認証サーバ同士をネットワーク接続した仕組みが提案されている。

この第２例の仕組みでは、各認証サーバ内の情報を共有するのではなく、認証サーバ同士で事前に秘密情報を共有することによってシングルサインオンを実現する。たとえば、ユーザは、認証サーバ２００ａで持つアカウントを使用して管理主体の異なるネットワーク９１ｂ内のサービス提供サーバ１００ｂを使用する際には、先ず、アカウントのあるネットワーク９１ａ内の認証サーバ２００ａで認証を行なうことで、その認証サーバ２００ａから認証を受けたというチケットを受け取る。そして、ユーザは、そのチケットを先ずネットワーク９１ａ内の認証サーバ２００ｂに提示する。チケットを提示された認証サーバ２００ｂは、認証サーバ同士（ここでは認証サーバ２００ａと認証サーバ２００ｂとの間）で事前に共有した秘密情報を使って、そのチケットの有効性を検証する。

しかしながら、第２例の仕組みでは、認証サーバ同士で取り決めをして、事前に秘密情報を共有しなくてはならないため、事前に取り決めたネットワークとの間でしかシングルサインオンを実現できない。また、ユーザは、チケットを発行してもらうために、必ずアカウント登録をしたネットワーク内で認証を受けた後でないと、他のサービス提供サーバを使用できない。

ところで、近年、無線ＬＡＮスポットやインターネットカフェなどの端末からネットワークに接続する環境、つまり、いつでもどこでもネットワークに繋がる環境が整い始めてきた。

しかしながら、ネットワークに接続するにはネットワークを提供する事業者の課金の面から、ネットワークに接続する際、つまり最初に使用する際に認証が必要となる。認証のためにはアカウント登録が必要であるが、無線ＬＡＮスポットなどを提供する事業者が異なれば、当然新たなアカウント登録が必要になる。つまり、初めて入る店等では環境（無線ＬＡＮ環境やネットワークに接続できる環境）があっても、アカウント登録を済ませないとすぐには利用できないという問題がある。

また、近年、コンビニ（コンビニエンスストア）などに設置されているコピー機やコピー機とＦＡＸ機能やその他の機能を備えた複合機などの店舗設置端末からインターネット上のＷｅｂサーバに接続してコンテンツ（情報の中身）を取得（ダウンロード）することや、会社内のサーバにアクセスすることができるようになってきた。なお、店舗設置端末を利用したサービスの提供においては、コイン投入機などを利用して有料サービスとしている場合もある。

しかし、このような環境が整ってきても、アカウントを所持していない店舗事業者に設置された店舗設置端末が目の前にあっても、先ず、その店舗設置端末を使用するための認証が必要となる。この場合、上述した第２例の仕組みでは、先ずアカウント登録をしたネットワーク内で認証を受ける必要があるが、店舗設置端末は、必ずしも自身がアカウント登録をしたネットワーク内に属するとは限らない（むしろ属しないケースの方が多い）ので、このままでは認証を受ける術がなく、店舗設置端末を使用することができないという問題がある。

また、上述した第１例や第２例の仕組みの他にも、様々なシングルサインオンの仕組みも提案されている（たとえば、特許文献１，２参照）。

特開２００２−０３２３４０号公報 特開２００２−３３５２３９号公報

たとえば、特許文献１では、上述した第１例の問題を解消する他の方法として、ユーザ端末とＷｅｂサーバとの間にＷｅｂサイトにおけるユーザ認証を代行するユーザ認証プロキシ装置を設けることで、ネットワークごとに個別のアカウントを使用可能にしつつ、ユーザ認証プロキシ装置にユーザの認証情報を記憶させ、各サーバへの認証情報入力を、このユーザ認証プロキシ装置にて代行させる仕組みが提案されている。

しかしながら、特許文献１に記載の仕組みでは、ユーザ認証プロキシ装置に全てのユーザの認証情報を記憶させるので、ユーザ認証プロキシ装置に対しての信用の問題が生じる。また、上述した第２例と類似して、必ずユーザ認証プロキシ装置に接続して認証（代行認証）を受けた後でないと、他のサービス提供サーバを使用できない。

また、特許文献２では、上述した第２例の変形例として、第１認証サーバで認証処理された認証トークンを第２認証サーバでユーザ認証に利用するというように、複数のサーバにおける個々のサーバがユーザの認証状態を分散管理することで、各サーバがユーザの認証状態を共有可能にする仕組みが提案されている。

具体的には、ユーザが操作する認証クライアント端末からコンテンツの要求をされた第１認証サーバがユーザの認証を実行して、この認証実行の結果である認証状態を保持し、この認証状態を示す認証トークンを作成しておき（第１認証処理）、この後、ユーザが操作する認証クライアント端末からコンテンツの要求をされた第２認証サーバは、第１認証処理で作成された認証トークンを利用して、ユーザの認証についての処理を行なう（第２認証処理）。

しかしながら、この特許文献２に記載の仕組みでは、上述した第２例と類似して、必ず第１認証サーバに接続して認証を受けた後でないと、他のサービス提供サーバを使用できない。

本発明は、上記事情に鑑みてなされたものであり、管理主体が異なるネットワーク内に設置されているサーバを使用する場合であっても、一度の認証で各サーバが利用できるようにする仕組みを提供することを目的とする。好ましくは、管理主体が異なるネットワーク同士で事前に秘密情報の共有が必要ないことと、アカウントを所持しないネットワークからでも認証処理やアクセス制御を行なうことの２つを満たす仕組みを提供することを目的とする。

本発明に係る認証方法は、ネットワークに配置された装置（ユーザがログイン要求している装置）を使用するユーザの認証を行なう認証方法であって、ユーザの認証情報とこのユーザについてのアカウントを管理する管理装置を示す管理装置情報を受け付ける認証処理情報取得工程と、管理装置情報に基づいて、ユーザについての認証処理を行なうために必要な認証結果を返送させる問合せ先の前記管理装置を特定する問合せ先特定工程と、特定した問合せ先の管理装置にユーザの認証情報を送付する認証情報送付工程と、送付した認証情報に基づいて問合せ先の管理装置にて得られる、ユーザについての認証結果を問合せ先の管理装置から受信する認証結果受信工程と、受信した認証結果に基づいて、ユーザについての認証処理を行なう認証実行工程とを備えるものとした。

認証実行工程において、受信した認証結果に基づいてユーザについての認証処理を行なう手法としては、受信した認証結果をそのまま当該工程の認証結果とする方法、受け付けた管理装置情報と受信した認証結果とに基づいて（利用して）ユーザについての認証処理を行なう方法、また問合せ先の管理装置から、この管理装置についての第三者機関である認証局発行の証明書を受信した場合には、この証明書、認証結果、および管理装置情報に基づいて、ユーザについての認証処理を行なう方法の何れをも採り得る。

本発明に係るサービス提供方法は、ネットワークに配置されたサービス提供装置を使用するユーザの認証を行ないサービス提供装置へのアクセスを許可してサービスを提供するサービス提供方法であって、上記本発明に係る認証方法を実行することでユーザについての認証を行なう工程と、この認証に成功したときにはユーザのサービス提供装置へのアクセスを許可し、失敗したときにはユーザのサービス提供装置へのアクセスを禁止するアクセス制御工程とを備えるものとした。つまり、本発明の認証方法を利用して認証を経た後に、ユーザが希望するサービス要求に応答するようにした。

本発明に係る認証装置は、上記本発明に係る認証方法を実施するのに好適な装置であって、ユーザの認証情報とこのユーザについてのアカウントを管理する管理装置を示す管理装置情報を受け付ける認証処理情報取得部と、認証処理情報取得部が受け付けた管理装置情報に基づいて、ユーザについての認証処理を行なうために必要な認証結果を返送させる問合せ先の管理装置を特定する問合せ先特定処理部と、問合せ先特定処理部が特定した問合せ先の管理装置に認証処理情報取得部が受け付けたユーザの認証情報を送付する問合せ処理部と、問合せ処理部が送付した認証情報に基づいて問合せ先の管理装置にて得られるユーザについての認証結果を、問合せ先の管理装置から受信し、この受信した認証結果に基づいて、ユーザについての認証処理を行なう認証処理実行部とを備えるものとした。

本発明に係るサービス提供装置は、上記本発明に係るサービス提供方法を実施するのに好適な装置であって、上記本発明に係る認証装置と、この認証装置による認証に成功したことを条件としてユーザの前記サービス提供装置へのアクセスを許可し、失敗したことを条件としてユーザのサービス提供装置へのアクセスを禁止するアクセス可否判断処理部とを備えるものとした。

本発明に係る情報入力装置は、上記本発明に係る認証装置やサービス提供装置と組み合わせて使用される装置であって、ユーザの認証情報とこのユーザについてのアカウントを管理する管理装置を示す管理装置情報の入力を受け付け、この受け付けた認証情報および管理装置情報を認証装置に通知する機能部を備えているものとした。

本発明に係る管理装置は、上記本発明に係る認証装置やサービス提供装置と組み合わせて使用される装置であって、ユーザのアカウント情報を保持するアカウント情報保持部と、認証装置やサービス提供装置から受信した認証情報をアカウント情報保持部が保持しているアカウント情報と照合することで認証処理を行ない、認証結果を認証装置やサービス提供装置に送付する認証処理部とを備えるものとした。

本発明に係る認証保証装置は、上記本発明に係る管理装置を構成する装置であって、所定の認証局から認証保証装置の証明書を取得する証明書取得部と、受信したユーザの認証情報を、このユーザについての認証処理を行なう大元の認証装置であるオリジナル認証装置に送付し、オリジナル認証装置から認証結果を受信して、この受信した認証結果を、証明書取得部が取得した証明書とともに出力する問合せ処理部とを備えるものとした。

また従属項に記載された発明は、本発明に係る認証方法および装置やサービス提供方法および装置、あるいは管理装置や認証保証装置のさらなる有利な具体例を規定する。さらに、本発明に係るプログラムは、本発明に係る認証方法および装置やサービス提供方法および装置、あるいは情報入力装置、管理装置、認証保証装置を、電子計算機（コンピュータ）を用いてソフトウェアで実現するために好適なものである。なお、プログラムは、コンピュータ読取り可能な記憶媒体に格納されて提供されてもよいし、有線あるいは無線による通信手段を介して配信されてもよい。

本発明の認証方法および認証装置に依れば、ユーザがログイン要求している装置は、先ず、ユーザの認証情報と管理装置情報を受け付け、管理装置情報に基づいて問合せ先の管理装置を特定し、この特定した問合せ先の管理装置にユーザの認証情報を送付する。そして、ユーザのアカウントを管理している問合せ先の管理装置側において認証処理を行なう。この後、ユーザがログイン要求している装置は、問合せ先の管理装置から返送される認証結果を参照し、ログイン要求しているユーザについての認証処理を実行する。

このため、ユーザがログイン要求している装置と、事前にアカウントを取得している管理装置とが異なる管理主体のネットワークに接続されている場合であっても、ユーザがログイン要求している装置は、入力された管理装置情報を参照して問合せ先の管理装置を特定することで、ログイン要求しているユーザがアカウントを取得している管理装置に接続して、そのユーザの認証可否を問い合わせることが可能となる。

よって、ユーザがログイン要求している装置については直接にアカウントを所有していない場合であっても、既に取得してある同一のアカウントを利用してユーザ認証を行なうことができる。また、図１９に示した第２例の仕組みとは異なり、事前に秘密情報を共有しておく必要はない。

また、本発明のサービス提供方法およびサービス提供装置に依れば、本発明の認証方法を利用してユーザ認証を経た後に、ユーザが希望するサービス要求に応答するようにした。このため、ユーザがサービス要求しているサービス提供装置については直接にアカウントを所有していない場合であっても、既に取得してある同一のアカウントを利用して、そのユーザのサービス提供装置へのアクセスを許可するか否かを制御できる。

以下、図面を参照して本発明の実施形態について詳細に説明する。

＜システムの概要＞
図１は、本発明に係る認証装置やサービス提供装置を利用したサービス提供システムの構成概要を示した図である。このサービス提供システム１は、各デバイスが、イントラネット（ネットワーク９２，９４，９６）やインターネット９８を介してネットワーク接続している状態で、認証処理機能とアクセス制御機能とを実行するように構成されている。具体的には、ユーザにサービスを提供する機能を備えた提供サーバ側に属する第１種デバイス１０と、ユーザについてのアカウントを管理する管理装置としての、ユーザ認証に関わる処理を行なう認証サーバ側に属する第２種デバイス２０および第３種デバイス３０とが通信網９０を介してネットワーク接続されて構成されている。

通信網９０のネットワーク構成としては、たとえば、図示するように、それぞれ管理主体の異なる第１ネットワーク９２、第２ネットワーク９４、および第３ネットワーク９６が、インターネット９８を介して相互に接続されるようになっている。そして、第１ネットワーク９２に第１種デバイス１０が、第２ネットワーク９４に第２種デバイス２０が、第３ネットワーク９６に第３種デバイス３０が接続されている。

また、サービス提供システム１は、ユーザ認証に関わる処理を行なう管理装置を構成する認証サーバ側に属するデバイスとして、第２種デバイス２０や第３種デバイス３０の他に、第１ネットワーク９２に接続された第１種認証サーバ５２と、第３ネットワーク９６に接続された第３種認証サーバ５６を備えている。

このような構成において、提供サーバ側に属する第１種デバイス１０は、ユーザ端末４０を介してもしくは第１種デバイス１０の操作パネル（図示せず）を介してユーザより入力された認証情報と認証サーバ情報とに基づいて、そのユーザについての認証を行なう大元の管理装置を特定し、この特定した管理装置にユーザより入力された認証情報を送る。

なお、ユーザ端末４０としては、ユーザがアカウントを所持しないサービス提供サーバ１００に接続可能な情報処理装置であればよく、たとえば、一時的に利用するノート型のパソコン（パーソナルコンピュータ）やＰＤＡ（Personal Digital Assistant；携帯情報端末）などが該当する。

管理装置側では、少なくとも認証サーバと連携して、アクセス要求しているユーザについて認証処理を行ない、その認証結果と、必要に応じて証明書を、第１種デバイス１０に返す。第１種デバイス１０は、ユーザより入力された認証サーバ情報と、管理装置側から受け取った認証結果や証明書を参照して、アクセス要求しているユーザについて認証処理を行ない、認証に成功した場合には、要求されたサービスの提供を開始する一方、認証に失敗した場合には、アクセスを禁止（不可に）するなど、その認証結果に基づいてサービス要求のアクセス可否を判定・制御（アクセス要求に対する承認処理を）する。

なお、アカウントを管理する管理装置は、少なくとも認証サーバ（認証装置）を備えていればよく、デバイス自身がユーザのアカウントを管理するタイプの第２ネットワーク９４に接続された第２種デバイス２０と、デバイス自身はユーザのアカウントを管理することなく、同一ネットワークに接続され、ユーザのアカウントを管理する大元の認証装置（オリジナル認証装置）から認証結果を得るタイプの、第３ネットワーク９６に接続された第３種デバイス３０がある。

また、管理装置は、後述するように、ユーザについての認証処理を行なう大元の認証サーバと、この認証サーバの保証を行なう仲介機能を備えた認証保証サーバ（認証保証装置）とを含む構成としてもよい。この場合、認証保証サーバのような仲介機能を備えたサーバを介して、ユーザより入力された認証情報を大元の認証サーバに送る。

また、管理装置は、第３者認証機関である認証局（ＣＡ；Certificate Authority ）３００からの証明を得ているタイプのものと、認証局３００からの証明を得ていないタイプのものとがある。認証局３００からの証明を得ているタイプのものは、それ自体が認証局３００から認証を得ているタイプのもの（本例では第２種認証サーバ）単独で構成することもできるし、認証局３００からの証明を得ていないタイプのもの（本例では第３種認証サーバ）および認証局３００からの証明を得て第３種認証サーバの保証を行なう認証保証サーバの組合せにて構築することもできる。

たとえば、ユーザが、第２ネットワーク９４に接続されている第２種デバイス２０においてアカウントを所持している場合、第２種デバイス２０が第２種認証サーバの機能を持つ。また、ユーザが、第３ネットワーク９６に接続されている第３種デバイス３０の使用時に第３ネットワーク９６に接続されている第３種認証サーバ５６にてアカウントを所持している場合、第３種デバイス３０が認証保証サーバの機能を持つ。

ここで、図１に示したサービス提供システム１の構成は、後述する各実施形態の全ての要素を取り込んだベストモードの態様を示している。少なくとも、管理装置側では、後述する各実施形態に応じて、必要なデバイス２０，３０や認証サーバ５２，５６を選択的に使用してシステムを構築することとなる。以下具体的に説明する。

＜第１実施形態＞
図２は、サービス提供システム１の第１実施形態のネットワーク構成を示した図である。図１に示した全体概要との相違は、第１種認証サーバ５２を備えていない点にある。この第１実施形態の構成は、第１種デバイス１０またはユーザ端末４０が第１ネットワーク９２に接続している状態で、第１種デバイス１０またはユーザ端末４０を使用する際にユーザ認証が必要な場合に対応したものである。

認証サーバ側においては、第２種デバイス２０は、装置自身がユーザのアカウントを管理するオリジナル認証装置の機能を持つ。一方、第３種デバイス３０側は、自装置が属する第３ネットワーク９６内の第３種認証サーバ５６（オリジナル認証装置の機能を持つ）にてアカウントを管理し、第３種デバイス３０は、そのアカウント情報を利用する。

＜構成例１＞
図３は、第１実施形態のネットワーク構成において、認証機能とアクセス制御機能に着目した、サービス提供システム１の具体的な構成（構成例１）を示したブロック図である。ここでは、第１種デバイス１０として、コンビニなどに設置される複合機を一例に、この第１種デバイス１０がサービス提供サーバ１００として機能するものとして説明する。

先ず、図２に示した第１種デバイス１０もしくはユーザ端末４０に、サービス提供サーバ１００の機能が組み込まれる。図では、第１種デバイス１０にサービス提供サーバ１００の機能が組み込まれている例で示しており、サービス提供サーバ１００（第１種デバイス１０）は、図示しない操作パネルを介した入力もしくはユーザが使用するユーザ端末４０から、認証情報Ｊ１２と認証サーバ情報Ｊ２２を受け取る。認証サーバ情報Ｊ２２は、管理装置情報の一例であって、ユーザが認証を受ける認証サーバの情報である。

サービス提供サーバ１００の操作パネルを介した入力の場合、操作パネルとアクセスインタフェース部１０２により本発明の情報入力装置が構成され、アクセスインタフェース部１０２が、ユーザの認証情報Ｊ１２と、ユーザについてのアカウントを管理する管理装置を示す管理装置情報の入力を受け付ける情報受付部、並びに情報受付部が受け付けた認証情報および管理装置情報を問合せ先特定処理部１１０に通知する通知部の機能を持つ。

一方、ユーザ端末４０介した入力の場合、図示しないが、ユーザ端末４０に、ユーザの認証情報Ｊ１２と、ユーザについてのアカウントを管理する管理装置を示す管理装置情報の入力を受け付ける情報受付部、並びに情報受付部が受け付けた認証情報および管理装置情報をサービス提供サーバ１００に通知する通知部を設ける。

認証サーバ情報Ｊ２２としては、アカウントを取得したサーバの情報を示すことができるものであればよく、たとえば、ＵＲＬ（Uniform Resource Locators ）やＩＰアドレス（Internet Protocol Address ）（纏めて場所情報Ｊ２４ともいう）、あるいは、ＵＲＬと認証を行なうプロシージャ（プログラム中に含まれる手続き）名などを使用することができる。

サービス提供サーバ１００には、ネットワークを介して、認証局３００からの証明を得ている第２種認証サーバ２０２と、認証局３００からの証明を得ていない第３種認証サーバ２０４とが接続されている。認証局３００は、たとえば、電子取引などで公開鍵（かぎ）暗号技術に基づく電子署名を利用するときに、公開鍵が正当であることを保証する機関であり、公開鍵を配布する企業や個人が偽物でないことを証明することで詐欺などの不正行為を防ぐ。認証結果Ｊ３２が認証局３００から受け取った証明書付きのものであれば、サービス提供サーバ１００は、その認証結果Ｊ３２を安心して使用することができる。

サービス提供サーバ１００は、認証処理情報取得部の一例であるアクセスインタフェース部１０２と、問合せ先特定処理部１１０と、問合せ処理部１２０と、認証処理部１３０と、認証サーバインタフェース部１５０とを備えている。認証処理部１３０は、所定の認証サーバより送付（送信）された認証結果Ｊ３２とアクセスインタフェース部１０２が受け取った認証情報Ｊ１２とに基づいて、認証処理を実行する認証処理実行部１３２と、認証処理実行部１３２の認証結果に基づいてサービス要求のアクセス可否を制御するアクセス可否判断処理部１３４とを有している。

サービス提供サーバ１００におけるアクセス可否判断処理部１３４を除く部分が、本発明の認証装置に対応する。そして、アクセス可否判断処理部１３４を含むサービス提供サーバ１００の全体が、本発明のサービス提供に対応する。

認証サーバ側においては、装置自身がユーザのアカウントを管理する第２種デバイス２０と、自装置が属するネットワーク内の認証サーバにてアカウントを管理する第３種デバイス３０とが存在する。

たとえば、先ず、第２種デバイス２０に対応する第２種認証サーバ２０２は、所定の認証局３００から自装置の証明書を取得して保持する証明書保持部（証明書取得部）２２２と、ユーザのアカウント情報を保持するアカウント情報保持部２４３と、サービス提供サーバ１００から送付された認証情報Ｊ１２をアカウント情報保持部２４３が保持しているアカウント情報と照合して検証することで認証処理を行なう認証処理部２２４とを備えている。

この第２種認証サーバ２０２は、認証結果（認証可否）Ｊ３２と自身の証明書であるサーバ証明書（デバイス証明書）Ｊ４２をサービス提供サーバ１００に送付する。なお、証明書保持部２２２は、予め認証局３００から自装置の証明書を取得して保持しておくことに限らず、必要な都度、証明書を取得する構成としてもよい。

ここで、第２種認証サーバ２０２は、認証結果Ｊ３２をサービス提供サーバ１００に返送するが、この認証結果Ｊ３２が本当に問い合わせに行った認証サーバ（デバイス）からのものであるか否かを補強する目的で、サーバ証明書Ｊ４２を使用する。サーバ証明書Ｊ４２には、認証結果Ｊ３２を返送した認証サーバ（デバイス）がどういった資質のものであるかが、認証局３００の保証の元で記述されている。これによって、サービス提供サーバ１００側では、認証結果Ｊ３２に加えてサーバ証明書Ｊ４２を受け取ることで、受け取った認証結果Ｊ３２の、正当さの信用度が増す。

一方、全てのデバイス（認証サーバ）が、サーバ証明書Ｊ４２をサービス提供サーバ１００に返送できるかというと、必ずしもそうではない。このような場合に備えたものが第３種デバイス３０に対応する第３種認証サーバ２０４である。

第３種認証サーバ２０４（第３種デバイス３０）と接続される第３種認証サーバ５６は、ユーザのアカウント情報を保持するアカウント情報保持部２４３と、第３種認証サーバ２０４から送付された認証情報Ｊ１２をアカウント情報保持部２４３が保持しているアカウント情報と照合して検証することで認証処理を行ない、その結果である認証結果Ｊ３２を第３種認証サーバ２０４に送付する認証処理部２４４を備えている。

第３種認証サーバ２０４（第３種デバイス３０）は、認証結果（認証可否）Ｊ３２をサービス提供サーバ１００に送付する問合せ処理部２３４を備えている。問合せ処理部２３４は、第３種認証サーバ５６に認証情報Ｊ１２を問い合わせて認証結果Ｊ３２を受け取り、これをサービス提供サーバ１００に送付する。このように、問合せ処理部２３４そのものは、直接的には認証処理を行なわないけれども、第３種認証サーバ５６と協働して認証情報Ｊ１２を検証して認証処理を行なうものであり、本発明の管理装置における認証処理部の一例として機能するものである。後述する問合せ処理部２８４も同様である。

なお、第３種デバイス３０としての第３種認証サーバ２０４は、第３種認証サーバ５６と協働して認証処理を行なうものとしているが、第３種認証サーバ２０６のように、ユーザのアカウント情報を保持するアカウント情報保持部２６４を設けて、証明書保持部２２２を備えていない第２種デバイス２０と同様の構成とすることもできる。この場合、第３種認証サーバ５６を利用することなく、第３種認証サーバ２０４単独で、認証処理部２６４にて、サービス提供サーバ１００から送付された認証情報Ｊ１２をアカウント情報保持部が保持しているアカウント情報と照合して検証することで認証処理を行ない、その結果である認証結果Ｊ３２をサービス提供サーバ１００に送付することができる。

図４は、構成例１において採り得る、認証処理およびアクセス制御処理の基本的な手順の一例を示したシーケンス図である。

図３に示した構成において、先ず、サービス要求時に、ユーザ認証を要求された際には、ユーザネームやパスワードなどのアカウント取得時の認証情報Ｊ１２とともに、認証サーバ情報Ｊ２２を入力する（Ｓ１００）。この操作は、サービス提供サーバ１００（第１種デバイス１０）の操作パネル上で行なってもよい。また、ユーザが利用するユーザ端末４０を、サービスを提供する装置であるサービス提供サーバ１００に接続しての場合には、自身が所有するユーザ端末４０の操作画面上にて行なうとよい。この場合、ユーザ端末４０は、入力された認証情報Ｊ１２と認証サーバ情報Ｊ２２とを第１ネットワーク９２を介してサービス提供サーバ１００（第１種デバイス１０）に通知する。なお、ユーザ端末４０がサービス提供サーバ１００の機能を備える場合には、この通知は不要である。

アクセスインタフェース部１０２は、ユーザより入力された認証情報Ｊ１２と認証サーバ情報Ｊ２２を受け取る（Ｓ１０２）。問合せ先特定処理部１１０は、アクセスインタフェース部１０２が受け取った認証サーバ情報Ｊ２２に基づいて、認証サーバインタフェース部１５０を介して接続されている複数の認証サーバの中から、認証を行なう管理装置である認証サーバ（以下問合せ認証サーバともいう）を特定する（Ｓ１０４）。この際、問合せ認証サーバは予め設定する必要がなく、サービスに対するアクセス要求時のログインに際し、その都度ユーザが入力する認証サーバ情報Ｊ２２に従うことで足りる。

問合せ処理部１２０は、第２種認証サーバ２０２もしくは第３種認証サーバ２０４のうち、問合せ先特定処理部１１０によって特定された問合せ認証サーバに、認証情報を問い合わせる（Ｓ１０６）。このため、問合せ処理部１２０は、アクセスインタフェース部１０２が受け取った認証情報Ｊ１２を、問合せ認証サーバに送信する。

なお、問合せ先特定処理部１１０として、次のものを保持しておき、問い合わせる前にチェックしてもよい。たとえば、問い合わせ先は予め設定した信用可能なサーバのリストに含まれているか、あるいは、問い合わせ先は、予め設定した信用できないサーバのリストに含まれないか、などである。

問合せ認証サーバが第２種認証サーバ２０２（第２種デバイス２０）である場合、認証処理部２２４は、サービス提供サーバ１００から受け取った認証情報Ｊ１２を検証して認証処理を行なう（Ｓ１０８−ＹＥＳ，Ｓ１１０）。この後、認証処理部２２４は、認証結果（認証可否）Ｊ３２と自身の証明書であるサーバ証明書Ｊ４２をサービス提供サーバ１００に送付する（Ｓ１１２）。

一方、問合せ認証サーバが第３種認証サーバ５６である場合、認証処理部２４４は、第３種認証サーバ５６と協働し、サービス提供サーバ１００から受け取った認証情報Ｊ１２を検証して認証処理を行なう（Ｓ１０８−ＮＯ，Ｓ１１４）。この後、認証処理部２４４は、認証結果（認証可否）Ｊ３２をサービス提供サーバ１００に送付する（Ｓ１１６）。

サービス提供サーバ１００において、認証サーバインタフェース部１５０は、問合せ認証サーバから認証結果Ｊ３２を受信するとともに、問合せ認証サーバが第２種認証サーバ２０２であった場合にはサーバ証明書Ｊ４２も受信する（Ｓ１２０）。

認証処理実行部１３２は、所定の認証ポリシーに従って、認証処理を行なう。たとえば、問合せ認証サーバが第２種認証サーバ２０２（第２種デバイス２０）であった場合にサーバ証明書Ｊ４２が得られた場合には、先ず、このサーバ証明書Ｊ４２を参照して認証を行なう（Ｓ１２１−ＹＥＳ，Ｓ１２２）。

具体的には、認証処理実行部１３２は、先ず、認証サーバ情報Ｊ２２とサーバ証明書Ｊ４２から認証サーバの正しさを検査する。ここで、検査の内容は、サーバ証明書Ｊ４２が正当な認証局３００が発行したものであることの確認と、問い合わせた認証サーバと同一の認証サーバからの応答であることの確認である。

認証サーバが正当である場合（Ｓ１２３−ＹＥＳ）、認証処理実行部１３２は、問い合わせた認証サーバの認証結果Ｊ３２とサーバ証明書Ｊ４２内の情報を利用して認証を行なう（Ｓ１２４）。

認証方法は、サーバ証明書Ｊ４２によって認証サーバの正しさが証明されたことによって認証結果Ｊ３２をそのまま認証結果とする方法と、サーバ証明書Ｊ４２によって証明された認証サーバのドメイン情報を認証に利用する方法とがある。たとえば後者の場合は、信頼できるドメインリストあるいは信頼できないドメインリストを事前に準備し、そのリスト内に認証サーバのドメイン情報と一致するものがあるかを比較することによって認証結果Ｊ３２を認証結果とするかどうかを判断する。具体的には、ドメイン情報が信頼リスト内にあればＪ３２を認証結果とし、信頼リスト内になければＪ３２の結果によらず、認証を拒否する。信頼できないリストを使用する場合は、その逆である。

一方、サーバ証明書Ｊ４２が得られていない場合、認証処理実行部１３２は、認証サーバインタフェース部１５０が問合せ認証サーバから受信した認証結果Ｊ３２と認証サーバ情報Ｊ２２とに基づいて認証を行なう（Ｓ１２６）。この際、信頼できるドメインリストあるいは信頼できないドメインリストを事前に準備し、認証サーバ情報Ｊ２２のドメイン情報と信頼できるドメインリスト内のドメインが一致した場合のみ、認証結果Ｊ３２をそのまま受け入れる。そうでない場合は、認証結果Ｊ３２によらず、認証を拒否する。なお、認証処理実行部１３２は、問合せ認証サーバから受信した認証結果Ｊ３２そのものを、当該認証処理実行部１３２における認証結果としてもよい。

ここで、「サーバ証明書Ｊ４２が得られていない場合」とは、問合せ認証サーバが第２種認証サーバ２０２（第２種デバイス２０）であった場合にサーバ証明書Ｊ４２が得られない場合と、問合せ認証サーバが第３種デバイス３０であった場合の双方を含む。

なお、問合せ認証サーバが第２種認証サーバ２０２（第２種デバイス２０）であった場合にサーバ証明書Ｊ４２が得られない場合には、即時に認証ＮＧとしてもよい。この点は、認証ポリシーに依存する。

何れの場合も、問合せ認証サーバにて一度認証を行なった後は、たとえばチケットを発行するなりＩＤ番号を振るなどの従来技術を用いることで、サービス提供サーバ１００は、問合せ認証サーバと協働して、アカウント管理を行なうことができるようになる。

アクセス可否判断処理部１３４は、認証処理実行部１３２による認証処理に成功した場合には要求されたサービスの提供を開始する一方（Ｓ１２８−ＹＥＳ、Ｓ１３０）、認証処理に失敗した場合にはアクセスを禁止（不可に）する（Ｓ１２８−ＮＯ、Ｓ１３２）。認証処理実行部１３２を介在させているが、実質的には、アクセス可否判断処理部１３４は、認証結果Ｊ３２（好ましくはサーバ証明書Ｊ４２も）を問い合わせた認証サーバから受け取り、認証サーバ情報Ｊ２２と認証結果Ｊ３２とサーバ証明書Ｊ４２に基づいて、アクセス制御を行なっている。

＜具体的処理；第１例＞
図５は、構成例１において採り得る、認証処理の具体例（第１の具体的処理）の手順の一例を示したシーケンス図である。なお、ここでは、ユーザは、認証局３００からの証明を得ているタイプの第２種認証サーバ２０２（第２種デバイス２０）においてアカウント登録を行なっており、その際のアカウント情報（たとえばユーザＩＤとパスワードを対にしたもの）がアカウント情報保持部２２３に保持されているものとする。

ユーザは、第１種デバイス１０をサービス提供サーバ１００として使用したい場合、第１種デバイス１０に、認証情報Ｊ１２と、認証サーバ情報Ｊ２２一例としてのアカウントを取得したサーバの情報（たとえばＵＲＬやＩＰアドレス）を入力することでログイン要求する（Ｓ２００）。この際、入力は第１種デバイス１０の図示しない操作パネルのキーボードなどから入力するとよい。あるいは、それらの情報を保持している図示しないＩＣカードを図示しないＩＣカードリーダで読み取ることにより第１種デバイス１０に入力する構成としてもよい。

ここでは、アカウントを発行した第２種デバイス２０のＵＲＬが“ｄｅｖ２．ｎｅｔ２．ｃｏｍ”、ＩＤ（Identification；識別子が“ｆｕｊｉ”、パスワードが“ｔａｒｏ”であるものとする。この場合、ユーザは、第１種デバイス１０にＩＤとパスワードとＵＲＬを入力する。たとえば、“ｆｕｊｉ：ｔａｒｏ＠ｄｅｖ２．ｎｅｔ２．ｃｏｍ”などのフォーマットで入力する。なお、このフォーマット形式は事前に決められたものであれば何でもよく、たとえば単純なカンマ区切りで区切ったものでもよい（例：ｆｕｊｉ，ｔａｒｏ，ｄｅｖ２．ｎｅｔ２．ｃｏｍ）。

次に、サービス提供サーバ１００のアクセスインタフェース部１０２は、ユーザよりＩＤ、パスワード、ＵＲＬを受け取る（Ｓ２０２）。問合せ先特定処理部１１０は、入力された情報（ＩＤ、パスワード、ＵＲＬ）を、認証情報Ｊ１２の一例であるＩＤおよびパスワードと、認証サーバ情報Ｊ２２の一例であるＵＲＬ（ｄｅｖ２．ｎｅｔ２．ｃｏｍ）に分離する（Ｓ２０４）。ここで、“ｄｅｖ２．ｎｅｔ２．ｃｏｍ”、ＩＤ、パスワード、ＵＲＬの分離は事前にフォーマット形式を決めておけば可能である。

また、問合せ先特定処理部１１０は、認証サーバ情報Ｊ２２に基づいて、複数の認証サーバの中から、認証情報Ｊ１２を問い合わせる認証サーバを特定し、この特定した問合せ処理部１２０に認証情報Ｊ１２を伝える（Ｓ２０４）。問合せ処理部１２０は、問合せ先特定処理部１１０が特定した認証サーバ（ここでは第２種認証サーバ２０２（第２種デバイス２０））に認証情報Ｊ１２を送信し、認証を問い合わせる（Ｓ２０６）。ここでは、問合せ処理部１２０は、“ｄｅｖ２．ｎｅｔ２．ｃｏｍ”の認証サーバにＩＤ（ｆｕｊｉ）とパスワード（ｔａｒｏ）を認証情報Ｊ１２として送信する。

認証情報Ｊ１２を送信された第２種認証サーバ２０２（第２種デバイス２０；ｄｅｖ２．ｎｅｔ２．ｃｏｍ）は、認証処理部２２４にて認証情報Ｊ１２の検証（認証の正当性のチェック）を行ない（Ｓ２１０）、認証が正当なものである場合には認証ＯＫを、そうでなければ認証ＮＧという認証結果Ｊ３２（認証ＯＫ／ＮＧ）と証明書保持部２２２が保持している認証サーバすなわち第２種認証サーバ２０２（ｄｅｖ２．ｎｅｔ２．ｃｏｍ）の証明書であるサーバ証明書Ｊ４２をサービス提供サーバ１００に送付する（Ｓ２１２）。

第２種認証サーバ２０２からの認証結果Ｊ３２とサーバ証明書Ｊ４２を受信した（Ｓ２２０）サービス提供サーバ１００（第１種デバイス１０）において、認証処理実行部１３２は、図４に示したステップＳ１２２〜Ｓ１２４と同様に、認証結果Ｊ３２と最初に入力された認証サーバ情報Ｊ２２、および送付されたサーバ証明書Ｊ４２、の３つの情報に基づいて、認証可否を判断する（Ｓ２２２）。どのように判断するかは、認証ポリシーに依存する。以下、図４に示したステップＳ１２８〜Ｓ１３２と同様である（Ｓ２２８〜Ｓ２３２）。

ここで、サービス提供サーバ１００（第１種デバイス１０）と認証サーバ（ｄｅｖ２．ｎｅｔ２．ｃｏｍ）の送受信方法は、送信・受信できる方法であれば何でもよい。一例としては、ＨＴＴＰ（Hypertext Transfer Protocol ）のＳＯＡＰ（Simple Object Access Protocol ）を使用した場合には、以下のようにすればよい。先ず、サービス提供サーバ１００（第１種デバイス１０）では、認証サーバのＵＲＬと認証を行なうプロシージャ（メソッド）名でＳＡＯＰを実行する。その際、引数には認証情報Ｊ１２を取る。ここで、認証を行なうプロシージャ名は事前に取り決めておいてもよいし、ユーザが入力した認証サーバ情報に含まれていてもよい。

ＳＯＡＰをコールされた認証サーバとしての第２種認証サーバ２０２（ｄｅｖ２．ｎｅｔ２．ｃｏｍ）では、コールされたプロシージャ（メソッド）を引数である認証情報Ｊ１２とともに実行し、その結果（認証結果）をＳＯＡＰの返り値としてサービス提供サーバ１００に返す。サーバ証明書Ｊ４２の送付は、たとえばＳＳＬ（Secure Sockets Layer）を使用して、サービス提供サーバ１００が確認することができる。

サービス提供サーバ１００が認証サーバとしての第２種認証サーバ２０２（ｄｅｖ２．ｎｅｔ２．ｃｏｍ）にＳＳＬ（より具体的にはＨＴＴＰＳ）で接続すると、認証サーバのサーバ証明書Ｊ４２が、サービス提供サーバ１００に送付される。これによりサービス提供サーバ１００すなわち第１種デバイス１０は、認証サーバの証明書を確認することができる。

このように、第１実施形態の構成例１においては、予め他のネットワーク環境の何れかの管理装置にてアカウントを取得しておくことで、サービス要求をユーザより受け付けた、事前にアカウントを取得していないサーバであるサービス提供サーバ１００では、認証情報Ｊ１２とともに、どこで認証を受けるかという情報である認証サーバ情報Ｊ２２がユーザから入力されることにより、ユーザがアカウントを取得した、異なる管理主体にある管理装置の一例である認証サーバに認証可否を問い合わせることが可能となる。

この結果、サービス提供サーバ１００にアカウントのないユーザに対しても、既に取得してある同一のアカウントを利用して認証を行なうことができる。また、認証状態を一元管理する管理サーバを必要とせずに、シングルサインオン機能を実現することができ、システム構築コストや運用管理コストを軽減することができる。加えて、サービス提供サーバ１００とアカウントを取得している認証サーバとの間で事前に、ユーザＩＤやパスワードなどの秘密情報を共有しておく必要もない。

また、ユーザは、一度認証を所定の認証サーバにて認証を行なうことで、異なるサーバにログインする際には、再度認証を要求されることがないし、いつでもどこでも事前準備なしにネットワークに接続することができ、また、異なるサーバを利用する都度に認証を要求されることもなく、利便性が大幅に向上する。

また、アカウントを所持しないものに一時的にパソコンを使用させる場合など、サービス提供サーバ１００にアカウントを所持しないユーザに対しても、そのユーザが他の認証サーバにてアカウントを持っている場合には、サービス提供サーバ１００は、その他の認証サーバと協働して認証処理を行なうことができる。

加えて、サービス提供サーバ１００にては、ゲストアカウントの使用許可や一時的なアカウント付与を行なう必要がないので、認証処理に際して、アカウント登録や削除の作業あるいはゲストアカウントのパスワードの漏洩といったセキュリティ上の問題を防ぐことができる。

＜構成例２；構成例１の変形例＞
図６は、サービス提供システム１の構成例１に対する変形例（以下構成例２という）を示したブロック図である。なお、ここでは、ユーザは、認証局３００からの証明を得ているタイプの第２種認証サーバ２０２（第２種デバイス２０）においてアカウント登録を行なっているものとする。

この構成例２は、認証情報Ｊ１２や認証サーバ情報Ｊ２２の入力に、予めこれらの情報を記憶した記憶媒体（たとえばＩＣカードなどの可搬型のもの）を利用する点に特徴を有する。また、構成例２は、第１の具体的処理において、認証情報Ｊ１２（具体的にはＩＤとパスワード部分）については、情報入力直後から認証サーバまでの間、暗号化した状態でデータ伝達する一方、認証サーバ情報Ｊ２２については、問合せ先特定処理部１１０が直ぐに認識可能なように暗号化せずに通常のデータ形式で伝達することを可能に構成した点に特徴を有する。なお、この構成例２においては、ＩＣカード３１０を情報入力装置として使用する。

第１種デバイス１０においては、ＩＣカードリーダ／ライタ３２０にＩＣカード３１０を入力すると、ＩＣカード３１０などに認証情報Ｊ１２および認証サーバ情報Ｊ２２の一例である認証サーバの場所情報Ｊ２４を格納するとともに、たとえば共通鍵暗号方式の共通鍵を格納する、あるいは認証サーバとＩＣカード３１０との間で公開鍵暗号方式により認証サーバの鍵を作成して認証サーバの公開鍵をＩＣカード３１０に格納する。以下、この共通鍵や公開鍵を纏めて認証鍵と記述する。

なお、ＩＣカード３１０には事前に取り決めた暗号方式での暗号化機能があるものとする。暗号化機能としては、共通鍵暗号ではＡＥＳ（Advanced Encryption Standard）やトリプルＤＥＳ（Data Encryption Standard）、公開鍵暗号方式ではＲＳＡ（Rivest Shamir Adleman）など、既存の暗号化方法でよい。

第２種認証サーバ２０２は、サービス提供サーバ１００から受信した認証情報Ｊ１２と時間情報Ｊ１４とを保存する認証情報保持部２２６を備えている。

＜具体的処理；第２例＞
図７は、構成例２において採り得る、認証処理の具体例（第２の具体的処理）の手順の一例を示したシーケンス図である。

第２種認証サーバ２０２としての第２種デバイス２０においてユーザがアカウントを取得する際に、ユーザは、ＩＣカード３１０に認証情報Ｊ１２と場所情報Ｊ２４を格納するとともに、認証サーバとしての第２種認証サーバ２０２とＩＣカード３１０と間で（サービス提供サーバ１００を介して）、認証用の認証鍵（ここでは認証サーバの公開鍵）を生成し、この認証鍵をＩＣカード３１０に格納する（Ｓ３００ａ，Ｓ３００ｂ）。

ユーザがＩＣカードリーダ／ライタ３２０にＩＣカード３１０を入力すると、ＩＣカード３１０は、中に格納されている認証情報Ｊ１２と、その時点の時間情報Ｊ１４を、それぞれ認証鍵で暗号化する（Ｓ３０１）。この後、この暗号化した認証情報Ｊ１２Ｃおよび時間情報Ｊ１４Ｃを、同じくＩＣカード３１０に格納している認証サーバの場所情報Ｊ２４（認証サーバ情報Ｊ２２の一例）とともに、サービス提供サーバ１００に通知する（Ｓ３０２）。この通知は、ユーザ端末４０もしくはサービス提供サーバ１００に備えられているＩＣカードリーダ／ライタ３２０がその情報を読み取ることで実現される。

サービス提供サーバ１００の問合せ先特定処理部１１０では、暗号化された“認証情報Ｊ１２Ｃおよび時間情報Ｊ１４Ｃ”と場所情報Ｊ２４とを分離する（Ｓ３０３）。これは、第１の具体的処理と同様にフォーマットを事前に決めておけば分離可能である。分離した場所情報Ｊ２４に基づいて、複数の認証サーバの中から、暗号化された認証情報Ｊ１２Ｃおよび時間情報Ｊ１４Ｃを問合せ認証サーバとしての第２種認証サーバ２０２を特定し、問合せ処理部１２０により、この特定した第２種認証サーバ２０２（第２種デバイス２０）に暗号化された認証情報Ｊ１２Ｃおよび時間情報Ｊ１４Ｃを送信するのは第１の具体的処理と同様である（Ｓ３０４，Ｓ３０６）。

暗号化された認証情報Ｊ１２Ｃおよび時間情報Ｊ１４Ｃを受け取った第２種認証サーバ２０２としての第２種デバイス２０では、認証処理部２２４にて、その認証サーバの認証鍵（ないしは秘密鍵）で暗号化された認証情報Ｊ１２Ｃと時間情報Ｊ１４Ｃとを復号化し、元の認証情報Ｊ１２および時間情報Ｊ１４を得る（Ｓ３０７）。

問合せ認証サーバである第２種認証サーバ２０２では、認証処理部２２４は、先ず復号した認証情報Ｊ１２および時間情報Ｊ１４をデータベースとして認証情報保持部２２６に保存し（Ｓ３０８）、時間情報Ｊ１４と認証情報Ｊ１２が同じものが過去のデータにないかを確認する（Ｓ３０９）。同じものがあった場合には、認証処理部２２４は、認証ＮＧを返答する（Ｓ３０９−ＹＥＳ，Ｓ３１２）。またさらに、時間情報Ｊ１４が一定時間（たとえば１分）以内でない場合には、認証処理部２２４は認証ＮＧを返答してもよい（Ｓ３０９−ＹＥＳ，Ｓ３１２）。他の部分は第１の具体的処理と同様である（Ｓ３２０〜Ｓ３２２）。

次に、同じものがなかった場合には、認証処理部２２４は、認証情報Ｊ１２を検査し、認証情報Ｊ１２が正当なものであれば認証ＯＫを返答する（Ｓ３０９−ＮＯ，Ｓ３１０，Ｓ３１２）。なお、認証処理部２２４は、過去のデータについては、時間情報Ｊ１４が一定時間以内かをチェックする際の一定時間の範囲のものだけを認証情報保持部２２６に保存しておけばよい。

このように、構成例２に依れば、他のネットワークに接続されているサービス提供サーバを利用した際の、アカウント取得時の認証情報Ｊ１２や認証サーバ情報Ｊ２２を予めＩＣカード３１０などの記憶媒体に格納しておき、サービス提供サーバ１００を利用する際には、このＩＣカード３１０を情報入力装置として使用して認証情報Ｊ１２や認証サーバ情報Ｊ２２をサービス提供サーバ１００に通知するようにしたので、ユーザは、これら情報の入力作業が簡便になる。

認証サーバ情報Ｊ２２は、サービス提供サーバ１００から離れた遠隔地にある認証サーバの所在を示す情報であり、文字列の長い情報になることが多く、キーボードからの手入力では、入力に手間取ったり、入力間違いを起こしたり仕勝ちであるが、記憶媒体を利用することで、これらの問題を解消できる。また、キーボードからの手入力を行なう必要がないので、キーロガーが組み込まれることによる個人情報漏洩の問題も起きないので、セキュリティ度合いが改善する。

加えて、個人情報である認証情報Ｊ１２については、ユーザによる情報入力直後から認証サーバまでの間を、つまり、サービス提供サーバ１００が問合せ認証サーバに接続に行く経路を、暗号化した状態でデータ伝達するようにしたので、個人情報の漏洩を防止することができる。また、認証サーバの所在を示す認証サーバ情報Ｊ２２については、情報漏洩の問題が少ないので、暗号化せずに問合せ先特定処理部１１０に通知するようにしたので、問合せ先特定処理部１１０は認証サーバ情報Ｊ２２を受け取ると即時に問合せ認証サーバを特定する処理に取り掛かることができる。

＜構成例３；構成例２の変形例＞
図８は、サービス提供システム１の構成例２に対する変形例（以下構成例３という）を示したブロック図である。なお、ここでは、ユーザは、認証局３００からの証明を得ているタイプの第２種認証サーバ２０２（第２種デバイス２０）においてアカウント登録を行なっているものとする。ＩＣカード３１０の機能および格納されている情報は図８に示した構成例２と同様でよい。

この構成例３は、第２の具体的処理において、情報入力装置としてのＩＣカード３１０−サービス提供サーバ１００（第１種デバイス１０）−第２種認証サーバ２０２（第２種デバイス２０）の３者間で、暗号方式や暗号検査関数を用いたエンティティ認証方式で認証を行なうことを可能に構成した点に特徴を有する。なお、ここではエンティティ認証方式として、チャレンジ／レスポンス方式を用いることとするが、同様あるいは類似の作用効果を奏する他のエンティティ認証方式を用いてもよい。

ネットワーク構成や、認証機能とアクセス制御機能に着目したブロック図そのものは構成例２と相違ないが、チャレンジ／レスポンス方式で認証を行なうため、ＩＣカード３１０−サービス提供サーバ１００（第１種デバイス１０）−第２種認証サーバ２０２（第２種デバイス２０）間でやり取りされる情報に相違がある。

なお、通常のチャレンジ／レスポンス方式では、２者間でのやり取りになるが、この構成例３では、３者間でのやり取りを行なうようにしている点で異なる。３者間でのチャレンジ／レスポンス方式による認証を行なうため、サービス提供サーバ１００における認証処理部１３０を除く各機能部は、この認証を行なう際のコード情報であるチャレンジキーＪ５２とレスポンスコードＪ５２Ｃを中継する機能部として作用する。

＜具体的処理；第３例＞
図９は、構成例３において採り得る、認証処理の具体例（第３の具体的処理）の手順の一例を示したシーケンス図である。

たとえば、第１種デバイス１０であるサービス提供サーバ１００は、ＩＣカード３１０から場所情報Ｊ２４を取得し（Ｓ４０１）、この場所情報Ｊ２４に基づいて問合せ認証サーバを特定し（Ｓ４０２）、この特定した問合せ認証サーバである第２種認証サーバ２０２に接続する。接続された第２種認証サーバ２０２の認証処理部２２４は、たとえば１２８ビット程度のランダムなビット列からなるチャレンジキーＪ５２を生成してサービス提供サーバ１００の問合せ処理部１２０を介してクライアント側であるＩＣカード３１０に送付する（Ｓ４０３）。第２種認証サーバ２０２は、ＩＣカード３１０から送付されるレスポンスコードＪ５２Ｃをチェックするための認証鍵を用意しておく。

チャレンジキーＪ５２を受け取ったＩＣカード３１０は、認証情報Ｊ１２を暗号化するとともに、受け取ったチャレンジキーＪ５２を暗号化してレスポンスコードＪ５２Ｃを生成し（Ｓ４０４）、暗号化した認証情報Ｊ１２ＣとレスポンスコードＪ５２Ｃをサービス提供サーバ１００に送る（Ｓ４０５）。サービス提供サーバ１００は、この認証情報Ｊ１２ＣとレスポンスコードＪ５２Ｃを第２種認証サーバ２０２に送付する（Ｓ４０６）。

第２種認証サーバ２０２の認証処理部２２４は、自身の認証鍵を使って認証情報Ｊ１２ＣとレスポンスコードＪ５２Ｃを復号化し（Ｓ４０７）、この復号した認証情報Ｊ１２およびチャレンジキーＪ５２をデータベースとして認証情報保持部２２６に保存する（Ｓ４０８）。

この後、認証処理部２２４はレスポンスコードＪ５２Ｃを復号して矛盾がないかどうかを確認する、すなわち復号化して得たチャレンジキーＪ５２が先ほど送ったもの（正当なチャレンジキーＪ５２）であるかをチェックすることで、ログイン認証（クライアント認証）を行なう（Ｓ４０９）。

認証処理部２２４は、正当なチャレンジキーＪ５２でない場合には、認証ＮＧをＩＣカード３１０に返送する（Ｓ４０９−ＮＯ，Ｓ４１２）。正当なチャレンジキーＪ５２である場合には（Ｓ４０９−ＹＥＳ）、第２種認証サーバ２０２は、次に認証情報Ｊ１２に基づいて認証の正当性をチェックし（Ｓ４１０）、認証結果Ｊ３２（認証ＯＫ／認証ＮＧ）を送付する（Ｓ４１２）。他の部分は第２の具体的処理と同様である（Ｓ４２０〜Ｓ４２２）。

上記説明では、ＩＣカード３１０の第２種認証サーバ２０２へのレスポンスとして、認証情報Ｊ１２とチャレンジキーＪ５２を暗号化したものを返答したが、暗号化に代えて、認証情報Ｊ１２とチャレンジキーＪ５２を合わせたビット列に対して、逆関数を持たない一方向性関数である暗号検査関数の値（たとえばハッシュ関数によるハッシュ値）を演算し、その結果とＩＤ情報を第２種認証サーバ２０２に返答してもよい。

その際は、第２種認証サーバ２０２では、受け取ったハッシュ値とＩＤ情報から得られるパスワードおよび先ほどのチャレンジキーＪ５２に対してハッシュを取り、その値が同じであれば正当だとすることができる。

このように構成例３に依れば、認証情報Ｊ１２および認証サーバ情報Ｊ２２を入力するＩＣカード３１０、サービス提供を行なうサービス提供サーバ１００、およびユーザについてのアカウントを管理する管理装置の一例である第２種認証サーバ２０２（第２種デバイス２０）の３者間で、チャレンジ／レスポンス方式で認証を行なう。これにより、構成例２と同様に、認証情報Ｊ１２を利用して第２種認証サーバ２０２と協働して認証処理を行なうことを可能にした。逆に言えば、チャレンジ／レスポンス方式などのエンティティ認証方式で構成例２と同様の認証手法を実現するには、エンティティ認証を３者間で行なうことが必要である。

このチャレンジ／レスポンス方式での認証処理に成功した後には、構成例２と同様にして、認証情報Ｊ１２を利用して第２種認証サーバ２０２と協働して認証処理を行なう。このため、サービス提供サーバ１００にアカウントのないユーザに対しても、既に取得してある同一のアカウントを利用して認証処理を不都合なく行なうことができ、また事前に秘密情報を共有しておく必要もない。

また、情報入力装置としてのＩＣカード３１０とアカウントを管理する認証サーバ２０２との間に、サービス提供を行なうサービス提供サーバ１００を介在させた構成としても、サービス提供サーバ１００にて認証サーバ情報Ｊ２２の一例である場所情報Ｊ２４に基づいて問合せ認証サーバとしての第２種認証サーバ２０２を特定して接続し、チャレンジ／レスポンス方式での認証処理を不都合なく行なうことができる。

さらに、チャレンジ／レスポンス方式という暗号方式や暗号検査関数を用いたエンティティ認証方式を採用したので、認証強度を高めることができる。たとえば、構成例２では、認証情報Ｊ１２を暗号化して第２種認証サーバ２０２に伝達することで情報漏洩を防止しいているが、この場合、暗号化された認証情報Ｊ１２Ｃを用いた不正利用（リプレースアタックなど）に対しては防御できない。

これに対して、構成例３で採用しているチャレンジ／レスポンス方式では、ログインの都度チャレンジキーＪ５２を変更することになるので、都度発行されるチャレンジキーＪ５２による認証を経た後でなければ、認証情報Ｊ１２Ｃを用いた認証処理に移行しないので、結果として、暗号化された認証情報Ｊ１２Ｃを用いた不正利用を防止することができる。

＜第２実施形態＞
図１０は、サービス提供システム１の第２実施形態のネットワーク構成を示した図である。この第２実施形態は、認証サーバの証明書を返さない認証サーバを使用する場合、または、認証サーバを外部から隠す場合に対応したものである。

図２に示した第１実施形態の構成との相違は、認証局３００からの証明を得ているタイプの認証サーバを、ユーザのアカウントを管理している認証サーバであって認証局３００からの証明を得ていない第３種認証サーバ２０６と、認証局３００からの証明を得て第３種認証サーバ２０６の保証を行なう認証保証サーバ２０８との組合せにて構築している点にある。この構成においては、第３種認証サーバ５６がユーザのアカウントを管理している第３種認証サーバ２０６の機能を持ち、第３種デバイス３０が認証保証サーバ２０８の機能を持つ。

＜構成例４＞
図１１は、第２実施形態のネットワーク構成において、認証機能とアクセス制御機能に着目したサービス提供システム１の具体的な構成（構成例４）を示したブロック図である。

認証サーバ側において、認証保証サーバ２０８（第３種デバイス３０）と接続される第３種認証サーバ２０６（第３種認証サーバ５６）は、ユーザのアカウント情報を保持するアカウント情報保持部２６３と、第３種認証サーバ２０６から送付された認証情報Ｊ１２をアカウント情報保持部２６３が保持しているアカウント情報と照合して検証することで認証処理を行ない、その結果である認証結果Ｊ３２を第３種認証サーバ２０６に送付する認証処理部２６４を備えている。

認証保証サーバ２０８は、認証局３００から得ている認証保証サーバの証明書を保持する保証サーバ証明書保持部２８２と、第３種認証サーバ２０６に認証情報Ｊ１２を問い合わせ、認証結果Ｊ３２を受け取る問合せ処理部２８４とを備えている。

認証保証サーバ２０８の問合せ処理部２８４は、第３種認証サーバ５６から得られる認証結果Ｊ３２とともに、保証サーバ証明書保持部２８２に保持している自身の証明書を示す保証サーバ証明書Ｊ４４をサービス提供サーバ１００に送付する。

なお、第３種認証サーバ２０６側に、その第３種認証サーバ２０６の証明書を示すサーバ証明書Ｊ４２を設けることで、認証保証サーバ２０８は、保証サーバ証明書保持部２８２を備えずに自身の証明書を示す保証サーバ証明書Ｊ４４に代えて、第３種認証サーバ２０６から受け取ったサーバ証明書Ｊ４２を認証結果Ｊ３２とともにサービス提供サーバ１００に渡す構成とすることもできる。

＜具体的処理；第４例＞
図１２は、構成例４において採り得る、認証処理の具体例（第４の具体的処理）の手順の一例を示したシーケンス図である。ここでは、図５に示した第１の具体的処理の手順との相違部分を中心に説明する。

ユーザは、サービス提供サーバ１００の図示しない操作パネルを介してもしくは自身が使用するユーザ端末４０から、認証情報Ｊ１２（たとえばＩＤおよびパスワード）と、ユーザの認証について責任を持つ認証保証サーバ（ここでは第３種デバイス３０／認証保証サーバ２０８）の情報である認証保証サーバ情報Ｊ２６をサービスを提供しているサービス提供サーバ１００の問合せ先特定処理部１１０に通知する（Ｓ５００，Ｓ５０２）。

認証情報Ｊ１２と認証保証サーバ情報Ｊ２６を通知されたサービス提供サーバ１００は、問合せ先特定処理部１１０により、認証保証サーバ情報Ｊ２６に基づいて、複数の認証保証サーバの中から、認証情報Ｊ１２を問い合わせる認証保証サーバ（問合せ認証保証サーバ）を特定し、この特定した情報を問合せ処理部１２０に伝える（Ｓ５０４）。問合せ処理部１２０は、問合せ先特定処理部１１０が特定した認証保証サーバに認証情報Ｊ１２を送信し、認証を問い合わせる（Ｓ５０６）。この際、問合せ認証保証サーバは予め設定する必要がなく、アクセス要求時に、その都度ユーザが入力する認証サーバ情報Ｊ２２に従う。

問い合わされた認証保証サーバ２０８は、アカウントを管理している第３種認証サーバ２０６に認証情報Ｊ１２を送信し、認証を問い合わせる（Ｓ５０８）。認証情報Ｊ１２を送信された第３種認証サーバ２０６は、認証処理部２６４にて認証情報Ｊ１２の検証（認証の正当性のチェック）を行ない（Ｓ５１０）、認証が正当なものである場合には認証ＯＫ、そうでなければ認証ＮＧという認証結果Ｊ３２（認証ＯＫ／ＮＧ）を送付する（Ｓ５１２）。

認証結果Ｊ３２を受け取った問合せ処理部２８４は、この認証結果Ｊ３２と保証サーバ証明書保持部２８２が保持している認証保証サーバの証明書である保証サーバ証明書Ｊ４４をサービス提供サーバ１００に送付する（Ｓ５１４）。

認証結果Ｊ３２と保証サーバ証明書Ｊ４４を送付されたサービス提供サーバ１００（第１種デバイス１０）において、認証処理実行部１３２は、認証結果Ｊ３２と最初に入力された認証サーバ情報Ｊ２２、および送付された保証サーバ証明書Ｊ４４、の３つの情報に基づいて、所定の認証ポリシーに従って認証可否を判断する（Ｓ５２０〜Ｓ５２８）。

たとえば、先ず、認証保証サーバ情報Ｊ２６と保証サーバ証明書Ｊ４４から認証保証サーバの正しさを検査する。ここで、検査の内容は、証明書が正当な認証局３００が発行したものであることの確認と、問い合わせた認証保証サーバと同一の認証保証サーバからの応答であることの確認である。正しい場合、問い合わせた認証保証サーバの認証結果と認証保証サーバの証明書内の情報を利用して認証を行なう。

アクセス可否判断処理部１３４は、認証処理実行部１３２による認証処理に成功した場合には、要求されたサービスの提供を開始する一方（Ｓ５２８−ＹＥＳ，Ｓ５３０）、認証処理に失敗した場合には、アクセスを禁止（不可に）する（Ｓ５２８−ＮＯ，Ｓ５３２）。

このように、第２実施形態の構成例４において、サービス提供サーバ１００では、認証情報Ｊ１２とともに、どこで認証を受けるかという情報である認証保証サーバ情報Ｊ２６が入力されることにより、先ず、異なる管理主体にある認証保証サーバに認証可否を問い合わせ、認証保証サーバは、さらにアカウントを管理している認証サーバ（前例では第３種認証サーバ２０６）に認証可否を問い合わせることが可能となる。

この結果、認証サーバの証明書を返さない認証サーバを使用する場合や認証サーバを外部から隠す場合、既存の認証サーバをそのまま使用する場合においても、第１実施形態の構成と同様に、予め他のネットワーク環境の何れかの管理装置にてアカウントを取得しておくことで、サービス提供サーバ１００にアカウントのないユーザに対しても、既に取得してある同一のアカウントを利用して認証処理を不都合なく行なうことができ、また事前に秘密情報を共有しておく必要もない。

既存の認証サーバが証明書を取得していない場合に、認証サーバの証明書を新規に取得する必要がないこと、また既存の認証サーバ（のインタフェース）を変更する必要がないこと、つまり既存の環境にデバイス（ここでは、認証保証サーバ２０８）を追加するだけで第１実施形態と同様の認証効果を得ることができるものである。この点では、この第２実施形態の構成例４は、実際の実現の場において採り得る最適例と考えることができる。

＜構成例５＞
図１３は、第２実施形態のネットワーク構成におけるサービス提供システム１の構成例４に対する変形例（以下構成例５という）を示したブロック図である。この構成例５は、ユーザが属するグループ（管理主体）単位で、アクセス承認処理を行なう（アクセス可否を制御する）点に特徴を有し、構成例１〜４が、ユーザ個人レベルでアクセス承認処理を行なうのと異なる。

図示するように、サービス提供サーバ１００は、構成例４に加えて、アクセス制御リスト保持部１４０を備えている。アクセス制御リスト保持部１４０は、各サービスとそのサービスを使用可能な管理主体（逆に言えば、使用不可な管理主体）の組み合わせを対応付けてリストとして保持している。

また、問合せ先の管理装置としての第３種認証サーバ２０６では、アカウント情報保持部２６３は、ユーザが属する管理主体の情報を、自装置（第３種認証サーバ２０６）が属する管理主体の情報と対応付け可能にしておく。たとえば、認証保証サーバ（第３種デバイス３０）から返される保証サーバ証明書により認証保証サーバが属する管理主体またはドメインが分る。そこで、認証処理部２６４は、サービス提供サーバ１００から受信した認証情報をアカウント情報保持部２６３が保持している保証サーバ証明書から得られる管理主体の情報と照合して、ユーザが属する管理主体を特定する。

なお、このユーザと管理主体とを対応付ける処理としては、サービス提供サーバ１００から認証情報を受信した段階で保証サーバ証明書を取得して照合処理を行なうことで実現してもよい。また、保証サーバ証明書を取得した段階で、アカウント情報保持部２６３に、ユーザＩＤ、パスワード、および管理主体を対応付けて格納しておいてもよい。なお、サービス提供サーバ１００から認証情報を受信した段階で保証サーバ証明書を取得して照合処理を行えばよいので、アカウント情報保持部２６３に、ユーザＩＤ、パスワード、および管理主体を対応付けて格納しておくことは必須ではない。

＜具体的処理；第５例＞
図１４は、構成例５において採り得る、認証処理の具体例（第５の具体的処理）の手順の一例を示したシーケンス図である。

認証処理実行部１３２が、認証結果Ｊ３２、認証サーバ情報Ｊ２２、および保証サーバ証明書Ｊ４４の３つの情報に基づいて、所定の認証ポリシーに従って認証可否を判断するまでの処理（Ｓ５００〜Ｓ５２８）は、上述した第４の具体的処理とほぼ同様である。

なお、ステップＳ５００において、サービス提供サーバ１００に通知（入力）する認証情報Ｊ１２としては、第４の具体的処理と同様に、ＩＤおよびパスワードだけでよく、管理主体の通知（入力）は不要である。

また、管理装置側において認証情報Ｊ１２を検証して認証処理を行なう際に、第３種認証サーバ２０６の認証処理部２６４においてユーザ個人レベルで認証を行なうとともに、アクセス要求したユーザが何れの管理主体に属するかの認証（管理主体認証という）も行なう（Ｓ５１０）。

この後、認証処理部２６４は、そのユーザが属する管理主体を示す管理主体情報Ｊ３８を、認証結果Ｊ３２とともに、問合せ処理部２８４に送付する（Ｓ５１２）。問合せ処理部２８４は、受け取った認証結果Ｊ３２と管理主体情報Ｊ３８とを、サービス提供サーバ１００に送付する（Ｓ５１４）。なお、サーバ証明書Ｊ４２も送付する場合には、このサーバ証明書Ｊ４２に管理主体情報Ｊ３８を記述しておくとよい。こうすることで、データ伝送過程における管理主体情報Ｊ３８の管理が容易になる。

認証処理実行部１３２は、認証処理部２２４から受け取ったユーザ個人レベルの認証結果Ｊ３２などを参照して認証を行なう。そして、認証処理実行部１３２による認証処理が完了し、ユーザ個人レベルでの認証に成功すると（Ｓ５２８−ＹＥＳ）、アクセス可否判断処理部１３４は、ユーザより要求されているサービスと、保証サーバ証明書Ｊ４４から得られる認証保証サーバの証明書内に記述されている管理主体情報Ｊ３８とに基づいて、アクセス制御リスト保持部１４０を検索して、アクセスの可否を判定する（Ｓ５４０）。たとえば、サービスを要求しているユーザが、そのサービスを使用可能な管理主体に属する場合にはアクセス可能とする。

アクセス可否判断処理部１３４は、アクセス可能であればサービスをユーザに提供する一方（Ｓ５４２−ＹＥＳ，Ｓ５４４）、不可であればアクセスを禁止するとともに、その旨をユーザに通知する（Ｓ５４２−ＮＯ，Ｓ５４６）。

このように、第２実施形態の構成例５に依れば、各サービスとそのサービスを使用可能な管理主体、あるいは使用不可な管理主体の組み合わせをリストとして保持しておき、ユーザ個人レベルでの認証処理後に、さらにそのユーザが属する管理主体に対してそのユーザが要求しているサービス提供が可能であるかを判断するようにしたので、既に取得してある同一のアカウントを利用して、ユーザが属する管理主体単位でアクセス可否を制御することができる。

事実上、ユーザ個人レベルでのアクセス承認処理を行なう必要がなくなるので、アクセス制御リスト保持部１４０に用意する情報を少なくすることができ、アクセスリストの管理が容易となるし、メモリ容量を削減することもできる。

なお、管理主体単位でアクセス承認処理を行なう仕組みとして、グループ単位でアクセス権（Access Right）を付与しておくもの（以下グループアクセス権方式という）が知られている。しかしながら、従来のグループアクセス権方式の仕組みでは、システム管理者（本例の認証サーバに対応）がユーザの属するグループに対してアクセス権を設定した後に、そのユーザがサービス提供サーバ１００にアクセスする際には、グループ単位でのアクセスＩＤとパスワードを入力するようにしている。

このため、ユーザは、自分の属するグループを特定して、そのグループ単位でのアクセスＩＤとパスワードを入力しなければならないので、これらの情報を知っている必要がある。ユーザや認証サーバにとっては、通常使用する個人レベルでのアクセスＩＤとパスワードの他に、グループ単位でのアクセスＩＤとパスワードをも管理する必要が生じ、管理が煩雑となる。

加えて、アクセス承認処理だけでなく認証処理もグループ単位で行なわなければならない。認証処理は個人レベルで行ないつつ、アクセス承認処理はグループ単位で行なうようにするために、個人レベルでのアクセスＩＤとパスワードの他に、グループ単位でのアクセスＩＤとパスワードを入力する変形例を考えることもできるが、入力に手間が掛かるし、全ての情報を１対１に伝達し処理を行なう必要が生じ、データ管理が煩雑になる。

これに対して、第２実施形態の構成例５では、ユーザから入力された個人レベルでのアクセスＩＤとパスワードに基づいて、認証処理は個人レベルで行ないつつ、アクセス承認処理は管理主体単位で行なうことができるので、前述のような入力の手間やデータ管理の煩雑さの問題は生じない。

また、管理主体によるアクセス制御における管理主体の特定も、たとえば、認証保証サーバ（第３種デバイス３０）から返される保証サーバ証明書により認証保証サーバが属する管理主体またはドメインが分るため、それを利用したアクセス制御を行なうことができ、第３種認証サーバ２０６に予め管理主体を対応づけして登録しておく必要は必ずしもなく、問合せがあった都度照合をすればよい。この点は、従来のグループ単位でのアクセス制御では、事前に、個人レベルでのユーザと管理主体とを対応づけして登録しておくことが必須であるのと大きく異なるところである。

なお、このように、アクセス制御リスト保持部１４０を備える構成とすることで、ユーザが属するグループ単位でアクセス可否を制御するようにする構成は、第２実施形態の構成に限らず、上述した第１実施形態の各構成例１〜３についても同様に適用することができ、同様の効果を享受することができる。

また、上記手順のステップＳ５１０における認証処理に際しては、認証処理部２２４は、ユーザ個人レベルで認証を行なうようにしていたが、管理主体レベルで認証を行なうようにしてもよい。この場合、認証処理部２２４は、管理主体レベルの認証結果Ｊ３２を管理主体情報Ｊ３８とともにサービス提供サーバ１００に送付する。このような変形を加えた場合でも、前述のような入力の手間やデータ管理の煩雑さの問題は生じない。

＜第３実施形態＞
図１５は、サービス提供システム１の第３実施形態のネットワーク構成を示した図である。この第３実施形態は、ユーザ端末４０が第１ネットワーク９２に接続する際に第１種認証サーバ５２による認証が必要になる場合に対応したものである。

図２に示した構成との相違は、第１種認証サーバ５２が、第１実施形態におけるサービス提供サーバ１００と同様の機能部、すなわち、アクセスインタフェース部１０２、問合せ先特定処理部１１０、問合せ処理部１２０、認証処理部１３０、および認証サーバインタフェース部１５０を備えている点にある。

管理装置側には、証明書保持部２２２および認証処理部２２４（何れも図示せず；図３を参照）を備え、ユーザについてのアカウントを管理する第２種認証サーバ２０２の機能を持ち、認証局３００からの証明を得ているタイプの第２種デバイス２０が設けられいている。

この第３実施形態の構成に依れば、予め他のネットワーク環境の管理装置（図では第２種デバイス２０としての第２種認証サーバ２０２）にてアカウントを取得しておくことで、ユーザ端末４０が第１ネットワーク９２に接続する際に、第１実施形態の構成と同様に、予め取得してある同一のアカウントを利用して、認証処理を不都合なく行なうことができ、また事前にネットワークを提供している事業者（たとえばインターネットプロバイダなど）ごとにユーザＩＤやパスワードを所得せずとも、ネットワークを利用することができる。また、ネットワーク事業者側においても自身にアカウント登録していないユーザの認証を行なうことができる。

従来であれば、たとえば無線ＬＡＮスポットなど、現在は提供しているネットワーク事業者が異なるとネットワークに参加することさえ（事前にアカウント登録をしていないと）できないが、上記第３実施形態を適用すれば解決可能である点で有効な構成である。

＜第４実施形態＞
図１６は、サービス提供システム１の第４実施形態のネットワーク構成を示した図である。この第４実施形態は、第３実施形態において、ユーザのアカウントを管理しているのが図１の第３ネットワーク９６に接続された第３種認証サーバ５６であり、認証保証サーバ２０８が第３種デバイス３０となる構成に変形したもので、管理装置側を、図１１に示した構成例４と同様にしたものである。

この第４実施形態は、管理装置側での認証処理の仕組みが異なるだけであり、第１種認証サーバ５２の処理は、第３実施形態の場合と相違がなく、同様の効果を享受できる。

なお、第１実施形態に対するネットワーク構成の変形例として、第２〜第４の実施形態を示したが、これらは、その変形の一例に過ぎず、上記実施形態で示した認証処理機能やアクセス処理機能を実現する各機能要素を適宜組み替えることができる。これにより、認証処理機能やアクセス処理機能を使うあらゆる場面に、上記実施形態で示した認証処理やアクセス処理を適用できる。

＜電子計算機を用いた構成＞
なお、上記実施形態で示した認証処理やアクセス制御処理を行なう仕組みは、ハードウェアにより構成することに限らず、その機能を実現するプログラムコードに基づき電子計算機（コンピュータ）を用いてソフトウェア的に実現することも可能である。よって、本発明に係るサービス提供方法やそれを実施するための各種デバイス（サービス提供サーバや認証サーバ）を、電子計算機（コンピュータ）を用いてソフトウェアで実現するために好適なプログラムあるいはこのプログラムを格納したコンピュータ読取可能な記憶媒体を発明として抽出することもできる。ソフトウェアにより実行させる仕組みとすることで、ハードウェアの変更を伴うことなく、処理手順などを容易に変更できる利点を享受できるようになる。

一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ（組込マイコンなど）、あるいは、ＣＰＵ（Central Processing Unit ；中央処理部）やＭＰＵ（Micro Processing Unit ）、論理回路、記憶装置などの機能を１つのチップ上に搭載して所望のシステムを実現するＳＯＣ（System On a Chip：システムオンチップ）、または、各種プログラムをインストールすることで各種の機能を実行することが可能な汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。または、ソフトウェアを構成するプログラムが、有線あるいは無線などの通信網を介して提供されてもよい。

記録媒体は、コンピュータのハードウェア資源に備えられている読取装置に対して、プログラムの記述内容に応じて、磁気、光、電気などのエネルギの変化状態を引き起こして、および対応する信号の形式で、読取装置にプログラムの記述内容を伝達できるものである。たとえば、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory ）、ＤＶＤ（Digital Versatile Disc）を含む）、光磁気ディスク（ＭＤ（Mini Disc ）を含む）、または半導体メモリなどよりなるパッケージメディア（可搬型の記憶媒体）により構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されているＲＯＭやハードディスクなどで構成されてもよい。

たとえば、認証処理やアクセス制御処理を行なう機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、ハードウェアにて構成する場合と同様の効果は達成される。この場合、記憶媒体から読み出されたプログラムコード自体が認証処理やアクセス制御処理の機能を実現することになる。

また、コンピュータが読み出したプログラムコードを実行することにより、認証処理やアクセス制御処理を行なう機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム；基本ソフト）などが実際の処理の一部または全部を行ない、その処理によって認証処理やアクセス制御処理を行なう機能が実現される場合であってもよい。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって認証処理やアクセス制御処理を行なう機能が実現される場合であってもよい。

なお、認証処理やアクセス制御処理を行なう機能を実現するプログラムコードを記述したファイルとしプログラムが提供されるが、この場合、一括のプログラムファイルとして提供されることに限らず、コンピュータで構成されるシステムのハードウェア構成に応じて、個別のプログラムモジュールとして提供されてもよい。

図１７は、サービス提供システム１を構成するユーザ端末４０や各種デバイス１０，２０，３０を、電子計算機を用いて構成する場合のハードウェア構成の一例を示した図である。ここでは、第１種デバイス１０としての、コンビニなどに設置される複合機を一例に説明する。

コンピュータ装置９００に組み込まれるソフトウェアとしては、たとえば、複写アプリケーション、プリンタアプリケーション、ファクシミリ（ＦＡＸ）アプリケーションあるいは他のアプリケーション用の処理プログラムなど、従来の複合機におけるものと同様のものが組み込まれる。また、装置が、スキャナ部で読み取った画像を処理したり、Ｗｅｂサイトへのアクセス要求に対してネットワークインタフェース部を介して外部とのデータを送受信したりするための認証処理あるいはアクセス制御処理のためのプログラムも組み込まれる。

図示するように、コンピュータ装置９００は、装置全体の動作制御やそのほかの演算や制御の各処理機能をなすＣＰＵ９１０と、不揮発性の記憶部の一例であるＲＯＭ９３０と、書換可能な記憶部の一例であるＲＡＭ９４０とを備える。

またコンピュータ装置９００は、ディスプレイ部９２２との間のインタフェース（Inter Face）機能をなすディスプレイＩ／Ｆ（インタフェース）部９５０と、操作部９２４を構成するタッチパネル９２４ａや操作キー９２４ｂとの間のインタフェース機能をなす入力Ｉ／Ｆ部９５２と、プリンタ部９２７との間のインタフェース機能をなすプリンタＩ／Ｆ部９５４と、スキャナ部９２８との間のインタフェース機能をなすスキャナＩ／Ｆ部９５６と、課金処理部９２９との間のインタフェース機能をなす課金Ｉ／Ｆ部９５７と、通信網９０との間のインタフェース機能をなすネットワークＩ／Ｆ部（ターミナルアダプタ部）９５８とを備える。なお課金処理部９２９は、店舗設置端末を利用したサービスの提供を、図示しないコイン投入機などを利用して有料サービスとするためのものである。

ネットワークＩ／Ｆ部９５８は、ＩＳＤＮやインターネットなどの通信網との間の通信データの受け渡しを仲介する。これにより、ユーザは、コンピュータ装置９００によって構成された複合機を利用して、先ず、Ｗｅｂサーバへアクセスして所望の画像データをダウンロードすることで、このダウンロードした画像データに基づく印刷出力を得ることができるようになる。

なお、複合機における、認証処理あるいはアクセス制御処理機能をなす全ての処理をソフトウェアで行なうのではなく、これら機能部分の一部をハードウェアにて行なうための処理回路９６０を設けてもよい。

さらに、コンピュータ装置９００は、フラッシュメモリなどの不揮発性の半導体メモリカードなど、種々の方式の記録メディア９０２から画像データを読み出すメモリリーダ９７２並びに画像データを記録メディア９０２に書き込むメモリライタ９７３を有し、この記録メディア９０２との間のインタフェース機能をなすメモリＩＦ部９７０と、各部を互いに接続するアドレスバスおよびデータバスを含む内部バス９８０とを備えている。画像データや制御データは、内部バス９８０を通じて各ハードウェア間をやり取りされる。

また、コンピュータ装置９００は、たとえばハードディスク装置９７４、フレキシブルディスク（ＦＤ）ドライブ９７６、あるいはＣＤ−ＲＯＭ（Compact Disk ROM）ドライブ９７８などの、記憶媒体からデータを読み出したり記録したりするための記録・読取装置を備えてもよい。なお、可搬型の記録媒体としては、ＦＤ９９６やＣＤ−ＲＯＭ９９８などのほかにも、ＤＶＤなどの光学記録媒体、ＭＤなどの磁気記録媒体、ＰＤなどの光磁気記録媒体、テープ媒体、磁気記録媒体、ＩＣカードやミニチュアカードなどの半導体メモリを用いることができる。

スキャナ部９２８、ＦＤ９９６、ＣＤ−ＲＯＭ９９８、あるいは記録メディア９０２は、画像入力ソースとしての機能を備えており、ユーザに対して画像出力サービスを行なうための、画像出力に供し得る画像データを提供し得るものである。

また、ハードディスク装置９７４、フレキシブルディスクドライブ９７６、ＣＤ−ＲＯＭドライブ９７８は、たとえば、ＣＰＵ９１０にソフトウェア処理をさせるためのプログラムデータを登録するなどのために利用される。なお、フラッシュメモリなどの不揮発性の半導体メモリカードなど、その他の記録媒体にプログラムを格納してもよい。

ＲＯＭ９３０は、内部に、ＣＰＵ９１０が各種処理を行なうための制御プログラムが格納されるプログラム記憶領域や、ＣＰＵ９１０が各種処理を行なうために必要とするそのほかのデータ記憶領域を有する。たとえば、ＲＯＭ９３０は、ＣＰＵ９１０が認証処理やアクセス制御処理機能を行なうのに必要となるプログラムをプログラム記憶領域に予め格納している。さらに、プログラム記憶領域は、図示されないＢＩＯＳ（Basic Input/Output System ）やＯＳ（Operating Systems ；基本ソフト）やＧＵＩ（Graphical User Interface）処理などのプログラムをも格納している。ＣＰＵ９１０は、ＢＩＯＳやＯＳやＧＵＩ処理を利用しつつ、ＲＯＭ９３０内のプログラムを実行することによって、上記実施形態で示した各部の機能を実現する。

ＲＡＭ９４０は、ＣＰＵ９１０が各種処理を実行する際のワークメモリとして用いられる作業領域であって、外部から取り込んだ画像データを格納する画像記憶領域、ディスプレイ部９２２にて画像表示するためあるいはプリンタ部９２７にて印刷出力するためのラスタデータ（ビットマップイメージ）を格納するページバッファ領域、画像処理に供されるビットマップイメージを格納するビットマップ領域、あるいはそのほかの処理対象画像データを格納する領域を含んでいる。

メモリ読出部９７０は、図示しないメディアユニットに挿入された記録メディア９０２からの画像データをＲＡＭ９４０やハードディスク装置９７４へ格納する。

ディスプレイＩ／Ｆ部１５０は、ＣＰＵ９１０による制御に従いつつ、ＲＡＭ９４０内のページバッファに展開されたラスタデータを、ディスプレイ部９２２に渡す。これにより、ディスプレイ部９２２は、外部から取り込んだ画像データに基づくラスタデータを表示するようになる。同様に、プリンタＩ／Ｆ部９５４は、ＣＰＵ９１０による制御に従いつつ、ＲＡＭ９４０内のページバッファに展開されたラスタデータを、プリンタ部９２７に渡す。これにより、プリンタ部９２７は、外部から取り込んだ画像データに基づくラスタデータに従って、所定の記録媒体上に画像を印刷出力するようになる。

たとえば、中央制御部の主要部をなすＣＰＵ９１０は、予めＲＯＭ９３０やハードディスク装置９７４内に格納されている制御プログラムに基づいて必要なＧＵＩ画面をディスプレイ部９２２に順次表示させるとともに、制御プログラムおよびタッチパネル９２４ａを介して与えられるユーザ入力に基づいて、図示しないＷｅｂサーバにアクセスして、ユーザの希望するコンテンツ（ここでは出力対象画像）をダウンロードし、プリンタ部９２７にて印刷出力させる。

この際、ＣＰＵ９１０は、上述した各実施形態で説明したようにして、そのユーザが既にアカウントを所持している認証サーバに問い合わせることでユーザ認証を行なってからそのユーザに複合機の使用を許可し、さらにＷｅｂサーバへのアクセスも制御する。

これにより、ユーザは、複合機の使用やＷｅｂサーバへのアクセスに対して直接にはアカウントを持っていなくても、他のネットワークに接続されている認証サーバにてアカウントを所持している場合には、そのアカウントを利用して、複合機の使用やＷｅｂサーバへのアクセスが可能となる。

なお、上記説明では、第１種デバイス１０としての複合機を一例に説明したが、管理装置側である第２種デバイス２０や第３種デバイス３０などをコンピュータ装置によって構成することもできるのは言うまでもない。この場合、複合機特有の構成部分である、たとえばプリンタＩ／Ｆ部９５４やスキャナＩ／Ｆ部９５６などを取り除いた図１７にて一点鎖線で囲んだ部分を少なくとも備えた構成にすればよい。

サービス提供システムの構成の概要を示した図である。 サービス提供システムの第１実施形態のネットワーク構成を示した図である。 サービス提供システムの構成例１を示したブロック図である。 構成例１において採り得る、認証処理およびアクセス制御処理の基本的な手順の一例を示したシーケンス図である。 構成例１において採り得る、認証処理の第１の具体的処理手順の一例を示したシーケンス図である。 サービス提供システムの構成例２を示したブロック図である。 構成例２において採り得る、認証処理の第２の具体的処理手順の一例を示したシーケンス図である。 サービス提供システムの構成例３を示したブロック図である。 構成例３において採り得る、認証処理の第３の具体的処理手順の一例を示したシーケンス図である。 サービス提供システムの第２実施形態のネットワーク構成を示した図である。 第２実施形態のネットワーク構成における、サービス提供システムの構成例４を示したブロック図である。 構成例４において採り得る、認証処理の第４の具体的処理手順の一例を示したシーケンス図である。 第２実施形態のネットワーク構成におけるサービス提供システム１の構成例４対する変形例（以下構成例５という）を示したブロック図である。 構成例５において採り得る、認証処理の第５の具体的処理手順の一例を示したシーケンス図である。 サービス提供システムの第３実施形態のネットワーク構成を示した図である。 サービス提供システムの第４実施形態のネットワーク構成を示した図である。 サービス提供システムを構成するユーザ端末や各種デバイスを、電子計算機を用いて構成する場合のハードウェア構成の一例を示した図である。 従来のシングルサインオンの仕組みの第１例を示す図である。 従来のシングルサインオンの仕組みの第２例を示す図である。

符号の説明

１…サービス提供システム、１０…第１種デバイス、２０…第２種デバイス、３０…第３種デバイス、４０…ユーザ端末、５２…第１種認証サーバ、５６…第３種認証サーバ、９０…通信網、１００…サービス提供サーバ、１０２…アクセスインタフェース部、１１０…問合せ先特定処理部、１２０…問合せ処理部、１３０…認証処理部、１３２…認証処理実行部、１３４…アクセス可否判断処理部、１４０…アクセス制御リスト保持部、１５０…認証サーバインタフェース部、２００…認証サーバ、２０２…第２種認証サーバ、２０４…第３種認証サーバ、２０６…第３種認証サーバ、２０８…認証保証サーバ、２２２…証明書保持部、２２３…アカウント情報保持部、２２４…認証処理部、２２６…認証情報保持部、２３４…問合せ処理部、２４３…アカウント情報保持部、２４４…認証処理部、２６３…アカウント情報保持部、２６４…認証処理部、２８２…保証サーバ証明書保持部、２８４…問合せ処理部、３００…認証局、３１０…ＩＣカード、３２０…ＩＣカードリーダ／ライタ

Claims (35)

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. ネットワークに配置されたサービス提供装置を使用するユーザの認証を行ない前記サービス提供装置へのアクセスを許可してサービスを提供する処理を、コンピュータを用いて行なうためのプログラムであって、
    前記コンピュータを、
    前記ユーザの認証情報と、当該ユーザについてのアカウントを管理する管理装置を示す管理装置情報を受け付ける認証処理情報取得部と、
    前記認証処理情報取得部が受け付けた前記管理装置情報に基づいて、前記ユーザについての認証処理を行なうために必要な認証結果を返送させる問合せ先の前記管理装置を特定する問合せ先特定処理部と、
    前記問合せ先特定処理部が特定した前記問合せ先の管理装置に前記認証処理情報取得部が受け付けたユーザの認証情報を送付する問合せ処理部と、
    前記問合せ処理部が送付した前記認証情報に基づいて前記問合せ先の管理装置にて得られる前記ユーザについての前記認証結果を前記問合せ先の管理装置から受信し、この受信した認証結果に基づいて、前記ユーザについての認証処理を行なう認証処理実行部と
    前記認証処理実行部による認証に成功したことを条件として前記ユーザの前記サーバ装置へのアクセスを許可し、失敗したことを条件として前記ユーザの前記サービス提供装置へのアクセスを禁止するアクセス可否判断処理部と
    して機能させることを特徴とするプログラム。
33. ネットワークに配置された装置を使用するユーザの認証を行なうために必要となる情報を認証装置に通知する処理を、コンピュータを用いて行なうためのプログラムであって、
    前記コンピュータを、
    前記ユーザの認証情報と、当該ユーザについてのアカウントを管理する管理装置を示す管理装置情報の入力を受け付ける情報受付部と
    前記情報受付部が受け付けた認証情報および管理装置情報を前記認証装置に通知する通知部と
    して機能させることを特徴とするプログラム。
34. ネットワークに配置された装置を使用するユーザの認証を行なうために必要となる情報を認証装置に通知する処理を、コンピュータを用いて行なうためのプログラムであって、
    前記コンピュータを、
    ユーザのアカウント情報を保持するアカウント情報保持部と、
    受信した認証情報を前記アカウント情報保持部が保持しているアカウント情報と照合することで認証処理を行ない、認証結果を出力する認証処理部と
    して機能させることを特徴とするプログラム。
35. ネットワークに配置された装置を使用するユーザの認証を行なうために必要となる情報を認証装置に通知する処理を、コンピュータを用いて行なうためのプログラムであって、
    前記コンピュータを、
    所定の認証局から証明書を取得する証明書取得部と、
    受信した前記ユーザの認証情報を当該ユーザについての認証処理を行なう大元の認証装置であるオリジナル認証装置に送付し、当該オリジナル認証装置から認証結果を受信して、この受信した認証結果を、前記証明書取得部が取得した証明書とともに出力する問合せ処理部と
    して機能させることを特徴とするプログラム。

Images