JP2013228951A - 認証ウエブページｕｒｌサービス装置、ウエブサービス提供システム、認証ウエブページｕｒｌサービス装置の動作方法、およびウエブサービス提供システムの動作方法 - Google Patents

Abstract

【課題】OpenID（登録商標）のような共用認証技術において、例えば未知のブログサーバγが悪意ある者により運営されている可能性もあり、そこから返信されるXRDS文書の信頼性が担保されていない、あるいは担保することが難しいという課題がある。
【解決手段】以上の課題解決のため、本発明は、複数の認証ウエブページURLをURL用IDと関連付けて蓄積した認証ウエブページURL蓄積部と、一方のサービス提供者サーバの求めに応じて他方のサービス提供者サーバから送信されるURL用IDを直接又は間接に受信するURL用ID受信部と、受信したURL用IDを用いてURL蓄積部から認証ウエブページURLを取得する認証ウエブページURL取得部と、取得した認証ウエブページURLを、前記一方のサービス提供者のために送信する認証ウエブページURL送信部と、を有する認証ウエブページURLサービスを提供する。
【選択図】図３

Description

本発明は、エンドユーザに対して行われる一方のサービス提供者サーバからの所定のサービスの提供を、他方のサービス提供者サーバでの認証に基づいて行う技術に関する。

現在、ウエブ上では多様なサービス提供者によって、例えば動画や音楽などのコンテンツデータを閲覧、購入できるコンテンツ配信サービスやニュース記事を閲覧できるニュース配信サービス、食品や書物などの各種商品を仮想店舗で購入できるネットショッピングサービス、インターネットブラウザを利用したメールの送受信サービス、ブログの投稿及び配信サービス、納税の受付や各種行政書類の発行などの行政サービスなど、様々なサービスが提供されている。

また、これらウエブで提供されるサービスでは、利用者（エンドユーザ）を特定するために、例えばユーザIDやパスワードなどの認証用情報を利用して認証を行う必要がある場合が多い。しかしこのような認証においては、予め利用したいウエブサービスにユーザIDやパスワードなどの認証用情報を登録しておく必要があり、また、基本的にユーザは複数のサービスを利用するが、各サービスにおける認証用情報をユーザ側で個別に管理するのは大変である。

そこで、認証を必要とする複数のウエブサービスを利用するに際し、例えば「OpenID（登録商標）」のように、所定のウエブサービスにおける認証を共用できる技術が開発、提供されている。

以下OpenID（登録商標）を例に挙げ、図１を用いてこの共用認証技術によるエンドユーザへのサービス提供手順を説明する。すなわち、エンドユーザαがある会員専用の技術記事閲覧サービスβを利用しようとした場合に、まず、当該サービスサーバβに対して利用する認証サービスの識別情報（例えばユーザＡが普段利用しているブログサービスγのユーザα専用のブログ公開URLなど）を送信する。

すると技術記事閲覧サーバβは、受信したURLに基づいてブログサーバγに対してXRDS（eXtensible Resource Descriptor Sequence）文書の送信を要求する。そしてXRDS文書には、認証システム（認証ウエブページ）のURLやそこでの認証方法、セキュリティポリシーなどが記述されており、技術記事閲覧サーバβでは、ブログサーバγから返信されたそのXRDS文書に記述されたURLで示される認証ウエブページに、例えばエンドユーザαの端末をリダイレクトし、そこで行われる認証結果を取得して正しい旨のユーザ認証がなされれば、技術記事の閲覧サービスをエンドユーザに提供するという具合である。

以上のように、上記手順においてはエンドユーザからのリクエスト（認証サービスの識別情報の受信）に応じて、技術記事閲覧サーバβが未知のブログサーバγと動的に連携してユーザ認証を行うことができる。

また、特許文献１には、ユーザがプレゼンス情報（ユーザの状況情報）や優先度、使用条件、サービス提供サーバ条件などを予め設定しておくことで、複数の認証サービスの中から利用する認証サービスを選択可能とする技術が開示されている。

特開２０１０−１２８７１９号公報

しかし上記共用認証技術において、例えば未知のブログサーバγが悪意ある者により運営されている可能性もあり、そこから返信されるXRDS文書の信頼性が担保されていない。あるいは、認証を担う未知のサーバの全てを第三者機関などが審査することで信頼性を保証する方法も考えられるが、全てのサーバについてそれを行うことは困難であり、やはり全ての信頼性を担保することは難しい、という課題がある。

