JP2005062556A - 認証システム、サーバおよび認証方法並びにプログラム - Google Patents
認証システム、サーバおよび認証方法並びにプログラム Download PDFInfo
- Publication number
- JP2005062556A JP2005062556A JP2003293643A JP2003293643A JP2005062556A JP 2005062556 A JP2005062556 A JP 2005062556A JP 2003293643 A JP2003293643 A JP 2003293643A JP 2003293643 A JP2003293643 A JP 2003293643A JP 2005062556 A JP2005062556 A JP 2005062556A
- Authority
- JP
- Japan
- Prior art keywords
- client
- service
- provider
- authentication
- usage history
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Storage Device Security (AREA)
Abstract
【課題】 ネットワークを介してサービスを提供する上で、サービス提供時のパフォーマンスへの影響が少ないシングルサインオンを実現する。
【解決手段】 サービスを提供するプロバイダ２０と、セキュリティトークンサービス４０と、これらセキュリティトークンサービス４０とプロバイダ２０との間に介在するプロキシサービス３０とを備える。そして、プロキシサービス３０は、セキュリティトークンサービス４０による認証結果を保存し、一定条件の下、プロバイダ２０から受け取った認証要求をセキュリティトークンサービス４０へ転送せず、自身が保存する認証結果に基づいてクライアントの認証を代行する。さらに、プロバイダ２０が、自身が保存するクライアント１０のサービス利用履歴に基づいてサービス提供可能であることが明らかなときは、認証要求を行うことなく、クライアント１０に対してサービスを提供する。
【選択図】 図１
【解決手段】 サービスを提供するプロバイダ２０と、セキュリティトークンサービス４０と、これらセキュリティトークンサービス４０とプロバイダ２０との間に介在するプロキシサービス３０とを備える。そして、プロキシサービス３０は、セキュリティトークンサービス４０による認証結果を保存し、一定条件の下、プロバイダ２０から受け取った認証要求をセキュリティトークンサービス４０へ転送せず、自身が保存する認証結果に基づいてクライアントの認証を代行する。さらに、プロバイダ２０が、自身が保存するクライアント１０のサービス利用履歴に基づいてサービス提供可能であることが明らかなときは、認証要求を行うことなく、クライアント１０に対してサービスを提供する。
【選択図】 図１
Description
本発明は、ネットワークを介してサービスを提供する場合などに実行されるユーザ認証に関し、特にシングルサインオンによるユーザ認証を行うシステムおよびその方法に関する。
インターネット上で提供されている複数のプロバイダの有料サービスを利用する場合、支払い金額、口座などを管理するために当該サービスを受けるクライアントの認証が必要となる場合がある。従来は、各プロバイダが異なる方法でクライアント認証を行っていることが多いため、それぞれのサービスに対して独立にクライアント認証が行われる。しかし、より自由なサービス利用のためには、複数プロバイダで共通のクライアント認証を用いるシングルサインオン（Single Sign On）を実現することが好ましい。
シングルサインオンを実現する手段として、複数のプロバイダを一括して管理するプロキシサービス（Proxy Service）とクライアント認証を行うセキュリティトークンサービス（Security Token Service）を導入することが考えられる。ここで、セキュリティトークンサービスとは、クライアント、プロバイダおよびプロキシサービスのいずれからも独立して存在し、クライアントを認証する機関を指す。この種の従来技術としては、プロキシサービスをクライアントとプロバイダとの間に配置し、クライアントの代わりにプロキシサービスがクライアント認証を要求することで、複数プロバイダへのシングルサインオンを実現しているものが存在する（例えば、特許文献１、２参照）。
また従来、プロキシサービスを導入することなくシングルサインオンを実現するモデルとして、一度、所定のプロバイダで行われたクライアント認証を、複数のプロバイダ間で使い回すというモデルも提案されている（例えば、特許文献３参照）。この従来技術では、クライアントが保持している認証トークンがプロバイダＡによって発行されたものであり、その認証トークンを提示してプロバイダＢに接続したい場合、プロバイダＢは、発行元のプロバイダＡへ認証トークンの検査を依頼する。
上述したように、ネットワーク上でのクライアント認証を効率良く行うためのシングルサインオンを実現する手法は、従来から提案されている。しかしながら、特許文献１、２のような、プロキシサービスをクライアントとプロバイダとの間に配置してプロキシサービスがクライアント認証を代行要求する従来技術では、プロキシサービスがボトルネックとなって、クライアントやプロバイダが処理能力の低い携帯端末である場合や、処理に多大な負荷を要する電子署名・暗号化を適用する場合には、システム全体のパフォーマンスが低下することが予想される。
また、特許文献３に開示される、所定のプロバイダにおけるクライアント認証の結果を他のプロバイダで流用する従来技術では、クライアントが前回と異なった（認証を行ったプロバイダとは別の）プロバイダへ接続する場合、プロバイダ間で認証結果の通知が行われるため、サービス提供までの通信回数が増えてしまい、パフォーマンス低下の原因となると考えられる。
そこで本発明は、上記の課題に鑑み、ネットワークを介してクライアント認証を要するサービスを提供する上で、パフォーマンスへの影響が少ないシングルサインオンを実現することを目的とする。
上記の目的を達成する本発明は、ネットワークを介して所定のサービスを提供する複数のプロバイダを一括管理してシングルサインオンによるクライアント認証を行う、次のように構成された認証システムとして実現される。この認証システムは、ネットワークを介して所定のサービスを提供するプロバイダと、このプロバイダにサービス要求を行ったクライアントの認証を行う認証サーバ（セキュリティトークンサービス）と、これら認証サーバとプロバイダとの間に介在して、プロバイダが認証サーバに対して行う認証要求を管理するプロキシサーバ（プロキシサービス）とを備える。そして、プロキシサーバは、認証サーバによる認証結果を保存し、一定条件の下、プロバイダから受け取った認証要求を認証サーバへ転送せず、保存されている認証結果に基づいてクライアントの認証を代行することを特徴とする。
ここで、より好ましくは、プロバイダは、クライアントのサービス利用履歴を保存し、サービス利用履歴に基づいてクライアントに対してサービスを提供可能であることが明らかである場合は、認証要求を行うことなく、クライアントに対してサービスを提供する。また、プロキシサーバは、クライアントのサービス利用履歴をプロバイダから取得して管理し、所定のプロバイダからの認証要求に応じて、認証サーバによる認証結果とサービス利用履歴とに基づきクライアントに対するサービス提供の可否を判断する。さらに、このプロキシサーバは、複数のプロバイダを巡回して、クライアントごとのサービス利用履歴を収集して比較し、最新の内容を選択して、各プロバイダにおけるクライアントごとのサービス利用履歴を最新の内容に更新させる。
また、本発明の他の認証システムは、ネットワークを介して所定のサービスを提供する複数のプロバイダと、所定のプロバイダからの検証要求に応じて、このプロバイダにサービス要求を行ったクライアントに対するサービス提供の可否を判断する検証サーバ（プロキシサービス）とを備える。そして、プロバイダはクライアントのサービス利用履歴を保存し、検証サーバは、クライアントの認証情報とこのクライアントによるサービス利用回数とを情報として含む符号化データを生成してクライアントに提供し、プロバイダからサービス利用履歴を取得して管理し、所定のクライアントが所定のプロバイダに対して符号化データを用いてサービス要求を行った場合に、このプロバイダからの検証要求に応じて、符号化データとクライアントのサービス利用履歴とを照合してサービス提供の可否を判断することを特徴とする。
ここで、このプロバイダは、所定のクライアントが符号化データを用いてサービス要求を行った場合に、符号化データとサービス利用履歴とを照合し、クライアントに対してサービスを提供可能であることが明らかである場合は、検証サーバに対する検証要求を行うことなく、クライアントに対してサービスを提供する。また、検証サーバは、複数のプロバイダを巡回して、クライアントごとのサービス利用履歴を収集して比較し、最新の内容を選択して、各プロバイダにおけるクライアントごとのサービス利用履歴を最新の内容に更新させる。
さらに、上記の目的を達成する他の本発明は、ネットワークを介して所定のサービスを提供する複数のプロバイダを一括管理してシングルサインオンを実現する、次のように構成されたサーバ（プロキシサービス）としても実現される。すなわち、このサーバは、プロバイダにおける所定のクライアントのサービス利用履歴を格納する利用履歴格納手段と、所定の認証サーバに依頼して取得した所定のクライアントに対する認証結果を格納する認証結果格納手段と、プロバイダからの問い合わせに応じて、サービス利用履歴と認証結果とを用いて、所定のクライアントに対するサービス提供の可否を判断する検証手段とを備える。そして、検証手段は、認証結果格納手段に保存されている認証結果が有効でない場合に、サービス提供の可否を判断するためのクライアント認証を認証サーバに依頼することを特徴とする。
ここで、このサーバは、管理下にある各プロバイダを巡回してクライアントごとのサービス利用履歴を収集し、最新のサービス利用履歴を各プロバイダに分配する分配・収集手段をさらに備える構成とすることができる。この分配・収集手段は、より好ましくは、サービス提供の可否を問い合わせるための接続を長期間行っていないプロバイダ、利用履歴収集手段によって前記最新のサービス利用履歴が収集されたクライアントとの通信回数が多いプロバイダ、クライアントとの通信の総量が多いプロバイダを優先して巡回する。
また、このサーバは、クライアントの認証情報とこのクライアントによるサービス利用回数とを情報として含む符号化データを生成する符号化データ生成手段を更に備え、検証手段は、所定のクライアントが所定のプロバイダに対して符号化データを用いてサービス要求を行った場合に、符号化データと利用履歴格納手段に格納されているクライアントのサービス利用履歴とを照合してサービス提供の可否を判断する構成とすることができる。
また、このサーバは、クライアントの認証情報とこのクライアントによるサービス利用回数とを情報として含む符号化データを生成する符号化データ生成手段を更に備え、検証手段は、所定のクライアントが所定のプロバイダに対して符号化データを用いてサービス要求を行った場合に、符号化データと利用履歴格納手段に格納されているクライアントのサービス利用履歴とを照合してサービス提供の可否を判断する構成とすることができる。
さらにまた、本発明は、コンピュータを用いて、プロバイダにサービスの提供を要求するクライアントの認証を行う、次のような認証方法としても実現される、すなわち、クライアントのサービス利用履歴を符号化した符号化データと所定の記憶手段に格納されているクライアントのサービス利用履歴の情報とを照合する第１のステップと、第１のステップで照合結果が「偽」である場合に、所定の記憶手段に格納されているクライアントに対する認証情報に基づいてクライアントに対するサービス提供の可否を判断する第２のステップと、第２のステップで用いられる認証情報が有効でない場合に、所定の認証サーバにクライアントの認証を依頼し、取得した認証結果に基づいてクライアントに対するサービス提供の可否を判断する第３のステップとを含むことを特徴とする。
そして、この認証方法は、第１のステップで照合結果が「真」である場合に、クライアントに対するサービス提供が可能と判断するステップを更に含み、また、第３のステップで取得された認証結果を、第２のステップで用いられる認証情報として所定の記憶手段に格納するステップを更に含む。
また本発明は、コンピュータを制御して上述したサーバ（プロキシサービス）として機能させるプログラム、あるいは上記の認証方法における各ステップに相当する処理をコンピュータに実行させるプログラムとして実現することができる。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより、提供することができる。
以上のように構成された本発明は、プロバイダを一括管理するプロキシサービスをプロバイダに対して上位に位置させることにより、認証時にプロキシサービスがボトルネックとなることが無く、また一定条件下で、セキュリティトークンサービスやプロキシサービスによるクライアント認証を省略可能とすることにより、プロキシサービス−セキュリティトークンサービス間の通信やプロバイダ−プロキシサービス間の通信を省略し、プロバイダによるサービス提供時のパフォーマンス低下を回避できるという効果がある。
また、本発明は、プロキシサービスが管理下のプロバイダを巡回して、クライアント認証に必要な情報を収集し、最新の情報を各プロバイダに分配することにより、セキュリティトークンサービスやプロキシサービスによるクライアント認証を省略可能となる機会を多くして、システム全体のさらなるパフォーマンス向上を図ることができるという効果がある。
また、本発明は、プロキシサービスが管理下のプロバイダを巡回して、クライアント認証に必要な情報を収集し、最新の情報を各プロバイダに分配することにより、セキュリティトークンサービスやプロキシサービスによるクライアント認証を省略可能となる機会を多くして、システム全体のさらなるパフォーマンス向上を図ることができるという効果がある。
以下、添付図面を参照して、本発明を実施するための最良の形態（以下、実施形態）について詳細に説明する。
図１は、本実施形態によるシングルサインオンを実現するシステムの全体構成を示す図である。
図１に示すように、本実施形態のシステムは、クライアント１０、プロバイダ２０、プロキシサービス３０、セキュリティトークンサービス４０の各コンポーネントを備えて構成される。これらのコンポーネントは、次のように定義される。
クライアント１０は、プロバイダ２０にサービスを要求するコンポーネントである。
プロバイダ２０は、クライアント１０に対してサービスを提供し、クライアント１０の利用履歴をキャッシュするコンポーネントである。
プロキシサービス３０は、クライアント１０の認証結果をキャッシュし、各プロバイダ２０に対するクライアント１０の利用履歴を管理するコンポーネントである。
セキュリティトークンサービス４０は、クライアント１０を認証するコンポーネントである。
図１は、本実施形態によるシングルサインオンを実現するシステムの全体構成を示す図である。
図１に示すように、本実施形態のシステムは、クライアント１０、プロバイダ２０、プロキシサービス３０、セキュリティトークンサービス４０の各コンポーネントを備えて構成される。これらのコンポーネントは、次のように定義される。
クライアント１０は、プロバイダ２０にサービスを要求するコンポーネントである。
プロバイダ２０は、クライアント１０に対してサービスを提供し、クライアント１０の利用履歴をキャッシュするコンポーネントである。
プロキシサービス３０は、クライアント１０の認証結果をキャッシュし、各プロバイダ２０に対するクライアント１０の利用履歴を管理するコンポーネントである。
セキュリティトークンサービス４０は、クライアント１０を認証するコンポーネントである。
プロキシサービス３０は全てのプロバイダ２０と全てのクライアント１０の情報を一括管理するものとして、セキュリティトークンサービス４０はクライアント認証機関として、本実施形態のシステムに導入される。セキュリティトークンサービス４０に対してクライアント認証要求を出すのは、クライアント１０、プロバイダ２０およびプロキシサービス３０のいずれでも良いが、セキュリティトークンサービス４０のクライアント認証結果をクライアント１０自身が保持することは好ましくない。したがって以下の説明では、クライアント認証要求は、プロキシサービス３０がセキュリティトークンサービス４０に出すものとする。
図１に示したように本実施形態では、プロキシサービス３０が、複数のプロバイダ２０の上位に配置され、各プロバイダ２０の情報とクライアント認証の結果などのクライアント情報とを一括管理し、また各プロバイダ２０へクライアント情報を提供する。さらに、プロキシサービス３０は、セキュリティトークンサービス４０によるクライアント認証の結果を用いて、サービス提供の可否（以下、クライアント検証と称す）を判断し、その判断結果をプロバイダ２０へ送信する。
図２は、本実施形態のシングルサインオンのシステムを構成する上記各コンポーネントを実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図２に示すコンピュータ装置は、演算手段であるＣＰＵ（Central Processing Unit：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２およびＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２およびＡＧＰ（Accelerated Graphics Port）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット１０２に接続された磁気ディスク装置（ＨＤＤ）１０５、ネットワークインターフェイス１０６と、さらにこのＰＣＩバスからブリッジ回路１０７およびＩＳＡ（Industry Standard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピーディスクドライブ１０８およびキーボード／マウス１０９とを備える。
図２に示すコンピュータ装置は、演算手段であるＣＰＵ（Central Processing Unit：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２およびＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２およびＡＧＰ（Accelerated Graphics Port）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット１０２に接続された磁気ディスク装置（ＨＤＤ）１０５、ネットワークインターフェイス１０６と、さらにこのＰＣＩバスからブリッジ回路１０７およびＩＳＡ（Industry Standard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピーディスクドライブ１０８およびキーボード／マウス１０９とを備える。
なお、図２は本実施形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、外部記憶装置として、ＡＴＡ（AT Attachment）やＳＣＳＩ（Small Computer System Interface）などのインターフェイスを介してＣＤ−Ｒ（Compact Disc Recordable）やＤＶＤ−ＲＡＭ（Digital Versatile Disc Random Access Memory）のドライブを設けても良い。また、上述したように、クライアント１０は、図２に示すようなコンピュータ装置の他に、ネットワーク機能を備えたＰＤＡ（Personal Digital Assistant）や携帯電話等の情報機器とすることができる。
図３は、クライアント１０に対する認証システムとして把握したプロバイダ２０、プロキシサービス３０およびセキュリティトークンサービス４０の機能構成を示す図である。
図示のように、本実施形態においてプロバイダ２０は、クライアント１０およびプロキシサービス３０との間でデータ通信を行うための通信制御部２１と、クライアント１０に所定のサービスを提供するためのサービス実行部２２と、クライアント認証を簡易に行うための認証実行部２３とを備える。なお、プロバイダ２０の認証実行部２３によるクライアント認証の詳細については後述する。
図示のように、本実施形態においてプロバイダ２０は、クライアント１０およびプロキシサービス３０との間でデータ通信を行うための通信制御部２１と、クライアント１０に所定のサービスを提供するためのサービス実行部２２と、クライアント認証を簡易に行うための認証実行部２３とを備える。なお、プロバイダ２０の認証実行部２３によるクライアント認証の詳細については後述する。
上記の構成において、通信制御部２１は、例えば図２に示したコンピュータ装置のプログラム制御されたＣＰＵ１０１とネットワークインターフェイス１０６とで実現される。サービス実行部２２および認証実行部２３は、例えば図２に示したコンピュータ装置のプログラム制御されたＣＰＵ１０１にて実現される。通信制御部２１やサービス実行部２２、認証実行部２３の機能をＣＰＵ１０１にて実現させるプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供される。
プロキシサービス３０は、プロバイダ２０およびセキュリティトークンサービス４０との間でデータ通信を行うための通信制御部３１と、クライアント認証をセキュリティトークンサービス４０によらずに行うための認証実行部３２と、認証実行部３２によるクライアント認証に用いられるクライアント１０のサービス利用履歴の分配・収集を行う利用履歴分配・収集部３３とを備える。この利用履歴分配・収集部３３により、プロキシサービス３０は、管理下にある各プロバイダ２０を巡回し、各クライアント１０のサービス利用履歴を収集して比較し、個々のクライアント１０に関して常に最新の利用履歴を保持するようにする。また、プロバイダ２０を巡回した際に、最新の利用履歴を各プロバイダ２０に分配する。なお、プロキシサービス３０の認証実行部３２によるクライアント認証の詳細については後述する。
上記の構成において、通信制御部３１は、例えば図２に示したコンピュータ装置のプログラム制御されたＣＰＵ１０１とネットワークインターフェイス１０６とで実現される。認証実行部３２および利用履歴分配・収集部３３は、例えば図２に示したコンピュータ装置のプログラム制御されたＣＰＵ１０１にて実現される。通信制御部３１や認証実行部３２、利用履歴分配・収集部３３の機能をＣＰＵ１０１にて実現させるプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供される。
セキュリティトークンサービス４０は、プロキシサービス３０との間でデータ通信を行うための通信制御部４１と、クライアント認証を行う認証実行部４２とを備える。セキュリティトークンサービス４０の認証実行部４２によるクライアント認証は、パスワードやクライアントのＩＤ情報を用いた、公知の種々の認証方法により行うことができる。
上記の構成において、通信制御部４１は、例えば図２に示したコンピュータ装置のプログラム制御されたＣＰＵ１０１とネットワークインターフェイス１０６とで実現される。認証実行部４２は、例えば図２に示したコンピュータ装置のプログラム制御されたＣＰＵ１０１にて実現される。通信制御部４１や認証実行部４２の機能をＣＰＵ１０１にて実現させるプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供される。
上記の構成において、通信制御部４１は、例えば図２に示したコンピュータ装置のプログラム制御されたＣＰＵ１０１とネットワークインターフェイス１０６とで実現される。認証実行部４２は、例えば図２に示したコンピュータ装置のプログラム制御されたＣＰＵ１０１にて実現される。通信制御部４１や認証実行部４２の機能をＣＰＵ１０１にて実現させるプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供される。
図４は、本実施形態のシングルサインオンにおけるクライアント認証の手順を示す図である。
図４のモデル１に示すように、クライアント１０から所定のプロバイダ２０へサービス要求が行われると、プロバイダ２０は、プロキシサービス３０に、サービス要求を行ったクライアント１０に対するサービス提供の可否を判断するクライアント検証を依頼する。
プロキシサービス３０は、これに応じてセキュリティトークンサービス４０に当該クライアント１０の認証を依頼し、認証結果を得る。そして、取得した認証結果に基づいて、当該クライアント１０に対するサービス提供の可否を判断し、判断結果（クライアント検証結果）をプロバイダ２０へ通知する。
プロバイダ２０は、プロキシサービス３０から受け取ったクライアント検証結果にしたがって、サービスの提供が可能であれば、当該クライアント１０に対してサービスを提供する。
図４のモデル１に示すように、クライアント１０から所定のプロバイダ２０へサービス要求が行われると、プロバイダ２０は、プロキシサービス３０に、サービス要求を行ったクライアント１０に対するサービス提供の可否を判断するクライアント検証を依頼する。
プロキシサービス３０は、これに応じてセキュリティトークンサービス４０に当該クライアント１０の認証を依頼し、認証結果を得る。そして、取得した認証結果に基づいて、当該クライアント１０に対するサービス提供の可否を判断し、判断結果（クライアント検証結果）をプロバイダ２０へ通知する。
プロバイダ２０は、プロキシサービス３０から受け取ったクライアント検証結果にしたがって、サービスの提供が可能であれば、当該クライアント１０に対してサービスを提供する。
以上のモデル１によるクライアント認証の手順は、本実施形態におけるクライアント認証の最も基本的なモデルである。モデル１によれば、クライアント認証方法がセキュリティトークンサービス４０によって決められ、またクライアント認証結果をプロキシサービス３０で一括して管理することにより、複数プロバイダ２０のサービスを対象としたシングルサインオンが容易に実現される。
しかしモデル１では、クライアント１０があるプロバイダ２０に接続するたびに、プロバイダ２０がプロキシサービス３０にクライアント検証を要求し、さらにプロキシサービス３０がセキュリティトークンサービス４０にクライアント認証を要求する、という手順を踏むことになる。この場合、クライアント１０のサービス要求に対し、クライアント１０−プロバイダ２０間の通信以外に、プロバイダ２０−プロキシサービス３０間、プロキシサービス３０−セキュリティトークンサービス４０間の２回の通信が必要になる。したがって、シングルサインオンではないクライアント１０−プロバイダ２０間のみの通信で行われるクライアント認証と比較すると、この２回の通信分、多くの通信時間がかかってしまう。
しかしモデル１では、クライアント１０があるプロバイダ２０に接続するたびに、プロバイダ２０がプロキシサービス３０にクライアント検証を要求し、さらにプロキシサービス３０がセキュリティトークンサービス４０にクライアント認証を要求する、という手順を踏むことになる。この場合、クライアント１０のサービス要求に対し、クライアント１０−プロバイダ２０間の通信以外に、プロバイダ２０−プロキシサービス３０間、プロキシサービス３０−セキュリティトークンサービス４０間の２回の通信が必要になる。したがって、シングルサインオンではないクライアント１０−プロバイダ２０間のみの通信で行われるクライアント認証と比較すると、この２回の通信分、多くの通信時間がかかってしまう。
そこで、クライアント１０におけるサービスの利用履歴に応じてクライアント認証を簡易化することで、サービス提供に必要な通信を省略することを考える。
図４に示したモデル２は、プロキシサービス３０−セキュリティトークンサービス４０間の通信を省略して簡易化したクライアント認証の手順を示し、モデル３は、プロキシサービス３０−セキュリティトークンサービス４０間およびプロキシサービス３０−プロバイダ２０間の通信を省略して簡易化したクライアント認証の手順を示す。
図４に示したモデル２は、プロキシサービス３０−セキュリティトークンサービス４０間の通信を省略して簡易化したクライアント認証の手順を示し、モデル３は、プロキシサービス３０−セキュリティトークンサービス４０間およびプロキシサービス３０−プロバイダ２０間の通信を省略して簡易化したクライアント認証の手順を示す。
このモデル２、３による簡易なクライアント認証を実行するために、本実施形態のプロバイダ２０およびプロキシサービス３０は、次のような構成を有する。
プロバイダ２０の認証実行部２３は、サービスを利用した各クライアント１０に関して当該サービスの利用履歴を保持する。この利用履歴は、例えば図２に示したコンピュータ装置のメインメモリ１０３や磁気ディスク装置１０５に格納される。
また、プロキシサービス３０の認証実行部３２は、セキュリティトークンサービス４０に依頼して取得したクライアント認証結果をキャッシュする。クライアント認証結果には有効期限が定められるものとする。このクライアント認証結果は、例えば図２に示したコンピュータ装置のメインメモリ１０３や磁気ディスク装置１０５に格納される。
また、プロキシサービス３０は、クライアント認証を要求してきたプロバイダ２０のＩＤ情報を保持している。このＩＤ情報は、例えば図２に示したコンピュータ装置のメインメモリ１０３や磁気ディスク装置１０５に格納される。
プロバイダ２０の認証実行部２３は、サービスを利用した各クライアント１０に関して当該サービスの利用履歴を保持する。この利用履歴は、例えば図２に示したコンピュータ装置のメインメモリ１０３や磁気ディスク装置１０５に格納される。
また、プロキシサービス３０の認証実行部３２は、セキュリティトークンサービス４０に依頼して取得したクライアント認証結果をキャッシュする。クライアント認証結果には有効期限が定められるものとする。このクライアント認証結果は、例えば図２に示したコンピュータ装置のメインメモリ１０３や磁気ディスク装置１０５に格納される。
また、プロキシサービス３０は、クライアント認証を要求してきたプロバイダ２０のＩＤ情報を保持している。このＩＤ情報は、例えば図２に示したコンピュータ装置のメインメモリ１０３や磁気ディスク装置１０５に格納される。
そして、
・クライアント１０からあるプロバイダ２０への初めてのサービス要求である場合
・プロキシサービス３０にキャッシュしてあるクライアント認証結果の有効期限が切れていた場合
には、モデル１によってクライアント認証が行われる。一方、
・プロキシサービス３０が保持しているクライアント認証結果のキャッシュが有効である場合
には、モデル２によってクライアント認証が行われる。また、
・プロバイダ２０が保持しているクライアント１０のサービスの利用履歴を用いてクライアント検証が行える場合
には、モデル３によってクライアント認証が行われる。
どのモデルによってクライアント認証を行うかの選択は、クライアント１０から所定のプロバイダ２０へサービス要求がなされた時点で動的に行うことができる。
・クライアント１０からあるプロバイダ２０への初めてのサービス要求である場合
・プロキシサービス３０にキャッシュしてあるクライアント認証結果の有効期限が切れていた場合
には、モデル１によってクライアント認証が行われる。一方、
・プロキシサービス３０が保持しているクライアント認証結果のキャッシュが有効である場合
には、モデル２によってクライアント認証が行われる。また、
・プロバイダ２０が保持しているクライアント１０のサービスの利用履歴を用いてクライアント検証が行える場合
には、モデル３によってクライアント認証が行われる。
どのモデルによってクライアント認証を行うかの選択は、クライアント１０から所定のプロバイダ２０へサービス要求がなされた時点で動的に行うことができる。
次に、本実施形態によるクライアント認証の全体的な手順を説明する。
図５は、本実施形態によるクライアント認証の手順を説明するフローチャートである。
前提として、クライアント１０は、過去のサービス（シングルサインオンによって統括される各プロバイダ２０が提供するサービス）の利用に対して、サービスの利用履歴を符号化したデータ（以下、符号化データ）を保持しておく。この符号化データは、例えばプロキシサービス３０にて作成され、クライアント１０に提供される。符号化データの詳細については後述する。
図５に示すように、新たなサービス要求を行う際またはプロバイダ２０からの要求に応じて、クライアント１０は、このサービスの利用履歴に関する符号化データをプロバイダ２０へ送信する（ステップ５０１）。
図５は、本実施形態によるクライアント認証の手順を説明するフローチャートである。
前提として、クライアント１０は、過去のサービス（シングルサインオンによって統括される各プロバイダ２０が提供するサービス）の利用に対して、サービスの利用履歴を符号化したデータ（以下、符号化データ）を保持しておく。この符号化データは、例えばプロキシサービス３０にて作成され、クライアント１０に提供される。符号化データの詳細については後述する。
図５に示すように、新たなサービス要求を行う際またはプロバイダ２０からの要求に応じて、クライアント１０は、このサービスの利用履歴に関する符号化データをプロバイダ２０へ送信する（ステップ５０１）。
プロバイダ２０は、クライアント１０から受信した利用履歴の符号化データを、プロバイダ２０が保持している利用履歴と照合する（ステップ５０２）。照合処理の詳細は後述する。照合結果が「真」であれば、サービスを提供可能と判断し、クライアント１０の利用履歴の検証が完了したとみなす。そして、プロキシサービス３０へのクライアント検証の要求を省略する（ステップ５０３）。このとき、モデル３によるクライアント認証が適用されたことになる。
ステップ５０３の照合結果が「偽」である場合、プロバイダ２０は、プロキシサービス３０にクライアント１０の利用履歴と符号化データとを送信し、クライアント検証要求を行う（ステップ５０４）。ステップ５０３における照合結果が「偽」となる理由としては、次のような理由が考えられる。
・クライアント１０が直前に別のプロバイダ２０にサービス要求したため、現在通信中のプロバイダ２０が保持している利用履歴が古くなった（理由１）。
・クライアント１０にとって初めてのサービス要求であるため、対応する利用履歴が保持されていない（理由２）。
・クライアント１０が利用履歴の情報を偽造している（理由３）。
・クライアント１０が直前に別のプロバイダ２０にサービス要求したため、現在通信中のプロバイダ２０が保持している利用履歴が古くなった（理由１）。
・クライアント１０にとって初めてのサービス要求であるため、対応する利用履歴が保持されていない（理由２）。
・クライアント１０が利用履歴の情報を偽造している（理由３）。
プロキシサービス３０は、プロバイダ２０からクライアント検証要求を受け取ると、当該クライアント検証要求に含まれる符号化データと、プロキシサービス３０にて保持されている利用履歴とを照合する（ステップ５０５）。プロキシサービス３０で管理されている利用履歴は、各プロバイダ２０から収集した最新の内容であるので、ステップ５０３で照合結果が「偽」となった理由が上記の理由１である場合は、ここで照合結果が「真」となる。この照合処理の詳細は後述する。ステップ５０６における照合結果が「真」であれば、サービスを提供可能と判断し、クライアント１０の利用履歴の検証が完了する。そして、セキュリティトークンサービス４０へのクライアント認証の依頼を省略する（ステップ５０６）。このとき、モデル２によるクライアント認証が適用されたことになる。
ステップ５０６の照合結果が「偽」である場合、プロキシサービス３０は、自身が当該クライアント１０に対するクライアント認証結果をキャッシュしているかどうか（すなわち当該クライアント１０が初めて検証依頼されたものであるかどうか）を調べる（ステップ５０７）。対応するクライアント認証結果がキャッシュされていない場合、上述したステップ５０３での照合結果が「偽」となった場合の理由２に該当するので、セキュリティトークンサービス４０にクライアント１０の認証を依頼し、認証結果を取得する。そして、プロキシサービス３０は、セキュリティトークンサービス４０によるクライアント認証結果に基づいて、当該クライアント１０に対するサービス提供の可否を判断し、クライアント検証結果をプロバイダ２０へ送信する（ステップ５０８）。このとき、モデル１によるクライアント認証が適用されたことになる。
ステップ５０７で該当する認証結果がキャッシュされていた場合、ステップ５０３での照合結果が「偽」となった理由が上記の理由３と認識されるので、プロキシサービス３０は、クライアント検証失敗という検証結果をプロバイダ２０へ返送する（ステップ５０９）。この場合も、セキュリティトークンサービス４０への認証依頼が省略されるので、クライアント認証の手順としては、モデル２に相当する。
ステップ５０７で該当する認証結果がキャッシュされていた場合、ステップ５０３での照合結果が「偽」となった理由が上記の理由３と認識されるので、プロキシサービス３０は、クライアント検証失敗という検証結果をプロバイダ２０へ返送する（ステップ５０９）。この場合も、セキュリティトークンサービス４０への認証依頼が省略されるので、クライアント認証の手順としては、モデル２に相当する。
図６は、プロバイダ２０よるクライアント１０のサービス利用履歴の照合処理を説明するフローチャートである。
図６に示すように、プロバイダ２０がクライアント１０からサービス要求と共にサービス利用履歴を受け取ると、認証実行部２３が、対応するサービス利用履歴が保持されているか検索する（ステップ６０１）。対応するサービス利用履歴が保持されていれば、次に認証実行部２３は、当該サービス利用履歴とクライアント１０から受け取ったサービス利用履歴とを照合する（ステップ６０２、６０３）。照合の結果が「真」であれば、クライアント検証を擬制して、サービス提供可能と判断されるので、サービス実行部２２により当該クライアント１０に対してサービスが提供される（ステップ６０４）。
図６に示すように、プロバイダ２０がクライアント１０からサービス要求と共にサービス利用履歴を受け取ると、認証実行部２３が、対応するサービス利用履歴が保持されているか検索する（ステップ６０１）。対応するサービス利用履歴が保持されていれば、次に認証実行部２３は、当該サービス利用履歴とクライアント１０から受け取ったサービス利用履歴とを照合する（ステップ６０２、６０３）。照合の結果が「真」であれば、クライアント検証を擬制して、サービス提供可能と判断されるので、サービス実行部２２により当該クライアント１０に対してサービスが提供される（ステップ６０４）。
ステップ６０２で対応するサービス利用履歴が検出されなかった場合、およびステップ６０３で照合結果が「偽」であった場合は、プロキシサービス３０に対してクライアント検証の要求が送られる（ステップ６０５）。そして、プロキシサービス３０からクライアント検証結果を取得すると（ステップ６０６）、当該クライアント検証結果が判断され、当該クライアント１０へのサービス提供が可能であることを示す結果であれば、サービス実行部２２により当該クライアント１０に対してサービスが提供される（ステップ６０７、６０４）。一方、当該クライアント１０へのサービス提供ができないことをしめす結果であれば、エラー処理（当該クライアント１０に対してサービスの提供を拒否するメッセージを送信する等）が行われて処理が終了する（ステップ６０８）。
図７は、プロキシサービス３０によるクライアント検証の処理を説明するフローチャートである。
図７に示すように、プロキシサービス３０がプロバイダ２０からクライアント検証要求を受け取ると、認証実行部３２が、当該クライアント検証要求の対象であるクライアント１０に対するクライアント認証がキャッシュされているか検索する（ステップ７０１）。対応するキャッシュデータが存在するならば、次に認証実行部３２は、当該キャッシュデータが有効か否か（有効期限が過ぎていないか）を検査する（ステップ７０２、７０３）。キャッシュデータが有効であれば、次に認証実行部３２は、当該キャッシュデータのクライアント認証の結果に基づき、当該クライアント１０におけるサービス利用履歴を検証する（ステップ７０４）。
図７に示すように、プロキシサービス３０がプロバイダ２０からクライアント検証要求を受け取ると、認証実行部３２が、当該クライアント検証要求の対象であるクライアント１０に対するクライアント認証がキャッシュされているか検索する（ステップ７０１）。対応するキャッシュデータが存在するならば、次に認証実行部３２は、当該キャッシュデータが有効か否か（有効期限が過ぎていないか）を検査する（ステップ７０２、７０３）。キャッシュデータが有効であれば、次に認証実行部３２は、当該キャッシュデータのクライアント認証の結果に基づき、当該クライアント１０におけるサービス利用履歴を検証する（ステップ７０４）。
ステップ７０２で対応するキャッシュデータが存在しないか、ステップ７０３でキャッシュデータが有効でないと判断された場合は、セキュリティトークンサービス４０にクライアント認証の要求が送られる（ステップ７０５）。そして、セキュリティトークンサービス４０からクライアント認証結果を取得すると（ステップ７０６）、当該認証結果が判断され、クライアント１０が正当であることを示す結果であれば、当該認証結果が認証実行部３２によりキャッシュされる（ステップ７０７、７０８）。そして、認証実行部３２が、新たにキャッシュされた認証結果に基づき、当該クライアント１０におけるサービス利用履歴を検証する（ステップ７０４）。
クライアント１０のサービス利用履歴を検証した結果、有効であれば、当該クライアント１０へのサービス提供が可能であることを示すクライアント検証結果と、検証されたサービス利用履歴とがプロバイダ２０へ送信される（ステップ７０９、７１０）。
ステップ７０９でサービス利用履歴が有効でないと判断された場合、およびステップ７０７でユーザが正当でないことを示す認証結果が得られた場合は、当該クライアント１０へのサービス提供ができないことを示すクライアント検証結果がプロバイダ２０へ送信される（ステップ７１１）。
ステップ７０９でサービス利用履歴が有効でないと判断された場合、およびステップ７０７でユーザが正当でないことを示す認証結果が得られた場合は、当該クライアント１０へのサービス提供ができないことを示すクライアント検証結果がプロバイダ２０へ送信される（ステップ７１１）。
さて、クライアント１０によるサービス要求時の状況に応じて、上述したモデル１、２、３を動的に選択してクライアント認証を実行することにより、プロバイダ２０によるサービス提供時のパフォーマンスが向上するが、このパフォーマンスを向上する効果を最大限に発揮するためには、できるだけ多くモデル３を適用することが望ましい。クライアント１０が接続したプロバイダ２０に保存されているクライアント１０の利用履歴が常に最新のものとなるようにプロバイダ２０間で情報交換を行うことで、モデル３を適用可能な機会を増やすことができる。
そこで、クライアント１０の最新利用履歴を複数のプロバイダ２０へ効率良く分配することを考える。本実施形態では、プロキシサービス３０がプロバイダ２０を巡回し、巡回したプロバイダ２０に保存されているクライアント１０の最新利用履歴を収集し（Ｔａｋｅ）、同時に当該プロバイダ２０に古い利用履歴が保存されている場合には最新の利用履歴を分配して更新させる（Ｇｉｖｅ）。これにより、より多くのプロバイダ２０に最新の利用履歴を分配することができる。
本実施形態では、プロキシサービス３０は、できるだけ効果的にプロバイダ２０からクライアント１０の利用履歴を収集し、またプロバイダ２０にクライアント１０の最新の利用履歴を分配するために、以下の基準に従って計算したプロバイダ２０のスコアを用いることとする。
基準１：プロキシサービス３０と長い間接続していないプロバイダ２０は、クライアント１０の古い利用履歴を多く持っている可能性が高いので、いち早くプロキシサービス３０から最新利用履歴を分配し、プロバイダ２０が保持している古い利用履歴を更新するべきである。よって、このようなプロバイダ２０に高スコアをつける。
基準２：プロキシサービス３０がプロバイダ２０からクライアント１０の最新利用履歴を収集したとき、この最新利用履歴をどのプロバイダ２０に分配するのが効果的かを考える。最も効果的な選択は、最新利用履歴が収集されたクライアント１０と通信回数の多いプロバイダ２０に、その最新利用履歴を分配することである。よって、このようなプロバイダ２０に高スコアをつける。
基準３：利用履歴の収集に着目すると、より多くの最新利用履歴を保有しているプロバイダ２０を選択するための単純な基準として、クライアント１０との通信の総量が多いプロバイダ２０は、より多くの最新利用履歴を保有していると考えることができる。よって、このようなプロバイダ２０に高スコアをつける。
基準１：プロキシサービス３０と長い間接続していないプロバイダ２０は、クライアント１０の古い利用履歴を多く持っている可能性が高いので、いち早くプロキシサービス３０から最新利用履歴を分配し、プロバイダ２０が保持している古い利用履歴を更新するべきである。よって、このようなプロバイダ２０に高スコアをつける。
基準２：プロキシサービス３０がプロバイダ２０からクライアント１０の最新利用履歴を収集したとき、この最新利用履歴をどのプロバイダ２０に分配するのが効果的かを考える。最も効果的な選択は、最新利用履歴が収集されたクライアント１０と通信回数の多いプロバイダ２０に、その最新利用履歴を分配することである。よって、このようなプロバイダ２０に高スコアをつける。
基準３：利用履歴の収集に着目すると、より多くの最新利用履歴を保有しているプロバイダ２０を選択するための単純な基準として、クライアント１０との通信の総量が多いプロバイダ２０は、より多くの最新利用履歴を保有していると考えることができる。よって、このようなプロバイダ２０に高スコアをつける。
次の数１式は、所定のプロバイダｉを対象として、上記の基準１、２、３を評価するためのスコア算出式の一例である。
ただし、Δｔiはプロバイダｉにおけるプロキシサービス３０との最終通信からの経過時間、ｎi,jはプロバイダｉと所定のクライアントｊとの通信回数（プロキシサービス３０が最新利用履歴を保有するクライアント１０だけが対象）、ｍiはプロバイダｉにおけるクライアント１０との通信回数の総量を、それぞれ意味する。
この３値を重み付け合計した値
Ｓi＝ａＳi1＋ｂＳi2＋ｃＳi3 （ａ、ｂ、ｃは適当な係数）
を、プロバイダｉのスコアとする。
この３値を重み付け合計した値
Ｓi＝ａＳi1＋ｂＳi2＋ｃＳi3 （ａ、ｂ、ｃは適当な係数）
を、プロバイダｉのスコアとする。
プロキシサービス３０は、上記のスコアをプロバイダ２０ごとに算出し、その値が最大のものから順にプロバイダ２０を選択して巡回する。そして、巡回したプロバイダ２０に対して、プロバイダ２０が保有する利用履歴の収集と、プロキシサービス３０が保有する最新利用履歴の配信とを行う。これにより、クライアント１０がサービス要求するプロバイダ２０において当該クライアント１０の最新利用履歴が保持される確率が高くなり、モデル３が適用可能となる機会が増える。そして、サービス提供に必要な接続回数の平均値が低下して、システム全体におけるサービス提供時のパフォーマンスが向上する。
図８は、プロキシサービス３０がプロバイダ２０を巡回して各クライアント１０のサービスの利用履歴を収集し、分配する動作を説明するフローチャートである。
プロキシサービス３０の利用履歴分配・収集部３３は、所定のタイミングで（例えば定期的に）管理下にある各プロバイダ２０のスコアを計算し、巡回するプロバイダ２０を決定する（ステップ８０１）。そして、巡回先の（すなわち最大スコアの）プロバイダ２０に接続し（ステップ８０２）、当該プロバイダ２０が保持しているサービスの利用履歴のうち、１つのクライアント１０に関する利用履歴に着目して、プロキシサービス３０が持つ当該クライアント１０の利用履歴と比較する（ステップ８０３）。
プロキシサービス３０の利用履歴分配・収集部３３は、所定のタイミングで（例えば定期的に）管理下にある各プロバイダ２０のスコアを計算し、巡回するプロバイダ２０を決定する（ステップ８０１）。そして、巡回先の（すなわち最大スコアの）プロバイダ２０に接続し（ステップ８０２）、当該プロバイダ２０が保持しているサービスの利用履歴のうち、１つのクライアント１０に関する利用履歴に着目して、プロキシサービス３０が持つ当該クライアント１０の利用履歴と比較する（ステップ８０３）。
比較の結果、プロバイダ２０がプロキシサービス３０よりも新しい利用履歴を持っている場合、利用履歴分配・収集部３３は、プロキシサービス３０の利用履歴をプロバイダ２０のものに更新する（ステップ８０４、８０５）。一方、プロキシサービス３０がプロバイダ２０よりも新しい利用履歴を持っている場合、利用履歴分配・収集部３３は、プロバイダ２０の利用履歴をプロキシサービス３０のものに更新する（ステップ８０４、８０６）。
次に、利用履歴分配・収集部３３接続しているプロバイダ２０が保持する全てのクライアント１０の利用履歴に対してステップ８０３〜８０６の処理を実行したかどうかを確認し、未処理の利用履歴が残っていれば、改めて１つのクライアント１０ごとに順次着目し、ステップ８０３〜８０６の処理を実行する。各クライアントの利用履歴に順次着目していき、全てのクライアント１０の利用履歴を更新したならば、当該プロバイダ２０に対する巡回処理を終了する（ステップ８０７）。
次に、本実施形態の実装例として、上述したクライアント１０におけるサービスの利用履歴の情報を含む符号化データとしてPayWordを用いた認証システムを説明する。
PayWordはクライアント１０がサービス要求時に利用する回数券として用いることができる。また、PayWordの利用履歴を検証することで、サービス要求を行ったクライアント１０を特定でき、クライアント検証が可能である。PayWordを利用すると、クライアント検証と利用履歴の管理ができるため、プロキシサービス３０はクライアント１０への課金管理という役割も兼ねることができる。ただし、クライアント検証を行うためには、PayWordが最後に使用された際の利用履歴（最終利用履歴）が必要である。
PayWordはクライアント１０がサービス要求時に利用する回数券として用いることができる。また、PayWordの利用履歴を検証することで、サービス要求を行ったクライアント１０を特定でき、クライアント検証が可能である。PayWordを利用すると、クライアント検証と利用履歴の管理ができるため、プロキシサービス３０はクライアント１０への課金管理という役割も兼ねることができる。ただし、クライアント検証を行うためには、PayWordが最後に使用された際の利用履歴（最終利用履歴）が必要である。
ここで、一方向符号化回数券の例として利用されるPayWordの詳細を説明する。
PayWordとは、一方向ハッシュ関数と任意の乱数をもとに計算したハッシュ値を使ってプロバイダ２０−クライアント１０間での認証を行う方法である。PayWordを用いた認証を行うには、クライアント１０の証明書を発行するＣＡ（Certificate Authority：認証局）の存在が前提となる。まず、PayWordを利用するＣＡ、クライアント１０およびプロバイダ２０に必要となる事前準備について説明し、次にPayWordの使用について説明する。また、クライアント１０とプロバイダ２０は予め同一の一方向ハッシュ関数を知っているものとする。
PayWordとは、一方向ハッシュ関数と任意の乱数をもとに計算したハッシュ値を使ってプロバイダ２０−クライアント１０間での認証を行う方法である。PayWordを用いた認証を行うには、クライアント１０の証明書を発行するＣＡ（Certificate Authority：認証局）の存在が前提となる。まず、PayWordを利用するＣＡ、クライアント１０およびプロバイダ２０に必要となる事前準備について説明し、次にPayWordの使用について説明する。また、クライアント１０とプロバイダ２０は予め同一の一方向ハッシュ関数を知っているものとする。
［事前準備］
１．ＣＡは、クライアント１０の証明書ＣｕをＣＡの署名付きで発行する。
２．クライアント１０は、まず、利用度数ｎと任意の乱数を一方向ハッシュ関数にかけた値Ｗnを決める。Ｗnをｎ回ハッシュ関数ｈにかけ、ｎ個のハッシュ値Ｗ0〜Ｗn-1を求める。すなわち、
Ｗi-1＝ｈ(Ｗi) ｆｏｒ ｉ＝１、・・・、ｎ
である。
３．クライアント１０は、証明書ＣｕとPayWordのルート値として利用する値Ｗ0とを署名してプロバイダ２０に送信する。
４．プロバイダ２０は、送られた証明書Ｃｕによりクライアント１０を認証し、値Ｗ0を保持しておく。
１．ＣＡは、クライアント１０の証明書ＣｕをＣＡの署名付きで発行する。
２．クライアント１０は、まず、利用度数ｎと任意の乱数を一方向ハッシュ関数にかけた値Ｗnを決める。Ｗnをｎ回ハッシュ関数ｈにかけ、ｎ個のハッシュ値Ｗ0〜Ｗn-1を求める。すなわち、
Ｗi-1＝ｈ(Ｗi) ｆｏｒ ｉ＝１、・・・、ｎ
である。
３．クライアント１０は、証明書ＣｕとPayWordのルート値として利用する値Ｗ0とを署名してプロバイダ２０に送信する。
４．プロバイダ２０は、送られた証明書Ｃｕによりクライアント１０を認証し、値Ｗ0を保持しておく。
［最初の使用（１st-Payment）］
１．クライアント１０は、利用したい度数ｊと対応するＷjとをプロバイダ２０に送信する。ここで送信するｊとＷjの組をPayWordとする。
２．プロバイダ２０は、送られてきたＷjをｊ回ハッシュ関数にかけ、その値と保持しているPayWordのルート値Ｗ0とを比較する。
３．値が一致すれば、事前に認証したクライアント１０と同一であることがわかるので、プロバイダ２０によるサービス提供が行われる。
４．プロバイダ２０は、次回のサービス要求のために、Ｗjを保持しておく。
１．クライアント１０は、利用したい度数ｊと対応するＷjとをプロバイダ２０に送信する。ここで送信するｊとＷjの組をPayWordとする。
２．プロバイダ２０は、送られてきたＷjをｊ回ハッシュ関数にかけ、その値と保持しているPayWordのルート値Ｗ0とを比較する。
３．値が一致すれば、事前に認証したクライアント１０と同一であることがわかるので、プロバイダ２０によるサービス提供が行われる。
４．プロバイダ２０は、次回のサービス要求のために、Ｗjを保持しておく。
［２回目の使用（２nd-Payment）］
１．クライアント１０は、利用したい度数ｋと対応するＷj+kとをプロバイダ２０に送信する。
２．プロバイダ２０は、送られてきたＷj+kをｋ回ハッシュ関数にかけ、その値と保持していたＷjの値とを比較する。
３．値が一致すれば、サービス提供し、Ｗj+kを保持しておく。
１．クライアント１０は、利用したい度数ｋと対応するＷj+kとをプロバイダ２０に送信する。
２．プロバイダ２０は、送られてきたＷj+kをｋ回ハッシュ関数にかけ、その値と保持していたＷjの値とを比較する。
３．値が一致すれば、サービス提供し、Ｗj+kを保持しておく。
以下、同様の操作を繰り返して、ｎ回のPayWordの使用が可能である。PayWordの特徴は、次の通りである。
・ハッシュ値の計算だけでクライアント認証とクライアント１０の利用履歴管理の両方を行うことができる。
・一方向ハッシュ関数により計算された値を用いるため、不正利用を防ぐことができる。
・クライアント１０の電子署名は、事前準備の際にクライアント１０がプロバイダ２０に証明書Ｃｕを送るときのみに必要であり、サービス要求時にはクライアント１０の署名は不要である。
・ハッシュ値の計算は電子署名の１００００倍程度の処理速度で行えることが指摘されており、高速である。
・ハッシュ値の計算だけでクライアント認証とクライアント１０の利用履歴管理の両方を行うことができる。
・一方向ハッシュ関数により計算された値を用いるため、不正利用を防ぐことができる。
・クライアント１０の電子署名は、事前準備の際にクライアント１０がプロバイダ２０に証明書Ｃｕを送るときのみに必要であり、サービス要求時にはクライアント１０の署名は不要である。
・ハッシュ値の計算は電子署名の１００００倍程度の処理速度で行えることが指摘されており、高速である。
このようなPayWordを用いた本実施形態のシングルサインオンのシステムでは、クライアント１０のサービス利用履歴としてPayWordの利用履歴が用いられる。プロキシサービス３０は、クライアント認証結果やクライアント１０利用履歴のキャッシュ、PayWord発行などを役割とする。クライアント１０におけるサービスの利用履歴をPayWordで管理することにより、クライアント１０−プロバイダ２０間でのクライアント検証を容易に行うことができ、プロキシサービス３０を使うことで同一のPayWord回数券が複数プロバイダ２０で利用できるようになる。
次に、シングルサインオンの実行手順について示す。ここでは、PayWordで用いるハッシュ関数は、予めクライアント１０、プロバイダ２０、プロキシサービス３０の間で共有しているものとする。
［回数券購入］
初めに、クライアント１０がサービス要求時に利用する回数券を購入する。
図９は、クライアント１０がPayWord回数券を購入する際の、クライアント１０、プロバイダ２０、プロキシサービス３０の動作を示す図である。
図９に示すように、まず、クライアント１０は、プロキシサービス３０に対し、例えば「１０回分の回数券を購入したい」という購入要求と共に、セキュリティトークン（クライアントＩＤとパスワードなど）に電子署名を付加して送信する（図中の動作（０−１））。この際、暗号化によりメッセージを安全に送信することが好ましい。
［回数券購入］
初めに、クライアント１０がサービス要求時に利用する回数券を購入する。
図９は、クライアント１０がPayWord回数券を購入する際の、クライアント１０、プロバイダ２０、プロキシサービス３０の動作を示す図である。
図９に示すように、まず、クライアント１０は、プロキシサービス３０に対し、例えば「１０回分の回数券を購入したい」という購入要求と共に、セキュリティトークン（クライアントＩＤとパスワードなど）に電子署名を付加して送信する（図中の動作（０−１））。この際、暗号化によりメッセージを安全に送信することが好ましい。
クライアント１０による購入要求に応じて、プロキシサービス３０は、クライアント１０のセキュリティトークンをセキュリティトークンサービス４０に提示し、クライアント認証要求と回数券購入要求を行う（図中の動作（０−２））。
セキュリティトークンサービス４０は、プロキシサービス３０から送られてきたクライアント１０のセキュリティトークンを検証し、「１０回分購入」という属性を含むクライアント認証をプロキシサービス３０に発行する（図中の動作（０−３））。
プロキシサービス３０は、セキュリティトークンサービス４０から受け取った属性内容を参照して、１０回分のPayWordを作成し、１０個のPayWordの値とそのルート値Ｗ0をクライアント１０へ返す（図中の動作（０−４））。ここで、プロキシサービス３０が受け取ったクライアント認証結果は、作成された１０個のPayWordの値とルート値Ｗ0およびクライアントＩＤに対応付けされて回数券の有効期限までキャッシュされる。
セキュリティトークンサービス４０は、プロキシサービス３０から送られてきたクライアント１０のセキュリティトークンを検証し、「１０回分購入」という属性を含むクライアント認証をプロキシサービス３０に発行する（図中の動作（０−３））。
プロキシサービス３０は、セキュリティトークンサービス４０から受け取った属性内容を参照して、１０回分のPayWordを作成し、１０個のPayWordの値とそのルート値Ｗ0をクライアント１０へ返す（図中の動作（０−４））。ここで、プロキシサービス３０が受け取ったクライアント認証結果は、作成された１０個のPayWordの値とルート値Ｗ0およびクライアントＩＤに対応付けされて回数券の有効期限までキャッシュされる。
クライアント１０は、以上のようにしてプロキシサービス３０から受け取ったPayWordを使ってサービスを受けることができる。ここで、プロキシサービス３０だけが実際のクライアントＩＤとサービス要求時にクライアント認証に使われるルート値Ｗ0の対応を知っており、クライアント１０の全プロバイダ２０に対する利用履歴を保持しているため、一定期間ごとにプロキシサービス３０が支払い実行要求を出して課金管理を行うことができる。
次に、クライアント１０−プロバイダ２０間のサービス提供の実行手順を示す。
まず、実行手順が決定される基本的な条件を列挙する。
・クライアント１０−プロバイダ２０間のクライアント検証は、クライアント１０から送られてきたPayWordを、プロバイダ２０が保持しているPayWordの利用履歴を用いて検証することによって行う。
・PayWordによるクライアント検証が成功した場合は、プロバイダ２０とプロキシサービス３０の接続は省略される。
・PayWordによるクライアント検証が失敗した場合のみ、プロバイダ２０はプロキシサービス３０に接続し、検証を依頼する。クライアント検証が失敗する原因としては、以下の要因が挙げられる。
要因１：クライアント１０にとって初めてのサービス要求である。
要因２：クライアント１０が直前に別のプロバイダ２０にサービス要求している。
要因３：クライアント１０が情報を偽造している。
要因４：クライアント１０はまだ回数券を購入していない。
・プロキシサービス３０の検証により上記の要因１または要因２が原因であることが分かれば、プロバイダ２０によりサービス提供が行われる。
まず、実行手順が決定される基本的な条件を列挙する。
・クライアント１０−プロバイダ２０間のクライアント検証は、クライアント１０から送られてきたPayWordを、プロバイダ２０が保持しているPayWordの利用履歴を用いて検証することによって行う。
・PayWordによるクライアント検証が成功した場合は、プロバイダ２０とプロキシサービス３０の接続は省略される。
・PayWordによるクライアント検証が失敗した場合のみ、プロバイダ２０はプロキシサービス３０に接続し、検証を依頼する。クライアント検証が失敗する原因としては、以下の要因が挙げられる。
要因１：クライアント１０にとって初めてのサービス要求である。
要因２：クライアント１０が直前に別のプロバイダ２０にサービス要求している。
要因３：クライアント１０が情報を偽造している。
要因４：クライアント１０はまだ回数券を購入していない。
・プロキシサービス３０の検証により上記の要因１または要因２が原因であることが分かれば、プロバイダ２０によりサービス提供が行われる。
以上の条件を踏まえて、
ケース１：所定のプロバイダ２０Ａに初めてサービス要求する場合、
ケース２：プロバイダ２０Ａに連続してサービス要求する場合、
ケース３：他のプロバイダ２０Ｂからサービスを受けた後、再びプロバイダ２０Ａにサービス要求する場合、
の３通りのサービス提供手順を説明する。なお、この動作説明では、個々のプロバイダ２０を区別する必要がある場合に、プロバイダ２０Ａ、２０Ｂのように、クライアント２０に英大文字の添え字を付して表記している。
ケース１：所定のプロバイダ２０Ａに初めてサービス要求する場合、
ケース２：プロバイダ２０Ａに連続してサービス要求する場合、
ケース３：他のプロバイダ２０Ｂからサービスを受けた後、再びプロバイダ２０Ａにサービス要求する場合、
の３通りのサービス提供手順を説明する。なお、この動作説明では、個々のプロバイダ２０を区別する必要がある場合に、プロバイダ２０Ａ、２０Ｂのように、クライアント２０に英大文字の添え字を付して表記している。
［ケース１：プロバイダ２０Ａへの初回要求］
図１０は、ケース１におけるクライアント１０、プロバイダ２０Ａ、プロキシサービス３０の動作を示す図である。
クライアント１０は、プロキシサービス３０から受け取ったPayWordを元に、プロバイダ２０Ａにサービス要求を出す（図中の動作（１−１））。同時に、そのサービスに対してクライアントＩＤと必要な回数券の枚数に対応するPayWord Ｗiをプロバイダ２０Ａに送信する。ここで、一方向符号化型回数券にPayWordを用いた場合には、プロバイダ２０Ａがクライアント１０を識別するためのクライアントＩＤの代用として、PayWordのルート値Ｗ0を用いることができる。この場合、Ｗ0は回数券の有効期限間のみ利用できる一時的なクライアントＩＤとして用いられる。また、プロバイダ２０Ａは本来のクライアントＩＤを知る必要はなく、Ｗ0からクライアント１０を想定することは難しいと考えられるため、クライアントＩＤをそのままクライアント１０の識別に用いるよりも安全性が高いといえる。さらに、Ｗ0にクライアント１０の署名付加・暗号化を施すことで、メッセージの安全性を一層高めることができる。
図１０は、ケース１におけるクライアント１０、プロバイダ２０Ａ、プロキシサービス３０の動作を示す図である。
クライアント１０は、プロキシサービス３０から受け取ったPayWordを元に、プロバイダ２０Ａにサービス要求を出す（図中の動作（１−１））。同時に、そのサービスに対してクライアントＩＤと必要な回数券の枚数に対応するPayWord Ｗiをプロバイダ２０Ａに送信する。ここで、一方向符号化型回数券にPayWordを用いた場合には、プロバイダ２０Ａがクライアント１０を識別するためのクライアントＩＤの代用として、PayWordのルート値Ｗ0を用いることができる。この場合、Ｗ0は回数券の有効期限間のみ利用できる一時的なクライアントＩＤとして用いられる。また、プロバイダ２０Ａは本来のクライアントＩＤを知る必要はなく、Ｗ0からクライアント１０を想定することは難しいと考えられるため、クライアントＩＤをそのままクライアント１０の識別に用いるよりも安全性が高いといえる。さらに、Ｗ0にクライアント１０の署名付加・暗号化を施すことで、メッセージの安全性を一層高めることができる。
この時点では、プロバイダ２０Ａへの初めてのサービス要求であるため、プロバイダ２０Ａはクライアント１０の履歴を保持していない。そこで、プロバイダ２０Ａは、クライアント１０情報をプロキシサービス３０に提示し、クライアント認証とPayWord Ｗiの有効性の検証をプロキシサービス３０に要求する（図中の動作（１−２））。
プロキシサービス３０は、クライアント１０が回数券を購入した際に取得したクライアント認証結果をキャッシュしているため、これに基づいて、クライアント検証としてPayWord Ｗiの有効性を確認する。Ｗiが有効であれば、プロキシサービス３０はクライアント検証結果をプロバイダ２０Ａに転送する（図中の動作（１−３））。プロキシサービス３０がキャッシュしているクライアント認証結果が有効期限内であれば、このクライアント認証結果を転送することができ、プロキシサービス３０は再度クライアント認証要求をする必要がない。したがって、プロキシサービス３０−セキュリティトークンサービス４０間の接続を省略できる。
また、プロキシサービス３０は、以上のクライアント検証の際に、クライアント１０の回数券利用履歴としてＷiの値をキャッシュする。
プロキシサービス３０は、クライアント１０が回数券を購入した際に取得したクライアント認証結果をキャッシュしているため、これに基づいて、クライアント検証としてPayWord Ｗiの有効性を確認する。Ｗiが有効であれば、プロキシサービス３０はクライアント検証結果をプロバイダ２０Ａに転送する（図中の動作（１−３））。プロキシサービス３０がキャッシュしているクライアント認証結果が有効期限内であれば、このクライアント認証結果を転送することができ、プロキシサービス３０は再度クライアント認証要求をする必要がない。したがって、プロキシサービス３０−セキュリティトークンサービス４０間の接続を省略できる。
また、プロキシサービス３０は、以上のクライアント検証の際に、クライアント１０の回数券利用履歴としてＷiの値をキャッシュする。
プロバイダ２０Ａは、受け取ったクライアント検証結果を信用し、クライアント１０にサービスを提供する（図中の動作（１−４））。プロバイダ２０Ａもルート値Ｗ0とクライアント１０の利用履歴としてＷiの値をキャッシュしておく。これにより、今後このクライアント１０と連続して通信する場合には、プロバイダ２０Ａ自身がクライアント検証を行うことができ、プロキシサービス３０への接続を省略できることとなる。
［ケース２：プロバイダ２０Ａへの連続要求］
図１１は、ケース２におけるクライアント１０、プロバイダ２０Ａ、プロキシサービス３０の動作を示す図である。
クライアント１０が、他のプロバイダ２０のサービスを利用せず、連続してプロバイダ２０Ａにサービス要求する場合には、上述したように、プロキシサービス３０とプロバイダ２０間の接続を省略できる。
図１１は、ケース２におけるクライアント１０、プロバイダ２０Ａ、プロキシサービス３０の動作を示す図である。
クライアント１０が、他のプロバイダ２０のサービスを利用せず、連続してプロバイダ２０Ａにサービス要求する場合には、上述したように、プロキシサービス３０とプロバイダ２０間の接続を省略できる。
まず、ケース１の初回要求と同様に、クライアント１０は、利用したい回数券の枚数に対応するPayWord Ｗjとルート値Ｗ0とサービス要求をプロバイダ２０Ａに出す（図中の動作（２−１））。
プロバイダ２０Ａは、クライアント１０の利用履歴をキャッシュしているため、PayWord Ｗjの有効性を検証することができる。プロバイダ２０Ａ自身でＷjの有効性を確認できれば、クライアント１０へサービス提供すればよい（図中の動作（２−２））。このように、PayWordを使うことで、同一プロバイダ２０Ａとクライアント１０間の検証に第３者機関（プロキシサービス３０やセキュリティトークンサービス４０）を必要とせず、２者間のみの通信によりサービス提供が可能になる。また、大まかな見積もりでは、ＲＳＡ暗号方式による電子署名付加に比べて、ハッシュ関数の計算は、１００００倍の速さで行うことができることがわかっている。したがって、クライアント１０とプロバイダ２０Ａへの負荷や通信時間を大幅に削減することができる。
プロバイダ２０Ａは、クライアント１０の利用履歴をキャッシュしているため、PayWord Ｗjの有効性を検証することができる。プロバイダ２０Ａ自身でＷjの有効性を確認できれば、クライアント１０へサービス提供すればよい（図中の動作（２−２））。このように、PayWordを使うことで、同一プロバイダ２０Ａとクライアント１０間の検証に第３者機関（プロキシサービス３０やセキュリティトークンサービス４０）を必要とせず、２者間のみの通信によりサービス提供が可能になる。また、大まかな見積もりでは、ＲＳＡ暗号方式による電子署名付加に比べて、ハッシュ関数の計算は、１００００倍の速さで行うことができることがわかっている。したがって、クライアント１０とプロバイダ２０Ａへの負荷や通信時間を大幅に削減することができる。
［ケース３：プロバイダ２０Ｂへ要求後のプロバイダ２０Ａへの再要求］
図１２は、ケース３におけるクライアント１０、プロバイダ２０Ａ、プロキシサービス３０の動作を示す図である。
クライアント１０は、同じPayWordの回数券を他のプロバイダ２０Ｂに対しても利用することができる。PayWord回数券を使ってプロバイダ２０Ｂのサービスをケース１の手順で利用した後、プロバイダ２０Ａのサービスを再度利用する場合、クライアント１０は、PayWord Ｗkとルート値Ｗ0をプロバイダ２０Ａに提示しサービスを要求する（図中の動作（３−１））。
図１２は、ケース３におけるクライアント１０、プロバイダ２０Ａ、プロキシサービス３０の動作を示す図である。
クライアント１０は、同じPayWordの回数券を他のプロバイダ２０Ｂに対しても利用することができる。PayWord回数券を使ってプロバイダ２０Ｂのサービスをケース１の手順で利用した後、プロバイダ２０Ａのサービスを再度利用する場合、クライアント１０は、PayWord Ｗkとルート値Ｗ0をプロバイダ２０Ａに提示しサービスを要求する（図中の動作（３−１））。
プロキシサービス３０が各プロバイダ２０を巡回してクライアント１０の最新利用履歴を分配・収集することにより、プロバイダ２０Ａがクライアント１０のプロバイダ２０Ｂでの最新利用履歴を知っている場合、上記のケース２と同等になり、２者間でのサービス提供が行われることとなる。しかし、プロバイダ２０Ａがクライアント１０のプロバイダ２０Ｂでの最新利用履歴を知らない場合、Ｗkの検証を行なっても矛盾が生じてしまう（照合結果が「偽」となる）。そこで、この場合のみ、Ｗkの検証をプロキシサービス３０に要求する（図中の動作（３−２））。
プロキシサービス３０は、クライアント１０のプロバイダ２０Ｂでの利用履歴をキャッシュしているので、Ｗkの有効性を検証でき、検証結果をプロバイダ２０Ａへ知らせることができる（図中の動作（３−３））。
プロバイダ２０Ａは、プロキシサービス３０のクライアント検証結果を信用してクライアント１０にサービスを提供する（図中の動作（３−４））。この際、プロキシサービス３０とプロバイダ２０Ａは、クライアント１０の利用履歴を更新する。このようにプロキシサービス３０で各プロバイダ２０でのクライアント１０の利用履歴をキャッシュすることによって、複数のプロバイダ２０で回数券を利用することが可能となり、シングルサインオンによるクライアント認証が実現される。
プロバイダ２０Ａは、プロキシサービス３０のクライアント検証結果を信用してクライアント１０にサービスを提供する（図中の動作（３−４））。この際、プロキシサービス３０とプロバイダ２０Ａは、クライアント１０の利用履歴を更新する。このようにプロキシサービス３０で各プロバイダ２０でのクライアント１０の利用履歴をキャッシュすることによって、複数のプロバイダ２０で回数券を利用することが可能となり、シングルサインオンによるクライアント認証が実現される。
上記のケース１〜ケース３で説明したように、クライアント１０は、サービス要求の際に同一のルート値Ｗ0とPayWordの値を送信するだけでよく、自らクライアント認証を要求する必要はない。また、同一プロバイダ２０へのサービス要求の場合は、プロバイダ２０が毎回クライアント検証要求をする必要はなく、PayWordを利用して自身でクライアント検証が行える。したがって、ケース３の適用が多いほど、少ない平均接続回数でサービス提供が可能になり、複数プロバイダ２０へのシングルサインオンも可能になる。
図８のフローチャートを参照して説明したような方法で、プロキシサービス３０が管理下の各プロバイダ２０を巡回し、プロキシサービス３０が持っているクライアント１０の最新利用履歴を分配・収集することにより、ケース３が適用される機会が多くなり、プロバイダ２０によるサービス提供のパフォーマンス向上が期待できる。
図８のフローチャートを参照して説明したような方法で、プロキシサービス３０が管理下の各プロバイダ２０を巡回し、プロキシサービス３０が持っているクライアント１０の最新利用履歴を分配・収集することにより、ケース３が適用される機会が多くなり、プロバイダ２０によるサービス提供のパフォーマンス向上が期待できる。
なお、クライアント１０が利用履歴を偽って不正にサービスの提供を受けようとする場合が考えられるが、プロキシサービス３０が、前回の巡回以後に行われたクライアント１０の利用履歴は全て収集することによって、そのような不正な利用を防止することができる。このため、プロバイダ２０は、クライアント１０の利用履歴のうち、プロキシサービス３０が収集していない最新利用履歴を全て保持しておく。そして、プロキシサービス３０は、収集した最新利用履歴をまとめて確認することにより、上述した不正利用が行われていれば、検出することができる。不正利用が行われたことが検出されたならば、プロキシサービス３０は、クライアント１０の最新利用履歴を修正し、修正した履歴を複数のプロバイダ２０へ分配する。
また、PayWordを用いることで、クライアントのサービス利用に対する課金管理を合わせて行うことができることを述べたが、この課金管理に関してはPayWordではなく他の公知の課金方式を用いて行うことも可能である。
また、PayWordを用いることで、クライアントのサービス利用に対する課金管理を合わせて行うことができることを述べたが、この課金管理に関してはPayWordではなく他の公知の課金方式を用いて行うことも可能である。
次に、本実施形態の他の実装例として、上述したクライアント１０におけるサービスの利用履歴の情報を含む符号化データとしてワンタイムパスワードを用いた認証システムを説明する。
クライアント１０がプロバイダ２０へログインする際に、毎回異なるパスワード（ワンタイムパスワード）を用いるものとする。この場合、クライアント１０が次にログインする際に利用する情報を、次にログインする可能性のあるプロバイダ２０へ予めプロキシサービス３０が分配しておく。これにより、クライアント１０は毎回違うパスワードを使いながらも、プロバイダ２０とクライアント１０の２者間での通信によってクライアント認証が可能になる。
クライアント１０がプロバイダ２０へログインする際に、毎回異なるパスワード（ワンタイムパスワード）を用いるものとする。この場合、クライアント１０が次にログインする際に利用する情報を、次にログインする可能性のあるプロバイダ２０へ予めプロキシサービス３０が分配しておく。これにより、クライアント１０は毎回違うパスワードを使いながらも、プロバイダ２０とクライアント１０の２者間での通信によってクライアント認証が可能になる。
ワンタイムパスワードとしては、
・予め決められた固定パスワードとnonce（１回の使用に限り有効な情報）、パスワード作成時刻createdの値から生成したワンタイムパスワード
・プロキシサービス３０とクライアント１０が共有するハードウェアトークンによるワンタイムパスワード
の２種類が考えられる。以下の説明では、例として固定パスワードから生成したワンタイムパスワードを用いる場合について説明する。
・予め決められた固定パスワードとnonce（１回の使用に限り有効な情報）、パスワード作成時刻createdの値から生成したワンタイムパスワード
・プロキシサービス３０とクライアント１０が共有するハードウェアトークンによるワンタイムパスワード
の２種類が考えられる。以下の説明では、例として固定パスワードから生成したワンタイムパスワードを用いる場合について説明する。
［固定パスワード・nonceの生成］
初めに、クライアント１０は、プロキシサービス３０にnonceの生成要求を行う。その要求に応じて、プロキシサービス３０は、クライアント１０が使うnonceに相当する値を複数（例えば、ｎ１、ｎ２、ｎ３、・・・、ｎ１０）作成し、それをクライアント１０に送る。また、クライアント１０は、所定のプロバイダ２０Ａと他のプロバイダ２０Ｂにログインしたい場合、予めそれぞれに固定パスワード（例えば、ＰＷＤａ、ＰＷＤｂ)を設定する。
初めに、クライアント１０は、プロキシサービス３０にnonceの生成要求を行う。その要求に応じて、プロキシサービス３０は、クライアント１０が使うnonceに相当する値を複数（例えば、ｎ１、ｎ２、ｎ３、・・・、ｎ１０）作成し、それをクライアント１０に送る。また、クライアント１０は、所定のプロバイダ２０Ａと他のプロバイダ２０Ｂにログインしたい場合、予めそれぞれに固定パスワード（例えば、ＰＷＤａ、ＰＷＤｂ)を設定する。
上述したPayWordを用いる実装例と同様にケース１、２、３を考える。
［ケース１：プロバイダ２０Ａへの初回要求］
クライアント１０がプロバイダ２０Ａに接続する場合、クライアント１０は、ＩＤとワンタイムパスワードＰＷＤを送る。ここでパスワードＰＷＤは、nonceと作成時刻ｃ１とを用いて、ＰＷＤ＝ＳＨＡ１（ｎ１＋ｃ１＋ＰＷＤａ）で算出されるものを使う。プロバイダ２０Ａへの初めてのリクエストの場合、プロバイダ２０Ａは、クライアント１０のＩＤとＰＷＤとをプロキシサービス３０へ転送し、クライアント認証を要求する。プロキシサービス３０は、nonceのｎ１の値を知っているので、ｎ１、ｃ１を使ってＰＷＤを計算することができる。したがって、プロバイダ２０Ａから送られてきたＰＷＤが、ｎ１およびｃ１を用いて計算されたＰＷＤの値と同じであれば、セキュリティトークンサービス４０から得たクライアント認証結果と次回のワンタイムパスワードの生成で使われるはずのnonce ｎ２をプロバイダ２０Ａに送る。プロキシサービス３０から取得したクライアント認証結果に問題がなければ、プロバイダ２０Ａはクライアント１０に対してサービス提供を行う。
また、プロキシサービス３０は、クライアント１０が次のパスワード生成に使うnonceの値ｎ２を他のプロバイダ２０へも分配しておく。
［ケース１：プロバイダ２０Ａへの初回要求］
クライアント１０がプロバイダ２０Ａに接続する場合、クライアント１０は、ＩＤとワンタイムパスワードＰＷＤを送る。ここでパスワードＰＷＤは、nonceと作成時刻ｃ１とを用いて、ＰＷＤ＝ＳＨＡ１（ｎ１＋ｃ１＋ＰＷＤａ）で算出されるものを使う。プロバイダ２０Ａへの初めてのリクエストの場合、プロバイダ２０Ａは、クライアント１０のＩＤとＰＷＤとをプロキシサービス３０へ転送し、クライアント認証を要求する。プロキシサービス３０は、nonceのｎ１の値を知っているので、ｎ１、ｃ１を使ってＰＷＤを計算することができる。したがって、プロバイダ２０Ａから送られてきたＰＷＤが、ｎ１およびｃ１を用いて計算されたＰＷＤの値と同じであれば、セキュリティトークンサービス４０から得たクライアント認証結果と次回のワンタイムパスワードの生成で使われるはずのnonce ｎ２をプロバイダ２０Ａに送る。プロキシサービス３０から取得したクライアント認証結果に問題がなければ、プロバイダ２０Ａはクライアント１０に対してサービス提供を行う。
また、プロキシサービス３０は、クライアント１０が次のパスワード生成に使うnonceの値ｎ２を他のプロバイダ２０へも分配しておく。
［ケース２：プロバイダ２０Ａへの連続要求］
クライアント１０は、ＩＤとＰＷＤ＝ＳＨＡ１（ｎ２＋ｃ２＋ＰＷＤａ）とをプロバイダ２０Ａへ送る。プロバイダ２０Ａは、プロキシサービス３０からｎ２を取得しているので、これによりＰＷＤを計算し、クライアント１０の検証ができる。このように、プロバイダ２０Ａへの連続要求の場合は、プロキシサービス３０に接続することなくプロバイダ２０Ａ自身でクライアント検証を行うことができる。
プロキシサービス３０は、巡回時にプロバイダ２０Ａからｎ２を収集し、クライアント１０が次に使うｎ３を他のプロバイダ２０へ分配しておく。
クライアント１０は、ＩＤとＰＷＤ＝ＳＨＡ１（ｎ２＋ｃ２＋ＰＷＤａ）とをプロバイダ２０Ａへ送る。プロバイダ２０Ａは、プロキシサービス３０からｎ２を取得しているので、これによりＰＷＤを計算し、クライアント１０の検証ができる。このように、プロバイダ２０Ａへの連続要求の場合は、プロキシサービス３０に接続することなくプロバイダ２０Ａ自身でクライアント検証を行うことができる。
プロキシサービス３０は、巡回時にプロバイダ２０Ａからｎ２を収集し、クライアント１０が次に使うｎ３を他のプロバイダ２０へ分配しておく。
［ケース３：プロバイダ２０Ｂへ要求後のプロバイダ２０Ａへの再要求］
クライアント１０がプロバイダ２０Ｂへの接続時のＰＷＤ生成にnonce ｎ３を使ったとする。この後、クライアント１０が再度プロバイダ２０Ａに接続する場合には、ＩＤとＰＷＤ＝ＳＨＡ１（ｎ４＋ｃ４＋ＰＷＤａ）をプロバイダ２０Ａへ送る。
プロキシサービス３０が管理下の各プロバイダ２０を適切に巡回できていれば、プロバイダ２０Ａはnonce ｎ４を知っているはずなので、これによりパスワードＰＷＤの検証が行える。
プロキシサービス３０による巡回がクライアント１０のサービス要求までに間に合わなかった場合、プロバイダ２０Ａは、パスワードＰＷＤの検証ができないので、プロキシサービス３０にＰＷＤの検証を依頼する。検証の結果、ＰＷＤが正しければ、プロバイダ２０Ａはクライアント１０にサービス提供を行う。
クライアント１０がプロバイダ２０Ｂへの接続時のＰＷＤ生成にnonce ｎ３を使ったとする。この後、クライアント１０が再度プロバイダ２０Ａに接続する場合には、ＩＤとＰＷＤ＝ＳＨＡ１（ｎ４＋ｃ４＋ＰＷＤａ）をプロバイダ２０Ａへ送る。
プロキシサービス３０が管理下の各プロバイダ２０を適切に巡回できていれば、プロバイダ２０Ａはnonce ｎ４を知っているはずなので、これによりパスワードＰＷＤの検証が行える。
プロキシサービス３０による巡回がクライアント１０のサービス要求までに間に合わなかった場合、プロバイダ２０Ａは、パスワードＰＷＤの検証ができないので、プロキシサービス３０にＰＷＤの検証を依頼する。検証の結果、ＰＷＤが正しければ、プロバイダ２０Ａはクライアント１０にサービス提供を行う。
以上のように、プロキシサービス３０は、クライアント１０が次に使うワンタイムパスワードを計算するためのnonceを予めプロバイダ２０に分配しておく。これによって、プロバイダ２０がプロキシサービス３０に問い合わせることなくパスワードＰＷＤの検証を行い、サービス提供を行うことが可能となる。
上述した固定パスワードとnonce、パスワード作成時刻の値から生成したワンタイムパスワードを用いる代わりに、ハードウェアトークンによるワンタイムパスワードを使う場合は、プロキシサービス３０とクライアント１０との間でハードウェアトークン生成器を持ち、プロキシサービス３０は、クライアント１０が次に使う可能性のあるパスワードをプロバイダ２０へ分配することになる。こうすることで、プロバイダ２０がクライアント１０ごとにハードウェアトークン生成器を持たなくても、ワンタイムパスワードでのログインが可能となり、シングルサインオンによるクライアント認証が実現される。
なお、クライアント１０がパスワードＰＷＤを生成するためのnonceをｎ１０まで使い切ってしまった場合、次にパスワードＰＷＤを生成するためには、再度ｎ１に戻って使う、または、再度プロキシサービス３０にnonceの新規作成を要求する、などの方策が考えられる。
なお、クライアント１０がパスワードＰＷＤを生成するためのnonceをｎ１０まで使い切ってしまった場合、次にパスワードＰＷＤを生成するためには、再度ｎ１に戻って使う、または、再度プロキシサービス３０にnonceの新規作成を要求する、などの方策が考えられる。
１０…クライアント、２０…プロバイダ、２１、３１、４１…通信制御部、２２…サービス実行部、２３、３２、４２…認証実行部、３０…プロキシサービス、３３…利用履歴分配・収集部、４０…セキュリティトークンサービス、１０１…ＣＰＵ（中央処理装置）、１０３…メインメモリ、１０５…磁気ディスク装置（ＨＤＤ）、１０６…ネットワークインターフェイス
Claims (22)
- ネットワークを介して所定のサービスを提供する複数のプロバイダを一括管理してシングルサインオンによるクライアント認証を行う認証システムにおいて、
ネットワークを介して所定のサービスを提供するプロバイダと、
前記プロバイダにサービス要求を行ったクライアントの認証を行う認証サーバと、
前記認証サーバと前記プロバイダとの間に介在して、前記プロバイダが前記認証サーバに対して行う認証要求を管理するプロキシサーバとを備え、
前記プロキシサーバは、前記認証サーバによる認証結果を保存し、一定条件の下、前記プロバイダから受け取った前記認証要求を前記認証サーバへ転送せず、保存されている認証結果に基づいて前記クライアントの認証を代行することを特徴とする認証システム。 - 前記プロバイダは、前記クライアントのサービス利用履歴を保存し、当該サービス利用履歴に基づいて当該クライアントに対してサービスを提供可能であることが明らかである場合は、前記認証要求を行うことなく、当該クライアントに対してサービスを提供することを特徴とする請求項１に記載の認証システム。
- 前記プロキシサーバは、前記クライアントのサービス利用履歴を前記プロバイダから取得して管理し、所定のプロバイダからの認証要求に応じて、前記認証サーバによる認証結果と当該サービス利用履歴とに基づき当該クライアントに対するサービス提供の可否を判断することを特徴とする請求項２に記載の認証システム。
- 前記プロキシサーバは、複数の前記プロバイダを巡回して、前記クライアントごとのサービス利用履歴を収集して比較し、最新の内容を選択して、各前記プロバイダにおける前記クライアントごとのサービス利用履歴を当該最新の内容に更新させることを特徴とする請求項２に記載の認証システム。
- ネットワークを介して所定のサービスを提供する複数のプロバイダと、
所定の前記プロバイダからの検証要求に応じて、当該プロバイダにサービス要求を行ったクライアントに対するサービス提供の可否を判断する検証サーバとを備え、
前記プロバイダは前記クライアントのサービス利用履歴を保存し、
前記検証サーバは、前記クライアントの認証情報と当該クライアントによるサービス利用回数とを情報として含む符号化データを生成して当該クライアントに提供し、前記プロバイダから前記サービス利用履歴を取得して管理し、所定のクライアントが所定のプロバイダに対して当該符号化データを用いてサービス要求を行った場合に、当該プロバイダからの検証要求に応じて、当該符号化データと当該クライアントのサービス利用履歴とを照合してサービス提供の可否を判断することを特徴とする認証システム。 - 前記プロバイダは、所定のクライアントが前記符号化データを用いてサービス要求を行った場合に、当該符号化データと前記サービス利用履歴とを照合し、当該クライアントに対してサービスを提供可能であることが明らかである場合は、前記検証サーバに対する検証要求を行うことなく、当該クライアントに対してサービスを提供することを特徴とする請求項５に記載の認証システム。
- 前記検証サーバは、複数の前記プロバイダを巡回して、前記クライアントごとのサービス利用履歴を収集して比較し、最新の内容を選択して、各前記プロバイダにおける前記クライアントごとのサービス利用履歴を当該最新の内容に更新させることを特徴とする請求項５に記載の認証システム。
- ネットワークを介して所定のサービスを提供する複数のプロバイダを一括管理してシングルサインオンを実現するサーバにおいて、
前記プロバイダにおける所定のクライアントのサービス利用履歴を格納する利用履歴格納手段と、
所定の認証サーバに依頼して取得した前記所定のクライアントに対する認証結果を格納する認証結果格納手段と、
前記プロバイダからの問い合わせに応じて、前記利用履歴格納手段に格納されている前記サービス利用履歴と前記認証結果格納手段に格納されている前記認証結果とを用いて、前記所定のクライアントに対するサービス提供の可否を判断する検証手段とを備え、
前記検証手段は、前記認証結果格納手段に保存されている認証結果が有効でない場合に、前記サービス提供の可否を判断するためのクライアント認証を前記認証サーバに依頼することを特徴とするサーバ。 - 複数の前記プロバイダを巡回して、前記クライアントごとのサービス利用履歴を収集し、最新の内容を選択して、前記利用履歴格納手段に格納する利用履歴収集手段を更に備えることを特徴とする請求項８に記載のサーバ。
- 前記利用履歴収集手段は、クライアントとの通信の総量が多いプロバイダを優先して巡回し、サービス利用履歴を収集することを特徴とする請求項９に記載のサーバ。
- 前記クライアントの認証情報と当該クライアントによるサービス利用回数とを情報として含む符号化データを生成する符号化データ生成手段を更に備え、
前記検証手段は、所定のクライアントが所定のプロバイダに対して当該符号化データを用いてサービス要求を行った場合に、当該符号化データと利用履歴格納手段に格納されている当該クライアントのサービス利用履歴とを照合してサービス提供の可否を判断することを特徴とする請求項８に記載のサーバ。 - コンピュータを用いて、プロバイダにサービスの提供を要求するクライアントの認証を行う認証方法であって、
前記コンピュータが、前記クライアントのサービス利用履歴を符号化した符号化データと所定の記憶手段に格納されている当該クライアントのサービス利用履歴の情報とを照合する第１のステップと、
前記第１のステップで照合結果が「偽」である場合に、前記コンピュータが、所定の記憶手段に格納されている前記クライアントに対する認証情報に基づいて当該クライアントに対するサービス提供の可否を判断する第２のステップと、
前記第２のステップで用いられる前記認証情報が有効でない場合に、前記コンピュータが、所定の認証サーバに前記クライアントの認証を依頼し、取得した当該認証結果に基づいて当該クライアントに対するサービス提供の可否を判断する第３のステップと
を含むことを特徴とする認証方法。 - 前記第１のステップで照合結果が「真」である場合に、当該クライアントに対するサービス提供が可能と判断するステップを更に含むことを特徴とする請求項１２に記載の認証方法。
- 前記第３のステップで取得された前記認証結果を、前記第２のステップで用いられる前記認証情報として所定の記憶手段に格納するステップを更に含むことを特徴とする請求項１２に記載の認証方法。
- コンピュータを、
前記プロバイダにおける所定のクライアントのサービス利用履歴を格納する利用履歴格納手段と、
所定の認証サーバに依頼して取得した前記所定のクライアントに対する認証結果を格納する認証結果格納手段と、
前記プロバイダからの問い合わせに応じて、前記利用履歴格納手段に格納されている前記サービス利用履歴と前記認証結果格納手段に格納されている前記認証結果とを用いて、前記所定のクライアントに対するサービス提供の可否を判断し、かつ認証結果格納手段に保存されている認証結果が有効でない場合に、前記サービス提供の可否を判断するためのクライアント認証を前記認証サーバに依頼する検証手段として
機能させることを特徴とするプログラム。 - 複数の前記プロバイダを巡回して、前記クライアントごとのサービス利用履歴を収集し、最新の内容を選択して、前記利用履歴格納手段に格納する利用履歴収集手段として、前記コンピュータを更に機能させることを特徴とする請求項１５に記載のプログラム。
- 前記利用履歴収集手段の機能として、前記コンピュータに、クライアントとの通信の総量が多いプロバイダを優先して巡回し、サービス利用履歴を収集させることを特徴とする請求項１６に記載のプログラム。
- 前記利用履歴格納手段に格納された最新の前記サービス利用履歴を前記プロバイダに分配する利用履歴分配手段として、前記コンピュータを更に機能させることを特徴とする請求項１６に記載のプログラム。
- 前記利用履歴格納手段の機能として、前記コンピュータに、サービス提供の可否を問い合わせるための接続を長期間行っていないプロバイダを優先して巡回し、前記最新のサービス利用履歴を分配させることを特徴とする請求項１８に記載のプログラム。
- 前記利用履歴格納手段の機能として、前記コンピュータに、前記利用履歴収集手段によって前記最新のサービス利用履歴が収集されたクライアントとの通信回数が多いプロバイダを優先して巡回し、前記最新のサービス利用履歴を分配させることを特徴とする請求項１８に記載のプログラム。
- 前記クライアントの認証情報と当該クライアントによるサービス利用回数とを情報として含む符号化データを生成する符号化データ生成手段として、前記コンピュータを更に機能させ、
前記検証手段の機能として、前記コンピュータに、所定のクライアントが所定のプロバイダに対して当該符号化データを用いてサービス要求を行った場合に、当該符号化データと利用履歴格納手段に格納されている当該クライアントのサービス利用履歴とを照合してサービス提供の可否を判断させることを特徴とする請求項１５に記載のプログラム。 - 請求項１５から請求項２１のいずれかに記載のプログラムを、コンピュータが読み取り可能に記録した記録媒体。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003293643A JP4039632B2 (ja) | 2003-08-14 | 2003-08-14 | 認証システム、サーバおよび認証方法並びにプログラム |
| CNB2004100563154A CN100444544C (zh) | 2003-08-14 | 2004-08-06 | 验证系统，服务器和验证方法及程序 |
| US10/917,712 US20050039054A1 (en) | 2003-08-14 | 2004-08-14 | Authentication system, server, and authentication method and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003293643A JP4039632B2 (ja) | 2003-08-14 | 2003-08-14 | 認証システム、サーバおよび認証方法並びにプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005062556A true JP2005062556A (ja) | 2005-03-10 |
| JP4039632B2 JP4039632B2 (ja) | 2008-01-30 |
Family
ID=34131765
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003293643A Expired - Fee Related JP4039632B2 (ja) | 2003-08-14 | 2003-08-14 | 認証システム、サーバおよび認証方法並びにプログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20050039054A1 (ja) |
| JP (1) | JP4039632B2 (ja) |
| CN (1) | CN100444544C (ja) |
Cited By (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006260321A (ja) * | 2005-03-18 | 2006-09-28 | Nec Corp | サービス提供システムおよびそのユーザ認証方法 |
| KR100639992B1 (ko) | 2004-12-14 | 2006-10-31 | 한국전자통신연구원 | 클라이언트 모듈을 안전하게 배포하는 보안 장치 및 그방법 |
| JP2007122553A (ja) * | 2005-10-31 | 2007-05-17 | Konica Minolta Business Technologies Inc | サーバ、サーバシステム、複合多機能端末、ユーザ認証方法 |
| JP2007172588A (ja) * | 2005-11-22 | 2007-07-05 | Ricoh Co Ltd | 認証チケット処理装置 |
| WO2009001447A1 (ja) * | 2007-06-27 | 2008-12-31 | Fujitsu Limited | 認証方法、認証システム、認証装置及びコンピュータプログラム |
| JP2009122915A (ja) * | 2007-11-14 | 2009-06-04 | Hitachi Ltd | 情報端末装置およびその運用方法 |
| JP2010055175A (ja) * | 2008-08-26 | 2010-03-11 | Nippon Telegr & Teleph Corp <Ntt> | 連携サービス提供システム、サービス管理装置、及び、情報共有方法 |
| JP2010277144A (ja) * | 2009-05-26 | 2010-12-09 | Nippon Telegr & Teleph Corp <Ntt> | ユーザ認証システム、ユーザ端末、ログ認証サーバ、ユーザ認証方法およびプログラム |
| JP2013077323A (ja) * | 2013-01-15 | 2013-04-25 | Fujitsu Ltd | 識別情報統合管理システム，識別情報統合管理サーバ及び識別情報統合管理プログラム |
| JP2013117748A (ja) * | 2011-12-01 | 2013-06-13 | Canon Inc | 情報処理システム、情報処理装置、認証方法、及びコンピュータプログラム |
| KR101306442B1 (ko) | 2011-11-30 | 2013-09-09 | 에스케이씨앤씨 주식회사 | 휴대용 디바이스에 발급된 토큰을 이용한 사용자 인증 방법 및 시스템 |
| US8819799B2 (en) | 2011-11-05 | 2014-08-26 | Kyocera Document Solutions Inc. | Image forming apparatus, image forming system, and method for realizing pseudo single sign-on |
| KR101436404B1 (ko) | 2013-02-15 | 2014-09-01 | 주식회사 안랩 | 사용자 인증 장치 및 방법 |
| US9294484B2 (en) | 2012-10-31 | 2016-03-22 | Ricoh Company, Ltd. | System, service providing device, and service providing method |
| WO2016137307A1 (en) * | 2015-02-27 | 2016-09-01 | Samsung Electronics Co., Ltd. | Attestation by proxy |
| US10193700B2 (en) | 2015-02-27 | 2019-01-29 | Samsung Electronics Co., Ltd. | Trust-zone-based end-to-end security |
| US11107047B2 (en) | 2015-02-27 | 2021-08-31 | Samsung Electronics Co., Ltd. | Electronic device providing electronic payment function and operating method thereof |
| US11129018B2 (en) | 2015-02-27 | 2021-09-21 | Samsung Electronics Co., Ltd. | Payment means operation supporting method and electronic device for supporting the same |
| US11182769B2 (en) | 2015-02-12 | 2021-11-23 | Samsung Electronics Co., Ltd. | Payment processing method and electronic device supporting the same |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7917468B2 (en) * | 2005-08-01 | 2011-03-29 | Seven Networks, Inc. | Linking of personal information management data |
| US8468126B2 (en) | 2005-08-01 | 2013-06-18 | Seven Networks, Inc. | Publishing data in an information community |
| US7698734B2 (en) * | 2004-08-23 | 2010-04-13 | International Business Machines Corporation | Single sign-on (SSO) for non-SSO-compliant applications |
| WO2006088922A2 (en) * | 2005-02-14 | 2006-08-24 | Reactivity, Inc. | Proxy server caching |
| US20190268430A1 (en) | 2005-08-01 | 2019-08-29 | Seven Networks, Llc | Targeted notification of content availability to a mobile device |
| US8032657B2 (en) * | 2005-09-12 | 2011-10-04 | Microsoft Corporation | Preservation of type information between a client and a server |
| WO2007059628A1 (en) | 2005-11-24 | 2007-05-31 | Oz Communications Inc. | Method for securely associating data with http and https sessions |
| US20070168297A1 (en) * | 2006-01-18 | 2007-07-19 | Cheng Siu L | Efficient method and system for secure business-to-business transaction |
| JP4742903B2 (ja) * | 2006-02-17 | 2011-08-10 | 日本電気株式会社 | 分散認証システム及び分散認証方法 |
| US20070245414A1 (en) * | 2006-04-14 | 2007-10-18 | Microsoft Corporation | Proxy Authentication and Indirect Certificate Chaining |
| JP4867482B2 (ja) * | 2006-06-06 | 2012-02-01 | 富士ゼロックス株式会社 | 制御プログラムおよび通信システム |
| US20080086766A1 (en) * | 2006-10-06 | 2008-04-10 | Microsoft Corporation | Client-based pseudonyms |
| US8656472B2 (en) | 2007-04-20 | 2014-02-18 | Microsoft Corporation | Request-specific authentication for accessing web service resources |
| KR101467174B1 (ko) * | 2007-08-16 | 2014-12-01 | 삼성전자주식회사 | 통신 수행 방법 및 그 장치와, 통신 수행 제어 방법 및 그장치 |
| KR101152782B1 (ko) * | 2007-08-16 | 2012-06-12 | 삼성전자주식회사 | 통신 중계 방법 및 그 장치와, 통신 중계 제어 방법 및 그장치 |
| WO2009084601A1 (ja) * | 2007-12-27 | 2009-07-09 | Nec Corporation | アクセス権限管理システム、アクセス権限管理方法及びアクセス権限管理用プログラム |
| US8910255B2 (en) | 2008-05-27 | 2014-12-09 | Microsoft Corporation | Authentication for distributed secure content management system |
| US7600253B1 (en) * | 2008-08-21 | 2009-10-06 | International Business Machines Corporation | Entity correlation service |
| US8549601B2 (en) * | 2009-11-02 | 2013-10-01 | Authentify Inc. | Method for secure user and site authentication |
| KR101286922B1 (ko) * | 2009-12-01 | 2013-07-23 | 한국전자통신연구원 | 간이 인증을 이용한 서비스 접속 방법, 장치, 사용자 인증 장치 및 단말 |
| JP5660050B2 (ja) * | 2009-12-28 | 2015-01-28 | 日本電気株式会社 | ユーザ情報活用システム、装置、方法およびプログラム |
| US8869258B2 (en) * | 2010-03-12 | 2014-10-21 | Microsoft Corporation | Facilitating token request troubleshooting |
| US8881247B2 (en) * | 2010-09-24 | 2014-11-04 | Microsoft Corporation | Federated mobile authentication using a network operator infrastructure |
| JP2012212211A (ja) * | 2011-03-30 | 2012-11-01 | Hitachi Ltd | 認証連携システム、および、認証連携方法 |
| FR2973626A1 (fr) * | 2011-03-31 | 2012-10-05 | France Telecom | Mecanisme de redirection entrante sur un proxy inverse |
| US8972729B2 (en) * | 2012-10-24 | 2015-03-03 | Verizon Patent And Licensing Inc. | Secure information delivery |
| CN103036883B (zh) * | 2012-12-14 | 2015-11-04 | 公安部第一研究所 | 一种安全服务器的安全通讯方法与系统 |
| JP6102296B2 (ja) * | 2013-02-06 | 2017-03-29 | 株式会社リコー | 情報処理システム、情報処理装置、認証方法及びプログラム |
| JP6843653B2 (ja) * | 2017-03-06 | 2021-03-17 | キヤノン株式会社 | サーバ装置、情報処理方法及びプログラム |
| US10623414B2 (en) * | 2017-04-26 | 2020-04-14 | International Business Machines Corporation | Authenticating multi-facets of a user through unaware third-party services |
| CN112527835B (zh) * | 2020-12-04 | 2023-07-11 | 平安科技（深圳）有限公司 | 基于缓存的认证请求处理方法、装置及相关设备 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5923756A (en) * | 1997-02-12 | 1999-07-13 | Gte Laboratories Incorporated | Method for providing secure remote command execution over an insecure computer network |
| US6609198B1 (en) * | 1999-08-05 | 2003-08-19 | Sun Microsystems, Inc. | Log-on service providing credential level change without loss of session continuity |
| US6601170B1 (en) * | 1999-12-30 | 2003-07-29 | Clyde Riley Wallace, Jr. | Secure internet user state creation method and system with user supplied key and seeding |
| US7174454B2 (en) * | 2002-11-19 | 2007-02-06 | America Online, Inc. | System and method for establishing historical usage-based hardware trust |
| JP2002032340A (ja) * | 2000-07-14 | 2002-01-31 | Nec Corp | Ｗｅｂサイトに対するシングルサインオンシステム及び方法並びに記録媒体 |
| JP2002288139A (ja) * | 2001-03-28 | 2002-10-04 | Novell Japan Ltd | 携帯電話機用シングルサインオンシステムおよび方法 |
| JP2002335239A (ja) * | 2001-05-09 | 2002-11-22 | Nippon Telegr & Teleph Corp <Ntt> | シングルサインオン認証方法及びシステム装置 |
-
2003
- 2003-08-14 JP JP2003293643A patent/JP4039632B2/ja not_active Expired - Fee Related
-
2004
- 2004-08-06 CN CNB2004100563154A patent/CN100444544C/zh not_active Expired - Fee Related
- 2004-08-14 US US10/917,712 patent/US20050039054A1/en not_active Abandoned
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100639992B1 (ko) | 2004-12-14 | 2006-10-31 | 한국전자통신연구원 | 클라이언트 모듈을 안전하게 배포하는 보안 장치 및 그방법 |
| JP2006260321A (ja) * | 2005-03-18 | 2006-09-28 | Nec Corp | サービス提供システムおよびそのユーザ認証方法 |
| JP2007122553A (ja) * | 2005-10-31 | 2007-05-17 | Konica Minolta Business Technologies Inc | サーバ、サーバシステム、複合多機能端末、ユーザ認証方法 |
| JP2007172588A (ja) * | 2005-11-22 | 2007-07-05 | Ricoh Co Ltd | 認証チケット処理装置 |
| US8612745B2 (en) | 2005-11-22 | 2013-12-17 | Ricoh Company, Ltd. | Authentication ticket processing apparatus and method with improved performance for self-contained ticket |
| WO2009001447A1 (ja) * | 2007-06-27 | 2008-12-31 | Fujitsu Limited | 認証方法、認証システム、認証装置及びコンピュータプログラム |
| JP2009122915A (ja) * | 2007-11-14 | 2009-06-04 | Hitachi Ltd | 情報端末装置およびその運用方法 |
| JP2010055175A (ja) * | 2008-08-26 | 2010-03-11 | Nippon Telegr & Teleph Corp <Ntt> | 連携サービス提供システム、サービス管理装置、及び、情報共有方法 |
| JP2010277144A (ja) * | 2009-05-26 | 2010-12-09 | Nippon Telegr & Teleph Corp <Ntt> | ユーザ認証システム、ユーザ端末、ログ認証サーバ、ユーザ認証方法およびプログラム |
| US8819799B2 (en) | 2011-11-05 | 2014-08-26 | Kyocera Document Solutions Inc. | Image forming apparatus, image forming system, and method for realizing pseudo single sign-on |
| KR101306442B1 (ko) | 2011-11-30 | 2013-09-09 | 에스케이씨앤씨 주식회사 | 휴대용 디바이스에 발급된 토큰을 이용한 사용자 인증 방법 및 시스템 |
| JP2013117748A (ja) * | 2011-12-01 | 2013-06-13 | Canon Inc | 情報処理システム、情報処理装置、認証方法、及びコンピュータプログラム |
| US9294484B2 (en) | 2012-10-31 | 2016-03-22 | Ricoh Company, Ltd. | System, service providing device, and service providing method |
| JP2013077323A (ja) * | 2013-01-15 | 2013-04-25 | Fujitsu Ltd | 識別情報統合管理システム，識別情報統合管理サーバ及び識別情報統合管理プログラム |
| KR101436404B1 (ko) | 2013-02-15 | 2014-09-01 | 주식회사 안랩 | 사용자 인증 장치 및 방법 |
| US11182769B2 (en) | 2015-02-12 | 2021-11-23 | Samsung Electronics Co., Ltd. | Payment processing method and electronic device supporting the same |
| WO2016137307A1 (en) * | 2015-02-27 | 2016-09-01 | Samsung Electronics Co., Ltd. | Attestation by proxy |
| US10193700B2 (en) | 2015-02-27 | 2019-01-29 | Samsung Electronics Co., Ltd. | Trust-zone-based end-to-end security |
| US11107047B2 (en) | 2015-02-27 | 2021-08-31 | Samsung Electronics Co., Ltd. | Electronic device providing electronic payment function and operating method thereof |
| US11129018B2 (en) | 2015-02-27 | 2021-09-21 | Samsung Electronics Co., Ltd. | Payment means operation supporting method and electronic device for supporting the same |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4039632B2 (ja) | 2008-01-30 |
| CN100444544C (zh) | 2008-12-17 |
| US20050039054A1 (en) | 2005-02-17 |
| CN1581771A (zh) | 2005-02-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4039632B2 (ja) | 認証システム、サーバおよび認証方法並びにプログラム | |
| CA3049761C (en) | Method for providing payment gateway service using utxo-based protocol and server using same | |
| CA3053316C (en) | Method for providing simplified account registration service and user authentication service, and authentication server using same | |
| US10924285B2 (en) | Method and server for providing notary service with respect to file and verifying file recorded by the notary service | |
| CN110268678B (zh) | 基于pki的认证代理用户的登录方法及利用其的服务器 | |
| US10462138B2 (en) | Application programming interface access controls | |
| US10944574B2 (en) | Method for providing virtual asset service based on decentralized identifier and virtual asset service providing server using them | |
| US10372942B1 (en) | Method and server for providing notary service for file and verifying file recorded by notary service | |
| JP6457165B1 (ja) | 検査システムおよび検査方法 | |
| US20190306147A1 (en) | Method for sso service using pki based on blockchain networks, and device and server using the same | |
| CN108810006A (zh) | 资源访问方法、装置、设备及存储介质 | |
| JP4964338B2 (ja) | ユーザ確認装置、方法及びプログラム | |
| US20200250655A1 (en) | Efficient, environmental and consumer friendly consensus method for cryptographic transactions | |
| JP2023542681A (ja) | ブロックチェーンの許可フレームワークへのデバイスアイデンティティの統合 | |
| CN110489957B (zh) | 访问请求的管理方法和计算机存储介质 | |
| CN107347073B (zh) | 一种资源信息处理方法 | |
| CN110301127A (zh) | 用于预测性令牌验证的装置和方法 | |
| Klopfenstein et al. | " Worth one minute": An anonymous rewarding platform for crowd-sensing systems | |
| JP2004362189A (ja) | ユーザ情報流通システム | |
| KR100609701B1 (ko) | 전자 거래 내역에 대한 프라이버시를 보호하는 거래 인증방법 및 시스템 | |
| Satoh et al. | Single sign on architecture with dynamic tokens | |
| CN116071070A (zh) | 资源转移方法及相关装置 | |
| CN115967508A (zh) | 数据访问控制方法及装置、设备、存储介质、程序产品 | |
| US11849041B2 (en) | Secure exchange of session tokens for claims-based tokens in an extensible system | |
| KR102245382B1 (ko) | 블록체인 네트워크 기반의 가상 공통 아이디 서비스 방법 및 이를 이용한 서비스 제공 서버 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061017 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070115 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070410 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070705 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070813 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20071030 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20071101 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071102 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101116 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |