図面 (/)

技術 情報提供システム、情報提供プログラム、及び情報提供方法

出願人 富士通株式会社
発明者 小倉孝夫森川郁也高木淳二
出願日 2015年11月10日 (5年1ヶ月経過) 出願番号 2015-220446
公開日 2017年5月25日 (3年7ヶ月経過) 公開番号 2017-091207
状態 特許登録済
技術分野 オンライン・システムの機密保護 記憶装置の機密保護
主要キーワード OEIC IDパラメータ 連携管理 状態チェック 連携元 アルバイト アクセストークン データ応答
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年5月25日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

同意に伴うユーザの負担を軽減すること。

解決手段

第1の情報処理装置31が、ユーザの属性情報38を取得することについての承認を第2の情報処理装置32に依頼し、第2の情報処理装置32が、属性情報38を第1の情報処理装置31に提供することについての同意をユーザに要求し、ユーザの同意74が得られたとき、第2の情報処理装置32が、同意34が得られたことを示す同意識別子を第1の情報処理装置31に通知し、第1の情報処理装置31が、属性情報38を保有する第3の情報処理装置33に同意識別子を通知し、第3の情報処理装置33が、第2の情報処理装置32に対し、通知された同意識別子の正当性の確認を依頼し、正当性が確認されたときに第3の情報処理装置33が第1の情報処理装置31に属性情報38を通知する情報提供方法による。

概要

背景

近年、複数のwebサービス連携させて新たなサービスを提供するサービス連携が普及しつつある。そのようなサービス連携としては、例えばTwitter(登録商標)でつぶやいたデータをFacebook(登録商標)へ反映させるサービスがある。このサービスではTwitterからFacebookにデータを渡してもよいとの同意をユーザから取得する必要があり、これを実現するために例えばOAuthプロトコルが使用される。

この他に、あるwebサービスのユーザ認証を別のサービスが代理で行う認証連携と呼ばれるサービス形態もある。代理でユーザ認証を行うサービス事業者は、IdP(Identity Provider)と呼ばれ、認証が成功した場合には依頼元住所や氏名等のユーザの属性情報を提供する。

一方、IdPに認証を依頼するサービス事業者は、RP(Relying Party)と呼ばれ、認証が成功した際にIdPから提供されるユーザの属性情報を利用して当該ユーザにサービスを提供する。

この認証連携においては、IdPからRPにユーザの属性情報を渡してもよいとの同意をユーザから取得する必要があり、これを実現するためのプロトコルとしてOpenID ConnectやSAML(Security Assertion Markup Language)がある。

概要

同意に伴うユーザの負担を軽減すること。第1の情報処理装置31が、ユーザの属性情報38を取得することについての承認を第2の情報処理装置32に依頼し、第2の情報処理装置32が、属性情報38を第1の情報処理装置31に提供することについての同意をユーザに要求し、ユーザの同意74が得られたとき、第2の情報処理装置32が、同意34が得られたことを示す同意識別子を第1の情報処理装置31に通知し、第1の情報処理装置31が、属性情報38を保有する第3の情報処理装置33に同意識別子を通知し、第3の情報処理装置33が、第2の情報処理装置32に対し、通知された同意識別子の正当性の確認を依頼し、正当性が確認されたときに第3の情報処理装置33が第1の情報処理装置31に属性情報38を通知する情報提供方法による。

目的

近年、複数のwebサービスを連携させて新たなサービスを提供する

効果

実績

技術文献被引用数
0件
牽制数
1件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

第1の情報処理装置、第2の情報処理装置、及び第3の情報処理装置を備えた情報提供システムであって、前記第1の情報処理装置は、前記第3の情報処理装置が保有するユーザの属性情報を取得することについての承認を求める承認依頼を前記第2の情報処理装置に通知し、前記属性情報の取得について前記ユーザの同意が得られたことを示す同意識別子が前記第2の情報処理装置から通知されたときに、前記同意識別子を前記第3の情報処理装置に通知する第1の通知部、を有し、前記第2の情報処理装置は、前記第3の情報処理装置からの依頼を受けて、前記第3の情報処理装置から通知された前記同意識別子の正当性を確認する確認部と、前記承認依頼を受けたときに前記属性情報を前記第1の情報処理装置に提供することについての前記同意を前記ユーザに要求し、前記同意が得られたときに前記同意識別子を前記第1の情報処理装置に通知する第2の通知部と、を有し、前記第3の情報処理装置は、前記属性情報を記憶した記憶部と、通知された前記同意識別子の前記正当性についての確認を前記第2の情報処理装置に依頼する依頼部と、前記確認部によって前記正当性が確認されたときに前記第1の情報処理装置に前記属性情報を通知し、前記正当性が確認されないときには前記第1の情報処理装置に前記属性情報を通知しない第3の通知部、を有する、ことを特徴とする情報提供システム。

請求項2

前記第1の通知部は、前記第2の情報処理装置から前記同意識別子が通知された場合に、前記属性情報の提供についての許可を求める要求を前記第3の情報処理装置に通知し、前記第2の通知部は、前記確認部により前記正当性が確認されたときに、前記属性情報の提供についてユーザが同意した旨の情報を前記第3の情報処理装置に通知し、前記第3の情報処理装置は、前記第2の通知部から通知された前記情報における前記属性情報と、前記第1の通知部から要求された前記属性情報とが一致しているかを判断する判断部を有し、前記第3の通知部は、前記判断部によって前記属性情報が一致していないと判断されたときには、前記第1の情報処理装置に前記属性情報を通知しないことを特徴とする請求項1に記載の情報提供システム。

請求項3

前記ユーザが操作する端末を更に有し、前記確認部は、前記端末と前記第2の情報処理装置との間で確立されたユーザセッションと、前記同意をした前記ユーザのユーザセッションとの同一性を確認し、前記第2の通知部は、前記ユーザセッションの前記同一性がないときには、前記ユーザが提供に同意した前記属性情報を前記第3の情報処理装置に通知しないことを特徴とする請求項1又は請求項2に記載の情報提供システム。

請求項4

前記第1の通知部は前記承認依頼に記号列を付加し、前記第2の通知部は、前記記号列の一部を前記同意識別子として前記第1の情報処理装置に通知することを特徴とする請求項1乃至請求項3のいずれか1項に記載の情報提供システム。

請求項5

第1の情報処理装置が、ユーザの属性情報を取得することについての承認を第2の情報処理装置に依頼し、前記依頼を受けた前記第2の情報処理装置が、前記属性情報を前記第1の情報処理装置に提供することについての同意を前記ユーザに要求し、前記ユーザの同意が得られたとき、前記第2の情報処理装置が、前記同意が得られたことを示す同意識別子を前記第1の情報処理装置に通知し、前記同意識別子の通知を受けた前記第1の情報処理装置が、前記属性情報を保有する第3の情報処理装置に前記同意識別子を通知し、前記同意識別子の通知を受けた前記第3の情報処理装置が、前記第2の情報処理装置に対し、通知された前記同意識別子の正当性の確認を依頼し、前記正当性が確認されたときに前記第3の情報処理装置が前記第1の情報処理装置に前記属性情報を通知し、前記正当性が確認されないときには前記第3の情報処理装置が前記第1の情報処理装置に前記属性情報を通知しないことを特徴とする情報提供方法

請求項6

第1の情報処理装置が、ユーザの属性情報を取得することについての承認を第2の情報処理装置に依頼する処理と、前記依頼を受けた前記第2の情報処理装置が、前記属性情報を前記第1の情報処理装置に提供することについての同意を前記ユーザに要求する処理と、前記ユーザの同意が得られたとき、前記第2の情報処理装置が、前記同意が得られたことを示す同意識別子を前記第1の情報処理装置に通知する処理と、前記同意識別子の通知を受けた前記第1の情報処理装置が、前記属性情報を保有する第3の情報処理装置に前記同意識別子を通知する処理と、前記同意識別子の通知を受けた前記第3の情報処理装置が、前記第2の情報処理装置に対し、通知された前記同意識別子の正当性の確認を依頼する処理と、前記正当性が確認されたときに前記第3の情報処理装置が前記第1の情報処理装置に前記属性情報を通知し、前記正当性が確認されないときには前記第3の情報処理装置が前記第1の情報処理装置に前記属性情報を通知しない処理と、をコンピュータに実行させる情報提供プログラム

技術分野

0001

本発明は、情報提供システム情報提供プログラム、及び情報提供方法に関する。

背景技術

0002

近年、複数のwebサービス連携させて新たなサービスを提供するサービス連携が普及しつつある。そのようなサービス連携としては、例えばTwitter(登録商標)でつぶやいたデータをFacebook(登録商標)へ反映させるサービスがある。このサービスではTwitterからFacebookにデータを渡してもよいとの同意をユーザから取得する必要があり、これを実現するために例えばOAuthプロトコルが使用される。

0003

この他に、あるwebサービスのユーザ認証を別のサービスが代理で行う認証連携と呼ばれるサービス形態もある。代理でユーザ認証を行うサービス事業者は、IdP(Identity Provider)と呼ばれ、認証が成功した場合には依頼元住所や氏名等のユーザの属性情報を提供する。

0004

一方、IdPに認証を依頼するサービス事業者は、RP(Relying Party)と呼ばれ、認証が成功した際にIdPから提供されるユーザの属性情報を利用して当該ユーザにサービスを提供する。

0005

この認証連携においては、IdPからRPにユーザの属性情報を渡してもよいとの同意をユーザから取得する必要があり、これを実現するためのプロトコルとしてOpenID ConnectやSAML(Security Assertion Markup Language)がある。

先行技術

0006

特開2013−88901号公報

発明が解決しようとする課題

0007

ところで、前述のサービス連携や認証連携が混在する場合には、サービス間でユーザの複数の属性情報が受け渡される場面が想定される。

0008

しかしながら、その場合には属性情報の受け渡しをするたびにユーザに同意を求める必要があるため、ユーザが複数の同意をしなければならず、同意に伴うユーザの負担が増す。

0009

一つの側面では、本発明は、同意に伴うユーザの負担を軽減することを目的とする。

課題を解決するための手段

0010

一つの側面では、本発明は、第1の情報処理装置、第2の情報処理装置、及び第3の情報処理装置を備えた情報提供システムであって、前記第1の情報処理装置は、前記第3の情報処理装置が保有するユーザの属性情報を取得することについての承認を求める承認依頼を前記第2の情報処理装置に通知し、前記属性情報の取得について前記ユーザの同意が得られたことを示す同意識別子が前記第2の情報処理装置から通知されたときに、前記同意識別子を前記第3の情報処理装置に通知する第1の通知部を有し、前記第2の情報処理装置は、前記第3の情報処理装置からの依頼を受けて、前記第3の情報処理装置から通知された前記同意識別子の正当性を確認する確認部と、前記承認依頼を受けたときに前記属性情報を前記第1の情報処理装置に提供することについての前記同意を前記ユーザに要求し、前記同意が得られたときに前記同意識別子を前記第1の情報処理装置に通知する第2の通知部とを有し、前記第3の情報処理装置は、前記属性情報を記憶した記憶部と、通知された前記同意識別子の前記正当性についての確認を前記第2の情報処理装置に依頼する依頼部と、前記確認部によって前記正当性が確認されたときに前記第1の情報処理装置に前記属性情報を通知し、前記正当性が確認されないときには前記第1の情報処理装置に前記属性情報を通知しない第3の通知部を有する情報提供システムが提供される。

発明の効果

0011

同意に伴うユーザの負担を軽減することができる。

図面の簡単な説明

0012

図1は、サービス連携と認証連携とが混在したシステムについて模式的に示す図である。
図2は、サービス連携と認証連携とが混在したシステムにおける処理の流れについて説明するためのシーケンス図(その1)である。
図3は、サービス連携と認証連携とが混在したシステムにおける処理の流れについて説明するためのシーケンス図(その2)である。
図4は、サービス連携と認証連携とが混在したシステムにおいて、同意要求をまとめた場合の処理の流れについて説明するためのシーケンス図(その1)である。
図5は、サービス連携と認証連携とが混在したシステムにおいて、同意要求をまとめた場合の処理の流れについて説明するためのシーケンス図(その2)である。
図6は、第1実施形態に係る情報提供システムの全体構成例を示す図である。
図7は、第1実施形態における第1〜第3の情報処理装置と端末の各々の機能構成例を示す図である。
図8は、第1実施形態における同意テーブルの一例を示す図である。
図9は、第1実施形態に係る情報提供システムの動作の一例を示すシーケンス図(その1)である。
図10は、第1実施形態に係る情報提供システムの動作の一例を示すシーケンス図(その2)である。
図11は、第1実施形態における許可応答の一例を示す図である。
図12は、第1実施形態における第2の情報処理装置の処理内容について示すフローチャート(その1)である。
図13は、第1実施形態における第2の情報処理装置の処理内容について示すフローチャート(その2)である。
図14は、第1実施形態における第2の情報処理装置の処理内容について示すフローチャート(その3)である。
図15は、第1実施形態における第2の情報処理装置の処理内容について示すフローチャート(その4)である。
図16は、第2実施形態に係る情報提供システムの動作の一例を示すシーケンス図(その1)である。
図17は、第2実施形態に係る情報提供システムの動作の一例を示すシーケンス図(その2)である。
図18は、第2実施形態に係る同意テーブルの一例を示す図である。
図19は、CSRF攻撃について説明するためのシーケンス図
図20は、第1及び第2実施形態に係る情報提供プログラムを実行するコンピュータハードウェア構成図である。

発明を実施するための最良の形態

0013

本実施形態の説明に先立ち、サービス連携と認証連携とが混在したシステムについて説明する。

0014

図1は、サービス連携と認証連携とが混在したシステムについて模式的に示す図である。

0015

このシステム10は、第1〜第3の情報処理装置1〜3と、ユーザが操作する端末4とを有しており、第1〜第3の情報処理装置1〜3が連携して新たなサービスをユーザに提供する。

0016

以下では、RP(Relying Party)が第1の情報処理装置1を用いてクラウドソーシング等のサービスを提供し、IdP(Identity Provider)が第2の情報処理装置2を用いて認証サービスを行う場合を想定する。

0017

このうち、第2の情報処理装置2は、ユーザの属性情報7が記憶された記憶部2aを有しており、認証が成功した場合には第1の情報処理装置1にユーザの属性情報7を提供する。

0018

そして、第3の情報処理装置3は、ユーザの過去の履歴を第1の情報処理装置1に提供する履歴サービスに使用され、ユーザの属性情報8として履歴が記憶された記憶部3aを有する。このように履歴サービスを行うサービス事業者はAP(Attribute Provider)と呼ばれる。

0019

各属性情報7、8は特に限定されない。以下では、ユーザに関連する任意の情報を属性情報7、8と呼ぶ。

0020

例えば、属性情報7には、ユーザの氏名、住所、生年月日、及びメールアドレスが含まれるものとする。また、属性情報8には、ユーザが過去に取得したTOEIC(Test of English for International Communication:登録商標)等の語学スコア記録証や看護師免許等の資格情報が含まれるものとする。

0021

また、第1の情報処理装置1と第2の情報処理装置2との間や、第2の情報処理装置2と第3の情報処理装置3との間の通信プロトコルはOpenID connectであり、第1の情報処理装置1と第3の情報処理装置3との間の通信プロトコルはOAuth 2.0であるとする。

0022

次に、第1〜第3の情報処理装置1〜3が連携して提供するサービスの一例について説明する。

0023

この例では、第1の情報処理装置1が翻訳アルバイト募集をしており、ユーザがそのアルバイトに応募することを考える。

0024

アルバイトに応募するため、ユーザは、端末4を操作することにより第1の情報処理装置1にサービス要求9を通知する。

0025

サービス要求9を受けた第1の情報処理装置1は、ユーザと連絡を取るために、第2の情報処理装置2が保有する属性情報7としてメールアドレスを要求する。このとき、第2の情報処理装置2は、メールアドレスを第1の情報処理装置1に提供してよいとの同意をユーザから得るために、端末4に対して同意要求11を通知する。

0026

また、第3の情報処理装置3は、属性情報8として語学スコア記録証を保有しているものとする。そして、その記録証がユーザのものであるかどうかを確認するために、第3の情報処理装置3は第2の情報処理装置2に対して属性情報7のうち氏名と住所とを要求する。

0027

このとき、第2の情報処理装置2は、氏名と住所とを第3の情報処理装置3に提供してよいとの同意をユーザから得るために、端末4に対して同意要求12を通知する。

0028

更に、第3の情報処理装置3は、第1の情報処理装置1に対して属性情報8として語学スコア記録証を提供する。このとき、第3の情報処理装置3は、語学スコア記録証を第1の情報処理装置1に提供してよいとの同意をユーザから得るために、端末4に対して同意要求13を通知する。

0029

このように、この例では同意要求11〜13の三つの全てにユーザが同意しなければならず、ユーザの負担が大きい。

0030

同意に伴うユーザの負担を減らすには、これらの同意要求11〜13を単純に一つにまとめればよいと考えられる。これが可能かどうかを検討するため、次に同意要求11〜13がOpenID ConnectとOAuth 2.0のそれぞれのプロトコルにおいてどのように通知されるのかについて説明する。

0031

図2及び図3は、システム10における処理の流れについて説明するためのシーケンス図である。

0032

なお、図2及び図3において、実線で示す処理はOpenID Connectに即した処理を示し、一点鎖線で示す処理はOAuth 2.0に即した処理を示す。また、点線で示す処理は、これらのプロトコルで規定されていない処理を示す。

0033

また、図2及び図3において、図1で説明したのと同じ要素には図1におけるのと同じ符号を付し、以下ではその説明を省略する。

0034

以下、図2及び図3に示す処理をステップ番号に沿って説明する。

0035

(S1)まず、第1の情報処理装置1が募集している翻訳アルバイトに応募するために、ユーザが端末4を操作することにより、第1の情報処理装置1にサービス要求9を通知する。

0036

(S2)そのサービス要求9を受けて、第1の情報処理装置1が第2の情報処理装置2に対して許可要求を通知する。

0037

この許可要求は、HTTP(Hypertext Transfer Protocol)リクエストであって、端末4により第2の情報処理装置2にリダイレクトされる。

0038

また、そのHTTPヘッダにはscopeパラメータが設定される。scopeパラメータは、第2の情報処理装置2が保有している複数の属性情報7のうち、第1の情報処理装置1が要求するものを特定するパラメータである。本ステップでは、そのscopeパラメータに、複数の属性情報7のうち当該ユーザのメールアドレスを指定する。

0039

(S3)第2の情報処理装置2は、ユーザが第2の情報処理装置2を利用する権限があるかを確認するための認証を行う。

0040

この認証は、例えばパスワード認証で行われ、ユーザが端末3を介して自分の認証IDであるA_IDとパスワードPWとを第2の情報処理装置2に送信することで行われる。

0041

(S4)ステップS3の認証が成功した場合、属性情報7(メールアドレス)を第1の情報処理装置1に提供してよいとの同意をユーザから得るために、第2の情報処理装置2が端末4に同意要求11を通知する。

0042

(S5)ユーザは、属性情報7(メールアドレス)の提供に同意するときは、端末4を操作して第2の情報処理装置2に同意を通知する。

0043

(S6)ステップS5で同意を受けたとき、第2の情報処理装置2は、ステップS2の許可要求に対する応答として、第1の情報処理装置1に許可応答を返す。その許可応答は、HTTPレスポンスであって、端末4によりリダイレクトされて第1の情報処理装置1に通知される。

0044

また、この許可応答には許可コード(Authorization Code)が付加される。許可コードは、第2の情報処理装置2が生成した記号列であって、HTTPレスポンスのLocationヘッダに指定される。また、許可コードは、属性情報7(メールアドレス)の提供を受けるためのアクセストークンと後で交換される。

0045

(S7)第1の情報処理装置1は、第2の情報処理装置2に対してアクセストークン要求を通知する。アクセストークン要求は、第2の情報処理装置2から属性情報7(メールアドレス)を得る際に必要となるアクセストークンを要求するHTTPリクエストである。

0046

また、そのHTTPヘッダのgrant_typeパラメータには、前述の許可コードが格納される。

0047

(S8)第2の情報処理装置2は、そのアクセストークン要求に含まれている許可コードを検証する。

0048

そして、検証に成功した場合には、第2の情報処理装置2が第1の情報処理装置1にアクセストークン応答を返す。

0049

アクセストークン応答は、許可コードと引き換えにアクセストークンを第1の情報処理装置1に渡すためのHTTPレスポンスである。アクセストークンは、第2の情報処理装置2が生成した記号列であって、HTTPヘッダのaccess_tokenパラメータに指定される。

0050

また、アクセストークンは、第2の情報処理装置2が所有する複数の属性情報7のうちの一つを特定するためのIDとしての機能も兼ねる。

0051

なお、有効期限切れたアクセストークンの代替となるリフレッシュトークンもアクセストークン応答に含めてもよい。これについては、後述の各アクセストークン応答でも同様である。

0052

(S9)第1の情報処理装置1は、第2の情報処理装置2にアクセストークンを渡すことにより、第2の情報処理装置2にデータ要求を通知する。この場合に要求するデータは、前述のようにユーザの属性情報7(メールアドレス)である。

0053

また、このデータ要求はHTTPリクエストであって、そのHTTPヘッダのaccess_tokenパラメータに上記のアクセストークンが指定される。

0054

(S10)第2の情報処理装置2は、第1の情報処理装置1から渡されたアクセストークンと、自身がステップS8で発行したアクセストークンとの同一性を確認する。

0055

そして、両者の同一性が確認できた場合には、第2の情報処理装置2は、そのアクセストークンが示すIDに対応する属性情報7(メールアドレス)を特定する。その後、その属性情報7(メールアドレス)をデータ応答に乗せて第2の情報処理装置2に通知する。

0056

ここまでのステップにより、第1の情報処理装置1が属性情報7(メールアドレス)を取得できたことになる。

0057

次に、第1の情報処理装置1は、以下のようにして第3の情報処理装置3が保有する属性情報8(語学スコア記録証)の取得を試みる

0058

(S11)まず、第1の情報処理装置1が第3の情報処理装置3に対して許可要求を通知する。

0059

この許可要求は、第3の情報処理装置3が保有している属性情報8(語学スコア記録証)の提供を要求するHTTPリクエストであり、端末4から第3の情報処理装置3にリダイレクトされる。

0060

また、第3の情報処理装置3が保有している複数の属性情報8のうち、第1の情報処理装置1が要求する情報が当該ユーザの語学スコア記録証であることを特定するために、HTTPヘッダのscopeパラメータにはその語学スコア記録証が指定される。

0061

(S12)第3の情報処理装置3は、語学スコア記録証がユーザ本人のものであることを確認するための属性情報7(氏名、住所)を第2の情報処理装置2から取得すべく、その属性情報7(氏名、住所)の提供を要求する許可要求を第2の情報処理装置2に通知する。

0062

この許可要求もHTTPリクエストであり、端末4から第2の情報処理装置2にリダイレクトされる。

0063

更に、第2の情報処理装置2が保有している複数の属性情報7のうち、第3の情報処理装置3が要求する情報が当該ユーザの氏名と住所であることを特定するために、HTTPヘッダのscopeパラメータにはその氏名と住所が指定される。

0064

(S13)第2の情報処理装置2は、属性情報7(氏名、住所)を第3の情報処理装置3に提供してよいとの同意をユーザから得るために、端末4に同意要求12を通知する。

0065

(S14)ユーザは、属性情報7(氏名、住所)の提供に同意するときは、端末4を操作して第2の情報処理装置2に同意を通知する。

0066