また、特許文献１の技術でもユーザが信頼性が高いと考える認証サービスの優先度などを高く設定していたとしても、そのユーザの考え自体が誤認である可能性があり、やはり返信されるXRDS文書の信頼性が担保されていない、あるいは担保することが難しいという課題は残されている。

以上の課題を解決するために、本発明は、上記XRDS文書のような認証ウエブページURLを含む情報を別途管理する第三のサーバ装置を提供し、そのサーバ装置の信頼性を担保することで容易に認証ウエブページURLを含む情報の信頼性を担保することができるよう構成する。

具体的に、複数の認証ウエブページURLをURL用IDと関連付けて蓄積した認証ウエブページURL蓄積部と、一方のサービス提供者サーバの求めに応じて他方のサービス提供者サーバから送信されるURL用IDを直接又は間接に受信するURL用ID受信部と、受信したURL用IDを用いてURL蓄積部から認証ウエブページURLを取得する認証ウエブページURL取得部と、取得した認証ウエブページURLを、前記一方のサービス提供者のために送信する認証ウエブページURL送信部と、を有する認証ウエブページURLサービスを提供する。

また上記構成を備え、さらにURL用ID受信部が、前記URL用IDを一方のサービス提供者から受信する中継受信手段を有する認証ウエブページURLサービス装置も提供する。

また、複数のサービス提供者サーバと、上記構成を備える認証ウエブページURLサービス装置と、からなるウエブサービス提供システムであって、前記一方のサービス提供者サーバは、認証ウエブページURLを受信する認証ウエブページURL受信部と、受信したURLで識別される認証ウエブページを利用した認証結果を取得する認証結果取得部と、取得した認証結果に基づいてサービスの提供処理を行うサービス提供処理部と、を有するウエブサービス提供システムも提供する。

また上記のような認証ウエブページURLサービス装置の動作方法、およびウエブサービス提供システムの動作方法も提供する。

以上のような構成をとる本発明によって、上記XRDS文書のような認証ウエブページURLを含む情報を、サービスを提供するサーバや認証を行うサーバとは別の認証ウエブページURLサービス装置にて管理し、その認証ウエブページURLサービス装置からこれらサーバに対して認証ウエブページURLを含む情報を提供することができる。

したがって、サービスを提供するサーバや認証を行うサーバの信頼性を個別に担保しなくとも、この認証ウエブページURLサービス装置の信頼性を担保することで容易に認証ウエブページURLを含む情報の信頼性を担保することができる。

従来の共用認証技術におけるエンドユーザへのサービス提供手順の一例を表すシーケンス図 実施例１の認証ウエブページURLサービス装置によるユーザ認証およびサービス利用の一例を説明するための概念図 実施例１の認証ウエブページURLサービス装置における機能ブロックの一例を表す図 実施例１の認証ウエブページURLサービス装置にて蓄積される認証ウエブページURLやURL用IDの一例を表す図 実施例１の認証ウエブページURLサービス装置から送信される認証ウエブページURLの一例を表す図 実施例１の認証ウエブページURLサービス装置と通信するサービス提供者サーバにおける機能ブロックの一例を表す図 実施例１の認証ウエブページURLサービス装置におけるハードウェア構成の一例を表す概略図 実施例１の認証ウエブページURLサービス装置における処理の流れの一例を表すフローチャート 実施例１の認証ウエブページURLサービス装置を含むウエブサービス提供システムにおける処理の流れの一例を表すシーケンス図

以下に、図を用いて本発明の実施の形態を説明する。なお、本発明はこれら実施の形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、種々なる態様で実施しうる。

なお、実施例１は、主に請求項１から６について説明する。

≪実施例１≫

<概要>

図２は、本実施例の認証ウエブページURLサービス装置によるユーザ認証およびサービス利用の一例を説明するための概念図である。この図にあるように、（１）エンドユーザαがユーザ認証を必要とする技術記事閲覧サービスβを利用しようとした場合に、まずユーザ端末αから当該サービスサーバβに対して、認証のための情報としてブログサービスγのユーザα専用のブログ公開URLを送信する。

すると、（２）技術記事閲覧サーバβは、受信したURLに基づいてブログサーバγに対してXRDS文書（の管理場所アドレス）の送信を要求する。そして（３）当該要求を受けたブログサーバγは、自身のXRDS文書を管理する本実施例の認証ウエブページURLサービス装置のURLを返信する。

