JP2019200515A - 情報処理装置、情報処理方法、およびコンピュータプログラム - Google Patents

Abstract

【課題】標準仕様に則りつつ、アクセス権の情報をネットワークに合わせて変更することができる情報処理装置、情報処理方法、及びコンピュータプログラムを提供する。【解決手段】クライアントにリソースを提供するリソースサーバーへの標準仕様であるＯＡｕｔｈ２．０に基づくアクセス権の情報を管理する情報処理装置は、クライアントが属するネットワークに関する付加情報を評価する評価手段と、評価結果に基づき、クライアントに付与するアクセス権を変更する変更手段と、を有する。アクセス権の変更は、ＯＡｕｔｈ２．０の権限スコープを拡張した形式である拡張権限スコープを削除、追加、置換することにより行う。【選択図】図６

Description

本発明は、標準仕様に基づくアクセス権の情報を管理する情報処理装置、情報処理方法、およびコンピュータプログラムに関する。

Ｗｅｂ上のリソースにアクセスする際に、適切な権限にもとづいたアクセスを行うことを目的とした認可の標準プロトコル仕様として、ＯＡｕｔｈ２．０が策定されている。ＯＡｕｔｈ２．０においては、リソースの所有者であるユーザーが、リソースを利用する主体であるＯＡｕｔｈ２．０クライアントからのアクセス権の要求にもとづき、クライアントにリソースを利用する権限を移譲する。移譲されたクライアントに対しては、リソースへのアクセスが許可される。この際、クライアントには認証により識別が行われる。この時、クライアントに割り当てる権限は、権限を管理する主体であるＯＡｕｔｈ２．０プロバイダに事前に登録される。更に、認可のシーケンスの過程で、クライアントからの認可リクエストを検証した上でクライアントに対して認可を行ったことを示す、認可トークンを発行することで、クライアントに適切なアクセス権を移譲する。ＯＡｕｔｈ２．０プロバイダは、クライアントが要求したアクセス権限の範囲（以降、権限スコープと呼称する）と、ＯＡｕｔｈ２．０プロバイダに事前に登録されている、クライアントに許可された権限スコープとを比較する。この比較の結果が適切である場合にのみ、認可トークンの発行が許可される。認可トークンには、クライアントに許可する権限スコープの情報が付与される。ユーザーのリソースを管理するリソースサーバーはＯＡｕｔｈ２．０クライアントから送付される認可トークンを検証することで、ＯＡｕｔｈ２．０クライアントからリソースへのアクセスリクエストが適切な権限にもとづいて実行されることになる。ＯＡｕｔｈ２．０では、複数のリソースに対する認可を、ＯＡｕｔｈ２．０プロバイダで集約して権限管理を行うことができるため、実装および運用のコスト面で優れている。

また、正規の利用者であっても、常時リソースへのアクセスを許可するのではなく、リソースアクセスを行う際のクライアント端末の周辺のコンテキストに応じて、アクセスを許可するか否かを判定する手段が提案されている（特許文献１）。本技術では、例えば、利用者のクライアントが周囲に上位権限者がいることを検知できる場合にのみリソースへのアクセスを許可する、という形のアクセス制御を実現している。

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

しかしながら、ＯＡｕｔｈ２．０認可フローでは、ユーザーおよび、ＯＡｕｔｈ２．０クライアントがともに正常に認証され、クライアントからリクエストされた権限が登録されている場合には一律認可トークンが発行されていた。このことは、例えばアクセスを求める主体が信頼のおけない脆弱なネットワークに存在している場合にも、認可が正しく行われることを意味している。また、特許文献１に記載の方法においては、周辺コンテキスト情報から認可の範囲を設定する仕組みを取っており、ＯＡｕｔｈ２．０のような標準仕様との互換性は無かった。

本発明は、上述した課題を解決するためになされたものであり、標準仕様に則りつつ、アクセス権の情報をネットワークに合わせて変更することを目的とする。

上記目的を達成するために、本発明は、クライアントにリソースを提供するリソースサーバーへの標準仕様に基づくアクセス権の情報を管理する情報処理装置であって、前記クライアントが属するネットワークに関する付加情報を評価する評価手段と、前記評価結果に基づき、前記クライアントに付与する前記アクセス権を変更する変更手段と、を有することを特徴とする。

本発明によれば、標準仕様に則りつつ、アクセス権の情報をネットワークに合わせて変更することが出来る。

認可システムの構成を示す図 認可フローのコンポーネント構成を示す図 認可フローのシーケンスを示す図 クライアントの権限スコープの登録フローのフローチャートを示す図 認可フローのフローチャートを示す図 認可フローのフローチャートを示す図 拡張権限スコープの登録データの一例を示す図 認可コード発行リクエストの一例を示す図 権限スコープの評価結果の一例を示す図 認可コードの一例を示す図 認可トークンの発行リクエストの一例を示す図 認可トークンの一例を示す図

以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

（実施形態１）
本実施形態で説明される認可システムの構成について、図１を参照して説明する。本実施形態における認可システムは単一の情報処理装置（コンピュータ）で実現してもよいし、必要に応じた複数の情報処理装置に各機能を分散して実現するようにしてもよい。複数の情報処理装置で構成される場合は、互いに通信可能なようにＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）などで接続されている。

本実施形態の認可システム１０１は、拡張権限スコープ管理手段１０２、認可コード発行手段１０３、権限条件評価手段１０４、権限スコープ変更手段１０５、認可トークン発行手段１０６、認可トークン検証手段１０７、から構成される。

認可システム１０１は、ユーザーの所有するリソースに対してアクセスを要求する対象の正当性を検証し、認可によりアクセス権限を移譲するシステムである。拡張権限スコープ管理手段１０２は、標準仕様であるＯＡｕｔｈ２．０の権限スコープを拡張した形式で表記される、クライアントに許可する操作権限を管理する手段である。認可コード発行手段１０３は、クライアントからの認可リクエスト及びユーザーの認証情報を検証し、ユーザーの認可への同意を得たことを示す認可コードを発行する手段である。権限条件評価手段１０４は、クライアントがリクエストした権限スコープと、リクエストに付与された付加情報と、拡張権限スコープ管理手段に登録された拡張権限スコープとを照会する。それにより、クライアントの要求する権限スコープとクライアントの付加情報が登録された拡張権限スコープにマッチするかどうかを判定する手段である。権限条件評価手段１０４での評価結果にもとづき、リクエストされた権限スコープから、権限が変更された新しい権限スコープを生成する手段である。認可トークン発行手段は１０６、認可コード発行手段１０３で発行された認可コードを受け付け、認可が行われたことを示す認可トークンを発行する手段である。認可トークン検証手段１０７は、認可トークンが有効なトークンかどうかを検証する手段である。

本実施形態の認可システム１０１を利用して、認可を行うためのコンポーネント配置構成の一例を図２に示す。クライアント２０１、認可サービスプロバイダ２２１、リソースサーバー２３１は、ネットワーク２１１を介して接続する。リソースサーバー２３１は、クライアントに対してそのリソースを提供する。クライアントは、ユーザーのリソースへのアクセス要求を受け付け、処理を代行する。クライアントはユーザーに対して認可要求を承認する画面、及び認証画面を表示するＷｅｂブラウザ２０２と、認可サービスプロバイダ及びリソースサーバーへリクエストを送受信するＷｅｂＡＰＩクライアント２０３から構成される。認可サービスプロバイダは、認可システム１０１を内包し、クライアントの要求に対して認可トークンを発行するとともに、リソースサーバーから送付された認可トークンを検証する。認可のリクエストを受け付ける認可ＡＰＩ２２３と、ユーザー認証に利用するユーザーの情報を格納するユーザーデータストア２２４から構成される。認可システム１０１はクライアントおよびクライアントに紐づいた拡張権限スコープを管理する拡張権限スコープ管理手段１０２を有している。リソースサーバー２３１は、クライアントからのリクエストを受け付け、要求されたリソースを返却する。リソースサーバーは、クライアントに対してリソースを公開するＷｅｂＡＰＩ２３３を有する。また、クライアントから受け付けた認可トークンを認可サービスプロバイダの認可ＡＰＩに送付し、認可トークンの妥当性を検証するＷｅｂＡＰＩクライアント２３２を有する。更に、クライアントに返却するリソースを格納するリソースデータストア２３４を有する。