(S15)ステップS14でユーザの同意が得られた場合には、第2の情報処理装置2は、ステップS12の許可要求に対する応答として第3の情報処理装置3に許可応答を返す。この許可応答もHTTPレスポンスであり、端末4により第3の情報処理装置3にリダイレクトされる。

0067

また、その許可応答のLocationヘッダには、第2の情報処理装置2が生成した記号列が許可コードとして指定される。その許可コードは、属性情報7(氏名、住所)の提供を受けるためのアクセストークンと後で交換される。

0068

(S16)第3の情報処理装置3は、第2の情報処理装置2に対してアクセストークン要求を通知する。このアクセストークン要求は、第2の情報処理装置2から属性情報7(氏名、住所)を得る際に必要となるアクセストークンを要求するHTTPリクエストである。

0069

また、そのアクセストークンのHTTPヘッダのgrant_typeフィールドには、ステップS15で第2の情報処理装置2が発行した許可コードが格納される。

0070

(S17)第2の情報処理装置2は、そのアクセストークンに含まれている許可コードを検証し、検証に成功した場合には第3の情報処理装置3にアクセストークン応答を返す。

0071

アクセストークン応答は、許可コードと引き換えにアクセストークンを第3の情報処理装置3に渡すためのHTTPレスポンスである。そして、第2の情報処理装置2が生成した記号列で表されるアクセストークンが、HTTPヘッダのaccess_tokenパラメータに指定される。

0072

このアクセストークンは、第2の情報処理装置2が所有する複数の属性情報7のうちの一つを特定するためのIDとしての機能も兼ねる。

0073

(S18)第3の情報処理装置3は、アクセストークンを第2の情報処理装置2に渡すことにより、第2の情報処理装置2にデータ要求を通知する。この場合に要求するデータは、前述のようにユーザの属性情報7(氏名、住所)である。

0074

(S19)第2の情報処理装置2は、第3の情報処理装置3から渡されたアクセストークンと、自身がステップS17で発行したアクセストークンとの同一性を確認する。

0075

そして、その同一性が確認できた場合には、第2の情報処理装置2は、アクセストークンが示すIDに対応した属性情報7(氏名、住所)を特定する。その後、その属性情報7(氏名、住所)をデータ応答に乗せて第3の情報処理装置3に通知する。

0076

ここまでのステップにより、第3の情報処理装置3が属性情報7(氏名、住所)を取得できたことになる。

0077

(S20)第3の情報処理装置3は、属性情報8(語学スコア記録証)を第3の情報処理装置3に提供してよいとの同意をユーザから得るために、端末4に同意要求13を通知する。

0078

(S21)ユーザは、属性情報8(語学スコア記録証)の提供に同意するときは、端末4を操作して第3の情報処理装置3に同意を通知する。

0079

(S22)ステップS21で同意が得られたときは、第1の情報処理装置1は、ステップS11の許可要求に対する応答として第1の情報処理装置1に許可応答を返す。この許可応答もHTTPレスポンスであり、端末4により第1の情報処理装置1にリダイレクトされる。

0080

また、このHTTPレスポンスのLocationヘッダには、第3の情報処理装置3が生成した記号列が許可コードとして格納される。この許可コードは、属性情報8(語学スコア記録証)の提供を受けるためのアクセストークンと後で交換される。

0081

(S23)第1の情報処理装置1は、第3の情報処理装置3に対してアクセストークン要求を通知する。このアクセストークン要求は、第3の情報処理装置3から属性情報8(語学スコア記録証)を得る際に必要となるアクセストークンを要求するHTTPリクエストである。

0082

また、そのアクセストークンのHTTPヘッダのgrant_typeフィールドには、ステップS22で第3の情報処理装置3が発行した許可コードが格納される。

0083

(S24)第3の情報処理装置3は、そのアクセストークンに含まれている許可コードを検証し、検証に成功した場合には第1の情報処理装置1にアクセストークン応答を返す。

0084

アクセストークン応答は、許可コードと引き換えにアクセストークンを第1の情報処理装置1に渡すためのHTTPレスポンスである。そして、第3の情報処理装置3が生成した記号列で表されるアクセストークンが、そのHTTPレスポンスのaccess_tokenパラメータに指定される。

0085

そのアクセストークンは、第3の情報処理装置3が所有する複数の属性情報8(語学スコア記録証)のうちの一つを特定するためのIDとしての機能も兼ねる。

0086

(S25)第1の情報処理装置1は、アクセストークンを第3の情報処理装置3に渡すことにより、第3の情報処理装置3にデータ要求を通知する。この場合に要求するデータはユーザの属性情報8(語学スコア記録証)である。

0087

(S26)第3の情報処理装置3は、第1の情報処理装置1が提示したアクセストークンと、自身がステップS24で発行したアクセストークンとの同一性を確認する。

0088

そして、両者の同一性が確認できた場合には、第3の情報処理装置3は、アクセストークンが示すIDに対応した属性情報8(語学スコア記録証)を特定する。その後、その属性情報8(語学スコア記録証)をデータ応答に乗せて第1の情報処理装置1に通知する。

0089

ここまでのステップにより、第1の情報処理装置1が属性情報8(語学スコア記録証)を取得できたことになる。

0090

(S27)第1の情報処理装置1は、ユーザの属性情報8(語学スコア記録証)に基づいて、翻訳アルバイトの採用の可否を決定し、その結果をサービス応答として端末4に通知する。

0091

以上により、このシステム10における基本処理を終了する。

0092

上記したように、ユーザが同意すべき同意要求11〜13は、ステップS4、S13、S20においてユーザに通知される。これらの複数の同意要求11〜13にいちいち同意するのはユーザにとって煩わしい。

0093

そこで、これらの同意要求11〜14をステップS4にまとめることで、ユーザの負担を減らすことを考える。

0094

図4及び図5は、このように同意要求をまとめた場合の処理の流れについて説明するためのシーケンス図である。なお、図4及び図5において、図2及び図3で説明したのと同じ要素とステップには同じ符号を付し、以下ではその説明を省略する。

0095

以下では、第1〜第3の情報処理装置1〜3の各々を使用するサービス事業者間で予め契約等の取り決めをしておくことで、どの情報処理装置にどの属性情報を提供するのかが事前に決められているものとする。

0096

例えば、属性情報7のメールアドレスを第1の情報処理装置1に提供することと、属性情報7の氏名と住所とを第3の情報処理装置3に提供することが事前に決められているものとする。また、属性情報8の語学スコア記録証を第1の情報処理装置1に提供することも事前に決められているものとする。

0097

このように事前に決めておくことで、第2の情報処理装置2は、ステップS2の許可要求を受けた時点で、後で同意要求11〜13を通知する必要があると判断できる。

0098

そこで、第2の情報処理装置2は、ステップS4においてユーザに同意要求11を要求する際に、残りの同意要求12、13も合わせてユーザに要求し、ステップS13、S14、S20、S21はスキップする。

0099

また、ユーザは、これら三つの同意要求11〜13について同意するか否かをステップS5で一度に判断する。

0100

そして、三つの同意要求11〜13の全てに同意する場合のみ、ステップS5においてユーザが第2の情報処理装置2に同意を通知する。

0101

その同意を受けた第2の情報処理装置2は、ユーザが提供に同意した属性情報7、8を同意済み属性として記憶しておく。この例では、属性情報7(メールアドレス、氏名、住所)と属性情報8(語学スコア記録証)とが同意済み属性として記憶される。

0102

そして、ステップS6の許可応答において、第2の情報処理装置2が第1の情報処理装置1に対して同意済み属性(メールアドレス、氏名、住所、語学スコア記録証)を通知する。その通知を受けた第1の情報処理装置1は、当該通知に含まれる同意済み属性(メールアドレス、氏名、住所、語学スコア記録証)をステップS11の許可要求のscopeパラメータに指定することで、最終的にステップS26でその属性を第3の情報処理装置3から取得できる。

0103

以上説明したような処理によれば、ステップS4において三つの同意要求11〜13を一度にユーザに通知したことで、ステップS5においてユーザが一度に同意を通知でき、ユーザの負担軽減を図ることができる。

0104

しかし、この処理には次のようなセキュリティ上の問題がある。

0105

例えば、悪意のある第1の情報処理装置1が、ステップS11の許可要求のscopeパラメータに、同意済み属性(メールアドレス、氏名、住所、語学スコア記録証)には含まれないユーザが未同意の属性情報8(例えば看護師免許)を指定する可能性がある。この場合には、第3の情報処理装置3が保有する属性情報8のうち、ユーザが同意していない情報を第1の情報処理装置1が不正に取得することになる。

0106

以下に、このようなセキュリティ上の問題を解決しつつ、ユーザに複数の同意を要求することがない各実施形態について説明する。

0107

(第1実施形態)
図6は、第1実施形態に係る情報提供システムの全体構成例を示す図である。

0108

図6に示すように、この情報提供システムは、第1〜第3の情報処理装置31〜33と端末34とを有しており、これらがネットワーク36を介して相互に接続される。

0109

このうち、第1の情報処理装置31は例えばユーザにサービスを提供するRPが使用し、第2の情報処理装置32は例えば代理でユーザ認証を行うIdPが使用する。そして、第3の情報処理装置33は、ユーザの属性を提供するAPが使用する。

0110

各情報処理装置の数は特に限定されず、第1の情報処理装置31と第3の情報処理装置33の数はそれぞれ複数であってもよい。

0111

また、端末34は、ユーザが操作することにより第1の情報処理装置31からサービスを受けるものであって、例えばPC(Personal Computer)、タブレット端末、及びスマートフォン等である。

0112

端末34の数も特に限定されず、ユーザの人数に応じて複数の端末34を設けてもよい。

0113

そして、これらの各部を接続するネットワーク36としては、例えばインターネット、LAN(Local Area Network)、WAN(Wide Area Network)、及びVPN(Virtual Private Network)等を採用し得る。

0114

図7は、第1〜第3の情報処理装置31〜33と端末34の各々の機能構成例を示す図である。

0115

図7に示すように、端末34は、ネットワーク36上の情報リソースを扱うためのwebブラウザ35を有する。

0116

一方、第1の情報処理装置31は、第1のメッセージ制御部41と、連携管理部42と、サービスアプリケーション43と、第1の記憶部44とを有する。

0117

このうち、第1メッセージ制御部41は、第1の通知部の一例であって、OAuthやOpenID Connect等の通信プロトコルに従って他の装置との間でメッセージ送受信を行う。

0118

例えば、第1のメッセージ制御部41は、第3の情報処理装置33が保有するユーザの後述の属性情報38を取得することについての承認を求める承認依頼を第2の情報処理装置32に通知する。また、第1のメッセージ制御部41は、属性情報38の取得についてユーザの同意が得られたことを示す後述の同意IDが第2の情報処理装置32から通知されたときに、その同意IDを第3の情報処理装置33に通知する。

0119

一方、連携管理部42は、第1〜第3の情報処理装置31〜33のうちのどれがサービスの連携に関与するのかを特定する連携IDを前述の承認依頼に付加する。

0120

また、サービスアプリケーション43は、ネットワーク36を介してユーザにサービスを提供するプログラムである。そのサービス内容は特に限定されない。以下では、サービスアプリケーション43が翻訳アルバイトを募集するサービスを提供する場合について説明する。

0121

また、第1の記憶部44は、第1のメッセージ制御部41が受信した前述の同意IDを記憶する。

0122

一方、第2の情報処理装置32は、第2のメッセージ制御部51、認証部52、第2の記憶部53、制御部54、及び同意テーブル55を有する。

0123

このうち、第2のメッセージ制御部51は、第2の通知部の一例であって、OpenID Connectに従って他の装置との間でメッセージの送受信を行う。

0124

例えば、第2のメッセージ制御部51は、第1の情報処理装置31から前述の承認依頼を受けたときに、属性情報38を第1の情報処理装置31に提供することについての同意をユーザに要求する。そして、その同意が得られたときに、第1の情報処理装置31は同意IDを第1の情報処理装置31に通知する。

0125