そして（４）技術記事閲覧サーバβは、その受信したURLに基づいて認証ウエブページURLサービス装置にアクセスし、ブログサーバγの認証ウエブページURLを含むXRDS文書の返信を要求する。

そして、（５）当該要求に応じて返信されたXRDS文書を受信すると、（６）技術記事閲覧サーバβは、そのXRDS文書に記述されたURLで示される認証ウエブページ、つまりブログサーバγのログイン画面などにユーザ端末αをリダイレクトなどでアクセスさせる。そして、（７）そのブログサーバγの認証ウエブページにて行われるエンドユーザの認証結果を取得し、正しい旨のユーザ認証がなされていれば、（８）限定公開されている技術記事の閲覧をエンドユーザαに許可する、という具合である。

このように、本実施例では認証ウエブページURLを含む情報を、サービスを提供するサーバや認証を行うサーバとは別の認証ウエブページURLサービス装置にて管理し、その認証ウエブページURLサービス装置からこれらサーバに対して認証ウエブページURLを含む情報を提供することができる。

したがって、サービスを提供するサーバや認証を行うサーバの信頼性を個別に担保しなくとも、この認証ウエブページURLサービス装置の信頼性を担保することで容易に認証ウエブページURLを含む情報の信頼性を担保することができる。

<機能的構成>

図３は、本実施例の認証ウエブページURLサービス装置における機能ブロックの一例を表す図である。

なお、以下に記載する本装置の機能ブロックは、ハードウェア及びソフトウェアの組み合わせとして実現され得る。具体的には、コンピュータを利用するものであれば、ＣＰＵや主メモリ、バス、あるいは二次記憶装置（ハードディスクや不揮発性メモリ、ＣＤやＤＶＤなどの記憶メディアとそれらメディアの読取ドライブなど）、情報入力に利用される入力デバイス、印刷機器や表示装置、その他の外部周辺装置などのハードウェア構成部、またその外部周辺装置用のインターフェース、通信用インターフェース、それらハードウェアを制御するためのドライバプログラムやその他アプリケーションプログラム、ユーザ・インターフェース用アプリケーションなどが挙げられる。そして主メモリ上に展開したプログラムに従ったＣＰＵの演算処理によって、入力デバイスやその他インターフェースなどから入力され、メモリやハードディスク上に保持されているデータなどが加工、蓄積されたり、上記各ハードウェアやソフトウェアを制御するための命令が生成されたりする。あるいは本装置の機能ブロックは専用ハードウェアによって実現されてもよい。また、この発明は装置として実現できるのみでなく、方法としても実現可能である。

また、このような発明の一部をソフトウェアとして構成することができる。さらに、そのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品、及び同製品を固定した記録媒体も、当然にこの発明の技術的な範囲に含まれる（本明細書の全体を通じて同様である）。

そしてこの図３に示すように、本実施例の「認証ウエブページURLサービス装置」（０３００）は、「認証ウエブページURL蓄積部」（０３０１）と、「URL用ID受信部」（０３０２）と、「認証ウエブページURL取得部」（０３０３）と、「認証ウエブページURL送信部」（０３０４）と、を有する。

「認証ウエブページURL蓄積部」（０３０１）は、複数の認証ウエブページURLをURL用IDと関連付けて蓄積する機能を有し、例えばＨＤＤ（ハードディスク・ドライブ）やフラッシュメモリなどの記憶装置によって実現することができる。

「認証ウエブページURL」とは、複数のサービス間で共通して認証に利用されるウエブページのURLをいい、前述の例ではブログサービスγにおけるログイン画面ページのURLなどが挙げられる。またこのURLは、URLにファイル名などを加えたURIであっても良い。また「URL用ID」とは、当該認証ウエブページURL以外でこのURLを識別する情報をいい、例えば前述の例ではブログサービスγにおけるユーザαのブログ公開URLやブログサービスγのドメイン名などが挙げられる。

図４は、ここで蓄積される認証ウエブページURLやURL用IDの一例を表す図である。この図にあるように、例えばURL用IDである「http://blog.com/user-a/」に対して、認証ウエブページURLである「http://blog.com/login/」が関連付けて蓄積されている。あるいはURIである「http://blog.com/login/login.php」が関連付けて蓄積されている、という具合である。