以降、本実施形態の認可システムの動作例について、図３〜図１２を用いて説明する。図４〜５に示すフローチャートにおけるアクセスの関係を図３に示す。認可サービスプロバイダに対して、クライアントに許可する拡張権限スコープを登録するフローチャートを図４に、拡張権限スコープを用いた認可のフローのフローチャートを図５に、リソースサーバーでの認可処理を図６に示す。また、アクセスの過程でやり取りされる、リクエストの例を図７〜図１２に示す。

認可サービスプロバイダへの拡張権限スコープ登録についてフローチャート及びシーケンスのＳ４０１〜Ｓ４０２に示す。登録が開始（Ｓ４０１）されると、認可サービスプロバイダの管理者は、認可システムの拡張権限スコープ管理手段に、クライアントに対する拡張権限スコープの登録を行う（Ｓ４０２）。拡張権限スコープ登録データの一例を図７に記載する。図７において、ｃｌｉｅｎｔ＿ｉｄ属性はクライアントを一意に識別するＩＤであり、ここでは、ｍｙＳｅｒｖｉｃｅＣｌｉｅｎｔ０１が割りあてられる。ｓｃｏｐｅｓ属性は拡張権限スコープを表す。ここでは、通常のＯＡｕｔｈ２．０表記で書かれた権限スコープであるｒｅａｄと、拡張表記法で記載されたｄｏｗｎｌｏａｄが指定されている。ｄｏｗｎｌｏａｄ権限の＄以降が拡張表記であることを表現し、ここではａｃｃｅｐｔ＿ｉｐ＿ｒａｎｇｅ［ ］指定により、［ ］内に記載される特定のＩＰからのリクエストが来た場合にのみこの権限スコープの発行を許すことを表現している。すなわち、この場合は２１６．２１３．１０．０／２４のＩＰレンジからリクエストが来た場合のみ、ｄｏｗｎｌｏａｄを要求することを許可する。以降、クライアントはこの拡張権限スコープの範囲の権限をクライアントに移譲することへの同意をユーザーに求めることができる。ここではＩＰアドレスについて記載しているが、本実施形態はＩＰアドレスに限定されるものではなく、ユーザーのＩＤやロール、ユーザーエージェント、ドメイン名、リクエスト時間などの付加情報を利用しても良い。