また、認証部52は、前述の承認依頼を受けたときに、第1の情報処理装置31や第3の情報処理装置33の代わりにユーザの認証を行う。認証方法は特に限定されず、例えばパスワード認証で認証を行い得る。

0126

そして、第2の記憶部53には、ユーザ認証に必要なユーザIDとパスワード等の認証情報39が予め登録される。

0127

その他に、ユーザの氏名、住所、及びメールアドレス等の複数の属性情報37も認証テーブル53に格納される。なお、属性情報37はこれらに限定されない。以下では、ユーザに関連する任意の情報を属性情報37と呼ぶ。

0128

制御部54は、ユーザが同意していない属性情報38が第1の情報処理装置31に取得されるのを防ぐ機能を有し、前述の同意IDを生成する生成部54aと、その同意IDの正当性を確認する確認部54bとを有する。

0129

そして、同意テーブル55は、同意IDの正当性を確認するのに使用されるものであって、例えば図8のような属性を有する。

0130

図8は、同意テーブル55の一例を示す図である。

0131

この例では、同意テーブル55には、「同意ID」、「ユーザセッション」、「連携ID」、「連携元」、及び「状態チェックフラグ」の各属性が設定される。

0132

このうち、「同意ID」は、各情報処理装置31〜33を流れるメッセージに一意に付加される記号列であって、同意識別子の一例である。

0133

確認部54b(図7参照)は、後述のように同意テーブル55に同意IDが存在するかを確認し、その確認を終了した場合には「状態チェックフラグ」が「1」とし、確認が行われていない場合には状態チェックフラグが「0」とする。

0134

また、「ユーザセッション」は、第2の情報処理装置32と端末34との間で確立されたセッションである。そして、「連携ID」は、第1〜第3の情報処理装置31〜33のうち、どの情報処理装置が連携してユーザにサービスを提供するのかを特定するIDであって、連携識別子の一例である。

0135

更に、「連携元」は、OAuthやOpenID Connectプロトコルに従って第2の情報処理装置32に対して前述の承認依頼を通知してきた要求元の情報処理装置を示す。

0136

再び図7を参照する。

0137

第3の情報処理装置33は、第3のメッセージ制御部61、第3の記憶部62、サービスアプリケーション63、及び管理部64を有する。

0138

このうち、第3の記憶部62は、ユーザの複数の属性情報38を記憶する。その属性情報38は、例えばユーザが過去に取得した資格等であり、語学スコア記録証や看護師免許等が含まれる。なお、属性情報38はこれらに限定されず、ユーザに関連する任意の情報を属性情報38とし得る。

0139

また、第3のメッセージ制御部61は、第3の通知部の一例であって、OAuthやOpenID Connect等の通信プロトコルに従って他の装置との間でメッセージの送受信を行う。

0140

また、サービスアプリケーション63は、第3の記憶部62に記憶されている属性情報38を第1の情報処理装置31に提供するプログラムである。例えば、サービスアプリケーション63は、ユーザの過去の履歴として属性情報38に含まれる語学スコア記録証や看護師免許を提供する履歴サービスを実現するプログラムである。

0141

そして、管理部64は、ユーザが同意していない属性情報38が第1の情報処理装置31に取得されるのを防ぐ機能を有し、依頼部64aと判断部64bとを有する。

0142

このうち、依頼部64aは、第1の情報処理装置31から通知された同意IDの正当性についての確認を第2の情報処理装置32に依頼する。

0143

そして、その正当性が第2の情報処理装置32の確認部54bによって確認されたときに、第3のメッセージ制御部61が第1の情報処理装置31に属性情報38を通知する。なお、同意IDの正当性が確認されないときは、第3のメッセージ制御部61は第1の情報処理装置31に属性情報38を通知しない。

0144

また、判断部64bは、ユーザが未同意の属性情報38を提供するのを防ぐために、第2の情報処理装置32から属性情報38の提供についてユーザの同意が得られとの情報が通知されたとき、その属性情報38が第1の情報処理装置31が要求するものと同一かを判断する。

0145

次に、本実施形態に係る情報提供システムの動作について説明する。

0146

図9及び図10は、本実施形態に係る情報提供システムの動作の一例を示すシーケンス図である。

0147

以下では、ユーザが端末34を操作することにより、第1の情報処理装置31が募集している翻訳アルバイトに応募する場合を例にして説明する。この場合、ユーザの英語力を確認するために、第1の情報処理装置31は第3の情報処理装置33から属性情報38として語学スコア記録証を要求する。

0148

更に、第1の情報処理装置31は、ユーザと連絡を取るために、第2の情報処理装置32に対して属性情報37としてメールアドレスを要求するものとする。また、第3の情報処理装置33は、語学スコア記録証がユーザ本人のものであるかを確認するために、第2の情報処理装置32に対して氏名と住所とを要求するものとする。

0149

なお、図9及び図10において、実線で示す処理はOpenID Connectに即した処理を示し、一点鎖線で示す処理はOAuth 2.0に即した処理を示す。また、点線で示す処理は、これらのプロトコルで規定されていない処理を示す。

0150

以下、図9及び図10に示す処理をステップ番号に沿って説明する。

0151

(S50)まず、第1の情報処理装置31が募集している翻訳アルバイトに応募するために、ユーザが端末34を操作することにより、webブラウザ35から第1の情報処理装置31にサービス要求を通知する。

0152

(S51)そのサービス要求を受けて、第1の情報処理装置31の第1のメッセージ制御部41が、第2の情報処理装置32に対して承認依頼70を通知する。

0153

承認依頼70は、属性情報37(メールアドレス)と属性情報38(語学スコア記録証)とを第1の情報処理装置31が取得してよいとの承認を第2の情報処理装置32に求めるHTTPリクエストであり、端末34から第2の情報処理装置32にリダイレクトされる。

0154

なお、この承認依頼70には、第3の情報処理装置33が属性情報37(氏名、住所)を取得してよいとの承認を第2の情報処理装置32に求める依頼も含まれる。

0155

また、この例ではHTTPヘッダにFEDパラメータを設け、そのFEDパラメータに連携IDの値を指定する。

0156

連携IDは、前述のように第1〜第3の情報処理装置31〜33のうちどの情報処理装置が連携してユーザにサービスを提供するのかを示すIDであって、連携管理部42によりHTTPヘッダに付加される。

0157

連携に関与する第1〜第3の情報処理装置31〜33とFEDパラメータの値との対応関係は特に限定されない。

0158

例えば、第1〜第3の情報処理装置31〜33の全てが連携する場合には、FED=001とし得る。

0159

一方、第3の情報処理装置33が連携に関与せずに、第1の情報処理装置31と第2の情報処理装置32のみが連携する場合には、HTTPヘッダにFEDパラメータを含めない。

0160

本例では、第1〜第3の情報処理装置31〜33の全てが連携するため、FED=001とする。

0161

なお、各属性情報37、38のうちのどの情報を各情報処理装置31〜33のうちのどの情報処理装置に提供するかは、各情報処理装置31〜33の間で予め取り決められている。

0162

よって、FEDパラメータにより連携に関与する情報処理装置が分かれば、各属性情報37、38のうちのどの情報を各情報処理装置31〜33のうちのどの情報処理装置に提供するかを判断できる。したがって、提供を求める属性情報を承認依頼70のscopeパラメータに指定しなくても、第2の情報処理装置32は、FEDパラメータを参照することでどの属性情報をどの情報処理装置に提供すべきかを判断できる。

0163

例えば、FED=001の場合には、属性情報37(メールアドレス)と属性情報38(語学スコア記録証)とを第1の情報処理装置31に提供し、かつ、第3の情報処理装置33に属性情報37(氏名、住所)を提供することを予め決めておく。これにより、第2の情報処理装置32は、FED=001のときの各属性情報37、58の提供先がどの情報処理装置であるかを判断できる。

0164

(S52)第2の情報処理装置32の制御部54が、承認依頼70に付加されたFEDパラメータの値を同意テーブル55(図8参照)の「連携ID」に格納する。

0165

これと共に、制御部54は、同意テーブル55の「連携元」に「第1の情報処理装置31」を格納する。前述のように、「連携元」は、承認依頼70を要求してきた要求元の情報処理装置であって、その承認依頼70の送信元URLから制御部54が判断する。

0166

(S53)第2の情報処理装置32の認証部52は、ユーザが第2の情報処理装置32と第3の情報処理装置33の各々を利用する権限があるかを確認するために、端末34に対して認証要求71を通知する。

0167

また、第2の情報処理装置32の第2のメッセージ制御部51が端末34との間でユーザセッションを確立し、そのユーザセッションに対応したcookieを生成する。そして、第2のメッセージ制御部51が認証要求71にそのcookieを付加し、端末34のwebブラウザ35がそのcookieを受け取る。

0168

なお、webブラウザ35は、以降のステップで第2の情報処理装置32にアクセスするときは、このcookieを第2の情報処理装置32の第2のメッセージ制御部51に渡す。

0169

(S54)ユーザは、第2の情報処理装置32にログインするための認証ID(A_ID)とパスワード(PW)を端末34のwebブラウザ35に入力する。そして、その認証IDとパスワード(PW)とが、認証情報72としてwebブラウザ35から第2の情報処理装置32に通知される。

0170

なお、この例ではシングルイオンを採用するため、第3の情報処理装置33にログインするための認証は、第2の情報処理装置32にログインするための認証が成功すれば不要である。

0171

その後、認証部52は、その認証情報72が第2の記憶部53に予め登録されている認証情報39と等しいかどうかを確認し、両者が等しい場合に認証が成功したと判断する。

0172

(S55)ステップS54の認証が成功した場合、第2の情報処理装置32の第2のメッセージ制御部51が端末34に同意要求73を通知する。

0173

その同意要求73は、第1〜第3の情報処理装置31〜33のいずれかに属性情報37や属性情報38を提供してよいとの同意をユーザに求める要求である。

0174

ここで、提供すべき属性情報37、38と、提供先の第1〜第3の情報処理装置31〜33とは、ステップS52で同意テーブル55に格納されている連携IDに基づいて第2のメッセージ制御部51が判断する。

0175

例えば、連携IDのFEDパラメータが001の場合は、第2のメッセージ制御部51が第1〜第3の情報処理装置31〜33の全てがサービスに関与すると判断する。そして、第2のメッセージ制御部51が、その同意要求73に、属性情報37(メールアドレス)と属性情報38(語学スコア記録証)とを第1の情報処理装置31に提供してよいとの同意を含める。また、第2のメッセージ制御部51は、その同意要求73に、第3の情報処理装置33に属性情報37(氏名、住所)を提供してもよいとの同意も含める。

0176

(S56)ユーザは、属性情報37(メールアドレス、氏名、住所)と属性情報38(語学スコア記録証)の提供に同意するときは、端末34を操作して第2の情報処理装置32に同意74を通知する。

0177

このように複数の属性情報37、38の提供についての同意を一度で済ますことで、ユーザの負担軽減を実現することができる。

0178

なお、同意74には、ステップS53で第2の情報処理装置32から渡されたcookieがwebブラウザ35により付加される。

0179

(S57)上記の同意74を受けて、第2の情報処理装置32の生成部54bが同意IDを生成する。その同意IDは、制御部54によって同意テーブル55の属性「同意ID」に格納される。ここでは、例えば同意ID = ID00xyzとする。

0180

更に、制御部54が、同意74に含まれるcookieに対応したユーザセッションを同意テーブル55の「ユーザセッション」に格納する。

0181

(S58)第2の情報処理装置32の第2のメッセージ制御部51は、ステップS51の承認依頼70に対する応答を第1の情報処理装置31に通知するために、第1の情報処理装置31に許可応答75を返す。

0182

その許可応答75はHTTPレスポンスであって、端末34により第1の情報処理装置31にリダイレクトされる。このリダイレクトの際、そのHTTPヘッダには、ステップS53で第2の情報処理装置32から端末34に渡されたcookieが、端末34により付加される。

0183