もちろん認証ウエブページURLやURL用IDは上記例には限定されず、認証ウエブページURLとして認証処理を行うアプリケーションのURLやURIと、URL用IDとして認証サービス自体のドメイン名（OpenID（登録商標）におけるOP Identifier）、あるいはその他のユニークな識別情報などの組み合わせが蓄積されていても良い。また、URL用IDは認証ウエブページURLと直接関連付けられている必要はなく、認証ウエブページURLを含む情報であるXRDS文書などと関連付けて蓄積管理されていると良い。

「URL用ID受信部」（０３０２）は、一方のサービス提供者サーバの求めに応じて他方のサービス提供者サーバを識別するURL用IDを直接又は間接に受信する機能を有し、例えばCPUや主メモリ、通信回路、URL用ID受信プログラムなどで実現することができる。

「一方のサービス提供者サーバ」とは、エンドユーザに対して所定のサービスを提供するサーバをいい、前述の通り例えば、動画や音楽などのコンテンツデータを閲覧、購入できるコンテンツ配信サーバやニュース記事を閲覧できる技術記事やニュースなどの配信サーバ、食品や書物などの各種商品を仮想店舗で購入できるネットショッピングサーバ、インターネットブラウザを利用したメールの送受信サーバ、ブログの投稿及び配信サーバ、納税の受付や各種行政書類の発行などの行政サーバなどが挙げられる。

また「他方のサービス提供者サーバ」とは、前記一方のサービス提供者サーバによるサービスを受けるためのユーザ認証を行うサーバをいい、例えばユーザ認証サービスのみを提供するサーバであっても良いし、例えば会員専用の所定のサービスであれば、登録会員であるかのユーザ認証に加えて、前述の各種サーバサービスを提供するサーバであっても良い。

つまり、一方のサービス提供者サーバと他方のサービス提供者サーバはそれぞれ専用のサーバとして構成されるのではなく、一のサーバがケースに応じて上記いずれかの役割を果たすように構成されていれば良い。具体的にはあるケースにおいては一方のサービス提供者サーバである例えば技術記事閲覧サーバβが、別のケースにおいては「他方のサービス提供者サーバ」となり、ブログサービスγなどの一方のサービス提供者サーバのサービスを利用するためのユーザ認証を行う、という具合である。

そして「一方のサービス提供者サーバの求め」とは、一方のサービス提供者サーバからのユーザ認証のためのリクエスト、例えば前述のXRDS文書（のアドレス）の取得要求やユーザ認証自体のリクエストなどが挙げられる。また、このURL用ID受信部はURL用IDを直接に受信しても良いし、間接に受信しても良い。なお「直接受信」とは、他方のサービス提供者サーバがURL用IDを送信しそれを受信することをいい、「間接受信」とは、前記URL用IDを一方のサービス提供者から受信することをいう。また間接受信の場合は、他方のサービス提供者サーバから送信されたURL用IDが一方のサービス提供サーバにていったん受信され、それが転送される形で受信する構成としても良い（中継受信手段）。

「認証ウエブページURL取得部」（０３０３）は、受信したURL用IDを用いてURL蓄積部から認証ウエブページURLを取得する機能を有し、例えばCPUや主メモリ、認証ウエブページURL取得プログラムなどで実現することができる。

具体的には、受信したURL用IDを検索キーとして、図４に示すようなテーブルデータなどを検索することで、そのURL用IDと関連付けられている該当する認証ウエブページURLを取得する、という具合である。

「認証ウエブページURL送信部」（０３０４）は、取得した認証ウエブページURLを、前記一方のサービス提供者のために送信する機能を有し、例えばCPUや主メモリ、通信回路、認証ウエブページURL送信プログラムなどで実現することができる。

図５は、ここで送信される認証ウエブページURLの一例を表す図であり、より具体的にはOpenID（登録商標）におけるXRDS文書の一例を表す図である。この図にあるように、XRDS文書中には、OpenID（登録商標）のバージョンナンバーやサービス要素などに加えて、認証ウエブページURL「http://blog.com/login/login.php」が記述されている。また認証ウエブページURLはXRDS文書中に複数含まれ、優先順位（priority）に応じて利用される認証ウエブページURLが順番に選択されるよう構成することもできる。

そして、上記のような認証ウエブページURL（やそれを含むXRDS文書など）を受信した一方のサービス提供者サーバでは、以下のような手順でユーザ認証を行い、エンドユーザにサービスを提供する。