次に、クライアントの認可トークン取得フローについてフローチャートＳ及びシーケンスＳ５０１〜Ｓ５１３に示す。先ず、ユーザーがクライアントの機能を利用する（Ｓ５０１）にあたり、ユーザーがクライアントにアクセスする（Ｓ５０２）。次に、クライアントは、評価条件への入力に利用する付加情報として、自身の周辺コンテキストを収集する（Ｓ５０３）。本例では、自身に割り当てられたＩＰアドレスの情報を取得し、クライアントのＩＰアドレスは、２１６．２１３．１．７であるものとする。ここでは、自身の周辺コンテキストを収集することとしているが、通常のリクエストの過程で付与されるメタデータを権限スコープ評価に用いても良い。例えば、送信元ＩＰアドレスはＨＴＴＰリクエストを行った場合にはＸ−Ｆｏｒｗａｒｄｅｄ−ＦｏｒのＨＴＴＰヘッダに付与されるのが通例であり、本メタデータを利用すると、認可サービスプロバイダはクライアントのＩＰアドレスを取得することができる。そのため、この場合クライアントは拡張権限スコープの表記を意識してリクエストを行う必要はない。次に、クライアントは移譲を希望する権限スコープと、Ｓ５０３により取得した周辺コンテキストを付加情報として指定して、ＷｅｂＡＰＩクライアントを介して、認可サービスプロバイダに認可トークン発行リクエストを行う（Ｓ５０４）。ここではＨＴＴＰリクエストでリクエストを行うものとする。ＨＴＴＰリクエストの一例を図８に記載する。図８では、Ｘ−Ｆｏｒｗａｒｄｅｄ−Ｆｏｒヘッダにクライアント自身のＩＰアドレスを指定した上で、拡張表記でない権限スコープを指定してリクエストを行った内容を記載している。認可サービスプロバイダの認可ＡＰＩがリクエストを受け付けると、認可サービスプロバイダに配置された認可システムの認可コード発行手段にリクエストを引き渡す。その後、認可コード発行手段は拡張権限スコープ管理手段から、リクエストされた権限スコープに一致する権限スコープを検索する。次に、権限条件評価手段にて、検索結果に拡張権限スコープ表記が用いられているかどうかを判定する（Ｓ５０５）。一致する権限スコープが拡張権限スコープとして評価条件が表記されている場合には、認可コード発行手段は権限条件評価手段に対して、クライアントから送付された付加情報と権限スコープを入力する。権限条件評価手段では、入力された権限スコープに対応する拡張権限スコープの表記にもとづいて、付加情報の内容を評価する（Ｓ５０６）。評価により、権限条件評価結果が生成される。生成された評価結果の一例を図９に示す。評価条件で許可されたＩＰレンジ２１６．２１３．１０．０／２４に対し、クライアントのＩＰ２１６．２１３．１．７は含まれないため、権限条件評価手段は、この権限スコープの発行は許可されないものとしてｄｅｎｉｅｄ評価を付与している。権限スコープ評価手段は、権限条件評価結果にもとづき、クライアントに許可する権限スコープを変更する（Ｓ５０７）。ｄｏｗｎｌｏａｄ権限スコープのｄｅｎｉｅｄ評価にもとづいて、ｄｏｗｎｌｏａｄ権限スコープを削除する。ｒｅａｄ権限スコープは評価無しであるため、発行を許可する。本例では、拡張表記にもとづいて権限スコープを削除する手段について記載したが、権限スコープを追加するという変更を行っても良い。また、表記にもとづいて他の権限スコープに置換する、１つ以上の別の権限スコープに変更する、といった形で権限スコープを変更してもよい。例えば、ｄｏｗｎｌｏａｄ＄ａｃｃｅｐｔ＿ｉｐ＿ｒａｎｇｅにマッチしないＩＰレンジからのリクエストにおいては、読み込みのみを許可するファイルをダウンロードさせるｒｅａｄｏｎｌｙ＿ｄｏｗｎｌｏａｄに権限スコープを置換する。また、オリジナルの画像をサムネイル、Ｗｅｂ画面サイズ、透かし入りにそれぞれ加工した画像をダウンロード許可する。これらは、ｔｈｕｍｂｎａｉｌ＿ｄｏｗｎｌｏａｄ、ｗｅｂＩｍａｇｅ＿ｄｏｎｗｌｏａｄ、ｗａｒｔｅｒＭａｒｋ＿ｄｏｗｎｌｏａｄの３権限を許可する。このような権限スコープ変更を行うことも可能である。評価条件の表記が無い権限スコープに対してリクエストが行われた場合には、認可システムは、通常のＯＡｕｔｈ２．０フローとして認可コードを発行する。クライアントのＷｅｂブラウザは、評価の結果生成された権限スコープをユーザーに対して表示するとともに、ユーザーの認証情報入力と、クライアントに権限を移譲することへの同意を求める画面を表示する（Ｓ５０８）。ユーザーは画面に対してユーザーＩＤとパスワードを入力する（Ｓ５０９）とともに、認証情報とクライアントへの移譲に対する同意を認可サービスプロバイダに送付する（Ｓ５１０）。ユーザーの認証情報と同意情報を認可ＡＰＩから認可コード発行手段が受け付けると、Ｓ５０８でユーザーに返却した権限スコープにもとづき、ユーザーが権限スコープへの認可を行ったことを示す認可コードを発行する（Ｓ５１１）。発行された認可コードの一例を図１０に示す。認可コードを取得したクライアントは、ＷｅｂＡＰＩクライアントを利用して、取得した認可コードとクライアント自身のＩＤ及びパスワードを指定して、認可サービスプロバイダの認可ＡＰＩに認可トークン発行リクエストを行う（Ｓ５１２）。認可サービスプロバイダ内認可システムの認可トークン発行手段は、認可コードをもとに認可トークンの発行を行う（Ｓ５１３）認可トークンの一例について図１１に示す。認可トークンにはアクセスを許可する権限スコープが示されている。これは、Ｓ５０８でユーザーに提示された権限スコープに一致するものであり、本権限スコープに対してクライアントにアクセスを許可することを示すものである。