更に、そのHTTPヘッダには、ステップS57で生成した同意IDが第2のメッセージ制御部51により付加される。

0184

図11は、許可応答75の一例を示す図である。

0185

この例では、HTTPヘッダにconsentIDパラメータ75aを設け、そのconsentIDパラメータに同意IDのID00xyzを指定する。

0186

また、このHTTPレスポンスには許可コード75bも付加される。許可コード75bは、第2の情報処理装置32が生成した記号列であって、HTTPレスポンスのLocationヘッダに指定される。その許可コードは、第2の情報処理装置32から属性情報37(メールアドレス)の提供を受けるためのアクセストークンと後で交換される。

0187

再び図9を参照する。

0188

(S59)第1の情報処理装置31の連携管理部42は、許可応答75に付加されている同意IDを第1の記憶部44に格納する。

0189

(S60)第1の情報処理装置31の第1のメッセージ制御部41は、第2の情報処理装置32に対してアクセストークン要求を通知する。

0190

アクセストークン要求は、第2の情報処理装置32から属性情報37(メールアドレス)を得る際に必要となるアクセストークンを要求するHTTPリクエストであって、そのHTTPヘッダのgrant_typeパラメータには前述の許可コードが指定される。

0191

(S61)第2の情報処理装置32の第2のメッセージ制御部51は、そのアクセストークン要求に含まれている許可コードの正当性を検証する。

0192

そして、検証に成功した場合には、第2のメッセージ制御部51が第1の情報処理装置31にアクセストークン応答を返す。

0193

アクセストークン応答は、許可コードをアクセストークンに交換し、そのアクセストークンを第1の情報処理装置31に通知するためのHTTPレスポンスである。アクセストークンは、第2のメッセージ制御部51が生成した記号列であって、HTTPヘッダのaccess_tokenパラメータに指定される。

0194

また、アクセストークンは、第2の情報処理装置32が所有する複数の属性情報37のうち、提供を許可する属性情報37を特定するIDとしての機能も有する。

0195

なお、有効期限が切れたアクセストークンの代替となるリフレッシュトークンもアクセストークン応答に含めてもよい。これについては、後述の各アクセストークン応答でも同様である。

0196

(S62)第1の情報処理装置31の第1のメッセージ制御部41は、第2の情報処理装置32にアクセストークンを渡すことにより、第2の情報処理装置32にデータ要求を通知する。この場合に要求するデータは、ユーザの属性情報37(メールアドレス)である。

0197

また、このデータ要求はHTTPリクエストであって、そのHTTPヘッダのaccess_tokenパラメータに上記のアクセストークンが指定される。

0198

(S63)第2の情報処理装置32の第2のメッセージ制御部51は、第1の情報処理装置31から渡されたアクセストークンと、自身がステップS61で発行したアクセストークンとの同一性を確認する。

0199

そして、その同一性が確認できた場合には、第2のメッセージ制御部51は、アクセストークンに対応した属性情報37(メールアドレス)を特定する。その後、その属性情報37(メールアドレス)をデータ応答に乗せて第2の情報処理装置32に通知する。

0200

ここまでのステップにより、第1の情報処理装置31が属性情報37(メールアドレス)を取得できたことになる。

0201

次に、第1の情報処理装置31は、以下のようにして第3の情報処理装置33が保有する属性情報38(語学スコア記録証)の取得を試みる。

0202

(S64)まず、第1の情報処理装置31の第1のメッセージ制御部41が、第3の情報処理装置33に対して許可要求76を通知する。

0203

この許可要求76は、第3の情報処理装置33が保有している属性情報38(語学スコア記録証)の提供についての許可を要求するHTTPリクエストであり、端末34によって第3の情報処理装置33にリダイレクトされる。

0204

また、第3の情報処理装置33が保有している複数の属性情報38のうち、第1の情報処理装置31が要求する情報が語学スコア記録証であることを通知するために、HTTPヘッダのscopeパラメータにはその語学スコア記録証が指定される。

0205

更に、第1の情報処理装置31の連携管理部42は、記憶部44に格納しておいた同意IDをそのHTTPヘッダのconsentIDパラメータに指定する。これにより、同意IDが第3の情報処理装置33に通知されることになる。

0206

(S65)第3の情報処理装置33の管理部64は、同意IDを第3の記憶部62に格納する。

0207

(S66)管理部64の依頼部64aは、第1の情報処理装置31から通知された同意IDの正当性を確認するために、第3のメッセージ制御部61を介して第2の情報処理装置32に対して確認依頼77を通知する。

0208

その確認依頼77は、属性情報37(氏名、住所)の取得についての許可を第2の情報処理装置32に要求する許可要求も兼ねたHTTPリクエストであり、そのHTTPヘッダのscopeパラメータには氏名と住所が指定される。

0209

また、第2の情報処理装置32に同意IDを通知するために、HTTPヘッダのconsentIDパラメータには、第3の記憶部62に格納した同意IDが同意管理部64により指定される。

0210

なお、その確認依頼77は端末34から第2の情報処理装置32にリダイレクトされる。そのリダイレクトの際、端末34のwebブラウザ35によって確認依頼77にcookieが付加される。

0211

(S67)第2の情報処理装置32の確認部54bは、確認依頼77に付加された同意IDの正当性を確認する。同意IDの正当性とは、その同意IDがステップS57で生成されたものであることを言う。

0212

同意IDの正当性を確認するために、確認部54bは、確認依頼77の同意ID(ID00xyz)が同意テーブル55に存在するか否かを確認する。そして、同意IDが同意テーブル55に存在した場合、同意IDの正当性が確認されたことになる。

0213

ここで、このように同意IDの正当性が確認された場合は、属性情報38の提供についてのユーザの同意が既に済んでいることになる。

0214

一方、同意IDの正当性が確認されない場合は、ユーザが同意していない状態で第1の情報処理装置31が第3の情報処理装置33の属性情報38を不正に取得しようとしていることになる。よって、この場合には第2の情報処理装置32から第1の情報処理装置31にエラーメッセージを通知し、これ以降の処理は行わない。これにより、ユーザが同意していない状態で第1の情報処理装置31が第3の情報処理装置33の属性情報38を不正に取得するのを防止することができる。

0215

また、確認部54bが、確認依頼77に付加されたcookieに基づいてユーザセッションを特定し、そのユーザセッションが同意テーブル55に存在するかどうかを確認してもよい。

0216

その確認の結果、ユーザセッションが同意テーブル55に存在しないと判断された場合には、ステップS56で同意74を通知したのとは別の端末34が使用されており、ユーザが入れ替わっている可能性がある。よって、この場合にも第2の情報処理装置32から第1の情報処理装置31にエラーメッセージを通知し、これ以降の処理は行わない。これにより、ユーザのなりすましを防止することができる。

0217

(S68)ステップS67で同意IDの正当性が確認された場合には、第2の情報処理装置32の第2のメッセージ制御部51が第3の情報処理装置33に応答通知78を通知する。

0218

その応答通知78は、確認依頼77に応答するためのHTTPレスポンスであり、端末34から第3の情報処理装置33にリダイレクトされる。

0219

そして、その応答通知78には、ユーザが属性情報38(語学スコア記録証)の提供に同意した旨の情報が含まれる。

0220

ここで、第3の情報処理装置33の判断部64bは、応答通知78においてユーザが提出に同意したとされる属性情報38と、許可要求76において第3の情報処理装置33が提供を求める属性情報38とが同一かどうかを判断する。

0221

これらの属性情報38が同一でない場合には、ユーザが提供に同意していない属性情報38(例えば看護師免許)を第3の情報処理装置33が不正に取得しようとしていることになる。

0222

よって、この場合には第3の情報処理装置33のメッセージ制御部61から第1の情報処理装置31にエラーメッセージを通知し、これ以降の処理は行わない。これにより、ユーザが提供に同意していない属性情報38が第1の情報処理装置31に不正に取得されるのを防止することができる。

0223

なお、この応答通知78は、第2の情報処理装置32の属性情報37(氏名、住所)を第3の情報処理装置33に提供するのを許可する許可通知も兼ねる。そのため、応答通知78のHTTPヘッダには、属性情報37(氏名、住所)の提供を受けるために必要なアクセストークンと後で交換される許可コードが付加される。

0224

(S69)第3の情報処理装置33の第3のメッセージ制御部61は、第2の情報処理装置32に対してアクセストークン要求を通知する。このアクセストークン要求は、第2の情報処理装置32から属性情報37(氏名、住所)を得る際に必要となるアクセストークンを要求するHTTPリクエストである。

0225

更に、そのHTTPリクエストのヘッダには、アクセストークンに引き換えられるステップS68の許可コードが付加される。

0226

(S70)第2の情報処理装置32の第2のメッセージ制御部51は、そのアクセストークン要求に含まれている許可コードの正当性を検証し、検証に成功した場合には第3の情報処理装置33にアクセストークン応答を返す。

0227

アクセストークン応答は、許可コードと引き換えにアクセストークンを第3の情報処理装置33に通知するためのHTTPレスポンスである。そして、第2のメッセージ制御部51が生成した記号列で表されるアクセストークンが、HTTPヘッダのaccess_tokenパラメータに指定される。

0228

このアクセストークンは、第2の情報処理装置32が所有する複数の属性情報37のうち、提供を許可する属性情報37を特定するためのIDとしての機能も兼ねる。

0229

(S71)第3の情報処理装置33の第3のメッセージ制御部61は、アクセストークンを第2の情報処理装置32に渡すことにより、第2の情報処理装置32にデータ要求を通知する。この場合に要求するデータは、前述のようにユーザの属性情報37(氏名、住所)である。

0230

(S72)第2の情報処理装置32の第2のメッセージ制御部51は、第3の情報処理装置33から渡されたアクセストークンと、自身がステップS70で発行したアクセストークンとの同一性を確認する。

0231

そして、その同一性が確認できた場合には、第2のメッセージ制御部51は、第3の情報処理装置33から通知されたアクセストークンに対応する属性情報37(氏名、住所)を特定する。その後、第2のメッセージ制御部51は、その属性情報37(氏名、住所)をデータ応答に乗せて第3の情報処理装置33に通知する。

0232

ここまでのステップにより、第3の情報処理装置33が属性情報37(氏名、住所)を取得できたことになる。

0233

(S73)第3の情報処理装置33の第3のメッセージ制御部61は、ステップS68における応答通知78を受けて、第1の情報処理装置31に許可応答79を通知する。

0234

この許可応答79は、属性情報38(語学スコア記録証)の取得を第3の情報処理装置33に許可するHTTPレスポンスであり、端末34により第1の情報処理装置31にリダイレクトされる。

0235

このHTTPレスポンスのLocationヘッダには、第3のメッセージ制御部61が生成した記号列が許可コードとして格納される。この許可コードは、属性情報38(語学スコア記録証)の提供を受けるためのアクセストークンと後で交換される。

0236

なお、ステップS68で判断部64bが許可要求76と応答通知78のそれぞれに含まれる属性情報38が同一でないと判断した場合には、前述のようにユーザが提供に同意していない属性情報38を第1の情報処理装置31が不正に取得しようとしていることになる。よって、この場合には、第3のメッセージ制御部61はこの許可応答79を第1の情報処理装置31に通知しない。

0237

これにより、ユーザが提供に同意していない属性情報38(例えば看護師免許)が第1の情報処理装置31に不正に取得されるのを防止できる。

0238

(S74)第1の情報処理装置31の第1のメッセージ制御部41は、第3の情報処理装置33に対してアクセストークン要求を通知する。このアクセストークン要求は、第3の情報処理装置33から属性情報38(語学スコア記録証)を得る際に必要となるアクセストークンを要求するHTTPリクエストである。

0239

また、そのアクセストークンのHTTPヘッダのgrant_typeフィールドには、ステップS73で第3の情報処理装置33が発行した許可コードが格納される。

0240

(S75)第3の情報処理装置33の第3のメッセージ制御部61は、そのアクセストークンに含まれている許可コードの正当性を検証し、検証に成功した場合には第1の情報処理装置31にアクセストークン応答を返す。