図６は、このサービス提供者サーバにおける機能ブロックの一例を表す図である。この図にあるように、「サービス提供者サーバ」（０６１０）は、「認証ウエブページURL受信部」（０６１１）と、「認証結果取得部」（０６１２）と、「サービス提供処理部」（０６１３）と、を有する。

「認証ウエブページURL受信部」（０６１１）は、認証ウエブページURLを受信する機能を有し、例えばCPUや主メモリ、通信回路、認証ウエブページURL受信プログラムなどで実現することができる。もちろん、図５に示すようなXRDS文書として取得し、その文書内のタグ<URI>などを参照して、XRDS文書中に記述されている認証ウエブページURLを取得するよう構成しても良い。

「認証結果取得部」（０６１２）は、受信したURLで識別される認証ウエブページを利用した認証結果を取得する機能を有し、例えばCPUや主メモリ、通信回路、認証結果取得プログラムなどで実現することができる。

具体的には、例えば、サービス提供のためのユーザ認証を要求しているエンドユーザの端末のアクセスを、受信したURLで示される認証ウエブページにリダイレクトし、そのリダイレクト先で他のサービス提供者サーバによって実行された認証処理の結果を取得するという具合である。もちろんこの処理は一例であって、リダイレクトなどをせずにユーザ端末を受信したURLで示される認証ウエブページへ誘導し、そこでの認証結果を取得する構成などとしても良い。

「サービス提供処理部」（０６１３）は、取得した認証結果に基づいてサービスの提供処理を行う機能を有し、例えばCPUや主メモリ、通信回路、サービス提供処理プログラムなどで実現することができる。

具体的には、サービスを受ける権利がある真正のユーザであることがその認証結果によって示されれば、提供するサービス内容に応じた処理、例えば、動画や音楽などのコンテンツデータの配信処理やニュース記事の配信処理、食品や書物などの各種商品の購入決済処理、インターネットブラウザを利用したメールの送受信処理、ブログの投稿受付及び配信処理、納税の受付処理や各種行政書類の発行処理などを実行する。

以上のように、認証ウエブページURLを含む情報を、サービスを提供するサーバや認証を行うサーバとは別の認証ウエブページURLサービス装置にて管理し、その認証ウエブページURLサービス装置からこれらサーバに対して認証ウエブページURLを含む情報を提供することができる。

<ハードウェア構成>

図７は、上記機能的な各構成要件をハードウェアとして実現した際の、認証ウエブページURLサービス装置における構成の一例を表す概略図である。この図を利用して認証ウエブページURLの送信処理におけるそれぞれのハードウェア構成部の働きについて説明する。

この図にあるように、認証ウエブページURLサービス装置は、認証ウエブページURL取得部であり、またその他の各種演算処理を実行するための「ＣＰＵ」（０７０１）と、「主メモリ」（０７０２）と、を備えている。また認証ウエブページURL蓄積部である「ＨＤＤ」（０７０３）や、インターネットを介してサービス提供者サーバと通信を行う「通信回路」（０７０４）を備えている。そしてそれらが「システムバス」などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う。

また、「主メモリ」にはプログラムが読み出され、「ＣＰＵ」は読み出された当該プログラムを参照し、プログラムで示される手順に従い各種演算処理を実行する。また、この「主メモリ」や「ＨＤＤ」にはそれぞれ複数のアドレスが割り当てられており、「ＣＰＵ」の演算処理においては、そのアドレスを特定し格納されているデータにアクセスすることで、データを用いた演算処理を行うことが可能になっている。

ここで、まず、図示しないキーボードなどの入力デバイスを用いた情報入力やインターネットを介して接続された管理者端末から送信された情報を「通信回路」にて受信し、その受信した情報に応じて、複数の認証ウエブページURLをURL用IDと関連付けて「ＨＤＤ」に書き込む処理を実行する。それによって、「ＨＤＤ」には、例えば図４に示すようなテーブルデータが保持されることになる。

その後、インターネット上にある図示しない一方のサービス提供者サーバβにおいてエンドユーザの端末からアクセスがあり、他方のサービス提供者サーバγの認証処理を利用したサービス提供要求が受信される。すると、その一方のサービス提供者サーバβは、認証処理を行う他方のサービス提供者サーバγに対して認証ウエブページURLを含むXRDS文書の要求（XRDS文書の入手先となる本実施例の認証ウエブページURLサービス装置のアドレスの要求）を行う。すると、他方のサービス提供者サーバγはそのアドレスを示す情報を一方のサービス提供者サーバβに返信し、一方のサービス提供者サーバβは、その返信されたアドレスに基づいてこの認証ウエブページURLサービス装置に対してアクセスを行い、XRDS文書の送信要求を他方のサービス提供者サーバγのIDと関連付けて送信する。