次に、認可された権限スコープを用いてクライアントがリソースへのアクセスを行うフローについて、フローチャート及びシーケンスＳ６０１〜Ｓ６０５に示す。クライアントによるリソースへのリクエストが開始する（Ｓ６０１）と、クライアントは、リソースサーバー上の任意のリソースに対するｒｅａｄをリソースＡＰＩに対して、認可トークンを指定してリクエストする（Ｓ６０２）。リソースサーバーのリソースＡＰＩがリクエストと認可トークンを受け付けると、リソースサーバーはＷｅｂクライアントを利用して、認可サービスプロバイダの認可ＡＰＩに認可トークンの検証をリクエストする（Ｓ６０３）。認可サービスプロバイダは、受け付けた認可トークンを認可システムの認可トークン検証手段に引き渡す。認可トークン検証手段が認可トークンの妥当性検証を行うと、認可サービスプロバイダは検証結果をリソースサーバーに返却する（Ｓ６０４）。返却結果が妥当であった場合、リソースサーバーは認可トークンの権限スコープ確認を行う（Ｓ６０５）。返却結果が不正であった場合には、リソースサーバーはクライアントからのアクセスを拒否する。本権限スコープ確認においては、クライアントが送付した認可トークンの権限スコープに、クライアントのリクエストした処理であるｒｅａｄが含まれるかを確認する。本例では、認可トークンの権限スコープにｒｅａｄが含まれるため、リソースサーバーはクライアントのリソースアクセスを許可し、リソースリポジトリから取得したリソースをクライアントに返却する（Ｓ６０６）。クライアントのリクエストした権限スコープが認可トークンの権限スコープに含まれない場合、例えば、ｄｏｗｎｌｏａｄを指定した場合には、リソースサーバーはリソースへのアクセスを拒否する。

（その他の実施形態）
以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、撮像装置、ｗｅｂアプリケーション等）から構成されるシステムに適用しても良い。また、一つの機器からなる装置に適用しても良い。

また、本発明の目的は、以下のようにすることによって達成されることはいうまでもない。即ち、前述した実施形態の機能を実現するソフトウェアのプログラムコード（コンピュータプログラム）を記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給する。係る記憶媒体は言うまでもなく、コンピュータ読み取り可能な記憶媒体である。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行する。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。

Claims (10)

1. クライアントにリソースを提供するリソースサーバーへの標準仕様に基づくアクセス権の情報を管理する情報処理装置であって、
   前記クライアントが属するネットワークに関する付加情報を評価する評価手段と、
   前記評価結果に基づき、前記クライアントに付与する前記アクセス権を変更する変更手段と、を有することを特徴とする情報処理装置。
2. 前記付加情報は、前記クライアントのＩＰアドレス、ＩＤ、ロール、ユーザーエージェント、ドメイン名および、リクエスト時間の少なくともいずれか一つであることを特徴とする請求項１に記載の情報処理装置。
3. 前記変更手段は、ＯＡｕｔｈ２．０の権限スコープを拡張した形式で前記アクセス権を変更することを特徴とする請求項１または請求項２に記載の情報処理装置。
4. 前記変更手段は、前記アクセス権に含まれる権限スコープを削除することにより、前記アクセス権を変更することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記変更手段は、前記アクセス権に権限スコープを追加することにより、前記アクセス権を変更することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
6. 前記変更手段は、前記アクセス権に含まれる権限スコープを置換することにより、前記アクセス権を変更することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
7. 前記付加情報は、ＨＴＴＰリクエストのＨＴＴＰヘッダに指定される情報であることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 前記評価手段は、前記クライアントが特定のネットワークのＩＰアドレスに属しているか否かに基づき評価することを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
9. クライアントにリソースを提供するリソースサーバーへの標準仕様に基づくアクセス権の情報を管理する情報処理装置の情報処理方法であって、
   評価手段が、前記クライアントが属するネットワークに関する付加情報を評価する評価工程と、
   変更手段が、前記評価結果に基づき、前記クライアントに付与する前記アクセス権を変更する変更工程と、を有することを特徴とする情報処理方法。
10. コンピュータを、
    クライアントにリソースを提供するリソースサーバーへの標準仕様に基づくアクセス権の情報を管理する情報処理装置であって、
    前記クライアントが属するネットワークに関する付加情報を評価する評価手段と、
    前記評価結果に基づき、前記クライアントに付与する前記アクセス権を変更する変更手段と、を有することを特徴とする情報処理装置として機能させるためのコンピュータプログラム。

Images