コンピュータネットワーク内の保護リソースへのアクセスを管理するための方法と、そのための物理エンティティおよびコンピュータプログラム
コントローラによって行われる方法を開示する。方法は、要求トークンを含むメッセージを受信すること(s10)を含む。要求トークンは、サービスプロバイダ(400)からの保護リソースにアクセスすることについてユーザに許可を求めるための、コンシューマ(300)によって用いられる値である。サービスプロバイダ(400)は、保護リソースへのアクセスを提供するように構成されたソフトウェアアプリケーションとウェブサイトとのうちの少なくとも一方である。コンシューマ(300)は、ユーザの代わりにサービスプロバイダ(400)にアクセスするように構成されたソフトウェアアプリケーションとウェブサイトとのうち少なくとも一方である。方法は、さらに、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定すること(s20)と、メッセージがポリシー設定に適合していないと判定された(s30)場合には、要求トークンが要求トークンに関連するサービスプロバイダ(400)へ転送されるのを阻止すること(s34)とを含む。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンピュータまたは通信ネットワーク内の保護リソースへのアクセスの管理と、そのようなリソースの利用とに関する。特に、本発明は、そのようなアクセス管理を行うために物理エンティティによって行われる方法と、そのために構成された物理エンティティとに関する。また、本発明は、コンピュータ上で実行される場合に、コンピュータに上記の方法を行わせるように構成された命令を含むコンピュータプログラムにも関する。本発明は、特に、コンピュータネットワーク内のユーザに関連するリソースを用いるウェブサービスの文脈で適用されうるものであり、ここで、リソースは、2つ以上のウェブアプリケーションまたはウェブサイト上に分散されている。
【背景技術】
【0002】
コンピュータまたは通信ネットワークにおいて、多様なウェブサイトまたはウェブアプリケーションが、ユーザの利益のために多様なサービスを提供することがある。例えば、1つのウェブサイトまたはウェブアプリケーションが、ユーザの電子メールアカウントを管理してもよい。別のウェブサイトまたはウェブアプリケーションが、ユーザのソーシャルネットワークのメンバと写真を共有するための写真のストレージを可能にしてもよい。別のウェブサイトまたはウェブアプリケーションが、ユーザの書店アカウントを管理する書店として動作してもよい。別のウェブサイトまたはウェブアプリケーションが、画像および写真の印刷を提供し、それらをユーザに配達してもよい。可能性は無限にある。
【0003】
けれども、ウェブサイトおよびウェブアプリケーションが、「他のサイトからの機能性も一緒に結合する」新しいサービスを提供したいと望むこともある(Eran Hammer−Lahav、“Explaining OAuth”、2007年9月5日、http://hueniverse.com/2007/09/explaining−oauth/−2009年9月15日検索、本書では参考資料[1]と呼ぶ)。例えば、(例示的なウェブサイト「printer.consumer.com」のような)デジタルフォトラボ印刷ウェブアプリケーションが、ユーザがそこのアカウントを有する(例示的なサイト「photos.container.com」のような)デジタル画像ホスティングウェブサイトの中に記憶されている写真を、これらの写真を印刷してユーザに配達することを目的として、ユーザの代わりに、検索したいと望むことがある。
【0004】
多様なウェブサイトおよびウェブアプリケーションからの保護リソースを統合するウェブサービスを実装することを目的として、本書では「コンシューマ」と呼ぶ第1のウェブサイトまたはウェブアプリケーションが、本書では「サービスプロバイダ」と呼ぶ(コンシューマもサービスを提供するのだが)第2のウェブサイトまたはウェブアプリケーションにアクセスするために、ユーザの認証情報を提供するようユーザに求めることがある。上記の例では、コンシューマはデジタルフォトラボ印刷ウェブアプリケーションであり、サービスプロバイダはデジタル画像ホスティングウェブサイトであり、保護リソースはユーザの個人的写真であろう。言い換えると、コンシューマがサービスプロバイダにアクセスするために、ユーザのユーザ名とパスワードとを提供するようユーザに求めることがある。しかし、これによって、ユーザのパスワードが秘密でなくなり、誰か他の人が、サービスプロバイダの中で、ユーザのアカウントに関連する任意の動作のためにそのパスワードを使用することが可能になる(例えば「あなたのパスワードを変更してあなたを締め出すことすら」、参考文献[1]のセクション「what is it For(それは何のためか)」)。
【0005】
この問題を解決するため、OAuthプロトコルが開発された(Atwood,M.他“OAuth Core 1.0 Revision A”、2009年6月24日、http://oauth.net/core/1.0a−2009年9月15日検索、本書では参考文献[2]と呼ぶ)。OAuthプロトコルは、ウェブサイトまたはウェブアプリケーションすなわちコンシューマが、ユーザのサービスプロバイダ認証情報をユーザがコンシューマに開示することを必要とせず(参考文献[2]、Abstract)、別のウェブサイトまたはウェブアプリケーションすなわちサービスプロバイダからの保護リソースにアクセスすることを可能にする。OAuthプロトコルは、アプリケーション・プログラミング・インターフェース(API)のアクセス委譲プロトコルとみなされてもよい。参考文献[1]のセクション「what is it For(それは何のためか)」で説明された従者の鍵のたとえは、OAuthプロトコルの目的を直感的に理解するのに役立ちうる。
【0006】
OAuthプロトコルでは、認証、すなわち「ユーザが、ユーザの認証情報をコンシューマと共有することなく、ユーザの保護リソースへのアクセスを認めるプロセス」(参考文献[2]、「6.Authenticating with OAuth(OAuthを使った認証)」)は、以下のように機能する。
【0007】
コンシューマが、未許可の要求トークンをサービスプロバイダから入手する。コンシューマは、サービスプロバイダのユーザ許可URL(「URL」は「Uniform Resource Locator」のこと)を用いてユーザのウェブブラウザを介してユーザをサービスプロバイダへと向ける。次いでユーザは、サービスプロバイダを使って自分自身を認証する。言い換えると、ユーザは、サービスプロバイダのウェブサイトにサイン・インする。ユーザは、決して自分のサービスプロバイダ認証情報をコンシューマに提供するのではない。
【0008】
次いでサービスプロバイダは、コンシューマが保護リソースへのアクセスを認められるようになることについてユーザが同意するかどうかを、ユーザに尋ねる。そうするため、サービスプロバイダは、コンシューマがアクセスすることを望む保護リソースについての情報を、ユーザに提示する。情報は、要求されたアクセスの持続時間とアクセスのタイプとを含んでいる(例えば、保護リソースをコピーする、修正する、削除する)。情報は、例えば、「このウェブサイト<consumer−name>は、これから1時間の間、あなたの個人的な写真へのアクセスを要求しています。そのようなアクセスを承認しますか?」というような例示的なメッセージと共に、サービスプロバイダのウェブサイトのウェブページ上に提示されてもよい。次いでユーザは、ユーザの代理としての想定されるアクセスをコンシューマに与えるための、サービスプロバイダについての許可を、認めるかまたは拒否する。
【0009】
ユーザが同意した場合、要求トークンは許可され、ユーザはコンシューマへ戻るように導かれ、その結果、コンシューマは、要求トークンが許可されたことを通知される。次いで、許可された要求トークンはアクセストークンと交換され、コンシューマはユーザに代わって保護リソースにアクセスすることができる。ユーザが許可を拒否した場合、コンシューマは、要求トークンが無効化されたことを通知される。
【0010】
OAuthプロトコルを用いた認証プロセスの一例が、Eran Hammer−Lahav、“Beginner’s Guide to OAuth−Part II;Protocol Workflow”、2007年10月15日、http://hueniverse.com/2007/10/beginners−guide−to−oauth−part−ii−protocol−workflow/−2009年9月15日検索、に提示されている。
【0011】
ユーザにかかる操作上の負荷を軽減する必要性を念頭に置けば、本書ではコンシューマと呼ぶウェブサイトまたはウェブアプリケーションが、本書ではサービスプロバイダと呼ぶ他のウェブサイトまたはウェブアプリケーション上にあるユーザに関連する保護リソースに対してユーザに代わって行うアクセスを管理するための方法、物理エンティティおよびコンピュータプログラムを改善することが望ましい。
【発明の概要】
【0012】
これらの目的に合致または少なくとも部分的に合致するため、独立請求項において方法、コントローラ、およびコンピュータプログラムが定義される。有利な諸実施形態が、従属請求項において定義される。
【0013】
一実施形態では、コントローラによって行われる方法を提供する。方法は、要求トークンを含むメッセージを受信するステップを含む。要求トークンは、サービスプロバイダからの保護リソースにアクセスすることについてユーザに許可を求めるための、コンシューマによって用いられる値である。サービスプロバイダは、保護リソースへのアクセスを提供するように構成されたソフトウェアアプリケーションとウェブサイトとのうちの少なくとも一方である。コンシューマは、ユーザの代わりにサービスプロバイダにアクセスするように構成されたソフトウェアアプリケーションとウェブサイトとのうち少なくとも一方である。方法は、さらに、メッセージが、保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するステップと、メッセージがポリシー設定に適合していないと判定された場合には、要求トークンが要求トークンに関連するサービスプロバイダへ転送されるのを阻止するステップとを含む。
【0014】
コントローラは物理エンティティであって、コントローラの機能を実行するためにコンピュータプログラムもしくはハードウェア回路部を含んでいてもよい。コントローラは、例えば、サーバコンピュータまたはユーザ端末と一体化されていてもよい。コントローラは、要求トークンを含むメッセージを受信し、次いで、メッセージがポリシー設定に適合しているかどうかチェックするように構成される。メッセージがポリシー設定に適合していない場合、要求トークンは、サービスプロバイダへ転送されるのを阻止される。結果として、ユーザは、サービスプロバイダの許可ページに、不必要に導かれることはない。この許可ページでは、ここへユーザが導かれた場合には、ユーザは、サービスプロバイダからアクセスできる保護リソースへのアクセスを認めるか拒否するかを決めるように求められることになる。
【0015】
保護リソースへのアクセスを管理するポリシー設定すなわちポリシー規則は、メッセージがポリシー設定に適合していない場合に保護リソースへのアクセスを拒否するコントローラが行使するように、事前に確立されている。メッセージがポリシー設定に適合していない場合、メッセージが受信された時点でユーザが介入することを必要とせず、コントローラによってアクセス拒否が実施される。
【0016】
言い換えると、コントローラが要求トークンも含めてメッセージをインターセプトし、メッセージに関連する許可要求およびその要求トークンのタイプに応じて、コントローラが、認証および許可プロセスを中断するかどうか決定する。コントローラは、要求トークンが転送されるのを阻止し、従って、要求トークンが許可されていた場合に発生する可能性があったことに関してメッセージから抽出または収集された情報に基づいて、認証および許可プロセスを中断する。
【0017】
これによってユーザは、メッセージが受信された時点で、場合によっては、すなわち、メッセージがポリシー設定に適合していないとコントローラが判定した場合には、サービスプロバイダと対話しなければならないことから解放される。
【0018】
ゆえに、方法は、特に、ユーザにかかる操作上の負荷を軽減することによって、コンピュータまたは通信ネットワークにおけるプライバシ管理を改善し、円滑化する。ユーザの観点から見たプライバシ管理とは、サービスプロバイダ上に記憶されるかサービスプロバイダによって提供されるかまたはサービスプロバイダからアクセスできてかつユーザに関連するどの保護リソースに、所与のコンシューマがアクセスできるのかできないのか、そしてそれはどのようにして行われるのかを、ユーザが、またはユーザの利益のために、制御することに存するタスクである。また、プライバシ管理には、例えば、ユーザの保護リソースに関連して行われうる操作に関して、ユーザの選好に合わせたかたちでの、ユーザの保護リソースの適切な処理が含まれる。
【0019】
また、ユーザにかかる操作上の負荷を軽減すること以外にも、本実施形態は、一部の保護リソースへのアクセスをユーザがうっかり認めてしまうことを含みうる人為的なミスのリスクを削減する。
【0020】
メッセージとは、情報の単位であって、通信チャネル経由またはネットワーク経由で送信されることができ、かつ、要求トークンと、もしあれば関連のパラメータとを搬送しうるものである。また、メッセージは、要求と呼ばれることもある。
【0021】
ユーザとは、そのIDが認証されうる人間または人間のグループであるかまたは、そのIDが認証されうる物理エンティティ、例えばユーザ端末もしくはユーザ装置である。言い換えると、本書で「ユーザ」という用語が用いられる場合、それは、実際のエンドユーザ、すなわち人間または人間のグループと、IDが与えられうるユーザ端末またはユーザ装置とのうちのいずれか一方あるいは両方を指してもよい。さらに、ユーザ端末が、(例えば異なるユーザプロフィールに関連して)複数のIDを用いて動作することができる場合、ユーザ端末がその下で動作しうる各IDは、本発明の文脈では1人のユーザに対応してもよい。
【0022】
それゆえ、本書では「ユーザ」という用語は、適切な場合には、ユーザ装置またはユーザ端末をも包含する。例えば、認証に関して、ユーザ装置は、人間の介在がなくても認証手順を行うように構成されてもよい。これは、特に、ユーザという用語が、一般に、人間または人間のグループとしてのユーザと、或る人間によって用いられるユーザ装置とのうちのいずれか一方または両方を指す理由である。
【0023】
保護リソースとは、ユーザのユーザIDまたはユーザのグループに関連するIDグループに関するデータか、あるいは、ユーザのIDまたはユーザのグループに関連するIDグループに関連するサービスかのいずれか一方である。保護リソースの例には、個人的な写真、オンラインアドレス帳の中の連絡先、オンライン・ソーシャル・ネットワークにおける友人リスト、ブックマークのリスト、オンライン・ソーシャル・ネットワーク・アカウントの中に記憶された好きな曲のリスト、オンラインストアから最近購入した商品のリスト、サーバまたはブログ等にあるデータを保存するか公開するかの可能性等が含まれる。保護リソースには、保護ソーシャル情報が含まれてもよい。
【0024】
保護リソースへのアクセスまたはその利用は、上記のように、サービスの利用に存していてもよい。その文脈において、サービスの提供とは、例えば販売を通じての物理的商品の所有や、コンピュータ構成の技術特性の変更などをもたらす結果となる、技術的および経済的活動である。サービスはウェブサービスであってもよい。
【0025】
本発明は、ウェブベースのソーシャルネットワークサービスと共に用いられてもよいが、それらに限定されない。同様に、本発明は、OAuthプロトコルまたはOAuthプロトコルから導出されたプロトコルを用いてもよいが、それに限定されない。本発明は、他の文脈において、また、他のプロトコルと共に用いられてもよい。
【0026】
一実施形態では、方法はさらに、メッセージがポリシー設定に適合していると判定された場合、要求トークンが要求トークンに関連するサービスプロバイダへ転送されることを許可するステップを含んでいる。すなわち、コントローラは、要求トークンの転送に反対する、他の障壁を維持しない。
【0027】
本実施形態の或る下位実施形態では、その後、要求トークンは、コントローラによって直接サービスプロバイダへ転送される。
【0028】
本実施形態の別の下位実施形態では、その後、要求トークンは中間的物理エンティティへ転送され、次いで、そこから要求トークンは、要求トークンに関連するサービスプロバイダへ転送される。そのような中間的物理エンティティまたはコンピュータプログラムは、ユーザ端末であってもよいし、ユーザ端末上で実行されるブラウザであってもよい。また、中間的物理エンティティまたはコンピュータプログラムは、それ自体がコントローラとして動作してもよい。これは、2つのコントローラまたは複数のコントローラの各々において異なるポリシー設定が行使されるような、2ステップまたは複数のステップの判定プロセスを提供する。
【0029】
一実施形態では、コントローラは、要求トークンが転送されるのを阻止し、それゆえ、要求トークンが許可された場合、どのコンシューマが保護リソースにアクセスするかまたはそれを使用するだろうか、要求トークンが許可された場合、どの保護リソースがアクセスされるかまたは使用されるだろうか、および、要求トークンが許可された場合、保護リソースがどう使用されるだろうかのうちの少なくとも1つに関するメッセージから抽出または収集された情報に基づいて、認証および許可プロセスの中断をもたらす。
【0030】
一実施形態では、メッセージがポリシー設定に適合しているかどうか判定するステップは、抽出するサブステップと判定するサブステップとを含んでいる。抽出するサブステップは、要求トークンの発信元であるコンシューマについての情報と、要求トークンを使ってそれに関する1つ以上の操作の許可が求められている保護リソースについての情報と、要求トークンを使って許可が求められている1つ以上の操作についての情報とのうち少なくとも1つをメッセージから抽出することを含んでいる。判定するサブステップは、抽出するサブステップにおいて抽出された情報がポリシー設定に適合しているかどうか判定することを含んでいる。
【0031】
本実施形態は、要求トークンを含むメッセージから推定されうる程度まで、プライバシ管理に関して要求トークンの重要性をコントローラが効果的に制御することを可能にする。メッセージから抽出された情報がポリシー設定に適合していなかった場合、要求トークンは、サービスプロバイダへ転送されるのを阻止される。
【0032】
要求トークンを含むメッセージをコントローラがインターセプトして検査することは、要求トークンの発信元であるコンシューマの特徴またはIDに関連してもよく、ここで一部のコンシューマまたはコンシューマのタイプもしくはグループは、信頼できないとみなされることがある。
【0033】
要求トークンを使ってそれに関する1つ以上の操作の許可が求められている保護リソースについての情報が、(メッセージがそのような保護リソースを識別するパラメータを含んでいるからか、または、要求トークンに関連する保護リソースのIDまたは保護リソースのタイプを導出することがメッセージの1つ以上の特性から可能になるからかのいずれかの理由で)メッセージから入手または抽出されることを条件として、メッセージの中間のインターセプトおよび検査は、保護リソースについてのそのような情報を抽出することを含んでいてもよい。メッセージが、機密情報(例えば、銀行についての詳細記述など)のように、特定の保護リソースまたは保護リソースのタイプに関する許可要求に相当する場合、要求トークンは、例えば、サービスプロバイダへ転送されるのを阻止されてもよい。
【0034】
一実施形態では、要求トークンを使ってそれに関する1つ以上の操作の許可が求められている保護リソースについての情報は、メッセージから入手または抽出することができる。
【0035】
要求トークンを使って許可が求められている1つ以上の操作についての情報がメッセージから入手または抽出されることを条件として、メッセージをインターセプトして検査するステップは、許可が求められている操作のそのような特性がポリシー設定に適合しているかどうか判定することを含んでいてもよい。
【0036】
一実施形態では、要求トークンを使って許可が求められている操作についての情報は、メッセージから入手または抽出することができる。
【0037】
一実施形態では、方法は、さらに、少なくとも1つのサービスプロバイダから、少なくとも1つのサービスプロバイダにおけるユーザIDに関連する保護リソースに関する情報を入手するステップを含んでいる。これは、サービスプロバイダからアクセスできる保護リソースの一覧をユーザが入手することを可能にする。これは、適切なプライバシ管理が実行されることを可能にする。
【0038】
本実施形態の或る下位実施形態では、少なくとも1つのサービスプロバイダにおけるユーザIDに関連する保護リソースに関してコントローラが入手できる情報は、少なくとも1つのサービスプロバイダにおけるユーザIDに関連する保護リソースの利用に関する情報を含んでいる。
【0039】
本実施形態は、ユーザがコントローラを通じて、ユーザのIDに関連する保護リソースの動的一覧を入手することを可能にする。それゆえ、コントローラは、その点で制御の中心点として動作する。
【0040】
入手可能な一覧は、ユーザが、どのようにして、および、いつ、すなわち、少なくとも或る期間内のいつ、保護リソースがどのコンシューマによって使われたかということに関する情報を入手できるという意味で、動的でありうる。このようにして、ユーザは、ユーザの保護リソースの利用についての情報を収集することができる。次いで、ユーザは、この知識に基づいて、コントローラの中のポリシー設定を修正するかどうか決定してもよい。ユーザからの明確な要求を受信した時点で、コントローラによって利用履歴の検索が行われてもよい。あるいは、コントローラが、ユーザとの最初の対話に基づいて、または、デフォルト設定に基づいて、ユーザIDに関連する保護リソースの利用履歴を検索するように構成されてもよい。
【0041】
ID、あるいは具体的にはユーザIDは、ユーザの特性の1つであり、ユーザを識別するかまたはユーザを識別するために何らかのかたちでユーザにマッピングされている。
【0042】
利用情報は、特に、保護リソースのタイプと、保護リソースへのアクセスのタイムスタンプと、IDリソースにアクセスするかまたはした、またはIDリソースを利用するかまたはしたコンシューマの識別子とのうち、1つ以上についての情報を含んでいてもよい。
【0043】
一実施形態では、方法は、さらに、受信されたメッセージおよびそれらの要求トークンが転送されるのを阻止されたかどうかと、受信された要求トークンおよびそれらが転送されるのを阻止されたかどうかと、受信されたメッセージおよびそれらの要求トークンが転送されるのを許可されたかどうかと、受信された要求トークンおよびそれらが転送されるのを許可されたかどうかとのうち少なくとも1つに関する情報を記録することを含んでおり、それを本書では履歴情報と呼ぶ。次いで、方法は、履歴情報をユーザ端末が利用できるようにするステップを含んでいる。
【0044】
一実施形態では、方法は、さらに、コントローラと通信することが可能なユーザ端末によって行われ、方法は、さらに、ユーザ端末が、コントローラの中にポリシー設定を設定することを含んでいる。
【0045】
また、本発明は、要求トークンを含むメッセージを受信するように構成された受信器を含むコントローラに関する。上記のように、要求トークンは、サービスプロバイダからの保護リソースにアクセスすることについてユーザに許可を求めるための、コンシューマによって用いられる値である。サービスプロバイダは、保護リソースへのアクセスを提供するように構成されたソフトウェアアプリケーションとウェブサイトとのうちの少なくとも一方である。コンシューマは、ユーザの代わりにサービスプロバイダにアクセスするように構成されたソフトウェアアプリケーションとウェブサイトとのうち少なくとも一方である。また、コントローラは、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するように構成された判定器と、メッセージがポリシー設定に適合していないと判定された場合、要求トークンが要求トークンに関連するサービスプロバイダへ転送されるのを阻止するように構成された転送器とを含んでいる。
【0046】
また、本発明は、コンピュータまたは上記のコントローラ上で実行された場合に、コンピュータまたはコントローラにそれぞれ、上記の方法を実行させるように構成された命令を含むコンピュータプログラムに関する。また、本発明は、そのようなコンピュータプログラムを含むコンピュータプログラムプロダクトまたはコンピュータ可読媒体に関する。
【0047】
次に、添付の図面と併せて、本発明の実施形態について説明する。
【図面の簡単な説明】
【0048】
【図1】本発明の一実施形態における方法のフローチャートである。
【図2】本発明の一実施形態における、コントローラと、その構成要素の一部とを略示する図である。
【図3】本発明の別の実施形態における方法のフローチャートである。
【図4】本発明の一実施形態における方法のフローチャートであって、ここで、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するステップは、メッセージから情報を抽出するサブステップと、抽出された情報がポリシー設定に適合しているかどうか判定するサブステップとを含んでいる。
【図5a】ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能である。
【図5b】ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能である。
【図5c】ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能である。
【図6a】ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能であり、このネットワーク構成は、いわゆるプロキシコントローラを含んでいる。
【図6b】ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能であり、このネットワーク構成は、いわゆるプロキシコントローラを含んでいる。
【図7】本発明の背景、および、本発明の実施形態によって対処される一部の問題の理解を深めることだけを目的にしてネットワーク構成を略示する図である。
【図8】本発明の一実施形態における方法を示す図である。
【図9】本発明の一実施形態における方法を示す図であり、特に、サービスプロバイダからアクセスできる保護リソースについての情報を入手するコンシューマとしてのコントローラの使用を示す図である。
【図10】本発明の一実施形態における方法を示す図であり、特に、保護リソースへのアクセスを管理するポリシー設定をコントローラにおいて設定する操作を示す図である。
【図11】本発明の一実施形態における方法を示す図であり、特に、サービスプロバイダの保護リソースにアクセスするためにコンシューマによって開始される許可手順を行う操作を示す図である。
【図12】本発明の一実施形態における方法を示す図であり、特に、保護リソースの利用の履歴をコントローラから入手する操作を示す図である。
【発明を実施するための形態】
【0049】
次に、本発明について、具体的な実施形態に関して記述しよう。留意されるであろうが、これらの具体的な実施形態は、当業者の理解を深めるのに役立つものであって、決して本発明の範囲を制限することは意図されておらず、本発明の範囲は、添付の請求項によって定義される。
【0050】
図1は、本発明の一実施形態における方法のフローチャートである。図1に示す方法は、コントローラ100によって行われる。
【0051】
最初に、コントローラ100が、ステップs10で、要求トークンを含むメッセージを受信する。メッセージは、サービスプロバイダ400からアクセスできる保護リソースにアクセスすることを求めるコンシューマ300から発信される。その文脈において、要求トークンは、保護リソースにアクセスするための要求を識別する値である。メッセージは、要求トークンに加えて、要求トークンに伴う各種の追加情報またはパラメータ、例えば要求トークンが発信されるコンシューマ300のID、コンシューマ300によって開始される許可要求の対象である保護リソース、および/または、保護リソースに関連してコンシューマ300によって許可が求められた操作などを含んでいてもよい。
【0052】
要求トークンを含むメッセージは、要求トークンを生成したコンシューマ300とは別の物理エンティティから来てもよい。すなわち、コンシューマ300とコントローラ100との間に、メッセージおよびその要求トークンがそこを通して転送される中間的物理エンティティが存在していてもよい。
【0053】
メッセージは、パケットでも、HTTP要求でも、いずれかのそれ以外の、要求トークンを搬送するための適切な形式の信号であってもよい。
【0054】
次いで、コントローラ100は、ステップs20で、受信されたメッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定する。
【0055】
ポリシー設定は、コントローラ100上に記憶されているかまたはコントローラ100がアクセスできるようになっており、コントローラ100が代理動作するユーザに関連する保護リソースに関係している。ポリシー設定は、図10に示すように、ユーザによって設定されてもよい。あるいは、または、それに加えて、プライバシ設定が、コントローラ100を起動する時にデフォルトで設定されてもよい。プライバシ設定の更新は、ユーザによって行われてもよいし、コントローラ100を設定するようにリモートで許可された第三者によって行われても、あるいはその両方によって行われてもよい。
【0056】
例えば、コントローラ100によって用いられることになるポリシー設定をユーザが事前に設定し、第1の特定のコンシューマ300、例えば「doesntcareaboutprivacy.com」や「sellsyourprivatedatato3rdparties.com」は、リソースが何であれ、また、リソースに関して行われることになる操作が何であれ、ユーザのいずれの保護リソースにもアクセスすることを許可されないということを示してもよい。また、ユーザは、別の特定のコンシューマ300、例えば「caresaboutprivacy.com」からのメッセージの中に見つかった要求トークンは、リソースに関して行われることになる操作が何であれ、保護リソースが例えば銀行の詳細情報であるかまたはソーシャルセキュリティ番号である場合、または、許可が求められた操作が一部の保護リソースの削除に存する場合に限って、転送されるのを阻止されるべきであることを示してもよい。
【0057】
ステップs20の結果として、メッセージがポリシー設定に適合していない場合(ステップs30)、メッセージは、ステップs34で、サービスプロバイダ400へ転送されるのを阻止される。転送の阻止は、例えば、メッセージを削除し、後で評価するためにメッセージの詳細についてコントローラ100の中にログを取り、そして、メッセージをインターセプトして転送しなかったことについてコンシューマ300に通知することによって行われてもよい。コンシューマ300へ送信された情報は、要求トークンを含むメッセージがなぜコントローラ100によって転送されるのを阻止されたのかについての詳細を含んでいてもよい。
【0058】
方法は、複数のネットワークエンティティに分散されたユーザの保護リソースのプライバシの側面を管理するためのユーザにやさしい効率的な解決策をエンドユーザに提供する。同時に、方法は、実装の影響を最小化する。ユーザは、ユーザが許可したい保護リソースの利用に制限を設定することを目的として、ユーザについての保護リソースを記憶している個々のサービスプロバイダをくまなく調べる必要はない。加えて、ユーザは、保護リソースにアクセスするためのコンシューマによる許可要求を認めたり拒否したりすることを求められてじゃまされる頻度が少なくなる。
【0059】
ステップs30で、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合していると判定された場合、メッセージは、転送されるのを阻止されてもされなくてもよい。例えば、コントローラ100がファイアウォールとしても動作する場合、コントローラ100は、他の理由でメッセージをブロックすることを決めてもよい。これは、メッセージが、保護リソースへのアクセスを管理するいずれのポリシー設定にも関係しない、何らかの添付「.exe」ファイルを含んでいるからであってもよい。
【0060】
メッセージがサービスプロバイダ400へ転送されるのをコントローラ100が阻止するその他の理由、すなわち、保護リソースへのアクセスを管理するポリシー設定に基づかないその他の理由があってもよい。別の例示的な理由は、コントローラ100がウェブブラウザと一体化されており、ブラウザ上ではHTTPのリダイレクションは可能にされていない/許されていないため、ブラウザが、メッセージが転送されるのを許さないということもありうる(この可能性は、参考文献[2]、セクション6.2.1に記載されている)。
【0061】
ステップs30で、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合していると判定され、その後メッセージが、サービスプロバイダ400へ転送されるのを阻止されなかった場合、この結果として、メッセージは、サービスプロバイダ400に直接転送されてもよい。あるいは、メッセージは、メッセージが最終的にサービスプロバイダ400へ転送される前に、別の決定プロセスを行う権利を有する別の物理エンティティへ転送されてもよい。これが起こり得る状況は、図6aに関して記述しよう。
【0062】
一実施形態では、2つ以上の要求トークンを含むメッセージが、コンシューマ300によって開始された許可プロセスに関与している。メッセージは、ポリシー設定をチェックされ、メッセージは、ポリシー設定に適合していない要求トークンだけがサービスプロバイダ400へ転送されるのを阻止されるように、コントローラ100によって修正されてもよい。
【0063】
図2は、本発明の一実施形態における、コントローラ100およびその一部の構成要素を略示する図である。コントローラ100は、要求トークンを含むメッセージを受信するように構成された受信器110を含んでいる。コントローラ100は、さらに、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するように構成された判定器120を含んでいる。ポリシー設定は、コントローラ100の中に記憶されてもよいし、コントローラ100からアクセス可能なデータベースもしくはメモリユニットの中に記憶されてもよい。メッセージがポリシー設定に適合していないとコントローラ100が判定した場合、転送器130は、メッセージがサービスプロバイダ400へ転送されるのを阻止する責任を持つ。
【0064】
図3は、本発明の一実施形態における方法のフローチャートである。図1のフローチャートに示すステップに加えて、図3に示す方法は、要求トークンがサービスプロバイダ400へ転送されるのを許可するステップs32を含んでいる。このステップs32は、ステップs30でメッセージがポリシー設定に適合していると判定された場合に起きる。言い換えると、図3に示す方法を行うコントローラ100は、メッセージがポリシー設定に適合していないと判定された場合に限って、要求トークンに関連するサービスプロバイダ400に要求トークンが転送されるのを阻止する。
【0065】
図4は、本発明の一実施形態における方法のフローチャートである。図1のフローチャートで示すステップに加えて、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するステップs20は、2つのサブステップを含んでいる。第1のサブステップs22は、メッセージから、
(i)要求トークンが許可された場合に保護リソースにアクセスしうるコンシューマ300についての情報と、
(ii)要求トークンが許可された場合にアクセスされうる保護リソースについての情報と、そして、
(iii)要求トークンが許可された場合に保護リソースに関して行われうる操作についての情報と、
のうち、少なくとも1つを抽出することに存する。
【0066】
メッセージから情報を抽出するサブステップs22は、メッセージを構文解析することを含んでいてもよい。
【0067】
第2のサブステップs24は、抽出された情報がポリシー設定に適合しているかどうかに基づいて要求トークンがサービスプロバイダ400へ転送されるのを阻止するかどうか判定することに存する。抽出された情報が、コントローラ100の中に記憶されたかまたはコントローラ100がアクセスできるポリシー設定に適合していなかった場合、コントローラ100は、要求トークンがサービスプロバイダ400へ転送されるのを阻止する。
【0068】
図5a乃至6bは、本発明の実施形態が適用されうる一部のネットワーク構成を示す。図5a乃至6bの各図には1つのコンシューマ300と1つのサービスプロバイダ400とだけを示しているが、2つ以上のサービスプロバイダ400と2つ以上のコンシューマ300とが提供されてもよい。同様に、1つのユーザ端末(すなわちUE)200だけがネットワークの他の構成要素と対話するように示しているが、2つ以上のユーザ端末200が関与してもよい。
【0069】
ユーザ端末200およびコントローラ100は通信してもよく、従ってコントローラ100はユーザ端末200が情報を利用できるようにすることができる。それに応じて、ユーザ端末200は、コンシューマ300から到着するメッセージを制御するためにコントローラ100によって用いられるポリシー設定を構成してもよい。ユーザがユーザ端末200を通じてコントローラ100の中にポリシー設定を設定することは、(例えばUE200上にある)コンピュータディスプレイ上に生成されたグラフィカルユーザインタフェースを用いて実施され、その結果、ユーザがポリシー設定を設定するためにユーザ端末と対話してもよい。コントローラ100は、ユーザのためのプライバシ代理人として動作する。
【0070】
図5a乃至6bに示すコンシューマ300またはコンシューマのウェブアプリケーション、および、サービスプロバイダ400またはサービスウェブアプリケーション(コンテナとも呼ばれることがある)は、一般に、少なくとも最初は、あるいはデフォルト動作としては、相互に信用していない。コンシューマ300とサービスプロバイダ400とは、連結による集中的手法をとらない。
【0071】
図5aは、本発明の一実施形態におけるネットワーク構成を略示する図であり、ここでコントローラ100とユーザ端末200とは、別個の物理エンティティである。ユーザ端末200はコントローラ100と通信することができる。コンシューマ300から要求トークンを含むメッセージを受信した時点で、コントローラ100は、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定する。ポリシー設定に適合していないメッセージは、サービスプロバイダ400へ転送されるのを阻止される。一方、ポリシー設定に適合しているメッセージは、サービスプロバイダ400へ転送されてもよい。そのようなかたちで、ポリシー設定が行使される。
【0072】
図5bは、本発明の一実施形態におけるネットワーク構成を示しており、ここで、図5aに関して記述したステップに加えて、コントローラ100は、ユーザ装置200すなわちユーザ端末200上で作動する。
【0073】
図5cは、本発明の一実施形態におけるネットワーク構成を略示する図であり、ここで、ユーザ端末200は、ユーザ端末200の上で作動するウェブブラウザ140を有している。ブラウザ140の動作は、少なくともある程度、コントローラ100によって制御されている。図5cではコントローラ100は、ブラウザ140を含むように描かれているが、コントローラ100は、ブラウザ140に到達するメッセージおよび要求のフローを制御するため、ブラウザ140と同時に作動してもよい。一実施形態では、コントローラ100は、ブラウザのアドオンを用いて実装される。
【0074】
コンシューマ300から発信されたメッセージが、コントローラ100によって受信される。メッセージは、ユーザ端末のウェブブラウザを要求トークンに関連するサービスプロバイダ400のアドレスにリダイレクトする(向けなおす)ための(または、本書では同じ意味であるが、向けるための)要求を含んでいる。コントローラ100が、リダイレクト要求は、保護リソースへのアクセスを管理するポリシー設定に基づいて、受け入れるのを阻止されるべきかどうか判定する。コンシューマ300が、最初にメッセージをコントローラ100へ送信し、次いで、コントローラ100によって行われる判定に応じて、コントローラ100が要求トークンをサービスプロバイダ400へ転送してもよい。
【0075】
その点において、図5cは、コントローラ100と、コントローラ100と通信できるユーザ端末200とを含むシステムを略示する図であるが、ここで、ユーザ端末200は、ウェブブラウザを作動するように構成され、メッセージは、ユーザ端末のウェブブラウザを要求トークンに関連するサービスプロバイダ400のアドレスへリダイレクトする(向けなおす)(または、向ける)ための要求を含んでいる。
【0076】
図6aは、本発明の一実施形態におけるネットワーク構成を示す図であり、ここで、コントローラ100は、プロキシコントローラ100である。メッセージをコンシューマ300から受信した時点で、メッセージがポリシー設定に適合していると判定された場合、メッセージおよびその要求トークンはユーザ端末200へ転送される。そうでない場合、メッセージはユーザ端末200へ転送されず、従って、要求トークンは、その後、要求トークンに関連するサービスプロバイダ400へユーザ端末200によって転送されるのを阻止される。言い換えると、コントローラ100は、ポリシー設定に従って必要であると判定された場合にメッセージをブロックすることによって、要求トークンがユーザ端末200によってサービスプロバイダ400へ転送されるのを阻止する。
【0077】
図6bは、本発明の一実施形態におけるネットワーク構成を略示する図であり、2つのコントローラ、すなわち、プロキシコントローラ100aとユーザ端末200上で作動するコントローラ100bとを含んでいる。コンシューマ300からのメッセージをプロキシコントローラ100aによって受信した時点で、プロキシコントローラ100aは、メッセージがポリシー設定に適合しているかどうか判定する。メッセージがポリシー設定に適合している場合、メッセージおよびその要求トークンは、コントローラ100bをホストするユーザ端末200へ転送される。そうでない場合、メッセージはユーザ端末200およびコントローラ100bへは転送されず、従って、要求トークンは、ユーザ端末200およびコントローラ100bによって要求トークンに関連するサービスプロバイダ400へ転送されるのを阻止される。
【0078】
メッセージおよびその要求トークンが、コントローラ100bをホストするユーザ端末200へ転送される場合、コントローラ100bは、コントローラ100bにとって適切であるポリシー設定に基づいて、メッセージの第2のインターセプトおよび検査を行う。
【0079】
図6bのネットワーク構成において、プロキシコントローラ100aは、例えば、ローカルネットワークアドミニストレータによって管理されてもよく、そして、ユーザ端末200上でホストされている他方のコントローラ100bは、例えばユーザ自身によって管理されてもよい。ここで、コントローラを管理するとは、コントローラに適用可能なポリシー設定を少なくとも設定できることを意味する。
【0080】
図7は、本発明の背景をさらに詳細に示すため、および、本発明によって解決される一部の問題の理解を深めるため、OAuthプロトコルによる認証および許可プロセスを略示する図である。しかし、本発明は、OAuthプロトコルへの適用に限定されない。
【0081】
OAuthプロトコルは、ユーザがユーザのサービスプロバイダ認証情報をコンシューマに開示することを必要とせず、(図7の「コンシューマ」と記されたボックスによって示す)コンシューマアプリケーションが(図7の「サービスプロバイダ」と記されたボックスで示す)サービスプロバイダの保護リソースにアクセスするのを可能にする。OAuthプロトコルは、保護リソースを求める要求の中で、ユーザの認証情報の代わりに、サービスプロバイダによって生成されるトークンを用いる。プロセスは2つのトークンタイプ、すなわち、要求トークンとアクセストークンとを用いる。要求トークンは、保護リソースへのアクセスを許可するようにユーザに求めるためにコンシューマによって用いられる。許可された要求トークンは、次いで、アクセストークンと交換される。アクセストークンは、ユーザの代わりに保護リソースにアクセスするためにコンシューマによって用いられる。
【0082】
やはり図7に関して、最初に、ユーザが何らかのかたちで、例えば、例示的なprinter.consumer.comのウェブサイト(コンシューマ)を自分のユーザエージェントを使って閲覧することによって、許可プロセスをトリガする(ステップA)。許可プロセスは、次いで、3つの連続ステップを含んでいる。
【0083】
(1)コンシューマが、未許可の要求トークンをサービスプロバイダから入手する(ステップB)。
【0084】
(2)ユーザが自分のユーザエージェントを用いて要求トークンを許可する。そうするために、最初に、コンシューマは未許可の要求トークンをユーザエージェントに送信し、それをユーザエージェントが、サービスプロバイダへ転送する(ステップC)。次いで、サービスプロバイダが、ユーザエージェントを通してユーザとの認証手順を始める(ステップD)。認証手順が成功したら、サービスプロバイダは、要求トークンを許可し、ユーザエージェントに許可された要求トークンを与え(ステップE)、それをユーザエージェントは、元のコンシューマへ転送する。認証手順が失敗したら、サービスプロバイダは、ユーザエージェントを通じて応答を転送する際に、要求トークンが無効化されたことをコンシューマに通知してもよい。
【0085】
(3)最後に、コンシューマは、その後でサービスプロバイダのユーザの保護リソースにアクセスすることを目的として、サービスプロバイダとの間で、許可された要求トークンをアクセストークンに交換(ステップF)する。
【0086】
OAuthプロトコルによれば、プライバシ管理はユーザ自身によって処理される。ユーザは、サービスプロバイダの保護リソースにアクセスするため、コンシューマを許可する。許可が与えられた後、コンシューマは、保護リソースにアクセスするためのアクセストークンを手に入れる。発明者らが特に認識していることだが、OAuthプロトコルはアクセストークンの有効期間についていかなる制限をも規定していないが、トークンが短期間有効である場合には、許可は、コンシューマが保護リソースへのアクセスを必要とする度に与えられる必要があるであろう。このように許可を繰り返し要求する必要があることは、面倒でありうる。
【0087】
また、発明者らがさらに特に認識していることだが、OAuthプロトコルは、コンシューマに対して認められるアクセス権をきめ細かくユーザが制御できるようにする方法は何ら考慮していない。代わりに、ユーザは、サービスプロバイダの中のユーザの保護リソース全部へのアクセスを所与のコンシューマに対して認めるか拒否するかである。
【0088】
また、発明者らがさらに特に認識していることだが、ユーザは、どの保護リソースをコンシューマが実際に要求しているのかが分からない。一旦コンシューマが許可されると、保護リソースにアクセスするための要求は、コンシューマとサービスプロバイダとの間の直接通信であり(図7のステップF)、ユーザは、どの保護リソースが現在使用されており、これまで使用されたのかを知る手段を持たない。
【0089】
ユーザは、ユーザIDに関連する保護リソースを記憶している各サービスプロバイダにおいてユーザのプライバシ設定を設定することができたであろう。しかし、プライバシ設定は、そもそも可能であればだが、サービスプロバイダ毎に明示的に記述される必要があるであろう。
【0090】
図8は、本発明の一実施形態におけるネットワーク構成と、この実施形態を行う際に含まれる通信フローとを略示する図である。
【0091】
両矢印「1」は、サービスプロバイダ400の中の保護リソースの存在についての情報をコントローラ100が検索することを示す。これは、いわゆる静的一覧検索であり、これについては図9に関して詳細に説明しよう。一旦コントローラ100がサービスプロバイダ400によって認証されると、コントローラ100は、所与のユーザに関連する保護リソースについての情報を入手するためにサービスプロバイダ400にクエリを行う。
【0092】
図9は、本発明の一実施形態を成す静的一覧検索を示す。本実施形態では、OAuthプロトコルが用いられる場合、コントローラ100は、OAuthコンシューマ300として動作または機能する。この目的で、コントローラ100は、目標のサービスプロバイダ400においてコンシューマ300として事前に登録されていてもよい。登録プロセスの間、サービスプロバイダ400は、コントローラ100にコンシューマ鍵とコンシューマ秘密とを提供する。これらの要素は、コントローラ100とサービスプロバイダ400との間の将来の通信に役立つものであり、コントローラ100がクエリを行うことを望んでいるサービスプロバイダ400について(ユーザ毎ではなく)一度だけ生成されうる。
【0093】
一旦コントローラ100がサービスプロバイダ400の中に登録されると、ユーザは、コントローラ100を用いてサービスプロバイダ400の中でユーザについて記憶された保護リソース(ユーザIDに関連する保護リソース)の静的な一覧を検索してもよい(ステップ0、「静的な一覧を示す」と記載された矢印)。コントローラ100は、サービスプロバイダ400から未許可の要求トークンを入手することによって動き始める(ステップ1、「未許可の要求トークンを入手する」)。次いで、許可プロセスが始まる(ステップ2、「要求トークンを許可する」)。この許可プロセスの間、サービスプロバイダ400は、ユーザが認証されることを必要とする(ステップ3a、「認証が必要とされる」)。このために、コントローラ100は、ユーザプロキシとして動作する。コントローラ100は、第1に、認証情報をユーザに要求し(ステップ3b、「認証プロセス」)、次いで、ユーザの認証情報を元のサービスプロバイダ400へ転送する(ステップ3c、「認証応答」)。この許可プロセスの最後に、コントローラ100が、許可された要求トークンを受信し(ステップ4、「許可された要求トークン」)、それをコントローラ100は、有効なアクセストークンと交換する(ステップ5、「アクセストークンを入手する」)。
【0094】
コントローラ100は、アクセストークンを用いて、サービスプロバイダ400において、サービスプロバイダ400でアクセス可能な保護リソースにアクセスする(ステップ6、「保護リソースを入手する」)。一旦サービスプロバイダ400がこの情報を開示すると、コントローラ100は、それをユーザに提示する(ステップ7、「利用可能な情報」)。
【0095】
一実施形態では、ユーザは、例えば情報の追加、更新、削除といった、保護リソースに関するさらなる管理操作を行う機会を提供されてもよい。
【0096】
図9で示す「静的一覧検索」の実施形態が、OpenSocialおよびOAuthプロトコルの文脈で用いられてもよい。OpenSocialは、ウェブベースのソーシャルネットワーキングアプリケーションがそれらのソーシャルデータを共有するのに役立てるため、アプリケーションプログラミングインタフェース(API)のセットを提供しており、米国のサンフランシスコに拠点を置くOpenSocial Foundation(http://www.opensocial.org/を参照のこと)によって維持されている。OpenSocial Specification v0.9は、2009年10月時点で、
http://opensocial.org/Technical−Resouces/opensocial−spec−v09/OpenSocial−Specification.htmlで入手可能である。
【0097】
ステップ1、2、3、4、5(図9に示す)は、OAuthプロトコル(参考文献「2」)に従ってもよい。しかし、ユーザが各サービスプロバイダ400を繰り返し認証する(ステップ3b)必要性を回避するため、コントローラ100は、ユーザの保護リソースをキープまたは維持する各サービスプロバイダ400にユーザの認証情報を記憶してもよい。有利には、これはシングルサインオン手順を提供する。また、ステップ6は、OpenSocial Specification v0.9に記述されたプロトコルに従ってもよい。
【0098】
図10は、本発明の一実施形態における、ユーザ、またはユーザ端末による、コントローラ100におけるプライバシ設定の管理を略示する図である。特に、プライバシ設定管理に含まれうる通信を示す。
【0099】
ユーザが、自分の保護リソースの使用と開示とを管理するためにプライバシ選好を設定したいと望む。コントローラ100は、多様な選択肢をユーザに示し、例えば保護リソースがアクセスされうる、すなわち使用または開示されうる条件のような、多様なパラメータを、ユーザが構成できるようにする。完了したならば、コントローラ100は、結果としてのポリシー設定を記憶する。その後、コンシューマ300が保護リソースにアクセスするための許可を必要とする度に、コントローラ100は、ユーザの選好、すなわちポリシー設定を行使する。
【0100】
ユーザは、自分の保護リソースへのアクセスに関する自分の選好を設定できることで、利益を得る。このために、ユーザは、コントローラ100の中にプライバシ選好を設定し、その後、コントローラ100は、これらのプライバシ選好を行使する。
【0101】
ポリシー設定の定義に加わる変数には、要求者(リクエスタ)、リソース、操作、パーミッションなどが含まれうる。ユーザは、コントローラ100のユーザなのだから、ポリシー設定の中にユーザが明示的に記述されなくてもよい。ただし、ユーザが記述されてもよい。
【0102】
要求者は、ユーザの保護リソースにアクセスしようとするいずれかのコンシューマ300であってもよい。
【0103】
リソースは、ポリシー設定規則に関係している保護リソースの識別子であってもよい。例えば、OpenSocialは、例えば人物や行動といった、標準的な保護リソースについての具体的なフォーマットを定義している。サービスプロバイダ400の静的な一覧が検索された場合、コントローラ100は、この情報を用いて、リソースに関連する見込まれる値を減らし、一層きめ細かいポリシーを提供しうる。
【0104】
操作の値は、いずれかのコンシューマ300が要求することができる操作であってもよく、例えば、OpenSocialの例では、それらは「クエリを行う」、「作成する」および「削除する」であってもよい。しかし、本発明の一実施形態は、ポリシー設定規則に従いうるいずれかの数またはタイプの操作に限定されない。
【0105】
パーミッションは、「認める」、「拒否する」または「アスク・ミー(askMe)」(ユーザが実施毎に決定することを望む場合;これはアドホック・インタラクション・サービス、すなわちブラウザにおけるポップアップ、SMSベースの許可などを使って実施されうる)に設定されてもよい。また、解決策の使い勝手を向上させるため、一部の選択肢(ワイルドカード)、すなわち、「すべての見込まれる値」、「全くなし」または「ユーザが選択した具体的な部分集合」、が導入されてもよい。
【0106】
これらの値は、ユーザによって設定され、コントローラ100に提出される(図10、ステップ0、「プライバシ選好を設定する」)。結果として、ユーザおよびユーザの保護リソースに関する新たなポリシー設定規則が作成され、コントローラ100の中に記憶される(ステップ1、「プライバシ選好を記憶する」)。ポリシー設定プロセスは、それに関して情報が開示されうるさらなる条件の明細を使って拡充されてもよい。
【0107】
ユーザは多様な手段を通じて自分のプライバシ選好を表現する機会を与えられてもよい。第1に、ユーザは複数の定義済のプライバシポリシーの中から1つを選び、それを保護リソースに関連付けてもよい。これらの定義済プライバシポリシーは、技術的知識のないユーザも理解できるように、自然言語で記述されてもよい。この自然言語記述は、プライバシポリシー表現言語として記述される具体的なポリシー実装にマッピングされる。これらのポリシーはユーザがそれらを比較して自分のニーズにもっと合致するものをより容易に選べるよう、階層的になっている。ユーザはポリシーの詳細を扱う必要がないことから、この手法には、モデルの単純性と使い勝手という強みがある。
【0108】
また、ユーザは、プライバシポリシーの詳細の各々を定義することができてもよい。この手法は、ユーザ選好の記述に与える柔軟性が大きくなるが、使い勝手については若干のリスクを生じさせることがある。上級ユーザだけがポリシーの意味を理解する(そして多分、知ることを望む)ことがありえる。これは、上級選択肢として提供されてもよい。
【0109】
次に、本発明の一実施形態におけるプライバシポリシーの行使について、図11に関して説明しよう。
【0110】
コンシューマ300が、保護リソースにアクセスすることを望む。保護リソースは、コントローラ100の中にユーザによって設定されたポリシー設定によって管理される。コントローラ100は、ポリシー設定を行使し、それゆえ、サービスプロバイダ400の保護リソースにコンシューマ300がアクセスすることを可能にするであろう許可されたトークンの返信をコンシューマ300が受信できるかどうか間接的に決定する。
【0111】
コンシューマ300は、ユーザの代わりに働いてもよい。ゆえに、両者間にすでにHTTP接続が確立されていてもよい。
【0112】
コンシューマ300は、保護リソースをホストするサービスプロバイダ400から未許可の要求トークンを入手することによってプロセスを開始する(図8、「B」と記載された矢印)。このステップの一部の実装は、OpenSocialおよびOAuth仕様によって定義されている。
【0113】
次に図11を参照するが、コンシューマ300が、OAuth許可プロセスを開始する。第1に、コンシューマ300が、許可のために(ステップ0、「要求トークンを許可する」)ユーザエージェントをサービスプロバイダ400にリダイレクトするHTTPメッセージを、ユーザエージェント(ユーザエージェントは、例えば、コントローラ100が実行されうる操作環境にあるブラウザであってもよい)に送信する。コントローラ100は、このメッセージを捕捉し、あるいは言い換えればインターセプトして、ポリシー行使のための一部の関連情報を抽出する(ステップ1、「ポリシー行使」)。特に(以下は、網羅的でないリストである)、OAuthプロトコルが用いられる場合、要求者、あるいはコンシューマ識別子が、oauth_callbackと呼ばれるOAuthパラメータから抽出されてもよい。OAuthプロトコルは、他の情報、すなわち、コンシューマ300がそれに関して許可を望んでいる保護リソースおよび操作をどのように検索するかを定義していない。しかし、OAuthプロトコルは、追加のパラメータがサービスプロバイダ400によって定義されうることを述べている。
【0114】
本発明の一実施形態は、この可能性を利用して、OAuth許可メッセージが含みうる2つの新たなパラメータ、oauth_requested_resourceおよびoauth_requested_operationを定義する。これらのパラメータが許可要求の中に含まれていない場合、コントローラ100は、コンシューマ300が、サービスプロバイダ400においてアクセス可能なすべての保護リソースにクエリを行い、修正し、削除しようとしていると想定してもよい。従って、コントローラ100は、この想定に基づいて、適宜にポリシー設定を行使してもよい。
【0115】
一旦ポリシー設定が行使され、行使の結果が「可能」(すなわち、「転送することが可能」)となったならば、コントローラ100は、プロセスを続行する。すなわち、コントローラ100は、最初の「許可」要求トークンメッセージをサービスプロバイダ400へ転送する(ステップ2、「要求トークンを許可する」)。次いで、サービスプロバイダ400は、ユーザの認証手順をユーザエージェントを通じて開始する(ステップ3a、「認証が必要とされる」)。この文脈では、認証は、アサートされたユーザのIDを、指定されたかまたは了承された信頼レベルで確認するプロセスである。
【0116】
一実施形態では、その段階で、コントローラ100は、メッセージを再び捕捉する。認証に必要な認証情報は、「静的一覧検索」のシナリオにおいて記憶されていてもよいため、ユーザが自分に同意を求めなければならないと明示的に記述していない限り、ステップ3b(サービスプロバイダ400においてユーザの認証情報を入手することを含めて、図9を参照のこと)は、必要ない。
【0117】
コントローラ100は、認証応答を送信する(ステップ3c、「認証応答」)。その結果、サービスプロバイダ400は、許可された要求トークンを返信し(ステップ4、「許可された要求トークン」)、コントローラ100は、それをコンシューマ300へ転送する(ステップ4b、「許可された要求トークン」)。次いでコンシューマ300は、サービスプロバイダ400において、許可された要求トークンをアクセストークンと交換し、次いで、保護リソースおよび必要な操作にアクセスしてもよい(ステップ5,6,7)。
【0118】
行使プロセス(ステップ1)の結果が「拒否する」である場合、コントローラ100は、メッセージをコンシューマ300へ返信し、拒否についてかまたは拒否の詳細についてコンシューマ300に通知してもよい。
【0119】
図11に関して記述したプロセスは、以下のように、OAuthプロトコル(参考文献[1])に基づいていてもよい。
【0120】
一実施形態では、コントローラ100は、ユーザおよびユーザのユーザエージェントの代理となる。すなわち、ユーザおよびユーザのユーザエージェントは、コンシューマ300からの要求が受信された場合、認証のいかなる通知も受信しない。許可プロセスは暗示的である。ユーザ定義のポリシー設定は、ユーザからの介在なしにコントローラ100によって適用される。
【0121】
一実施形態では、OAuthプロトコルへの拡張が行われる。すなわち、2つの追加パラメータ、oauth_requested_resourceおよびoauth_requested_operation(当然、これらのパラメータに別の名前が付けられてもよい)が、許可を求めるすべての要求に、すなわち、要求トークンを含むすべてのメッセージに、含まれてもよい。OAuthプロトコルは、これらの拡張を可能にする。
【0122】
一旦ユーザまたはユーザの代わりにコントローラ100が、要求トークンを許可したならば、要求トークンは、アクセストークンと交換することができる。アクセストークンは、ユーザに関連し、かつ、サービスプロバイダ400からアクセス可能な保護リソースに関する操作を行う特権をコンシューマ300に認める。
【0123】
以前の実施形態において定義されたOAuthプロトコルへの拡張が実施された場合、従って、コンシューマ300が要求トークンの中で(追加パラメータを用いて)どの情報および操作が要求されているかを宣言する場合、一実施形態では、コンシューマ300がその当初の許可を求める要求の中で宣言したことだけに限ってサービスプロバイダ400がコンシューマ300に特権を認めるかたちで、OAuthプロトコルが拡張されてもよい。これは、許可プロセスに一貫性と信用とを与える。
【0124】
一実施形態では、サービスプロバイダ400が保護リソースのコンシューマ300に、コンシューマ300はアクセスすることが許可されていることを通知する。サービスプロバイダ400は、アクセストークンを開示している間に送信される追加パラメータを用いて、コンシューマ300に通知する。
【0125】
図12に関して記述した一実施形態では、動的一覧検索機能が実装される。コントローラ100が、サービスプロバイダ400の中のユーザの保護リソースの静的一覧を検索していたと仮定しよう。
【0126】
さらに、コンシューマ300が、ユーザに関連する一部の保護リソースにアクセスしようとしたと仮定しよう。今、ユーザは自分に関連する一部の保護リソースの利用履歴を知りたいと望んでいる。この目的で、ユーザは、要求をコントローラ100に送信する(ステップ0、「利用履歴を入手する」)。コントローラ100は、要求されたデータを検索し(ステップ1、「利用履歴を検索する」)、次いで、それがユーザに提示される(ステップ2、「利用履歴の詳細」)。
【0127】
動的一覧検索機能は、以下のように使用可能にされてもよい。コンシューマ300が、ユーザに関連する保護リソースへのアクセスを要求する度に、このイベントがコントローラ100によってログがとられる。コントローラ100は、コントローラ100がポリシー設定を行使した後に、この情報のログをとってもよい。ゆえに、ポリシー行使の結果に関する情報は、ログに追加されてもよい。この情報は、例えば、将来の監査のために用いられてもよい。
【0128】
提示された情報には、要求された保護リソースと、アクセスのタイムスタンプと、情報を記憶したサービスプロバイダ400と、情報にアクセスしたコンシューマ300と、ポリシー行使の結果とについての詳細が含まれてもよい。情報は、コンシューマ300によって送信されるメッセージの中に含まれる多様なパラメータから抽出されてもよい。入手可能であれば、さらなる条件、例えば、コンシューマ300によって行われたプライバシの約束、あるいは、情報を開示した時点でサービスプロバイダ400によって課される条件が提示されてもよい。
【0129】
コントローラ、サービスプロバイダ、コンシューマおよびユーザ端末を含めて本発明による物理エンティティは、コンピュータプログラムが物理エンティティ上で実行される場合、本発明の実施形態によるステップおよび手順が行われるような命令を含むコンピュータプログラムを含んでいるかまたは記憶していてもよい。また、本発明は、本発明による方法を行うためのコンピュータプログラム、および、本発明による方法を行うためのコンピュータプログラムを記憶するいずれかのコンピュータ可読媒体に関する。
【0130】
「受信器」、「判定器」、「転送器」、「取得器」、「記録器」、「開示器」という用語が本書で用いられている場合、これらの要素がどのようにして分散され、要素がどのようにして集結されるかに関して、制限はない。すなわち、これらの要素の構成部分は、意図された機能を実現するための異なるソフトウェアもしくはハードウェアコンポーネントもしくはデバイスとして分散されてもよい。また、複数の別個の要素が、意図された機能性を提供するために集結されてもよい。
【0131】
コントローラの上記の要素のいずれか1つが、ハードウェア、ソフトウェア、フィールドプログラマブルゲートアレー(FPGA)、特定用途向け集積回路(ASIC)、ファームウェア等の中に実装されてもよい。同じことは、ユーザ端末、コンシューマ、サービスプロバイダにも適用される。
【0132】
本発明の別の実施形態において、上記の「受信器」、「判定器」、「転送器」、「取得器」、「記録器」、「開示器」のいずれか1つが、「受信器」、「判定器」、「転送器」、「取得器」、「記録器」、「開示器」の機能を行うための、受信手段、判定手段、転送手段、取得手段、記録手段、開示手段によってそれぞれ置換されるか、または、受信ユニット、判定ユニット、転送ユニット、取得ユニット、記録ユニット、開示ユニットによってそれぞれ置換されてもよい。
【0133】
本発明の別の実施形態において、上記のステップのいずれか1つが、いずれかの種類のコンピュータ言語での、例えばコンピュータが理解可能な手順、方法等の形式の、および/または、ファームウェア、集積回路等の上の内蔵ソフトウェアの形式の、コンピュータ可読命令を用いて実装されてもよい。
【0134】
本発明を詳細な例に基づいて記述してきたが、詳細な例は、当業者の理解を深める働きをするだけであって、本発明の範囲を限定することは意図されていない。そうではなく、本発明の範囲は、添付の請求項によって定義される。
【技術分野】
【0001】
本発明は、コンピュータまたは通信ネットワーク内の保護リソースへのアクセスの管理と、そのようなリソースの利用とに関する。特に、本発明は、そのようなアクセス管理を行うために物理エンティティによって行われる方法と、そのために構成された物理エンティティとに関する。また、本発明は、コンピュータ上で実行される場合に、コンピュータに上記の方法を行わせるように構成された命令を含むコンピュータプログラムにも関する。本発明は、特に、コンピュータネットワーク内のユーザに関連するリソースを用いるウェブサービスの文脈で適用されうるものであり、ここで、リソースは、2つ以上のウェブアプリケーションまたはウェブサイト上に分散されている。
【背景技術】
【0002】
コンピュータまたは通信ネットワークにおいて、多様なウェブサイトまたはウェブアプリケーションが、ユーザの利益のために多様なサービスを提供することがある。例えば、1つのウェブサイトまたはウェブアプリケーションが、ユーザの電子メールアカウントを管理してもよい。別のウェブサイトまたはウェブアプリケーションが、ユーザのソーシャルネットワークのメンバと写真を共有するための写真のストレージを可能にしてもよい。別のウェブサイトまたはウェブアプリケーションが、ユーザの書店アカウントを管理する書店として動作してもよい。別のウェブサイトまたはウェブアプリケーションが、画像および写真の印刷を提供し、それらをユーザに配達してもよい。可能性は無限にある。
【0003】
けれども、ウェブサイトおよびウェブアプリケーションが、「他のサイトからの機能性も一緒に結合する」新しいサービスを提供したいと望むこともある(Eran Hammer−Lahav、“Explaining OAuth”、2007年9月5日、http://hueniverse.com/2007/09/explaining−oauth/−2009年9月15日検索、本書では参考資料[1]と呼ぶ)。例えば、(例示的なウェブサイト「printer.consumer.com」のような)デジタルフォトラボ印刷ウェブアプリケーションが、ユーザがそこのアカウントを有する(例示的なサイト「photos.container.com」のような)デジタル画像ホスティングウェブサイトの中に記憶されている写真を、これらの写真を印刷してユーザに配達することを目的として、ユーザの代わりに、検索したいと望むことがある。
【0004】
多様なウェブサイトおよびウェブアプリケーションからの保護リソースを統合するウェブサービスを実装することを目的として、本書では「コンシューマ」と呼ぶ第1のウェブサイトまたはウェブアプリケーションが、本書では「サービスプロバイダ」と呼ぶ(コンシューマもサービスを提供するのだが)第2のウェブサイトまたはウェブアプリケーションにアクセスするために、ユーザの認証情報を提供するようユーザに求めることがある。上記の例では、コンシューマはデジタルフォトラボ印刷ウェブアプリケーションであり、サービスプロバイダはデジタル画像ホスティングウェブサイトであり、保護リソースはユーザの個人的写真であろう。言い換えると、コンシューマがサービスプロバイダにアクセスするために、ユーザのユーザ名とパスワードとを提供するようユーザに求めることがある。しかし、これによって、ユーザのパスワードが秘密でなくなり、誰か他の人が、サービスプロバイダの中で、ユーザのアカウントに関連する任意の動作のためにそのパスワードを使用することが可能になる(例えば「あなたのパスワードを変更してあなたを締め出すことすら」、参考文献[1]のセクション「what is it For(それは何のためか)」)。
【0005】
この問題を解決するため、OAuthプロトコルが開発された(Atwood,M.他“OAuth Core 1.0 Revision A”、2009年6月24日、http://oauth.net/core/1.0a−2009年9月15日検索、本書では参考文献[2]と呼ぶ)。OAuthプロトコルは、ウェブサイトまたはウェブアプリケーションすなわちコンシューマが、ユーザのサービスプロバイダ認証情報をユーザがコンシューマに開示することを必要とせず(参考文献[2]、Abstract)、別のウェブサイトまたはウェブアプリケーションすなわちサービスプロバイダからの保護リソースにアクセスすることを可能にする。OAuthプロトコルは、アプリケーション・プログラミング・インターフェース(API)のアクセス委譲プロトコルとみなされてもよい。参考文献[1]のセクション「what is it For(それは何のためか)」で説明された従者の鍵のたとえは、OAuthプロトコルの目的を直感的に理解するのに役立ちうる。
【0006】
OAuthプロトコルでは、認証、すなわち「ユーザが、ユーザの認証情報をコンシューマと共有することなく、ユーザの保護リソースへのアクセスを認めるプロセス」(参考文献[2]、「6.Authenticating with OAuth(OAuthを使った認証)」)は、以下のように機能する。
【0007】
コンシューマが、未許可の要求トークンをサービスプロバイダから入手する。コンシューマは、サービスプロバイダのユーザ許可URL(「URL」は「Uniform Resource Locator」のこと)を用いてユーザのウェブブラウザを介してユーザをサービスプロバイダへと向ける。次いでユーザは、サービスプロバイダを使って自分自身を認証する。言い換えると、ユーザは、サービスプロバイダのウェブサイトにサイン・インする。ユーザは、決して自分のサービスプロバイダ認証情報をコンシューマに提供するのではない。
【0008】
次いでサービスプロバイダは、コンシューマが保護リソースへのアクセスを認められるようになることについてユーザが同意するかどうかを、ユーザに尋ねる。そうするため、サービスプロバイダは、コンシューマがアクセスすることを望む保護リソースについての情報を、ユーザに提示する。情報は、要求されたアクセスの持続時間とアクセスのタイプとを含んでいる(例えば、保護リソースをコピーする、修正する、削除する)。情報は、例えば、「このウェブサイト<consumer−name>は、これから1時間の間、あなたの個人的な写真へのアクセスを要求しています。そのようなアクセスを承認しますか?」というような例示的なメッセージと共に、サービスプロバイダのウェブサイトのウェブページ上に提示されてもよい。次いでユーザは、ユーザの代理としての想定されるアクセスをコンシューマに与えるための、サービスプロバイダについての許可を、認めるかまたは拒否する。
【0009】
ユーザが同意した場合、要求トークンは許可され、ユーザはコンシューマへ戻るように導かれ、その結果、コンシューマは、要求トークンが許可されたことを通知される。次いで、許可された要求トークンはアクセストークンと交換され、コンシューマはユーザに代わって保護リソースにアクセスすることができる。ユーザが許可を拒否した場合、コンシューマは、要求トークンが無効化されたことを通知される。
【0010】
OAuthプロトコルを用いた認証プロセスの一例が、Eran Hammer−Lahav、“Beginner’s Guide to OAuth−Part II;Protocol Workflow”、2007年10月15日、http://hueniverse.com/2007/10/beginners−guide−to−oauth−part−ii−protocol−workflow/−2009年9月15日検索、に提示されている。
【0011】
ユーザにかかる操作上の負荷を軽減する必要性を念頭に置けば、本書ではコンシューマと呼ぶウェブサイトまたはウェブアプリケーションが、本書ではサービスプロバイダと呼ぶ他のウェブサイトまたはウェブアプリケーション上にあるユーザに関連する保護リソースに対してユーザに代わって行うアクセスを管理するための方法、物理エンティティおよびコンピュータプログラムを改善することが望ましい。
【発明の概要】
【0012】
これらの目的に合致または少なくとも部分的に合致するため、独立請求項において方法、コントローラ、およびコンピュータプログラムが定義される。有利な諸実施形態が、従属請求項において定義される。
【0013】
一実施形態では、コントローラによって行われる方法を提供する。方法は、要求トークンを含むメッセージを受信するステップを含む。要求トークンは、サービスプロバイダからの保護リソースにアクセスすることについてユーザに許可を求めるための、コンシューマによって用いられる値である。サービスプロバイダは、保護リソースへのアクセスを提供するように構成されたソフトウェアアプリケーションとウェブサイトとのうちの少なくとも一方である。コンシューマは、ユーザの代わりにサービスプロバイダにアクセスするように構成されたソフトウェアアプリケーションとウェブサイトとのうち少なくとも一方である。方法は、さらに、メッセージが、保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するステップと、メッセージがポリシー設定に適合していないと判定された場合には、要求トークンが要求トークンに関連するサービスプロバイダへ転送されるのを阻止するステップとを含む。
【0014】
コントローラは物理エンティティであって、コントローラの機能を実行するためにコンピュータプログラムもしくはハードウェア回路部を含んでいてもよい。コントローラは、例えば、サーバコンピュータまたはユーザ端末と一体化されていてもよい。コントローラは、要求トークンを含むメッセージを受信し、次いで、メッセージがポリシー設定に適合しているかどうかチェックするように構成される。メッセージがポリシー設定に適合していない場合、要求トークンは、サービスプロバイダへ転送されるのを阻止される。結果として、ユーザは、サービスプロバイダの許可ページに、不必要に導かれることはない。この許可ページでは、ここへユーザが導かれた場合には、ユーザは、サービスプロバイダからアクセスできる保護リソースへのアクセスを認めるか拒否するかを決めるように求められることになる。
【0015】
保護リソースへのアクセスを管理するポリシー設定すなわちポリシー規則は、メッセージがポリシー設定に適合していない場合に保護リソースへのアクセスを拒否するコントローラが行使するように、事前に確立されている。メッセージがポリシー設定に適合していない場合、メッセージが受信された時点でユーザが介入することを必要とせず、コントローラによってアクセス拒否が実施される。
【0016】
言い換えると、コントローラが要求トークンも含めてメッセージをインターセプトし、メッセージに関連する許可要求およびその要求トークンのタイプに応じて、コントローラが、認証および許可プロセスを中断するかどうか決定する。コントローラは、要求トークンが転送されるのを阻止し、従って、要求トークンが許可されていた場合に発生する可能性があったことに関してメッセージから抽出または収集された情報に基づいて、認証および許可プロセスを中断する。
【0017】
これによってユーザは、メッセージが受信された時点で、場合によっては、すなわち、メッセージがポリシー設定に適合していないとコントローラが判定した場合には、サービスプロバイダと対話しなければならないことから解放される。
【0018】
ゆえに、方法は、特に、ユーザにかかる操作上の負荷を軽減することによって、コンピュータまたは通信ネットワークにおけるプライバシ管理を改善し、円滑化する。ユーザの観点から見たプライバシ管理とは、サービスプロバイダ上に記憶されるかサービスプロバイダによって提供されるかまたはサービスプロバイダからアクセスできてかつユーザに関連するどの保護リソースに、所与のコンシューマがアクセスできるのかできないのか、そしてそれはどのようにして行われるのかを、ユーザが、またはユーザの利益のために、制御することに存するタスクである。また、プライバシ管理には、例えば、ユーザの保護リソースに関連して行われうる操作に関して、ユーザの選好に合わせたかたちでの、ユーザの保護リソースの適切な処理が含まれる。
【0019】
また、ユーザにかかる操作上の負荷を軽減すること以外にも、本実施形態は、一部の保護リソースへのアクセスをユーザがうっかり認めてしまうことを含みうる人為的なミスのリスクを削減する。
【0020】
メッセージとは、情報の単位であって、通信チャネル経由またはネットワーク経由で送信されることができ、かつ、要求トークンと、もしあれば関連のパラメータとを搬送しうるものである。また、メッセージは、要求と呼ばれることもある。
【0021】
ユーザとは、そのIDが認証されうる人間または人間のグループであるかまたは、そのIDが認証されうる物理エンティティ、例えばユーザ端末もしくはユーザ装置である。言い換えると、本書で「ユーザ」という用語が用いられる場合、それは、実際のエンドユーザ、すなわち人間または人間のグループと、IDが与えられうるユーザ端末またはユーザ装置とのうちのいずれか一方あるいは両方を指してもよい。さらに、ユーザ端末が、(例えば異なるユーザプロフィールに関連して)複数のIDを用いて動作することができる場合、ユーザ端末がその下で動作しうる各IDは、本発明の文脈では1人のユーザに対応してもよい。
【0022】
それゆえ、本書では「ユーザ」という用語は、適切な場合には、ユーザ装置またはユーザ端末をも包含する。例えば、認証に関して、ユーザ装置は、人間の介在がなくても認証手順を行うように構成されてもよい。これは、特に、ユーザという用語が、一般に、人間または人間のグループとしてのユーザと、或る人間によって用いられるユーザ装置とのうちのいずれか一方または両方を指す理由である。
【0023】
保護リソースとは、ユーザのユーザIDまたはユーザのグループに関連するIDグループに関するデータか、あるいは、ユーザのIDまたはユーザのグループに関連するIDグループに関連するサービスかのいずれか一方である。保護リソースの例には、個人的な写真、オンラインアドレス帳の中の連絡先、オンライン・ソーシャル・ネットワークにおける友人リスト、ブックマークのリスト、オンライン・ソーシャル・ネットワーク・アカウントの中に記憶された好きな曲のリスト、オンラインストアから最近購入した商品のリスト、サーバまたはブログ等にあるデータを保存するか公開するかの可能性等が含まれる。保護リソースには、保護ソーシャル情報が含まれてもよい。
【0024】
保護リソースへのアクセスまたはその利用は、上記のように、サービスの利用に存していてもよい。その文脈において、サービスの提供とは、例えば販売を通じての物理的商品の所有や、コンピュータ構成の技術特性の変更などをもたらす結果となる、技術的および経済的活動である。サービスはウェブサービスであってもよい。
【0025】
本発明は、ウェブベースのソーシャルネットワークサービスと共に用いられてもよいが、それらに限定されない。同様に、本発明は、OAuthプロトコルまたはOAuthプロトコルから導出されたプロトコルを用いてもよいが、それに限定されない。本発明は、他の文脈において、また、他のプロトコルと共に用いられてもよい。
【0026】
一実施形態では、方法はさらに、メッセージがポリシー設定に適合していると判定された場合、要求トークンが要求トークンに関連するサービスプロバイダへ転送されることを許可するステップを含んでいる。すなわち、コントローラは、要求トークンの転送に反対する、他の障壁を維持しない。
【0027】
本実施形態の或る下位実施形態では、その後、要求トークンは、コントローラによって直接サービスプロバイダへ転送される。
【0028】
本実施形態の別の下位実施形態では、その後、要求トークンは中間的物理エンティティへ転送され、次いで、そこから要求トークンは、要求トークンに関連するサービスプロバイダへ転送される。そのような中間的物理エンティティまたはコンピュータプログラムは、ユーザ端末であってもよいし、ユーザ端末上で実行されるブラウザであってもよい。また、中間的物理エンティティまたはコンピュータプログラムは、それ自体がコントローラとして動作してもよい。これは、2つのコントローラまたは複数のコントローラの各々において異なるポリシー設定が行使されるような、2ステップまたは複数のステップの判定プロセスを提供する。
【0029】
一実施形態では、コントローラは、要求トークンが転送されるのを阻止し、それゆえ、要求トークンが許可された場合、どのコンシューマが保護リソースにアクセスするかまたはそれを使用するだろうか、要求トークンが許可された場合、どの保護リソースがアクセスされるかまたは使用されるだろうか、および、要求トークンが許可された場合、保護リソースがどう使用されるだろうかのうちの少なくとも1つに関するメッセージから抽出または収集された情報に基づいて、認証および許可プロセスの中断をもたらす。
【0030】
一実施形態では、メッセージがポリシー設定に適合しているかどうか判定するステップは、抽出するサブステップと判定するサブステップとを含んでいる。抽出するサブステップは、要求トークンの発信元であるコンシューマについての情報と、要求トークンを使ってそれに関する1つ以上の操作の許可が求められている保護リソースについての情報と、要求トークンを使って許可が求められている1つ以上の操作についての情報とのうち少なくとも1つをメッセージから抽出することを含んでいる。判定するサブステップは、抽出するサブステップにおいて抽出された情報がポリシー設定に適合しているかどうか判定することを含んでいる。
【0031】
本実施形態は、要求トークンを含むメッセージから推定されうる程度まで、プライバシ管理に関して要求トークンの重要性をコントローラが効果的に制御することを可能にする。メッセージから抽出された情報がポリシー設定に適合していなかった場合、要求トークンは、サービスプロバイダへ転送されるのを阻止される。
【0032】
要求トークンを含むメッセージをコントローラがインターセプトして検査することは、要求トークンの発信元であるコンシューマの特徴またはIDに関連してもよく、ここで一部のコンシューマまたはコンシューマのタイプもしくはグループは、信頼できないとみなされることがある。
【0033】
要求トークンを使ってそれに関する1つ以上の操作の許可が求められている保護リソースについての情報が、(メッセージがそのような保護リソースを識別するパラメータを含んでいるからか、または、要求トークンに関連する保護リソースのIDまたは保護リソースのタイプを導出することがメッセージの1つ以上の特性から可能になるからかのいずれかの理由で)メッセージから入手または抽出されることを条件として、メッセージの中間のインターセプトおよび検査は、保護リソースについてのそのような情報を抽出することを含んでいてもよい。メッセージが、機密情報(例えば、銀行についての詳細記述など)のように、特定の保護リソースまたは保護リソースのタイプに関する許可要求に相当する場合、要求トークンは、例えば、サービスプロバイダへ転送されるのを阻止されてもよい。
【0034】
一実施形態では、要求トークンを使ってそれに関する1つ以上の操作の許可が求められている保護リソースについての情報は、メッセージから入手または抽出することができる。
【0035】
要求トークンを使って許可が求められている1つ以上の操作についての情報がメッセージから入手または抽出されることを条件として、メッセージをインターセプトして検査するステップは、許可が求められている操作のそのような特性がポリシー設定に適合しているかどうか判定することを含んでいてもよい。
【0036】
一実施形態では、要求トークンを使って許可が求められている操作についての情報は、メッセージから入手または抽出することができる。
【0037】
一実施形態では、方法は、さらに、少なくとも1つのサービスプロバイダから、少なくとも1つのサービスプロバイダにおけるユーザIDに関連する保護リソースに関する情報を入手するステップを含んでいる。これは、サービスプロバイダからアクセスできる保護リソースの一覧をユーザが入手することを可能にする。これは、適切なプライバシ管理が実行されることを可能にする。
【0038】
本実施形態の或る下位実施形態では、少なくとも1つのサービスプロバイダにおけるユーザIDに関連する保護リソースに関してコントローラが入手できる情報は、少なくとも1つのサービスプロバイダにおけるユーザIDに関連する保護リソースの利用に関する情報を含んでいる。
【0039】
本実施形態は、ユーザがコントローラを通じて、ユーザのIDに関連する保護リソースの動的一覧を入手することを可能にする。それゆえ、コントローラは、その点で制御の中心点として動作する。
【0040】
入手可能な一覧は、ユーザが、どのようにして、および、いつ、すなわち、少なくとも或る期間内のいつ、保護リソースがどのコンシューマによって使われたかということに関する情報を入手できるという意味で、動的でありうる。このようにして、ユーザは、ユーザの保護リソースの利用についての情報を収集することができる。次いで、ユーザは、この知識に基づいて、コントローラの中のポリシー設定を修正するかどうか決定してもよい。ユーザからの明確な要求を受信した時点で、コントローラによって利用履歴の検索が行われてもよい。あるいは、コントローラが、ユーザとの最初の対話に基づいて、または、デフォルト設定に基づいて、ユーザIDに関連する保護リソースの利用履歴を検索するように構成されてもよい。
【0041】
ID、あるいは具体的にはユーザIDは、ユーザの特性の1つであり、ユーザを識別するかまたはユーザを識別するために何らかのかたちでユーザにマッピングされている。
【0042】
利用情報は、特に、保護リソースのタイプと、保護リソースへのアクセスのタイムスタンプと、IDリソースにアクセスするかまたはした、またはIDリソースを利用するかまたはしたコンシューマの識別子とのうち、1つ以上についての情報を含んでいてもよい。
【0043】
一実施形態では、方法は、さらに、受信されたメッセージおよびそれらの要求トークンが転送されるのを阻止されたかどうかと、受信された要求トークンおよびそれらが転送されるのを阻止されたかどうかと、受信されたメッセージおよびそれらの要求トークンが転送されるのを許可されたかどうかと、受信された要求トークンおよびそれらが転送されるのを許可されたかどうかとのうち少なくとも1つに関する情報を記録することを含んでおり、それを本書では履歴情報と呼ぶ。次いで、方法は、履歴情報をユーザ端末が利用できるようにするステップを含んでいる。
【0044】
一実施形態では、方法は、さらに、コントローラと通信することが可能なユーザ端末によって行われ、方法は、さらに、ユーザ端末が、コントローラの中にポリシー設定を設定することを含んでいる。
【0045】
また、本発明は、要求トークンを含むメッセージを受信するように構成された受信器を含むコントローラに関する。上記のように、要求トークンは、サービスプロバイダからの保護リソースにアクセスすることについてユーザに許可を求めるための、コンシューマによって用いられる値である。サービスプロバイダは、保護リソースへのアクセスを提供するように構成されたソフトウェアアプリケーションとウェブサイトとのうちの少なくとも一方である。コンシューマは、ユーザの代わりにサービスプロバイダにアクセスするように構成されたソフトウェアアプリケーションとウェブサイトとのうち少なくとも一方である。また、コントローラは、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するように構成された判定器と、メッセージがポリシー設定に適合していないと判定された場合、要求トークンが要求トークンに関連するサービスプロバイダへ転送されるのを阻止するように構成された転送器とを含んでいる。
【0046】
また、本発明は、コンピュータまたは上記のコントローラ上で実行された場合に、コンピュータまたはコントローラにそれぞれ、上記の方法を実行させるように構成された命令を含むコンピュータプログラムに関する。また、本発明は、そのようなコンピュータプログラムを含むコンピュータプログラムプロダクトまたはコンピュータ可読媒体に関する。
【0047】
次に、添付の図面と併せて、本発明の実施形態について説明する。
【図面の簡単な説明】
【0048】
【図1】本発明の一実施形態における方法のフローチャートである。
【図2】本発明の一実施形態における、コントローラと、その構成要素の一部とを略示する図である。
【図3】本発明の別の実施形態における方法のフローチャートである。
【図4】本発明の一実施形態における方法のフローチャートであって、ここで、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するステップは、メッセージから情報を抽出するサブステップと、抽出された情報がポリシー設定に適合しているかどうか判定するサブステップとを含んでいる。
【図5a】ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能である。
【図5b】ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能である。
【図5c】ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能である。
【図6a】ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能であり、このネットワーク構成は、いわゆるプロキシコントローラを含んでいる。
【図6b】ネットワーク構成を略示する図であって、その文脈において本発明の実施形態における方法を実行可能であり、このネットワーク構成は、いわゆるプロキシコントローラを含んでいる。
【図7】本発明の背景、および、本発明の実施形態によって対処される一部の問題の理解を深めることだけを目的にしてネットワーク構成を略示する図である。
【図8】本発明の一実施形態における方法を示す図である。
【図9】本発明の一実施形態における方法を示す図であり、特に、サービスプロバイダからアクセスできる保護リソースについての情報を入手するコンシューマとしてのコントローラの使用を示す図である。
【図10】本発明の一実施形態における方法を示す図であり、特に、保護リソースへのアクセスを管理するポリシー設定をコントローラにおいて設定する操作を示す図である。
【図11】本発明の一実施形態における方法を示す図であり、特に、サービスプロバイダの保護リソースにアクセスするためにコンシューマによって開始される許可手順を行う操作を示す図である。
【図12】本発明の一実施形態における方法を示す図であり、特に、保護リソースの利用の履歴をコントローラから入手する操作を示す図である。
【発明を実施するための形態】
【0049】
次に、本発明について、具体的な実施形態に関して記述しよう。留意されるであろうが、これらの具体的な実施形態は、当業者の理解を深めるのに役立つものであって、決して本発明の範囲を制限することは意図されておらず、本発明の範囲は、添付の請求項によって定義される。
【0050】
図1は、本発明の一実施形態における方法のフローチャートである。図1に示す方法は、コントローラ100によって行われる。
【0051】
最初に、コントローラ100が、ステップs10で、要求トークンを含むメッセージを受信する。メッセージは、サービスプロバイダ400からアクセスできる保護リソースにアクセスすることを求めるコンシューマ300から発信される。その文脈において、要求トークンは、保護リソースにアクセスするための要求を識別する値である。メッセージは、要求トークンに加えて、要求トークンに伴う各種の追加情報またはパラメータ、例えば要求トークンが発信されるコンシューマ300のID、コンシューマ300によって開始される許可要求の対象である保護リソース、および/または、保護リソースに関連してコンシューマ300によって許可が求められた操作などを含んでいてもよい。
【0052】
要求トークンを含むメッセージは、要求トークンを生成したコンシューマ300とは別の物理エンティティから来てもよい。すなわち、コンシューマ300とコントローラ100との間に、メッセージおよびその要求トークンがそこを通して転送される中間的物理エンティティが存在していてもよい。
【0053】
メッセージは、パケットでも、HTTP要求でも、いずれかのそれ以外の、要求トークンを搬送するための適切な形式の信号であってもよい。
【0054】
次いで、コントローラ100は、ステップs20で、受信されたメッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定する。
【0055】
ポリシー設定は、コントローラ100上に記憶されているかまたはコントローラ100がアクセスできるようになっており、コントローラ100が代理動作するユーザに関連する保護リソースに関係している。ポリシー設定は、図10に示すように、ユーザによって設定されてもよい。あるいは、または、それに加えて、プライバシ設定が、コントローラ100を起動する時にデフォルトで設定されてもよい。プライバシ設定の更新は、ユーザによって行われてもよいし、コントローラ100を設定するようにリモートで許可された第三者によって行われても、あるいはその両方によって行われてもよい。
【0056】
例えば、コントローラ100によって用いられることになるポリシー設定をユーザが事前に設定し、第1の特定のコンシューマ300、例えば「doesntcareaboutprivacy.com」や「sellsyourprivatedatato3rdparties.com」は、リソースが何であれ、また、リソースに関して行われることになる操作が何であれ、ユーザのいずれの保護リソースにもアクセスすることを許可されないということを示してもよい。また、ユーザは、別の特定のコンシューマ300、例えば「caresaboutprivacy.com」からのメッセージの中に見つかった要求トークンは、リソースに関して行われることになる操作が何であれ、保護リソースが例えば銀行の詳細情報であるかまたはソーシャルセキュリティ番号である場合、または、許可が求められた操作が一部の保護リソースの削除に存する場合に限って、転送されるのを阻止されるべきであることを示してもよい。
【0057】
ステップs20の結果として、メッセージがポリシー設定に適合していない場合(ステップs30)、メッセージは、ステップs34で、サービスプロバイダ400へ転送されるのを阻止される。転送の阻止は、例えば、メッセージを削除し、後で評価するためにメッセージの詳細についてコントローラ100の中にログを取り、そして、メッセージをインターセプトして転送しなかったことについてコンシューマ300に通知することによって行われてもよい。コンシューマ300へ送信された情報は、要求トークンを含むメッセージがなぜコントローラ100によって転送されるのを阻止されたのかについての詳細を含んでいてもよい。
【0058】
方法は、複数のネットワークエンティティに分散されたユーザの保護リソースのプライバシの側面を管理するためのユーザにやさしい効率的な解決策をエンドユーザに提供する。同時に、方法は、実装の影響を最小化する。ユーザは、ユーザが許可したい保護リソースの利用に制限を設定することを目的として、ユーザについての保護リソースを記憶している個々のサービスプロバイダをくまなく調べる必要はない。加えて、ユーザは、保護リソースにアクセスするためのコンシューマによる許可要求を認めたり拒否したりすることを求められてじゃまされる頻度が少なくなる。
【0059】
ステップs30で、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合していると判定された場合、メッセージは、転送されるのを阻止されてもされなくてもよい。例えば、コントローラ100がファイアウォールとしても動作する場合、コントローラ100は、他の理由でメッセージをブロックすることを決めてもよい。これは、メッセージが、保護リソースへのアクセスを管理するいずれのポリシー設定にも関係しない、何らかの添付「.exe」ファイルを含んでいるからであってもよい。
【0060】
メッセージがサービスプロバイダ400へ転送されるのをコントローラ100が阻止するその他の理由、すなわち、保護リソースへのアクセスを管理するポリシー設定に基づかないその他の理由があってもよい。別の例示的な理由は、コントローラ100がウェブブラウザと一体化されており、ブラウザ上ではHTTPのリダイレクションは可能にされていない/許されていないため、ブラウザが、メッセージが転送されるのを許さないということもありうる(この可能性は、参考文献[2]、セクション6.2.1に記載されている)。
【0061】
ステップs30で、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合していると判定され、その後メッセージが、サービスプロバイダ400へ転送されるのを阻止されなかった場合、この結果として、メッセージは、サービスプロバイダ400に直接転送されてもよい。あるいは、メッセージは、メッセージが最終的にサービスプロバイダ400へ転送される前に、別の決定プロセスを行う権利を有する別の物理エンティティへ転送されてもよい。これが起こり得る状況は、図6aに関して記述しよう。
【0062】
一実施形態では、2つ以上の要求トークンを含むメッセージが、コンシューマ300によって開始された許可プロセスに関与している。メッセージは、ポリシー設定をチェックされ、メッセージは、ポリシー設定に適合していない要求トークンだけがサービスプロバイダ400へ転送されるのを阻止されるように、コントローラ100によって修正されてもよい。
【0063】
図2は、本発明の一実施形態における、コントローラ100およびその一部の構成要素を略示する図である。コントローラ100は、要求トークンを含むメッセージを受信するように構成された受信器110を含んでいる。コントローラ100は、さらに、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するように構成された判定器120を含んでいる。ポリシー設定は、コントローラ100の中に記憶されてもよいし、コントローラ100からアクセス可能なデータベースもしくはメモリユニットの中に記憶されてもよい。メッセージがポリシー設定に適合していないとコントローラ100が判定した場合、転送器130は、メッセージがサービスプロバイダ400へ転送されるのを阻止する責任を持つ。
【0064】
図3は、本発明の一実施形態における方法のフローチャートである。図1のフローチャートに示すステップに加えて、図3に示す方法は、要求トークンがサービスプロバイダ400へ転送されるのを許可するステップs32を含んでいる。このステップs32は、ステップs30でメッセージがポリシー設定に適合していると判定された場合に起きる。言い換えると、図3に示す方法を行うコントローラ100は、メッセージがポリシー設定に適合していないと判定された場合に限って、要求トークンに関連するサービスプロバイダ400に要求トークンが転送されるのを阻止する。
【0065】
図4は、本発明の一実施形態における方法のフローチャートである。図1のフローチャートで示すステップに加えて、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定するステップs20は、2つのサブステップを含んでいる。第1のサブステップs22は、メッセージから、
(i)要求トークンが許可された場合に保護リソースにアクセスしうるコンシューマ300についての情報と、
(ii)要求トークンが許可された場合にアクセスされうる保護リソースについての情報と、そして、
(iii)要求トークンが許可された場合に保護リソースに関して行われうる操作についての情報と、
のうち、少なくとも1つを抽出することに存する。
【0066】
メッセージから情報を抽出するサブステップs22は、メッセージを構文解析することを含んでいてもよい。
【0067】
第2のサブステップs24は、抽出された情報がポリシー設定に適合しているかどうかに基づいて要求トークンがサービスプロバイダ400へ転送されるのを阻止するかどうか判定することに存する。抽出された情報が、コントローラ100の中に記憶されたかまたはコントローラ100がアクセスできるポリシー設定に適合していなかった場合、コントローラ100は、要求トークンがサービスプロバイダ400へ転送されるのを阻止する。
【0068】
図5a乃至6bは、本発明の実施形態が適用されうる一部のネットワーク構成を示す。図5a乃至6bの各図には1つのコンシューマ300と1つのサービスプロバイダ400とだけを示しているが、2つ以上のサービスプロバイダ400と2つ以上のコンシューマ300とが提供されてもよい。同様に、1つのユーザ端末(すなわちUE)200だけがネットワークの他の構成要素と対話するように示しているが、2つ以上のユーザ端末200が関与してもよい。
【0069】
ユーザ端末200およびコントローラ100は通信してもよく、従ってコントローラ100はユーザ端末200が情報を利用できるようにすることができる。それに応じて、ユーザ端末200は、コンシューマ300から到着するメッセージを制御するためにコントローラ100によって用いられるポリシー設定を構成してもよい。ユーザがユーザ端末200を通じてコントローラ100の中にポリシー設定を設定することは、(例えばUE200上にある)コンピュータディスプレイ上に生成されたグラフィカルユーザインタフェースを用いて実施され、その結果、ユーザがポリシー設定を設定するためにユーザ端末と対話してもよい。コントローラ100は、ユーザのためのプライバシ代理人として動作する。
【0070】
図5a乃至6bに示すコンシューマ300またはコンシューマのウェブアプリケーション、および、サービスプロバイダ400またはサービスウェブアプリケーション(コンテナとも呼ばれることがある)は、一般に、少なくとも最初は、あるいはデフォルト動作としては、相互に信用していない。コンシューマ300とサービスプロバイダ400とは、連結による集中的手法をとらない。
【0071】
図5aは、本発明の一実施形態におけるネットワーク構成を略示する図であり、ここでコントローラ100とユーザ端末200とは、別個の物理エンティティである。ユーザ端末200はコントローラ100と通信することができる。コンシューマ300から要求トークンを含むメッセージを受信した時点で、コントローラ100は、メッセージが保護リソースへのアクセスを管理するポリシー設定に適合しているかどうか判定する。ポリシー設定に適合していないメッセージは、サービスプロバイダ400へ転送されるのを阻止される。一方、ポリシー設定に適合しているメッセージは、サービスプロバイダ400へ転送されてもよい。そのようなかたちで、ポリシー設定が行使される。
【0072】
図5bは、本発明の一実施形態におけるネットワーク構成を示しており、ここで、図5aに関して記述したステップに加えて、コントローラ100は、ユーザ装置200すなわちユーザ端末200上で作動する。
【0073】
図5cは、本発明の一実施形態におけるネットワーク構成を略示する図であり、ここで、ユーザ端末200は、ユーザ端末200の上で作動するウェブブラウザ140を有している。ブラウザ140の動作は、少なくともある程度、コントローラ100によって制御されている。図5cではコントローラ100は、ブラウザ140を含むように描かれているが、コントローラ100は、ブラウザ140に到達するメッセージおよび要求のフローを制御するため、ブラウザ140と同時に作動してもよい。一実施形態では、コントローラ100は、ブラウザのアドオンを用いて実装される。
【0074】
コンシューマ300から発信されたメッセージが、コントローラ100によって受信される。メッセージは、ユーザ端末のウェブブラウザを要求トークンに関連するサービスプロバイダ400のアドレスにリダイレクトする(向けなおす)ための(または、本書では同じ意味であるが、向けるための)要求を含んでいる。コントローラ100が、リダイレクト要求は、保護リソースへのアクセスを管理するポリシー設定に基づいて、受け入れるのを阻止されるべきかどうか判定する。コンシューマ300が、最初にメッセージをコントローラ100へ送信し、次いで、コントローラ100によって行われる判定に応じて、コントローラ100が要求トークンをサービスプロバイダ400へ転送してもよい。
【0075】
その点において、図5cは、コントローラ100と、コントローラ100と通信できるユーザ端末200とを含むシステムを略示する図であるが、ここで、ユーザ端末200は、ウェブブラウザを作動するように構成され、メッセージは、ユーザ端末のウェブブラウザを要求トークンに関連するサービスプロバイダ400のアドレスへリダイレクトする(向けなおす)(または、向ける)ための要求を含んでいる。
【0076】
図6aは、本発明の一実施形態におけるネットワーク構成を示す図であり、ここで、コントローラ100は、プロキシコントローラ100である。メッセージをコンシューマ300から受信した時点で、メッセージがポリシー設定に適合していると判定された場合、メッセージおよびその要求トークンはユーザ端末200へ転送される。そうでない場合、メッセージはユーザ端末200へ転送されず、従って、要求トークンは、その後、要求トークンに関連するサービスプロバイダ400へユーザ端末200によって転送されるのを阻止される。言い換えると、コントローラ100は、ポリシー設定に従って必要であると判定された場合にメッセージをブロックすることによって、要求トークンがユーザ端末200によってサービスプロバイダ400へ転送されるのを阻止する。
【0077】
図6bは、本発明の一実施形態におけるネットワーク構成を略示する図であり、2つのコントローラ、すなわち、プロキシコントローラ100aとユーザ端末200上で作動するコントローラ100bとを含んでいる。コンシューマ300からのメッセージをプロキシコントローラ100aによって受信した時点で、プロキシコントローラ100aは、メッセージがポリシー設定に適合しているかどうか判定する。メッセージがポリシー設定に適合している場合、メッセージおよびその要求トークンは、コントローラ100bをホストするユーザ端末200へ転送される。そうでない場合、メッセージはユーザ端末200およびコントローラ100bへは転送されず、従って、要求トークンは、ユーザ端末200およびコントローラ100bによって要求トークンに関連するサービスプロバイダ400へ転送されるのを阻止される。
【0078】
メッセージおよびその要求トークンが、コントローラ100bをホストするユーザ端末200へ転送される場合、コントローラ100bは、コントローラ100bにとって適切であるポリシー設定に基づいて、メッセージの第2のインターセプトおよび検査を行う。
【0079】
図6bのネットワーク構成において、プロキシコントローラ100aは、例えば、ローカルネットワークアドミニストレータによって管理されてもよく、そして、ユーザ端末200上でホストされている他方のコントローラ100bは、例えばユーザ自身によって管理されてもよい。ここで、コントローラを管理するとは、コントローラに適用可能なポリシー設定を少なくとも設定できることを意味する。
【0080】
図7は、本発明の背景をさらに詳細に示すため、および、本発明によって解決される一部の問題の理解を深めるため、OAuthプロトコルによる認証および許可プロセスを略示する図である。しかし、本発明は、OAuthプロトコルへの適用に限定されない。
【0081】
OAuthプロトコルは、ユーザがユーザのサービスプロバイダ認証情報をコンシューマに開示することを必要とせず、(図7の「コンシューマ」と記されたボックスによって示す)コンシューマアプリケーションが(図7の「サービスプロバイダ」と記されたボックスで示す)サービスプロバイダの保護リソースにアクセスするのを可能にする。OAuthプロトコルは、保護リソースを求める要求の中で、ユーザの認証情報の代わりに、サービスプロバイダによって生成されるトークンを用いる。プロセスは2つのトークンタイプ、すなわち、要求トークンとアクセストークンとを用いる。要求トークンは、保護リソースへのアクセスを許可するようにユーザに求めるためにコンシューマによって用いられる。許可された要求トークンは、次いで、アクセストークンと交換される。アクセストークンは、ユーザの代わりに保護リソースにアクセスするためにコンシューマによって用いられる。
【0082】
やはり図7に関して、最初に、ユーザが何らかのかたちで、例えば、例示的なprinter.consumer.comのウェブサイト(コンシューマ)を自分のユーザエージェントを使って閲覧することによって、許可プロセスをトリガする(ステップA)。許可プロセスは、次いで、3つの連続ステップを含んでいる。
【0083】
(1)コンシューマが、未許可の要求トークンをサービスプロバイダから入手する(ステップB)。
【0084】
(2)ユーザが自分のユーザエージェントを用いて要求トークンを許可する。そうするために、最初に、コンシューマは未許可の要求トークンをユーザエージェントに送信し、それをユーザエージェントが、サービスプロバイダへ転送する(ステップC)。次いで、サービスプロバイダが、ユーザエージェントを通してユーザとの認証手順を始める(ステップD)。認証手順が成功したら、サービスプロバイダは、要求トークンを許可し、ユーザエージェントに許可された要求トークンを与え(ステップE)、それをユーザエージェントは、元のコンシューマへ転送する。認証手順が失敗したら、サービスプロバイダは、ユーザエージェントを通じて応答を転送する際に、要求トークンが無効化されたことをコンシューマに通知してもよい。
【0085】
(3)最後に、コンシューマは、その後でサービスプロバイダのユーザの保護リソースにアクセスすることを目的として、サービスプロバイダとの間で、許可された要求トークンをアクセストークンに交換(ステップF)する。
【0086】
OAuthプロトコルによれば、プライバシ管理はユーザ自身によって処理される。ユーザは、サービスプロバイダの保護リソースにアクセスするため、コンシューマを許可する。許可が与えられた後、コンシューマは、保護リソースにアクセスするためのアクセストークンを手に入れる。発明者らが特に認識していることだが、OAuthプロトコルはアクセストークンの有効期間についていかなる制限をも規定していないが、トークンが短期間有効である場合には、許可は、コンシューマが保護リソースへのアクセスを必要とする度に与えられる必要があるであろう。このように許可を繰り返し要求する必要があることは、面倒でありうる。
【0087】
また、発明者らがさらに特に認識していることだが、OAuthプロトコルは、コンシューマに対して認められるアクセス権をきめ細かくユーザが制御できるようにする方法は何ら考慮していない。代わりに、ユーザは、サービスプロバイダの中のユーザの保護リソース全部へのアクセスを所与のコンシューマに対して認めるか拒否するかである。
【0088】
また、発明者らがさらに特に認識していることだが、ユーザは、どの保護リソースをコンシューマが実際に要求しているのかが分からない。一旦コンシューマが許可されると、保護リソースにアクセスするための要求は、コンシューマとサービスプロバイダとの間の直接通信であり(図7のステップF)、ユーザは、どの保護リソースが現在使用されており、これまで使用されたのかを知る手段を持たない。
【0089】
ユーザは、ユーザIDに関連する保護リソースを記憶している各サービスプロバイダにおいてユーザのプライバシ設定を設定することができたであろう。しかし、プライバシ設定は、そもそも可能であればだが、サービスプロバイダ毎に明示的に記述される必要があるであろう。
【0090】
図8は、本発明の一実施形態におけるネットワーク構成と、この実施形態を行う際に含まれる通信フローとを略示する図である。
【0091】
両矢印「1」は、サービスプロバイダ400の中の保護リソースの存在についての情報をコントローラ100が検索することを示す。これは、いわゆる静的一覧検索であり、これについては図9に関して詳細に説明しよう。一旦コントローラ100がサービスプロバイダ400によって認証されると、コントローラ100は、所与のユーザに関連する保護リソースについての情報を入手するためにサービスプロバイダ400にクエリを行う。
【0092】
図9は、本発明の一実施形態を成す静的一覧検索を示す。本実施形態では、OAuthプロトコルが用いられる場合、コントローラ100は、OAuthコンシューマ300として動作または機能する。この目的で、コントローラ100は、目標のサービスプロバイダ400においてコンシューマ300として事前に登録されていてもよい。登録プロセスの間、サービスプロバイダ400は、コントローラ100にコンシューマ鍵とコンシューマ秘密とを提供する。これらの要素は、コントローラ100とサービスプロバイダ400との間の将来の通信に役立つものであり、コントローラ100がクエリを行うことを望んでいるサービスプロバイダ400について(ユーザ毎ではなく)一度だけ生成されうる。
【0093】
一旦コントローラ100がサービスプロバイダ400の中に登録されると、ユーザは、コントローラ100を用いてサービスプロバイダ400の中でユーザについて記憶された保護リソース(ユーザIDに関連する保護リソース)の静的な一覧を検索してもよい(ステップ0、「静的な一覧を示す」と記載された矢印)。コントローラ100は、サービスプロバイダ400から未許可の要求トークンを入手することによって動き始める(ステップ1、「未許可の要求トークンを入手する」)。次いで、許可プロセスが始まる(ステップ2、「要求トークンを許可する」)。この許可プロセスの間、サービスプロバイダ400は、ユーザが認証されることを必要とする(ステップ3a、「認証が必要とされる」)。このために、コントローラ100は、ユーザプロキシとして動作する。コントローラ100は、第1に、認証情報をユーザに要求し(ステップ3b、「認証プロセス」)、次いで、ユーザの認証情報を元のサービスプロバイダ400へ転送する(ステップ3c、「認証応答」)。この許可プロセスの最後に、コントローラ100が、許可された要求トークンを受信し(ステップ4、「許可された要求トークン」)、それをコントローラ100は、有効なアクセストークンと交換する(ステップ5、「アクセストークンを入手する」)。
【0094】
コントローラ100は、アクセストークンを用いて、サービスプロバイダ400において、サービスプロバイダ400でアクセス可能な保護リソースにアクセスする(ステップ6、「保護リソースを入手する」)。一旦サービスプロバイダ400がこの情報を開示すると、コントローラ100は、それをユーザに提示する(ステップ7、「利用可能な情報」)。
【0095】
一実施形態では、ユーザは、例えば情報の追加、更新、削除といった、保護リソースに関するさらなる管理操作を行う機会を提供されてもよい。
【0096】
図9で示す「静的一覧検索」の実施形態が、OpenSocialおよびOAuthプロトコルの文脈で用いられてもよい。OpenSocialは、ウェブベースのソーシャルネットワーキングアプリケーションがそれらのソーシャルデータを共有するのに役立てるため、アプリケーションプログラミングインタフェース(API)のセットを提供しており、米国のサンフランシスコに拠点を置くOpenSocial Foundation(http://www.opensocial.org/を参照のこと)によって維持されている。OpenSocial Specification v0.9は、2009年10月時点で、
http://opensocial.org/Technical−Resouces/opensocial−spec−v09/OpenSocial−Specification.htmlで入手可能である。
【0097】
ステップ1、2、3、4、5(図9に示す)は、OAuthプロトコル(参考文献「2」)に従ってもよい。しかし、ユーザが各サービスプロバイダ400を繰り返し認証する(ステップ3b)必要性を回避するため、コントローラ100は、ユーザの保護リソースをキープまたは維持する各サービスプロバイダ400にユーザの認証情報を記憶してもよい。有利には、これはシングルサインオン手順を提供する。また、ステップ6は、OpenSocial Specification v0.9に記述されたプロトコルに従ってもよい。
【0098】
図10は、本発明の一実施形態における、ユーザ、またはユーザ端末による、コントローラ100におけるプライバシ設定の管理を略示する図である。特に、プライバシ設定管理に含まれうる通信を示す。
【0099】
ユーザが、自分の保護リソースの使用と開示とを管理するためにプライバシ選好を設定したいと望む。コントローラ100は、多様な選択肢をユーザに示し、例えば保護リソースがアクセスされうる、すなわち使用または開示されうる条件のような、多様なパラメータを、ユーザが構成できるようにする。完了したならば、コントローラ100は、結果としてのポリシー設定を記憶する。その後、コンシューマ300が保護リソースにアクセスするための許可を必要とする度に、コントローラ100は、ユーザの選好、すなわちポリシー設定を行使する。
【0100】
ユーザは、自分の保護リソースへのアクセスに関する自分の選好を設定できることで、利益を得る。このために、ユーザは、コントローラ100の中にプライバシ選好を設定し、その後、コントローラ100は、これらのプライバシ選好を行使する。
【0101】
ポリシー設定の定義に加わる変数には、要求者(リクエスタ)、リソース、操作、パーミッションなどが含まれうる。ユーザは、コントローラ100のユーザなのだから、ポリシー設定の中にユーザが明示的に記述されなくてもよい。ただし、ユーザが記述されてもよい。
【0102】
要求者は、ユーザの保護リソースにアクセスしようとするいずれかのコンシューマ300であってもよい。
【0103】
リソースは、ポリシー設定規則に関係している保護リソースの識別子であってもよい。例えば、OpenSocialは、例えば人物や行動といった、標準的な保護リソースについての具体的なフォーマットを定義している。サービスプロバイダ400の静的な一覧が検索された場合、コントローラ100は、この情報を用いて、リソースに関連する見込まれる値を減らし、一層きめ細かいポリシーを提供しうる。
【0104】
操作の値は、いずれかのコンシューマ300が要求することができる操作であってもよく、例えば、OpenSocialの例では、それらは「クエリを行う」、「作成する」および「削除する」であってもよい。しかし、本発明の一実施形態は、ポリシー設定規則に従いうるいずれかの数またはタイプの操作に限定されない。
【0105】
パーミッションは、「認める」、「拒否する」または「アスク・ミー(askMe)」(ユーザが実施毎に決定することを望む場合;これはアドホック・インタラクション・サービス、すなわちブラウザにおけるポップアップ、SMSベースの許可などを使って実施されうる)に設定されてもよい。また、解決策の使い勝手を向上させるため、一部の選択肢(ワイルドカード)、すなわち、「すべての見込まれる値」、「全くなし」または「ユーザが選択した具体的な部分集合」、が導入されてもよい。
【0106】
これらの値は、ユーザによって設定され、コントローラ100に提出される(図10、ステップ0、「プライバシ選好を設定する」)。結果として、ユーザおよびユーザの保護リソースに関する新たなポリシー設定規則が作成され、コントローラ100の中に記憶される(ステップ1、「プライバシ選好を記憶する」)。ポリシー設定プロセスは、それに関して情報が開示されうるさらなる条件の明細を使って拡充されてもよい。
【0107】
ユーザは多様な手段を通じて自分のプライバシ選好を表現する機会を与えられてもよい。第1に、ユーザは複数の定義済のプライバシポリシーの中から1つを選び、それを保護リソースに関連付けてもよい。これらの定義済プライバシポリシーは、技術的知識のないユーザも理解できるように、自然言語で記述されてもよい。この自然言語記述は、プライバシポリシー表現言語として記述される具体的なポリシー実装にマッピングされる。これらのポリシーはユーザがそれらを比較して自分のニーズにもっと合致するものをより容易に選べるよう、階層的になっている。ユーザはポリシーの詳細を扱う必要がないことから、この手法には、モデルの単純性と使い勝手という強みがある。
【0108】
また、ユーザは、プライバシポリシーの詳細の各々を定義することができてもよい。この手法は、ユーザ選好の記述に与える柔軟性が大きくなるが、使い勝手については若干のリスクを生じさせることがある。上級ユーザだけがポリシーの意味を理解する(そして多分、知ることを望む)ことがありえる。これは、上級選択肢として提供されてもよい。
【0109】
次に、本発明の一実施形態におけるプライバシポリシーの行使について、図11に関して説明しよう。
【0110】
コンシューマ300が、保護リソースにアクセスすることを望む。保護リソースは、コントローラ100の中にユーザによって設定されたポリシー設定によって管理される。コントローラ100は、ポリシー設定を行使し、それゆえ、サービスプロバイダ400の保護リソースにコンシューマ300がアクセスすることを可能にするであろう許可されたトークンの返信をコンシューマ300が受信できるかどうか間接的に決定する。
【0111】
コンシューマ300は、ユーザの代わりに働いてもよい。ゆえに、両者間にすでにHTTP接続が確立されていてもよい。
【0112】
コンシューマ300は、保護リソースをホストするサービスプロバイダ400から未許可の要求トークンを入手することによってプロセスを開始する(図8、「B」と記載された矢印)。このステップの一部の実装は、OpenSocialおよびOAuth仕様によって定義されている。
【0113】
次に図11を参照するが、コンシューマ300が、OAuth許可プロセスを開始する。第1に、コンシューマ300が、許可のために(ステップ0、「要求トークンを許可する」)ユーザエージェントをサービスプロバイダ400にリダイレクトするHTTPメッセージを、ユーザエージェント(ユーザエージェントは、例えば、コントローラ100が実行されうる操作環境にあるブラウザであってもよい)に送信する。コントローラ100は、このメッセージを捕捉し、あるいは言い換えればインターセプトして、ポリシー行使のための一部の関連情報を抽出する(ステップ1、「ポリシー行使」)。特に(以下は、網羅的でないリストである)、OAuthプロトコルが用いられる場合、要求者、あるいはコンシューマ識別子が、oauth_callbackと呼ばれるOAuthパラメータから抽出されてもよい。OAuthプロトコルは、他の情報、すなわち、コンシューマ300がそれに関して許可を望んでいる保護リソースおよび操作をどのように検索するかを定義していない。しかし、OAuthプロトコルは、追加のパラメータがサービスプロバイダ400によって定義されうることを述べている。
【0114】
本発明の一実施形態は、この可能性を利用して、OAuth許可メッセージが含みうる2つの新たなパラメータ、oauth_requested_resourceおよびoauth_requested_operationを定義する。これらのパラメータが許可要求の中に含まれていない場合、コントローラ100は、コンシューマ300が、サービスプロバイダ400においてアクセス可能なすべての保護リソースにクエリを行い、修正し、削除しようとしていると想定してもよい。従って、コントローラ100は、この想定に基づいて、適宜にポリシー設定を行使してもよい。
【0115】
一旦ポリシー設定が行使され、行使の結果が「可能」(すなわち、「転送することが可能」)となったならば、コントローラ100は、プロセスを続行する。すなわち、コントローラ100は、最初の「許可」要求トークンメッセージをサービスプロバイダ400へ転送する(ステップ2、「要求トークンを許可する」)。次いで、サービスプロバイダ400は、ユーザの認証手順をユーザエージェントを通じて開始する(ステップ3a、「認証が必要とされる」)。この文脈では、認証は、アサートされたユーザのIDを、指定されたかまたは了承された信頼レベルで確認するプロセスである。
【0116】
一実施形態では、その段階で、コントローラ100は、メッセージを再び捕捉する。認証に必要な認証情報は、「静的一覧検索」のシナリオにおいて記憶されていてもよいため、ユーザが自分に同意を求めなければならないと明示的に記述していない限り、ステップ3b(サービスプロバイダ400においてユーザの認証情報を入手することを含めて、図9を参照のこと)は、必要ない。
【0117】
コントローラ100は、認証応答を送信する(ステップ3c、「認証応答」)。その結果、サービスプロバイダ400は、許可された要求トークンを返信し(ステップ4、「許可された要求トークン」)、コントローラ100は、それをコンシューマ300へ転送する(ステップ4b、「許可された要求トークン」)。次いでコンシューマ300は、サービスプロバイダ400において、許可された要求トークンをアクセストークンと交換し、次いで、保護リソースおよび必要な操作にアクセスしてもよい(ステップ5,6,7)。
【0118】
行使プロセス(ステップ1)の結果が「拒否する」である場合、コントローラ100は、メッセージをコンシューマ300へ返信し、拒否についてかまたは拒否の詳細についてコンシューマ300に通知してもよい。
【0119】
図11に関して記述したプロセスは、以下のように、OAuthプロトコル(参考文献[1])に基づいていてもよい。
【0120】
一実施形態では、コントローラ100は、ユーザおよびユーザのユーザエージェントの代理となる。すなわち、ユーザおよびユーザのユーザエージェントは、コンシューマ300からの要求が受信された場合、認証のいかなる通知も受信しない。許可プロセスは暗示的である。ユーザ定義のポリシー設定は、ユーザからの介在なしにコントローラ100によって適用される。
【0121】
一実施形態では、OAuthプロトコルへの拡張が行われる。すなわち、2つの追加パラメータ、oauth_requested_resourceおよびoauth_requested_operation(当然、これらのパラメータに別の名前が付けられてもよい)が、許可を求めるすべての要求に、すなわち、要求トークンを含むすべてのメッセージに、含まれてもよい。OAuthプロトコルは、これらの拡張を可能にする。
【0122】
一旦ユーザまたはユーザの代わりにコントローラ100が、要求トークンを許可したならば、要求トークンは、アクセストークンと交換することができる。アクセストークンは、ユーザに関連し、かつ、サービスプロバイダ400からアクセス可能な保護リソースに関する操作を行う特権をコンシューマ300に認める。
【0123】
以前の実施形態において定義されたOAuthプロトコルへの拡張が実施された場合、従って、コンシューマ300が要求トークンの中で(追加パラメータを用いて)どの情報および操作が要求されているかを宣言する場合、一実施形態では、コンシューマ300がその当初の許可を求める要求の中で宣言したことだけに限ってサービスプロバイダ400がコンシューマ300に特権を認めるかたちで、OAuthプロトコルが拡張されてもよい。これは、許可プロセスに一貫性と信用とを与える。
【0124】
一実施形態では、サービスプロバイダ400が保護リソースのコンシューマ300に、コンシューマ300はアクセスすることが許可されていることを通知する。サービスプロバイダ400は、アクセストークンを開示している間に送信される追加パラメータを用いて、コンシューマ300に通知する。
【0125】
図12に関して記述した一実施形態では、動的一覧検索機能が実装される。コントローラ100が、サービスプロバイダ400の中のユーザの保護リソースの静的一覧を検索していたと仮定しよう。
【0126】
さらに、コンシューマ300が、ユーザに関連する一部の保護リソースにアクセスしようとしたと仮定しよう。今、ユーザは自分に関連する一部の保護リソースの利用履歴を知りたいと望んでいる。この目的で、ユーザは、要求をコントローラ100に送信する(ステップ0、「利用履歴を入手する」)。コントローラ100は、要求されたデータを検索し(ステップ1、「利用履歴を検索する」)、次いで、それがユーザに提示される(ステップ2、「利用履歴の詳細」)。
【0127】
動的一覧検索機能は、以下のように使用可能にされてもよい。コンシューマ300が、ユーザに関連する保護リソースへのアクセスを要求する度に、このイベントがコントローラ100によってログがとられる。コントローラ100は、コントローラ100がポリシー設定を行使した後に、この情報のログをとってもよい。ゆえに、ポリシー行使の結果に関する情報は、ログに追加されてもよい。この情報は、例えば、将来の監査のために用いられてもよい。
【0128】
提示された情報には、要求された保護リソースと、アクセスのタイムスタンプと、情報を記憶したサービスプロバイダ400と、情報にアクセスしたコンシューマ300と、ポリシー行使の結果とについての詳細が含まれてもよい。情報は、コンシューマ300によって送信されるメッセージの中に含まれる多様なパラメータから抽出されてもよい。入手可能であれば、さらなる条件、例えば、コンシューマ300によって行われたプライバシの約束、あるいは、情報を開示した時点でサービスプロバイダ400によって課される条件が提示されてもよい。
【0129】
コントローラ、サービスプロバイダ、コンシューマおよびユーザ端末を含めて本発明による物理エンティティは、コンピュータプログラムが物理エンティティ上で実行される場合、本発明の実施形態によるステップおよび手順が行われるような命令を含むコンピュータプログラムを含んでいるかまたは記憶していてもよい。また、本発明は、本発明による方法を行うためのコンピュータプログラム、および、本発明による方法を行うためのコンピュータプログラムを記憶するいずれかのコンピュータ可読媒体に関する。
【0130】
「受信器」、「判定器」、「転送器」、「取得器」、「記録器」、「開示器」という用語が本書で用いられている場合、これらの要素がどのようにして分散され、要素がどのようにして集結されるかに関して、制限はない。すなわち、これらの要素の構成部分は、意図された機能を実現するための異なるソフトウェアもしくはハードウェアコンポーネントもしくはデバイスとして分散されてもよい。また、複数の別個の要素が、意図された機能性を提供するために集結されてもよい。
【0131】
コントローラの上記の要素のいずれか1つが、ハードウェア、ソフトウェア、フィールドプログラマブルゲートアレー(FPGA)、特定用途向け集積回路(ASIC)、ファームウェア等の中に実装されてもよい。同じことは、ユーザ端末、コンシューマ、サービスプロバイダにも適用される。
【0132】
本発明の別の実施形態において、上記の「受信器」、「判定器」、「転送器」、「取得器」、「記録器」、「開示器」のいずれか1つが、「受信器」、「判定器」、「転送器」、「取得器」、「記録器」、「開示器」の機能を行うための、受信手段、判定手段、転送手段、取得手段、記録手段、開示手段によってそれぞれ置換されるか、または、受信ユニット、判定ユニット、転送ユニット、取得ユニット、記録ユニット、開示ユニットによってそれぞれ置換されてもよい。
【0133】
本発明の別の実施形態において、上記のステップのいずれか1つが、いずれかの種類のコンピュータ言語での、例えばコンピュータが理解可能な手順、方法等の形式の、および/または、ファームウェア、集積回路等の上の内蔵ソフトウェアの形式の、コンピュータ可読命令を用いて実装されてもよい。
【0134】
本発明を詳細な例に基づいて記述してきたが、詳細な例は、当業者の理解を深める働きをするだけであって、本発明の範囲を限定することは意図されていない。そうではなく、本発明の範囲は、添付の請求項によって定義される。
【特許請求の範囲】
【請求項1】
コントローラ(100)によって実行される方法であって、
要求トークンを含むメッセージを受信するステップ(s10)を備え、
要求トークンは、サービスプロバイダ(400)の保護リソースにアクセスすることについてユーザからの許可を要求するための、コンシューマ(300)によって使用される値であり、
サービスプロバイダ(400)は、保護リソースに対するアクセスを提供するように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
コンシューマ(300)は、ユーザの代わりにサービスプロバイダ(400)にアクセスするように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
前記方法は更に、
前記メッセージが保護リソースに対するアクセスを管理するポリシー設定に適合するか否かを判定するステップ(s20)と、
前記メッセージが前記ポリシー設定に適合しないと判定された(s30)場合に、前記要求トークンに関連する前記サービスプロバイダ(400)へ前記要求トークンが転送されることを阻止するステップ(s34)と、
を備えることを特徴とする方法。
【請求項2】
前記メッセージが前記ポリシー設定に適合すると判定された(s30)場合に、前記要求トークンに関連する前記サービスプロバイダ(400)へ前記要求トークンが転送されることを許可するステップ(s32)
を更に備えることを特徴とする請求項1に記載の方法。
【請求項3】
前記メッセージが前記ポリシー設定に適合するか否かを判定する前記ステップ(s20)は、
前記要求トークンの発信元である前記コンシューマ(300)に関する情報と、
1以上の操作を許可するよう前記要求トークンを通じて要求される前記保護リソースに関する情報と、
前記要求トークンを通じて許可を要求される前記1以上の操作に関する情報と、
のうちの少なくとも1つを前記メッセージから抽出するステップ(s22)と、
前記抽出された情報が前記ポリシー設定に適合するか否かを判定するステップ(s24)と、
を含む
ことを特徴とする請求項1又は2に記載の方法。
【請求項4】
少なくとも1つのサービスプロバイダ(400)から、前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースに関する情報を取得するステップ
を更に備えることを特徴とする請求項1乃至3のいずれか1項に記載の方法。
【請求項5】
前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースに関する前記情報は、前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースの利用に関する情報を含む
ことを特徴とする請求項4に記載の方法。
【請求項6】
受信したメッセージ、及び、その要求トークンが転送されることが阻止されたか否か、と、
受信した要求トークン、及び、それが転送されることが阻止されたか否か、と、
受信したメッセージ、及び、その要求トークンが転送されることが許可されたか否か、と、
受信した要求トークン、及び、それが転送されることが許可されたか否か、と、
のうちの少なくとも1つに関する、履歴情報と呼ぶ情報を記録するステップと、
前記履歴情報をユーザ端末(200)が入手できるようにするステップと、
を更に備えることを特徴とする請求項1乃至5のいずれか1項に記載の方法。
【請求項7】
前記コントローラ(100)と通信可能なユーザ端末(200)が追加的に実行する、請求項1乃至6のいずれか1項に記載の方法であって、
前記ユーザ端末(200)が、前記コントローラ(100)の中の前記ポリシー設定を設定するステップ
を更に備えることを特徴とする請求項1乃至6のいずれか1項に記載の方法。
【請求項8】
コントローラ(100)であって、
要求トークンを含むメッセージを受信するように構成された受信器(110)を備え、
要求トークンは、サービスプロバイダ(400)の保護リソースにアクセスすることについてユーザからの許可を要求するための、コンシューマ(300)によって使用される値であり、
サービスプロバイダ(400)は、保護リソースに対するアクセスを提供するように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
コンシューマ(300)は、ユーザの代わりにサービスプロバイダ(400)にアクセスするように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
前記コントローラは更に、
前記メッセージが保護リソースに対するアクセスを管理するポリシー設定に適合するか否かを判定するように構成された判定器(120)と、
前記メッセージが前記ポリシー設定に適合しないと判定された場合に、前記要求トークンに関連する前記サービスプロバイダ(400)へ前記要求トークンが転送されることを阻止するように構成された転送器(130)と、
を備えることを特徴とするコントローラ(100)。
【請求項9】
前記転送器(130)は更に、前記メッセージが前記ポリシー設定に適合すると判定された場合に、前記要求トークンに関連する前記サービスプロバイダ(400)へ前記要求トークンが転送されることを許可するように構成される
ことを特徴とする請求項8に記載のコントローラ(100)。
【請求項10】
前記判定器(120)は更に、
前記メッセージが前記ポリシー設定に適合するか否かを判定することが、
前記要求トークンの発信元である前記コンシューマ(300)に関する情報と、
1以上の操作を許可するよう前記要求トークンを通じて要求される前記保護リソースに関する情報と、
前記要求トークンを通じて許可を要求される前記1以上の操作に関する情報と、
のうちの少なくとも1つを前記メッセージから抽出することと、
前記抽出された情報が前記ポリシー設定に適合するか否かを判定することと、
を含むように構成される
ことを特徴とする請求項8又は9に記載のコントローラ(100)。
【請求項11】
少なくとも1つのサービスプロバイダ(400)から、前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースに関する情報を取得するように構成された取得器
を更に備えることを特徴とする請求項8乃至10のいずれか1項に記載のコントローラ(100)。
【請求項12】
前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースに関する前記情報は、前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースの利用に関する情報を含む
ことを特徴とする請求項11に記載のコントローラ(100)。
【請求項13】
受信したメッセージ、及び、その要求トークンが転送されることが阻止されたか否か、と、
受信した要求トークン、及び、それが転送されることが阻止されたか否か、と、
受信したメッセージ、及び、その要求トークンが転送されることが許可されたか否か、と、
受信した要求トークン、及び、それが転送されることが許可されたか否か、と、
のうちの少なくとも1つに関する、履歴情報と呼ぶ情報を記録するように構成された記録器と、
前記履歴情報をユーザ端末(200)が入手できるようにする開示器と、
を更に備えることを特徴とする請求項8乃至12のいずれか1項に記載のコントローラ(100)。
【請求項14】
請求項8乃至13のいずれか1項に記載のコントローラ(100)と、
前記コントローラ(100)と通信可能なユーザ端末(200)と、
を備え、
前記ユーザ端末(200)は、前記コントローラ(100)の中の前記ポリシー設定を設定するように構成される
ことを特徴とするシステム。
【請求項15】
コントローラ(100)において実行された場合に、前記コントローラ(100)に、請求項1乃至7のいずれか1項に記載の方法を実行させるように構成された命令を含んだコンピュータプログラム。
【請求項1】
コントローラ(100)によって実行される方法であって、
要求トークンを含むメッセージを受信するステップ(s10)を備え、
要求トークンは、サービスプロバイダ(400)の保護リソースにアクセスすることについてユーザからの許可を要求するための、コンシューマ(300)によって使用される値であり、
サービスプロバイダ(400)は、保護リソースに対するアクセスを提供するように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
コンシューマ(300)は、ユーザの代わりにサービスプロバイダ(400)にアクセスするように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
前記方法は更に、
前記メッセージが保護リソースに対するアクセスを管理するポリシー設定に適合するか否かを判定するステップ(s20)と、
前記メッセージが前記ポリシー設定に適合しないと判定された(s30)場合に、前記要求トークンに関連する前記サービスプロバイダ(400)へ前記要求トークンが転送されることを阻止するステップ(s34)と、
を備えることを特徴とする方法。
【請求項2】
前記メッセージが前記ポリシー設定に適合すると判定された(s30)場合に、前記要求トークンに関連する前記サービスプロバイダ(400)へ前記要求トークンが転送されることを許可するステップ(s32)
を更に備えることを特徴とする請求項1に記載の方法。
【請求項3】
前記メッセージが前記ポリシー設定に適合するか否かを判定する前記ステップ(s20)は、
前記要求トークンの発信元である前記コンシューマ(300)に関する情報と、
1以上の操作を許可するよう前記要求トークンを通じて要求される前記保護リソースに関する情報と、
前記要求トークンを通じて許可を要求される前記1以上の操作に関する情報と、
のうちの少なくとも1つを前記メッセージから抽出するステップ(s22)と、
前記抽出された情報が前記ポリシー設定に適合するか否かを判定するステップ(s24)と、
を含む
ことを特徴とする請求項1又は2に記載の方法。
【請求項4】
少なくとも1つのサービスプロバイダ(400)から、前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースに関する情報を取得するステップ
を更に備えることを特徴とする請求項1乃至3のいずれか1項に記載の方法。
【請求項5】
前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースに関する前記情報は、前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースの利用に関する情報を含む
ことを特徴とする請求項4に記載の方法。
【請求項6】
受信したメッセージ、及び、その要求トークンが転送されることが阻止されたか否か、と、
受信した要求トークン、及び、それが転送されることが阻止されたか否か、と、
受信したメッセージ、及び、その要求トークンが転送されることが許可されたか否か、と、
受信した要求トークン、及び、それが転送されることが許可されたか否か、と、
のうちの少なくとも1つに関する、履歴情報と呼ぶ情報を記録するステップと、
前記履歴情報をユーザ端末(200)が入手できるようにするステップと、
を更に備えることを特徴とする請求項1乃至5のいずれか1項に記載の方法。
【請求項7】
前記コントローラ(100)と通信可能なユーザ端末(200)が追加的に実行する、請求項1乃至6のいずれか1項に記載の方法であって、
前記ユーザ端末(200)が、前記コントローラ(100)の中の前記ポリシー設定を設定するステップ
を更に備えることを特徴とする請求項1乃至6のいずれか1項に記載の方法。
【請求項8】
コントローラ(100)であって、
要求トークンを含むメッセージを受信するように構成された受信器(110)を備え、
要求トークンは、サービスプロバイダ(400)の保護リソースにアクセスすることについてユーザからの許可を要求するための、コンシューマ(300)によって使用される値であり、
サービスプロバイダ(400)は、保護リソースに対するアクセスを提供するように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
コンシューマ(300)は、ユーザの代わりにサービスプロバイダ(400)にアクセスするように構成されたソフトウェアアプリケーション及びウェブサイトのうちの少なくとも一方であり、
前記コントローラは更に、
前記メッセージが保護リソースに対するアクセスを管理するポリシー設定に適合するか否かを判定するように構成された判定器(120)と、
前記メッセージが前記ポリシー設定に適合しないと判定された場合に、前記要求トークンに関連する前記サービスプロバイダ(400)へ前記要求トークンが転送されることを阻止するように構成された転送器(130)と、
を備えることを特徴とするコントローラ(100)。
【請求項9】
前記転送器(130)は更に、前記メッセージが前記ポリシー設定に適合すると判定された場合に、前記要求トークンに関連する前記サービスプロバイダ(400)へ前記要求トークンが転送されることを許可するように構成される
ことを特徴とする請求項8に記載のコントローラ(100)。
【請求項10】
前記判定器(120)は更に、
前記メッセージが前記ポリシー設定に適合するか否かを判定することが、
前記要求トークンの発信元である前記コンシューマ(300)に関する情報と、
1以上の操作を許可するよう前記要求トークンを通じて要求される前記保護リソースに関する情報と、
前記要求トークンを通じて許可を要求される前記1以上の操作に関する情報と、
のうちの少なくとも1つを前記メッセージから抽出することと、
前記抽出された情報が前記ポリシー設定に適合するか否かを判定することと、
を含むように構成される
ことを特徴とする請求項8又は9に記載のコントローラ(100)。
【請求項11】
少なくとも1つのサービスプロバイダ(400)から、前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースに関する情報を取得するように構成された取得器
を更に備えることを特徴とする請求項8乃至10のいずれか1項に記載のコントローラ(100)。
【請求項12】
前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースに関する前記情報は、前記少なくとも1つのサービスプロバイダ(400)におけるユーザのIDに関連する前記保護リソースの利用に関する情報を含む
ことを特徴とする請求項11に記載のコントローラ(100)。
【請求項13】
受信したメッセージ、及び、その要求トークンが転送されることが阻止されたか否か、と、
受信した要求トークン、及び、それが転送されることが阻止されたか否か、と、
受信したメッセージ、及び、その要求トークンが転送されることが許可されたか否か、と、
受信した要求トークン、及び、それが転送されることが許可されたか否か、と、
のうちの少なくとも1つに関する、履歴情報と呼ぶ情報を記録するように構成された記録器と、
前記履歴情報をユーザ端末(200)が入手できるようにする開示器と、
を更に備えることを特徴とする請求項8乃至12のいずれか1項に記載のコントローラ(100)。
【請求項14】
請求項8乃至13のいずれか1項に記載のコントローラ(100)と、
前記コントローラ(100)と通信可能なユーザ端末(200)と、
を備え、
前記ユーザ端末(200)は、前記コントローラ(100)の中の前記ポリシー設定を設定するように構成される
ことを特徴とするシステム。
【請求項15】
コントローラ(100)において実行された場合に、前記コントローラ(100)に、請求項1乃至7のいずれか1項に記載の方法を実行させるように構成された命令を含んだコンピュータプログラム。
【図1】
【図2】
【図3】
【図4】
【図5a】
【図5b】
【図5c】
【図6a】
【図6b】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5a】
【図5b】
【図5c】
【図6a】
【図6b】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公表番号】特表2013−508831(P2013−508831A)
【公表日】平成25年3月7日(2013.3.7)
【国際特許分類】
【出願番号】特願2012−534549(P2012−534549)
【出願日】平成21年10月22日(2009.10.22)
【国際出願番号】PCT/EP2009/063891
【国際公開番号】WO2011/047722
【国際公開日】平成23年4月28日(2011.4.28)
【出願人】(598036300)テレフオンアクチーボラゲット エル エム エリクソン(パブル) (2,266)
【出願人】(511227473)ウニベルシダッド ポリテクニカ デ マドリッド (4)
【氏名又は名称原語表記】Universidad Politecnica de Madrid
【住所又は居所原語表記】Ramiro de Maeztu, 7, E−28040 Madrid, SPAIN
【公表日】平成25年3月7日(2013.3.7)
【国際特許分類】
【出願日】平成21年10月22日(2009.10.22)
【国際出願番号】PCT/EP2009/063891
【国際公開番号】WO2011/047722
【国際公開日】平成23年4月28日(2011.4.28)
【出願人】(598036300)テレフオンアクチーボラゲット エル エム エリクソン(パブル) (2,266)
【出願人】(511227473)ウニベルシダッド ポリテクニカ デ マドリッド (4)
【氏名又は名称原語表記】Universidad Politecnica de Madrid
【住所又は居所原語表記】Ramiro de Maeztu, 7, E−28040 Madrid, SPAIN
[ Back to top ]