そして認証ウエブページURLサービス装置は「通信回路」を介してその送信要求を受信すると、「ＣＰＵ」はURL用ID受信プログラムを解釈し、その解釈結果にしたがって受信した送信要求に関連付けられている他方のサービス提供者サーバγのIDを、URL用IDとして「主メモリ」のアドレス１に格納する。

つづいて「ＣＰＵ」は認証ウエブページURL取得プログラムを解釈し、その解釈結果にしたがって、前述のように「ＨＤＤ」に保持されている図４に示すようなテーブルデータを対象として、URL用IDを検索キーとする検索処理を実行する。そして、その結果取得した認証ウエブページURLを含む XRDS文書の識別情報を、「主メモリ」のアドレス２に格納する。

そして「ＣＰＵ」は、認証ウエブページURL送信プログラムを解釈し、その解釈結果に従って、取得した識別情報で識別されるXRDS文書を「ＨＤＤ」から読み出し、「通信回路」を介して一方のサービス提供者サーバβに送信する、という具合である。

そして一方のサービス提供者サーバβでは、その受信したXRDS文書に記述されている認証ウエブページURLを取得し、そのURLで示される認証ウエブページにエンドユーザの端末のアクセスをリダイレクトする。すると、そのリダイレクト先で他のサービス提供者サーバγによって認証処理が実行され、その認証結果を一方のサービス提供者サーバβが取得する。そしてその認証結果にて当該エンドユーザがサービスを受ける権利がある真正のユーザであることが示されれば、一方のサービス提供者サーバβはその要求されたサービスに係る処理を実行する。

<処理の流れ>
図８は、本実施例の認証ウエブページURLサービス装置における処理の流れの一例を表すフローチャートである。なお、以下に示すステップは、上記のような計算機の各ハードウェア構成によって実行されるステップであっても良いし、媒体に記録され計算機を制御するためのプログラムを構成する処理ステップであっても構わない。

この図にあるように、まず、複数の認証ウエブページURLをURL用IDと関連付けて認証ウエブページURL蓄積部に記録する（認証ウエブページURL記録ステップ：ステップＳ０８０１）。

その後、一方のサービス提供者サーバの求めに応じて他方のサービス提供者サーバから送信されるURL用IDを直接又は間接に受信する（URL用ID受信ステップ：ステップＳ０８０２）と、受信したURL用IDを用いてURL蓄積部から認証ウエブページURLを取得する（認証ウエブページURL取得ステップ：ステップＳ０８０３）。そして取得した認証ウエブページURLを、前記一方のサービス提供者のために送信する（認証ウエブページURL送信ステップ：ステップＳ０８０４）。

図９は、上記認証ウエブページURLサービス装置と、複数の（図では一方と他方の）サービス提供者サーバと、からなるウエブサービス提供システムにおける処理の流れの一例を表すシーケンス図である。

この図にあるように、エンドユーザの端末αから、（１）例えば会員専用の技術記事閲覧サービスを提供する一方のサービス提供者サーバβに対してサービスの利用要求が送信される。そして、その際のユーザ認証として、ユーザαが利用するブログサービスγのユーザα専用ブログ公開ページのURLなどが送信される。

すると（２）一方のサービス提供者サーバβは、受信したURLに基づいてブログサービスを提供する他方のサービス提供者サーバγに対してXRDS文書を管理している認証ウエブページURLサービス装置のアドレスの送信を要求する。そして（３）他方のサービス提供者サーバγはその要求に応じて認証ウエブページURLサービス装置のアドレスを返信する。

すると（４）一方のサービス提供者サーバβは、受信したアドレスに基づいて認証ウエブページURLサービス装置にアクセスし、先に取得していたブログサービスのα専用ブログ公開ページのURLをURL用IDとして送信する。