0241

アクセストークン応答は、許可コードと引き換えにアクセストークンを第1の情報処理装置31に通知するためのHTTPレスポンスである。そして、第3の情報処理装置33が生成した記号列で表されるアクセストークンが、そのHTTPレスポンスのaccess_tokenパラメータに指定される。

0242

アクセストークンは、第3の情報処理装置33が所有する複数の属性情報38のうち、提供を許可する属性情報38(語学スコア記録証)を特定するIDとしての機能も有する。

0243

(S76)第1の情報処理装置31の第1のメッセージ制御部41は、アクセストークンを第3の情報処理装置33に渡すことにより、第3の情報処理装置33にデータ要求を通知する。この場合に要求するデータはユーザの属性情報38(語学スコア記録証)である。

0244

(S77)第3の情報処理装置33の第3のメッセージ制御部61は、第1の情報処理装置31が提示したアクセストークンと、自身がステップS75で発行したアクセストークンとの同一性を確認する。

0245

そして、その同一性が確認できた場合には、第3のメッセージ制御部61は、アクセストークンに対応した属性情報38(語学スコア記録証)を特定する。その後、その属性情報38(語学スコア記録証)をデータ応答に乗せて第1の情報処理装置31に通知する。

0246

ここまでのステップにより、第1の情報処理装置31が属性情報38(語学スコア記録証)を取得できたことになる。

0247

なお、前述のようにステップS67で同意IDの正当性が確認されない場合にはステップS67以降の処理を行わないため、本ステップS77において第3のメッセージ制御部61が第1の情報処理装置31に属性情報38(語学スコア記録証)を通知することはない。

0248

これにより、ユーザが同意していない状態で第1の情報処理装置31が第3の情報処理装置33の属性情報38を不正に取得するのを防止できる。

0249

同様に、ステップS68において、許可要求76と応答通知78の各々に含まれる属性情報38が一致しない場合にも、本ステップS77において第3のメッセージ制御部61が第1の情報処理装置31に属性情報38(語学スコア記録証)を通知することはない。

0250

その結果、ユーザが提供に同意していない属性情報38が第1の情報処理装置31に取得されるのを防止することが可能となる。

0251

(S78)第1の情報処理装置31のサービスアプリケーション31は、ユーザの属性情報38(語学スコア記録証)に基づいて、翻訳アルバイトの採用の可否を決定する。そして、その結果をサービス応答として端末34に通知する。

0252

以上により、本実施形態に係る情報提供システムにおける基本処理を終了する。

0253

この情報提供システムによれば、ステップS55で連携IDに基づいて全ての情報処理装置31〜33がサービスに関与すると第2のメッセージ制御部51が判断したとき、同意要求73に複数の属性情報37、38の提供についての同意を含める。

0254

そのため、ユーザは、ステップS56において複数の属性情報37、38の提供についての同意を一度で済ますことができる。これにより、それぞれの属性情報37、38ごとにユーザに同意を求める場合と比較して、同意に伴うユーザの負担軽減を実現することができる。

0255

更に、ステップS67において確認依頼77に付加された同意IDの正当性を確認することで、属性情報38の提供についてユーザが同意済みかどうかを確認できる。そのため、ユーザが同意していない状態で第1の情報処理装置31が第3の情報処理装置33の属性情報38を不正に取得するのを防止することができる。

0256

しかも、このようにシステムにOpenID ConnectとOAuth 2.0の二つのプロトコルが混在していても、上記のようにメッセージに同意IDを付加してユーザの同意を管理することで、各プロトコルを一つのプロトコルのように扱うこともできる。

0257

次に、図9図10の各処理を実現するための第2の情報処理装置32の処理内容について説明する。

0258

図12図15は、第2の情報処理装置32の処理内容について示すフローチャートである。

0259

なお、第2の情報処理装置32の処理内容は、第2の情報処理装置32が受信するメッセージの種類によって異なる。そこで、以下ではメッセージごとに処理内容を説明する。

0260

<承認依頼70を受信したとき>
図12は、承認依頼70(図9参照)を受信したときの第2の情報処理装置32の処理内容を示すフローチャートである。

0261

この場合は、連携IDのFEDパラメータの値により処理が異なる。

0262

まず、FEDパラメータがない場合について説明する。

0263

前述のように、FEDパラメータがない場合は、第1の情報処理装置31と第2の情報処理装置32のみが連携してサービスを提供し、第3の情報処理装置33はサービスに関与しない。

0264

この場合は、ステップS100において、ステップS53、S54のユーザ認証が済んでいるか否かを認証部52が判断する。

0265

そして、認証済みである(YES)と判断された場合にはステップS103に移る。そのステップS103では、第2の情報処理装置32が保有する属性情報37のみの提供についてユーザに同意を求める同意要求を第2のメッセージ制御部51が端末34に通知する。

0266

一方、ステップS100において認証済みではない(NO)と判断された場合にはステップS53に移る。

0267

そのステップS53では、図9を参照して説明したように、端末34に対して認証要求71を通知する。

0268

次に、FED=001の場合について説明する。

0269

前述のように、FED=001の場合は、第1〜第3の情報処理装置31〜33の全てが連携してユーザにサービスを提供する。

0270

この場合は、ステップS101において、ステップS55のユーザ認証が済んでいるか否かを認証部52が判断する。

0271

ここで、認証済みではない(NO)と判断された場合にはステップS52に移る。

0272

図9を参照して説明したように、ステップS52においては、制御部54が、承認依頼70に付加されたFEDパラメータの値を同意テーブル55(図8参照)の「連携ID」に格納する。これと共に、制御部54は、同意テーブル55の「連携元」に「第1の情報処理装置31」を格納する。

0273

次に、図9で説明したステップS53に移り、端末34に対して認証要求71を通知する。

0274

一方、ステップS101において認証済みである(YES)と判断された場合にはステップS102に移る。

0275

この場合は、第2の情報処理装置32が承認依頼70を受信した時点で、既にステップS55のユーザ認証が済んでいることになる。しかし、図9のシーケンスでは、第2の情報処理装置32が承認依頼70を受信した後にステップS55が行われており、これらが逆の順序で起こることは想定されない。よって、この場合には想定外の事態が生じたとして、制御部54が第1の情報処理装置31にエラーメッセージを送信する。

0276

<確認依頼77を受信したとき>
図13は、確認依頼77(図10参照)を受信したときの第2の情報処理装置32の処理内容を示すフローチャートである。

0277

まず、ステップS110において、ステップS53、S54のユーザ認証が済んでいるか否かを認証部52が判断する。

0278

そして、認証済みである(YES)と判断された場合にはステップS67に移る。

0279

図9を参照して説明したように、ステップS67においては、確認依頼77に含まれる同意IDが同意テーブル55に存在するか否かが制御部54の確認部54bで確認される。

0280

そして、同意IDが同意テーブル55に存在する(YES)と判断された場合にはステップS111に移る。

0281

ステップS111においては、確認部54bが、同意テーブル55の「状態チェックフラグ」を「1」にセットする。

0282

次に、ステップS68に移る。ステップS68では、図10を参照して説明したように、第2の情報処理装置32の第2のメッセージ制御部51が第3の情報処理装置33に応答通知78を返す。

0283

一方、ステップS110において認証済みではない(NO)と判断された場合にはステップS112に移る。

0284

この場合は、第2の情報処理装置32に確認依頼77が通知された時点で、ステップS54のユーザ認証が行われていないことになる。しかし、図9図10のシーケンスによれば、ステップS53、S54のユーザ認証が行われた後に第2の情報処理装置32に確認依頼77が通知される。よって、想定外の事態が生じたとして、この場合には制御部54が第1の情報処理装置31にエラーメッセージを送信する。

0285

<認証情報72を受信したとき>
図14は、認証情報72(図9参照)を受信したときの第2の情報処理装置32の処理内容を示すフローチャートである。

0286

まず、ステップS121において、ステップS54(図9参照)の認証が成功したかどうかを認証部52が判断する。そして、認証が成功したとき(YES)は、ステップS122に移る。

0287

そのステップS122においては、制御部54が、承認依頼70に付加されているFEDパラメータの値が「001」であるか否かを判断する。

0288

そして、「001」である(YES)と判断された場合にはステップS55に移る。

0289

前述のように、FED=001のときは、第1〜第3の情報処理装置31〜33の全てが連携することにより、属性情報37(メールアドレス、氏名、住所)と属性情報38(語学スコア記録証)とが提供先に提供されることが予め決められている。

0290

よって、ステップS55では、図9を参照して説明したように、これらの属性情報37、38の提供についてユーザに同意を求める同意要求73を端末34に通知する。

0291

一方、ステップS121において、認証が失敗したとき(NO)は、ステップS123に移り、認証が失敗した旨の通知を端末34に通知する。

0292

また、ステップS122においてFEDパラメータの値が「001」ではない(NO)と判断された場合にはステップS124に移る。

0293

本例では、FEDパラメータの値が「001」であるか、FEDパラメータ自体が存在しないかの二通りしか想定していないため、FEDパラメータの値が「001」ではない場合にはFEDパラメータが存在しないということになる。

0294

また、FEDパラメータが存在しない場合には、前述のように第1の情報処理装置31と第2の情報処理装置32のみが連携する。よって、この場合には、第2の情報処理装置32が保有する属性情報37のみの提供についてユーザに同意を求める同意要求を端末34に通知する。

0295

<同意74を受信したとき>
図15は、同意74(図9参照)を受信したときの第2の情報処理装置32の処理内容を示すフローチャートである。

0296

まず、ステップS130において、ユーザが属性情報37、38の提供に同意したか否かを同意74に基づいて制御部54が判断する。

0297

ここで、同意した(YES)と判断した場合にはステップS131に移る。

0298

そのステップS131においては、第2の情報処理装置32の確認部54bが、同意テーブル55におけるFEDパラメータの値が「001」であるか否かを判断する。

0299

そして、「001」である(YES)と判断された場合にはステップS57に移る。

0300

図9を参照して説明したように、ステップS57においては、制御部54が同意IDを生成し、その同意IDを同意テーブル55に格納する。

0301

また、これと共に、同意74に含まれるcookieに対応したユーザセッションを第2のメッセージ制御部51が同意テーブル55に格納する。

0302

次に、ステップS58に移り、第2のメッセージ制御部51が許可応答75に同意IDを付加し、その許可応答75を端末34に通知する。

0303

一方、ステップS130においてユーザが同意していない(NO)と判断した場合にはステップS135に移る。

0304

この場合は、ユーザが属性情報37(氏名、住所、メールアドレス)と属性情報38(語学スコア記録証)の提出に同意していないことになる。よって、この場合には、第2のメッセージ制御部51が第1の情報処理装置31にエラーメッセージを送信する。

0305

また、ステップS131においてFEDパラメータの値が「001」ではない(NO)と判断された場合にはステップS134に移る。

0306

この場合にはFEDパラメータが存在しないことになるため、前述のように第1の情報処理装置31と第2の情報処理装置32のみが連携し、第3の情報処理装置33はサービスに関与しない。

0307

よって、この場合には、第1の情報処理装置31が第3の情報処理装置33に属性情報38を要求することは想定されないので、第1の情報処理装置31が属性情報38を不正に取得するのを防止するための同意IDは不要である。そのため、第2の情報処理装置32の第2のメッセージ制御部51は、許可応答75に同意IDを付加せずに、当該許可応答75を第1の情報処理装置31に通知する。

0308

(第2実施形態)
第1実施形態では、図11に示したように、OAuthやOpenID Connect等の既存のプロトコルでは規定されていないconsentIDをメッセージに追加することにより、ユーザが同意していない属性情報38が不正に取得されるのを防止した。

0309

これに対し、本実施形態では、既存のプロトコルでは規定されてないパラメータを追加せずに、属性情報38が不正に取得されるのを防止する。

0310

図16及び図17は、本実施形態に係る情報提供システムの動作の一例を示すシーケンス図である。