（５）認証ウエブページURLサービス装置では、受信した要求に含まれるURL用IDを検索キーとして、予め蓄積されている例えば図４に示すようなテーブルデータを参照し、当該URL用IDに関連付けられている認証ウエブページURL（他方のサービス提供者サーバγにおけるログインページのURLなど）を含むXRDS文書を取得する。そして、（６）その取得したXRDS文書を一方のサービス提供者サーバβに返信する。

そして（７）一方のサービス提供者サーバβでは、返信されたXRDS文書に記述されている認証ウエブページURLにユーザ端末αのアクセスをリダイレクトする。すると、ユーザ端末αは他方のサービス提供者サーバγのログインページにアクセスするので、（８）そこでユーザ名やパスワードなどを入力し認証処理が実行される。そして（９）その認証結果が一方のサービス提供者サーバβに送信される。

そして（１０）一方のサービス提供者サーバβでは、その認証結果によって当該エンドユーザがサービスを受ける権利がある真正のユーザであることが示されれば、要求されたサービスに係る処理を実行する。

<効果の簡単な説明>

以上のように、本実施例の認証ウエブページURLサービス装置、そしてウエブサービス提供システムによって、XRDS文書のような認証ウエブページURLを含む情報を、サービスを提供するサーバや認証を行うサーバとは別の認証ウエブページURLサービス装置にて管理し、その認証ウエブページURLサービス装置からこれらサーバに対して認証ウエブページURLを含む情報を提供することができる。

したがって、サービスを提供するサーバや認証を行うサーバの信頼性を個別に担保しなくとも、この認証ウエブページURLサービス装置の信頼性を担保することで容易に認証ウエブページURLを含む情報の信頼性を担保することができる。

０３００ 認証ウエブページURLサービス装置
０３０１ 認証ウエブページURL蓄積部
０３０２ URL用ID受信部
０３０３ 認証ウエブページURL取得部
０３０４ 認証ウエブページURL送信部

Claims (6)

1. 複数の認証ウエブページURLをURL用IDと関連付けて蓄積した認証ウエブページURL蓄積部と、
   一方のサービス提供者サーバの求めに応じて他方のサービス提供者サーバを識別するURL用IDを直接又は間接に受信するURL用ID受信部と、
   受信したURL用IDを用いてURL蓄積部から認証ウエブページURLを取得する認証ウエブページURL取得部と、
   取得した認証ウエブページURLを、前記一方のサービス提供者のために送信する認証ウエブページURL送信部と、
   を有する認証ウエブページURLサービス装置。
2. 前記URL用ID受信部は、前記URL用IDを一方のサービス提供者から受信する中継受信手段を有する請求項１に記載の認証ウエブページURLサービス装置。
3. 複数のサービス提供者サーバと、請求項１または２に記載の認証ウエブページURLサービス装置と、からなるウエブサービス提供システムであって、
   前記一方のサービス提供者サーバは、
   認証ウエブページURLを受信する認証ウエブページURL受信部と、
   受信したURLで識別される認証ウエブページを利用した認証結果を取得する認証結果取得部と、
   取得した認証結果に基づいてサービスの提供処理を行うサービス提供処理部と、
   を有するウエブサービス提供システム。
4. 複数の認証ウエブページURLをURL用IDと関連付けて蓄積した認証ウエブページURL蓄積部を備える認証ウエブページURLサービス装置の動作方法であって、
   一方のサービス提供者サーバの求めに応じて他方のサービス提供者サーバを識別するURL用IDを直接又は間接に受信するURL用ID受信ステップと、
   受信したURL用IDを用いてURL蓄積部から認証ウエブページURLを取得する認証ウエブページURL取得ステップと、
   取得した認証ウエブページURLを、前記一方のサービス提供者のために送信する認証ウエブページURL送信ステップと、
   を実行する認証ウエブページURLサービス装置の動作方法。
5. 前記URL用ID受信ステップは、前記URL用IDを一方のサービス提供者から受信する中継受信ステップである請求項４に記載の認証ウエブページURLサービス装置の動作方法。
6. 複数のサービス提供者サーバと、請求項１または２に記載の認証ウエブページURLサービス装置と、からなるウエブサービス提供システムの動作方法であって、
   前記一方のサービス提供者サーバにて、
   認証ウエブページURLを受信する認証ウエブページURL受信ステップと、
   受信したURLで識別される認証ウエブページを利用した認証結果を取得する認証結果取得ステップと、
   取得した認証結果に基づいてサービスの提供処理を行うサービス提供処理ステップと、
   を実行するウエブサービス提供システムの動作方法。

Images