0311

なお、図16及び図17において、第1実施形態で説明したのと同じ要素とステップには第1実施形態におけるのと同じ符号を付し、以下ではその説明を簡略化する。

0312

また、第1実施形態と同様に、図16及び図17において実線で示す処理はOpenID Connectに即した処理を示し、一点鎖線で示す処理はOAuth 2.0に即した処理を示す。また、点線で示す処理は、これらのプロトコルで規定されていない処理を示す。

0313

本実施形態では、以下のようにしてOAuth 2.0で規定されているstateパラメータを同意IDとして使用する。

0314

以下、図16及び図17に示す処理をステップ番号に沿って説明する。

0315

(S50)まず、ユーザが端末34を操作することにより、第1の情報処理装置31にサービス要求を通知する。

0316

(S51)そのサービス要求を受けて、第1の情報処理装置31の第1のメッセージ制御部41が第2の情報処理装置32に対して承認依頼70を通知する。

0317

本実施形態では、第1のメッセージ制御部41がその承認依頼70のHTTPヘッダにstateパラメータを設定する。stateパラメータは、後述のCSRF(Cross Site Request Forgery)攻撃への対策としてOAuth 2.0で規定されている記号列である。

0318

stateパラメータの生成方法は特に限定されない。以下では、第1実施形態で説明した連携IDと同意IDとを結合した記号列をstateパラメータとする。

0319

例えばstate=RID00xyzとした場合、先頭の「R」が連携IDであり、後続の「ID00xyz」が同意IDである。

0320

なお、連携IDの「R」は、第1〜第3の情報処理装置31〜33の全てが連携することを示す。第3の情報処理装置33が連携に関与せずに、第1の情報処理装置31と第2の情報処理装置32のみが連携する場合には、先頭の「R」を省くものとする。

0321

(S90)第2の情報処理装置32の制御部54が、承認依頼70に付加されたstateパラメータを同意テーブル55に格納する。

0322

図18は、本実施形態に係る同意テーブル55の一例を示す図である。

0323

本実施形態では、同意テーブル55には「state」、「ユーザセッション」、「連携元」、及び「状態チェックフラグ」の各属性が設定される。

0324

これらのうち、属性「state」にstateパラメータの値(RID00xyz)が格納される。

0325

なお、第1実施形態と同様に、本ステップでは制御部54が同意テーブル55の「連携元」に「第1の情報処理装置31」を格納する。

0326

(S53)第2の情報処理装置32は、端末34に対して認証要求71を通知する。なお、その認証要求71には、端末34のユーザセッションに対応したcookieが第2のメッセージ制御部51により付加される。

0327

(S54)ユーザの操作のもとで、webブラウザ35は、第2の情報処理装置32にログインするための認証IDとパスワードとを認証情報72として第2の情報処理装置32に通知する。

0328

(S55)ステップS54の認証が成功した場合、第2の情報処理装置32の第2のメッセージ制御部51が端末34に同意要求を通知する。

0329

その同意要求は、属性情報37(メールアドレス)と属性情報38(語学スコア記録証)とを第1の情報処理装置31に提供してよいとの同意と、第3の情報処理装置33に属性情報37(氏名、住所)を提供してもよいとの同意をユーザに要求するものである。

0330

(S56)ユーザは、属性情報37(メールアドレス、氏名、住所)と属性情報38(語学スコア記録証)の提供に同意するときは、端末34を操作して第2の情報処理装置32に同意74を通知する。

0331

第1実施形態で説明したように、このように複数の属性情報37、38の提供についての同意を一度で済ますことで、ユーザの負担軽減を実現することができる。

0332

なお、その同意74には、ステップS53で第2の情報処理装置32から渡されたcookieがwebブラウザ35により付加される。

0333

(S91)第2の情報処理装置32の第2のメッセージ制御部51が、同意74に含まれるcookieに対応したユーザセッションを同意テーブル55の属性「ユーザセッション」に格納する。

0334

(S58)第2の情報処理装置32の第2のメッセージ制御部51は、端末34に許可応答75をHTTPレスポンスで返す。

0335

その許可応答75のHTTPヘッダには、同意テーブル55にあるstateパラメータと、ステップS91で生成したcookieとが第2のメッセージ制御部51により付加される。

0336

前述のように、stateパラメータは、連携IDと同意IDとが連結された記号列である。よって、本ステップにより、その記号列の一部が同意IDとして第1の情報処理装置31に通知されることになる。

0337

更に、第2のメッセージ制御部51は、アクセストークンと後で交換される許可コードをHTTPヘッダに付加する。

0338

(S92)第1の情報処理装置31の連携管理部42は、許可応答75に付加されているstateパラメータを第1の記憶部44に格納する。

0339

(S60)第1の情報処理装置31の第1のメッセージ制御部41は、第2の情報処理装置32に対してアクセストークン要求を通知する。そのアクセストークン要求のHTTPヘッダには、第1のメッセージ制御部41により前述の許可コードが格納される。

0340

(S61)第2の情報処理装置32の第2のメッセージ制御部51は、そのアクセストークン要求に含まれている許可コードの正当性を検証する。

0341

そして、検証に成功した場合には、第2のメッセージ制御部51が第1の情報処理装置31にアクセストークン応答を返し、第2の情報処理装置32にアクセストークンを渡す。

0342

(S62)第1の情報処理装置31の第1のメッセージ制御部41は、第2の情報処理装置32にアクセストークンを渡すことにより、第2の情報処理装置32にデータ要求を通知する。この場合に要求するデータは、ユーザの属性情報37(メールアドレス)である。

0343

(S63)第2の情報処理装置32の第2のメッセージ制御部51は、第1の情報処理装置31から渡されたアクセストークンと、自身がステップS61で発行したアクセストークンとの同一性を確認する。

0344

その同一性が確認できた場合には、第2の情報処理装置32は、属性情報37(メールアドレス)をデータ応答に乗せて第2の情報処理装置32に通知する。

0345

ここまでのステップにより、第1の情報処理装置31が属性情報37(メールアドレス)を取得できたことになる。

0346

次に、第1の情報処理装置31は、以下のようにして第3の情報処理装置33が保有する属性情報38(語学スコア記録証)の取得を試みる。

0347

(S64)まず、第1の情報処理装置31の第1のメッセージ制御部41が、第3の情報処理装置33に対して許可要求76を通知する。

0348

この許可要求は、第3の情報処理装置33が保有している属性情報38(語学スコア記録証)の提供を要求するHTTPリクエストであって、scopeパラメータにはその語学スコア記録証が指定される。

0349

更に、第1の情報処理装置31の第1のメッセージ制御部41は、記憶部44に格納しておいたstateパラメータをHTTPヘッダに付加することにより、そのstateパラメータを第3の情報処理装置33に渡す。

0350

前述のようにstateパラメータの一部は同意IDとして機能するため、本ステップにより同意IDが第3の情報処理装置33に通知されることになる。

0351

(S93)第3の情報処理装置33の管理部64が、その同意IDを含むstateパラメータを第3の記憶部62に格納する。

0352

(S66)管理部64の依頼部64aは、第1の情報処理装置31から通知された同意IDの正当性を確認するために、第3のメッセージ制御部61を介して第2の情報処理装置32に対して確認依頼77を通知する。

0353

その確認依頼77は、属性情報37(氏名、住所)の取得についての許可を第2の情報処理装置32に要求する許可要求も兼ねたHTTPリクエストであり、そのHTTPヘッダのscopeパラメータには氏名と住所が指定される。

0354

また、第2の情報処理装置32に同意IDを通知するために、HTTPヘッダのconsentIDパラメータには、第3の記憶部62に格納したstateパラメータが同意管理部64により指定される。

0355

なお、その確認依頼77は端末34から第2の情報処理装置32にリダイレクトされる。そのリダイレクトの際、端末34のwebブラウザ35によって確認依頼77にcookieが付加される。

0356

(S67)第2の情報処理装置32の確認部54bは、確認依頼77に付加された同意IDの正当性を確認するために、その同意IDを一部に含むsateパラメータのチェックを行う。

0357

本実施形態における同意IDの正当性とは、確認依頼77で通知されたstateパラメータが、ステップS50において第1の情報処理装置31が自ら生成して依頼承認70に付加したstateパラメータと同一であることをいう。

0358

同意IDの正当性を確認するために、確認部54bは、確認依頼77のstateパラメータ(RID00xyz)が同意テーブル55に存在するか否かを確認する。そして、stateパラメータが同意テーブル55に存在した場合、同意IDの正当性が確認されたことになる。

0359

ここで、このように同意IDの正当性が確認された場合は、ユーザの同意74を受けて第2の情報処理装置32が通知する許可応答75に含まれるstateパラメータと、確認依頼77に含まれるstateパラメータとが同一ということになる。

0360

よって、この場合にはユーザの同意を属性情報38の提供についてのユーザの同意が既に済んでいることになる。

0361

一方、同意IDの正当性が確認されない場合は、ユーザが同意していない状態で第1の情報処理装置31が第3の情報処理装置33の属性情報38を不正に取得しようとしていることになる。したがって、この場合には第2の情報処理装置32から第1の情報処理装置31にエラーメッセージを通知し、これ以降の処理は行わない。これにより、ユーザが同意していない状態で第1の情報処理装置31が第3の情報処理装置33の属性情報38を不正に取得するのを防止することができる。

0362

また、第1実施形態と同様に、確認部54bが、確認依頼77に付加されたcookieに基づいてユーザセッションを特定し、そのユーザセッションが同意テーブル55に存在するかどうかを確認してもよい。

0363

ステップS67で同意IDの正当性が確認された場合には、第1実施形態と同様にしてステップS68〜S78を行う。これにより、ステップS77において第1の情報処理装置31が属性情報38(語学スコア記録証)を取得することができる。

0364

以上説明した本実施形態によれば、OAuthやOpenID Connect等の既存のプロトコルで規定されているstateパラメータを承認依頼70に付加することにより、既存のプロトコルの範疇で第1の情報処理装置31の不正を検出できる。

0365

しかも、そのstateパラメータとして同意IDと連携IDとを結合した記号列を使用することで、連携ID用のパラメータをHTTPヘッダに追加することなしに、各情報処理装置31〜33のどれが連携するのかを確認できる。

0366

更に、そのstateパラメータは、以下のようにCSRF攻撃への対策ともなる。

0367

図19は、CSRF攻撃について説明するためのシーケンス図である。

0368

なお、図19において、図16及び図17で説明したのと同じ要素とステップにはこれらの図におけるのと同じ符号を付し、以下ではその説明を省略する。

0369

図19の例では端末34が二台あり、ユーザセッションがUser001sで表される端末が攻撃者により操作され、ユーザセッションがUser002sで表される端末が被害者により操作されているものとする。

0370

このとき、攻撃者の端末34は、OAuth 2.0の仕様に反して、ステップS140において許可要求76を第3の情報処理装置33にリダイレクトさせずに、何らかの手法で被害者の端末34に許可要求76を渡す。

0371

そして、被害者の端末34は、OAuth 2.0の仕様に従って、ステップS141において許可要求76を本来のリダイレクト先である第3の情報処理装置33にリダイレクトする。

0372

その結果、これ以降のステップでは、被害者の端末34と各情報処理装置31〜33との間でユーザセッションが確立されることになる。これにより、例えばアクセストークンとユーザセッションとが対応付けられている場合、各情報処理装置31〜33に攻撃者が保有しているアカウントに対するアクセストークンが、被害者のユーザセッションと対応付くことになる。これにより、攻撃者のアカウントに被害者のリソースを登録させる等の不正を行うことができる。

0373

本実施形態では、これを防止するために、図18に示すように、同意テーブル55においてstateパラメータとユーザセッションとを対応させる。

0374

これにより、ステップS67で確認依頼77のstateパラメータが同意テーブル55に存在しても、ユーザセッションが同意テーブル55にない場合にはCSRF攻撃を受けている可能性があると判断でき、CSRF攻撃に対するシステムの堅牢性が増す。

0375

(ハードウェア構成)
上記した第1実施形態と第2実施形態で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することで実現できる。そこで、以下では、上記の各実施形態と同様の機能を有するプログラムを実行するコンピュータの一例について説明する。

0376

図20は、第1及び第2実施形態に係る情報提供プログラムを実行するコンピュータのハードウェア構成図である。

0377

以下では、第1〜第3の情報処理装置31〜33と端末34のそれぞれにコンピュータ100を用意する。

0378

コンピュータ100の台数は特に限定されない。例えば、複数のコンピュータ100が第1の情報処理装置31の処理を実行してもよい。これについては、第2及び第3の情報処理装置32、33についても同様である。

0379

そのコンピュータ100は、各種演算処理を実行するCPU(Central Processing Unit)101と、データ入力受け付け入力装置102と、モニタ103とを有する。

0380

また、コンピュータ100は、記憶媒体110からプログラムを読み取る媒体読取装置104と、各種装置と接続するためのインタフェース装置105と、他の装置と有線または無線により接続するための通信装置106とを有する。

0381

更に、コンピュータ100は、各種情報一時記憶するRAM(Random Access Memory)107と、ハードディスク装置108とを有する。なお、各装置101〜108は、バス109に接続される。

0382

上記のハードディスク装置108には、第1〜第3の情報処理装置31〜33と端末34のそれぞれの機能を実現するための情報提供プログラムが記憶される。

0383

例えば、第1の情報処理装置31用のハードディスク装置108には、第1のメッセージ制御部41、第1の連携管理部42、サービスアプリケーション43、及び第1の記憶部44の各部の機能を有する情報提供プログラムが記憶される。

0384

また、第2の情報処理装置32用のハードディスク装置108には、第2のメッセージ制御部51、認証部52、第2の記憶部53、制御部54、及び同意テーブル55の各部の機能を有する情報提供プログラムが記憶される。

0385

更に、第3の情報処理装置33用のハードディスク装置108には、第3のメッセージ制御部61、第3の記憶部62、サービスアプリケーション63、及び管理部64の各部の機能を有する情報提供プログラムが記憶される。

0386

そして、端末34用のハードディスク装置108には、webブラウザ35としての機能を有する情報提供プログラムが記憶される。

0387

一方、入力装置102は、例えばユーザからパスワードの入力を受け付けたり、コンピュータ100の管理者から管理情報の入力を受け付けたりする。モニタ103は、例えば認証のためのパスワード入力画面を表示したり、コンピュータ100の管理者がメンテナンス等を行う場合に各種情報を表示したりする。

0388

インタフェース装置105には、例えば不図示の印刷装置等が接続される。通信装置106は、ネットワーク35に接続され、第1〜第3の情報処理装置31〜33と端末34のそれぞれの間の通信を行う。

0389

また、CPU101は、ハードディスク装置108に記憶された前述の情報提供プログラムを読み出して、RAM107に展開して実行する。これにより、CPU101やRAM107等のハードウェア資源と情報提供プログラムとが協働して図7に示した第1〜第3の情報処理装置33と端末34の各機能が実現される。

0390

また、上記の情報提供プログラムをコンピュータ100が読み取り可能な記録媒体110に記憶させておき、コンピュータ100に記録媒体110の情報提供プログラムを読み取らせるようにしてもよい。

0391

そのような記録媒体110としては、例えばCD-ROM(Compact Disc - Read Only Memory)、DVD(Digital Versatile Disc)、及びUSB(Universal Serial Bus)メモリ等の可搬型記憶媒体がある。また、フラッシュメモリ等の半導体メモリハードディスクドライブを記憶媒体110として使用してもよい。これらの記憶媒体110は、物理的な形態を持たない搬送波のような一時的な媒体ではない。

0392

更に、公衆回線、インターネット、及びLAN等に接続された装置にこの情報処理プログラムを記憶させておき、コンピュータ100がこれらから情報処理プログラムを読み出して実行するようにしてもよい。

0393

以上説明した各実施形態に関し、更に以下の付記を開示する。

0394

(付記1) 第1の情報処理装置、第2の情報処理装置、及び第3の情報処理装置を備えた情報提供システムであって、
前記第1の情報処理装置は、
前記第3の情報処理装置が保有するユーザの属性情報を取得することについての承認を求める承認依頼を前記第2の情報処理装置に通知し、前記属性情報の取得について前記ユーザの同意が得られたことを示す同意識別子が前記第2の情報処理装置から通知されたときに、前記同意識別子を前記第3の情報処理装置に通知する第1の通知部、
を有し、
前記第2の情報処理装置は、
前記第3の情報処理装置からの依頼を受けて、前記第3の情報処理装置から通知された前記同意識別子の正当性を確認する確認部と、
前記承認依頼を受けたときに前記属性情報を前記第1の情報処理装置に提供することについての前記同意を前記ユーザに要求し、前記同意が得られたときに前記同意識別子を前記第1の情報処理装置に通知する第2の通知部と、
を有し、
前記第3の情報処理装置は、
前記属性情報を記憶した記憶部と、
通知された前記同意識別子の前記正当性についての確認を前記第2の情報処理装置に依頼する依頼部と、
前記確認部によって前記正当性が確認されたときに前記第1の情報処理装置に前記属性情報を通知し、前記正当性が確認されないときには前記第1の情報処理装置に前記属性情報を通知しない第3の通知部、
を有する、
ことを特徴とする情報提供システム。

0395

(付記2) 前記第1の通知部は、前記第2の情報処理装置から前記同意識別子が通知された場合に、前記属性情報の提供についての許可を求める要求を前記第3の情報処理装置に通知し、
前記第2の通知部は、前記確認部により前記正当性が確認されたときに、前記属性情報の提供についてユーザが同意した旨の情報を前記第3の情報処理装置に通知し、
前記第3の情報処理装置は、前記第2の通知部から通知された前記情報における前記属性情報と、前記第1の通知部から要求された前記属性情報とが一致しているかを判断する判断部を有し、
前記第3の通知部は、前記判断部によって前記属性情報が一致していないと判断されたときには、前記第1の情報処理装置に前記属性情報を通知しないことを特徴とする付記1に記載の情報提供システム。

0396

(付記3) 前記ユーザが操作する端末を更に有し、
前記確認部は、前記端末と前記第2の情報処理装置との間で確立されたユーザセッションと、前記同意をした前記ユーザのユーザセッションとの同一性を確認し、
前記第2の通知部は、前記ユーザセッションの前記同一性がないときには、前記ユーザが提供に同意した前記属性情報を前記第3の情報処理装置に通知しないことを特徴とする付記1又は付記2に記載の情報提供システム。

0397

(付記4) 前記第2の情報処理装置は、前記第3の情報処理装置が保有するのとは別の属性情報を記憶した別の記憶部を有し、
前記同意には、前記別の属性情報を前記第3の情報処理装置に提供することについての同意が含まれることを特徴とする付記1乃至付記3のいずれかに記載の情報提供システム。

0398

(付記5) 前記第1の情報処理装置は、前記第1乃至第3の情報処理装置のうちのどれが連携して前記ユーザにサービスを提供するのかを特定する連携識別子を前記承認依頼に付加する連携管理部を有し、
前記第2の通知部は、前記連携識別子に基づいて第1乃至第3の情報処理装置の全てが連携することが確認できた場合に、前記別の記憶部に記憶された前記別の属性情報を前記第3の情報処理装置に提供することについての同意を前記同意に含めることを特徴とする付記4に記載の情報提供システム。

0399

(付記6) 前記第1の通知部は前記承認依頼に記号列を付加し、
前記第2の通知部は、前記記号列の一部を前記同意識別子として前記第1の情報処理装置に通知することを特徴とする付記1に記載の情報提供システム。

0400

(付記7) 前記記号列のうち、前記同意識別子を除いた残りの部分は、前記第1乃至第3の情報処理装置のうちのどれが連携して前記ユーザにサービスを提供するのかを特定する連携識別子であることを特徴とする付記6に記載の情報提供システム。

0401

(付記8) 前記第2の情報処理装置は、前記承認依頼を受けて前記ユーザの認証を行う認証部を有することを特徴とする付記1に記載の情報提供システム。

0402

(付記9) 前記確認部は、前記第2の通知部が前記第1の情報処理装置に通知した前記同意識別子を記憶したテーブルを用い、前記テーブルの前記同意識別子と、前記第3の情報処理装置から通知された前記同意識別子とが同一であるかどうかを確認することにより、前記正当性の確認を行うことを特徴とする付記1に記載の情報提供システム。

0403

(付記10) 第1の情報処理装置が、ユーザの属性情報を取得することについての承認を第2の情報処理装置に依頼し、
前記依頼を受けた前記第2の情報処理装置が、前記属性情報を前記第1の情報処理装置に提供することについての同意を前記ユーザに要求し、
前記ユーザの同意が得られたとき、前記第2の情報処理装置が、前記同意が得られたことを示す同意識別子を前記第1の情報処理装置に通知し、
前記同意識別子の通知を受けた前記第1の情報処理装置が、前記属性情報を保有する第3の情報処理装置に前記同意識別子を通知し、
前記同意識別子の通知を受けた前記第3の情報処理装置が、前記第2の情報処理装置に対し、通知された前記同意識別子の正当性の確認を依頼し、
前記正当性が確認されたときに前記第3の情報処理装置が前記第1の情報処理装置に前記属性情報を通知し、前記正当性が確認されないときには前記第3の情報処理装置が前記第1の情報処理装置に前記属性情報を通知しないことを特徴とする情報提供方法。

0404

(付記11) 前記同意識別子の通知を受けた前記第1の情報処理装置が、前記第3の情報処理装置に対し、前記属性情報の提供について許可を求める要求を通知し、
前記正当性が確認された場合、前記第2の情報処理装置が、前記属性情報の提供についてユーザが同意した旨の情報を第3の情報処理装置に通知し、
前記第3の情報処理装置は、前記第2の情報処理装置から通知された前記情報における前記属性情報と、前記第1の情報処理装置から要求された前記属性情報とが一致していない場合には、前記第1の情報処理装置に前記属性情報を通知しないことを特徴とする付記10に記載の情報提供方法。

0405

(付記12) 第1の情報処理装置が、ユーザの属性情報を取得することについての承認を第2の情報処理装置に依頼する処理と、
前記依頼を受けた前記第2の情報処理装置が、前記属性情報を前記第1の情報処理装置に提供することについての同意を前記ユーザに要求する処理と、
前記ユーザの同意が得られたとき、前記第2の情報処理装置が、前記同意が得られたことを示す同意識別子を前記第1の情報処理装置に通知する処理と、
前記同意識別子の通知を受けた前記第1の情報処理装置が、前記属性情報を保有する第3の情報処理装置に前記同意識別子を通知する処理と、
前記同意識別子の通知を受けた前記第3の情報処理装置が、前記第2の情報処理装置に対し、通知された前記同意識別子の正当性の確認を依頼する処理と、
前記正当性が確認されたときに前記第3の情報処理装置が前記第1の情報処理装置に前記属性情報を通知し、前記正当性が確認されないときには前記第3の情報処理装置が前記第1の情報処理装置に前記属性情報を通知しない処理と、
をコンピュータに実行させる情報提供プログラム。

0406

1〜3…第1〜第3の情報処理装置、2a、3a…記憶部、4…端末、7、8…属性情報、9…サービス要求、10…システム、31〜33…第1〜第3の情報処理装置、34…端末、35…webブラウザ、36…ネットワーク、37、38…属性情報、39…認証情報、41…第1のメッセージ制御部、42…連携管理部、43…サービスアプリケーション、44…第1の記憶部、51…第2のメッセージ制御部、52…認証部、53…第2の記憶部、54…制御部、54a…生成部、54b…確認部、55…同意テーブル、61…第3のメッセージ制御部、62…第3の記憶部、63…サービスアプリケーション、64…管理部、64a…依頼部、64b…判断部。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