JP7301668B2 - システム、制御方法、プログラム - Google Patents

Description

本発明は、ユーザーのリソースの権限委譲を可能とするシステム、制御方法、プログラムに関する。

クラウドのｗｅｂサービスでＯＡｕｔｈ２．０による権限委譲を実現している。特許文献１ではシステム連携を設定する際にユーザーは、クライアントと認可サーバーの両方をウェブブラウザで操作し、認可操作を行うことで、ユーザーの権限をクライアントに委譲できることについて開示している。クライアントは、委譲されたユーザーの権限を用いて、ユーザーのリソースにアクセスでき、システム連携が実現する。

特許５６２３２３４

ＯＡｕｔｈ２．０でユーザーの権限をクライアントに委譲するためには、ユーザーがクライアントにウェブブラウザでアクセスすることが必要になる。例えば、マルチテナントシステムで、外部システムから各テナントのデータを解析する際に各テナントの管理者の許可が必要なケースを考える。この場合、解析処理のタイミングでテナントの管理者がクライアントである外部システムにアクセスすることを期待できず、クライアントが自律的に権限委譲の要求を行う必要がある。

また、あらかじめユーザー特定できる場合はそのユーザーに権限委譲を求められるが、クライアントがアクセスしたいリソースは分かっているものの、そのリソースの所有者が分からず、ユーザーを指定して権限委譲を求められない場合が考えられる。例えば、データ解析対象のテナントは識別できるものの、その管理者ユーザーが不明なケースでは、前述の課題が発生する。

本発明は前述の課題を鑑みてなされたもので、本発明はクライアントがリソース所有者を指定して権限委譲を求められない場合に、リソースを指定して権限委譲を求められるようにすることを目的とする。

本発明の一実施形態に係る認可サーバーは、ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムにおける前記認可サーバーであって、前記クライアントがアクセスするリソースに対応するリソース識別子を含んだ認可開始リクエストを受信する受信手段と、前記受信手段により受信された認可開始リクエストに含まれる前記リソース識別子とともに、前記リソース識別子に対応するリソースの所有者であるユーザーを解決するための要求を前記リソースサーバーへ送信する送信する送信手段と、前記要求に対する応答として取得したユーザーの情報に関連づく端末情報を特定する特定手段と、特定された端末情報に対応するユーザー端末に対して認可確認リクエストを送信し、応答として認可確認の結果を受信する確認手段と、前記確認手段により受信された認可確認の結果に応じて前記アクセストークンの発行を制御し、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ発行した前記アクセストークンを送信する発行手段と、を有することを特徴とする。

本願発明によれば、クライアントがアクセスしたいリソースは分かっているものの、そのリソースの所有者が分からない場合でも、認可開始リクエストを行えるようになる。

ネットワーク構成を示す図である。 本実施の形態に係る、認可サーバー１５１の構成を示す図である。 本実施の形態に係る、モジュール構成を示す図である。 本実施の形態に係る、認可開始リクエストおよび認可確認リクエストのフローである。 本実施の形態に係る、アクセストークン発行フローである。 本実施の形態に係る、全体のフローである。 本実施の形態に係る、認可確認画面の例である。 本実施の第２の形態に係る、モジュール構成を示す図である。 本実施の第２の形態に係る、リソースアクセスのフローである。 本実施の第３の形態に係る、モジュール構成を示す図である。 本実施の第３の形態に係る、リソース所有者の変更フローである。

以下、本発明を実施するための形態について図面を用いて説明する。

本実施の形態に係る権限委譲システムは、図１に示すような構成のネットワーク上に実現される。１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１１０、１５０、１７０は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１１０、ＬＡＮ１５０、ＬＡＮ１７０）である。

１５２はユーザーのリソースを管理するリソースサーバーであり、１１１はリソースサーバー１５２上のリソースにアクセスするクライアントである。ここでクライアント１１１がリソースサーバー１５２上のリソースにアクセスするためには、リソース所有者であるユーザーがクライアント１１１に権限を委譲する必要がある。１５１はクライアントの求めに応じてリソースへのアクセス許可の証拠となるアクセストークンを発行する認可サーバーである。１７１はクライアント１１１が権限委譲を求めた際に認可確認画面を表示するユーザー端末である。

認可サーバー１５１、リソースサーバー１５２はそれぞれＬＡＮ１５０を介してＷＡＮ１００と接続されている。また同様にクライアント１１１はＬＡＮ１１０を介して、ユーザー端末１７１はＬＡＮ１７０を介して、それぞれＷＡＮ１００と接続されている。なお認可サーバー１５１、リソースサーバー１５２はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。同様に、同一のＰＣまたはサーバーコンピューター上に構成されていてもよい。また、認可サーバー１５１、リソースサーバー１５２は図１ではそれぞれが１台として描かれているが複数のサーバーから構成されたサーバーシステムでも良い。例えば、複数台のサーバーをクラスタ化して認可サーバー１５１を構成しても良い。なお、本願発明においてサーバーシステムと称した場合は、少なくとも１台のサーバーから構成された特定のサービスを提供する装置を指すものとする。

本実施の形態に係るイベント通知システムは、図２に示すような構成のＰＣから成るシステム上に実現される。図２は本実施の形態に係る、認可サーバー１５１の構成を示す図である。またクライアント１１１、リソースサーバー１５２の構成やユーザー端末１７１の構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のサーバーコンピューターおよび端末には一般的な情報処理装置のハードウェア構成を適用できる。

図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムである。ソフトウェア上の主体は、ＣＰＵ２０１がそれらプログラムを実行することで実現する。

図３は本実施の形態に係る、クライアント１１１、認可サーバー１５１、リソースサーバー１５２のモジュール構成を示す図である。図３（Ａ）はクライアント１１１、図３（Ｂ）は認可サーバー１５１、図３（Ｃ）はリソースサーバー１５２のモジュール構成を、それぞれ示す。また図３（Ｄ）はユーザー端末１７１のモジュール構成を示す。クライアント１１１は認可開始リクエスト発行モジュール３０１、アクセストークン要求モジュール３０２、アクセストークン管理モジュール３０３、リソースアクセスモジュール３０４を持つ。認可サーバー１５１は認可リクエスト管理モジュール３５１、リソース所有者解決モジュール３５２、認可確認モジュール３５３、アクセストークン発行モジュール３５４を持つ。リソースサーバー１５２はリソース管理モジュール３７１を持つ。ユーザー端末１７１は認可操作受付モジュール３９１を持つ。

認可サーバー１５１の認可リクエスト管理モジュール３５１は、クライアント１１１の認可開始リクエスト発行モジュール３０１の要求に従い、認可開始リクエストを処理する。ここで認可開始リクエストにはクライアント１１１がアクセスしようとするリソース情報が含まれる。リソース所有者解決モジュール３５２は認可開始リクエストに含まれるリソース情報を用いて、リソースサーバー１５２に対し、当該リソースのリソース所有者情報を問い合わせる。ここで得られたリソース所有者情報を元に、認可確認モジュール３５３は、特定のユーザー端末１７１に対し認可確認リクエストを行う。認可確認リクエストに対しユーザーが認可操作を行うと、クライアント１１１は、認可サーバー１５１からアクセストークンを取得できるようになり、またリソースサーバーに対してアクセスできるようになる。

図４（Ａ）は本実施の形態に係る、クライアント１１１が認可サーバー１５１に対し認可開始リクエストを行うフローである。本フローはクライアント１１１がリソースサーバー１５２上のリソースへのアクセスに先立ち、アクセストークンが必要になった際に開始される。

ステップＳ４０１で認可開始リクエスト発行モジュール３０１は、操作対象のリソース識別子およびスコープを含む認可開始リクエストを、認可サーバー１５１に対して送信する。ここでスコープは、リソースへのアクセス範囲を示す。

ステップＳ４０２で認可開始リクエスト発行モジュール３０１は、認可サーバー１５１からレスポンスを受信する。このレスポンスには、認可サーバー１５１が発行した認可リクエスト識別子が含まれる。

ステップＳ４０３で認可開始リクエスト発行モジュール３０１は、ステップＳ４０２で受信したレスポンスに含まれる認可リクエスト識別子を、ステップＳ４０１の操作対象リソースおよびスコープとともに記憶し、フローを終了する。表１はクライアント１１１が記憶する認可リクエスト管理テーブルの例である。

表１ではリソース識別子“／ｄａｔａｌａｋｅ／ｉｏｔ００１０／ｄａｔａ”で示されるリソースに対し、スコープ“ｇｅｔ－ｄａｔａ”で行った認可開始リクエストが、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”に関連付けて記憶されている。また認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”に対しては、“ａｃｔｋ１１１２２２３３３”で示されるアクセストークンを取得済みであることを示す。ここでリソース識別子が示すリソースは、ファイルシステム上の１つのファイルを示してもよく、データベース上の特定のレコードを示してもよい。またそれらの集合を示してもよい。

図４（Ｂ）は本実施の形態に係る、認可サーバー１５１における認可開始リクエストの受信フローである。本フローは認可サーバー１５１がクライアント１１１から認可開始リクエストを受信することで開始される。

ステップＳ４１１で認可リクエスト管理モジュール３５１は、クライアント１１１から認可開始リクエストを受け付ける。ここで認可開始リクエストには、クライアント１１１のクライアント識別子と、クライアント１１１が操作対象としているリソース識別子が含まれる。

ステップＳ４１２でリソース所有者解決モジュール３５２は、ステップＳ４１１で指定されたリソースの所有者を、リソースサーバー１５２に問い合わせる。ステップＳ４１３でリソース所有者解決モジュール３５２は、ステップＳ４１２の問い合わせの応答として、ステップＳ４１１で指定されたリソースの所有者のユーザー識別子を受信する。ステップＳ４１４で認可リクエスト管理モジュール３５１は、ステップＳ４１１で受信した認可開始リクエストに対応する認可リクエスト識別子を生成する。

ステップＳ４１５で認可リクエスト管理モジュール３５１は、ステップＳ４１４で生成した認可リクエスト識別子に、認可リクエストの情報を関連付けて記憶する。ここで認可リクエストの情報とは、ステップＳ４１１で受信したクライアント識別子、操作対象のリソース識別子、スコープと、ステップＳ４１３で受信したユーザー識別子を含む。表２は認可リクエスト管理モジュール３５１が記憶する認可確認状況管理テーブルの例である。

表２では、クライアント識別子“ｃｌｉｅｎｔ＿ｘｙｚ”で示されるクライアントが、リソース識別子“／ｄａｔａｌａｋｅ／ｉｏｔ００１０／ｄａｔａ”で示されるリソースに対し、スコープ“ｇｅｔ－ｄａｔａ”で行った認可開始リクエストが、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”に関連付けて記憶されている。また認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”にはユーザー識別子“ｕｓｅｒ＿ａｂｃｄｅ”が関連付けられているが、これはリソース“／ｄａｔａｌａｋｅ／ｉｏｔ００１０／ｄａｔａ”のリソース所有者を解決した結果、ユーザー識別子が”ｕｓｅｒ＿ａｂｃｄｅ”だったことを示している。なお認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”の認可結果が“（空欄）”となっているのは、ユーザーがまだ認可操作を行っていないことを示している。それに対し認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”の認可結果は“ａｐｐｒｏｖｅｄ”で、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿４４４４４”の認可結果は“ｄｉｓａｐｐｒｏｖｅｄ”である。これらはそれぞれ、ユーザーが認可を行ったことと、認可を拒否したことをそれぞれ示している。

ステップＳ４１６で認可リクエスト管理モジュール３５１は、ステップＳ４１１の応答として、ステップＳ４１４で生成した認可リクエスト識別子をクライアント１１１に返し、フローを終了する。

図４（Ｃ）は本実施の形態に係る、認可サーバー１５１における認可確認リクエストを行うフローである。本フローはステップＳ４１５で認可リクエストの情報を記憶したことを受けて開始される。

ステップＳ４２１で認可確認モジュール３５３は、ステップＳ４１５で記憶した認可リクエスト識別子に紐付くユーザー識別子を取得する。ここで、ステップＳ４１５で記憶した認可リクエスト識別子が“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”であれば、紐付くユーザー識別子は“ｕｓｅｒ＿ａｂｃｄｅ”である。

ステップＳ４２２で認可確認モジュール３５３は、ステップＳ４２１で取得したユーザー識別子から、ユーザー端末１７１を特定する。表３はユーザー識別子とユーザー端末１７１の対応を記憶するユーザー管理テーブルの例である。

ここでユーザー識別子“ｕｓｅｒ＿ａｂｃｄｅ”に対応するユーザー端末情報は、”１９２．１６８．０．１”であることが分かる。このように、端末情報からユーザーが保有するユーザー端末が特定される。ステップＳ４２３で認可確認モジュール３５３は、ステップＳ４１５で記憶した認可リクエスト識別子に紐付くクライアント識別子およびスコープを取得する。ここで、ステップＳ４１５で記憶した認可リクエスト識別子が“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”であれば、紐付くクライアント識別子およびスコープはそれぞれ“ｃｌｉｅｎｔ＿ｘｙｚ”および“ｇｅｔ－ｄａｔａ”である。

ステップＳ４２４で認可確認モジュール３５３は、ステップＳ４２２で特定したユーザー端末１７１に対し、ステップＳ４２３で取得したクライアント識別子、リソース識別子およびスコープを含めて認可確認リクエストを送信する。なお認可確認リクエストの送信方法は、ユーザー端末１７１のエンドポイントを指定した通信方法でもよく、またＭＱＴＴ（Ｍｅｓｓａｇｅ Ｑｕｅｕｅｉｎｇ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ）をはじめとするＰＵＳＨ通知を用いた方法でもよい。またその他の方法でもよい。いずれにせよ、ユーザー端末１７１からのアクセスから通信がスタートするのではなく、認可確認モジュール３５３からユーザー端末１７１に対して通信を開始することになるので、サーバー側からユーザー端末へ通信できる通信方式が必須となる。

ユーザー端末１７１の認可操作受付モジュール３９１は、取得した認可確認リクエストを基に、図７に示すような認可確認画面１００１を表示し、ユーザーに認可を求める。表示内容は認可確認リクエストに含まれるクライアント識別子やリソース識別子を参照し決定されるものとする。

ステップＳ４２５で認可確認モジュール３５３は、ステップＳ４２４で送信した認可確認リクエストの応答として、ユーザー端末１７１から認可結果を受信する。ステップＳ４２６で認可確認モジュール３５３は、ステップＳ４２５で受信した認可結果を、ステップＳ４１５で記憶した認可リクエスト識別子に関連付けて記憶し、フローを終了する。表２では、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”に対し、認可されたことを示す“ａｐｐｒｏｖｅｄ”が記憶されている。

図４（Ｄ）は本実施の形態に係る、リソースサーバー１５２におけるリソース所有者を返すフローである。本フローはリソースサーバー１５２が認可サーバー１５１から、リソース所有者の問い合わせを受けて開始される。

ステップＳ４５１でリソース管理モジュール３７１は、認可サーバー１５１からリソース所有者の問い合わせを受信する。この問い合わせにはリソース識別子を含む。ステップＳ４５２でリソース管理モジュール３７１は、ステップＳ４１５で指定されたリソースの所有者のユーザー識別子を取得し、認可サーバー１５１に返し、フローを終了する。表４はリソース管理モジュール３７１におけるリソース管理テーブルの例である。表４では、リソース識別子“／ｄａｔａｌａｋｅ／ｉｏｔ００１０／ｄａｔａ”で示されるリソースの所有者が、ユーザー識別子“ｕｓｅｒ＿ａｂｃｄｅ”であることが示されている。

図５（Ａ）は本実施の形態に係る、認可サーバー１５１がクライアント１１１に認可完了通知を行うフローである。本フローはステップＳ４２６で認可結果を記憶したことを受けて開始される。

ステップＳ５０１で認可確認モジュール３５３は、ステップＳ４２６で記憶した認可リクエスト識別子を取得する。ステップＳ５０２で認可確認モジュール３５３は、ステップＳ５０１で取得した認可リクエスト識別子に紐付くクライアントの接続先情報であるクライアントエンドポイントを取得する。表５はクライアント識別子とクライアントエンドポイントの対応を管理する、クライアント管理テーブルの例である。表５では、クライアント識別子“ｃｌｉｅｎｔ＿ｘｙｚ”のクライアントエンドポイントが、”１０．０．０．１”であることを示している。

ステップＳ５０３で認可確認モジュール３５３は、ステップＳ５０２で取得したクライアントエンドポイントに対し、ユーザーが認可したことを通知し、フローを終了する。なおここでクライアントエンドポイントに通知する内容は、ステップＳ５０１で取得した認可リクエスト識別子でもよく、またユーザーの認可に対応して発行したアクセストークンでもよい。アクセストークンを発行する際は後述の図５（Ｃ）に示されるようなフローを実行する。

図５（Ｂ）は本実施の形態に係る、クライアント１１１が認可サーバー１５１にアクセストークンリクエストを行うフローである。本フローはクライアント１１１が認可サーバー１５１からステップＳ５０３の認可完了通知を受けて開始される。または本フローは、クライアント１１１が、定期的に実行してもよい。

ステップＳ５１１でアクセストークン要求モジュール３０２は、アクセストークンリクエストを行う認可リクエスト識別子を決定する。ここで本フローが定期的に実行される場合には、認可リクエスト識別子は、表１に示される認可リクエスト管理テーブルでアクセストークン未取得のものから選ばれる。また本フローが認可サーバー１５１からの通知を受けて開始される場合は、認可サーバー１５１からの通知に含まれる認可リクエスト識別子が用いられる。

ステップＳ５１２でアクセストークン要求モジュール３０２は、ステップＳ５１１で決定した認可リクエスト識別子を指定して、認可サーバー１５１に対してアクセストークンリクエストを行う。ステップＳ５１３でアクセストークン管理モジュール３０３は、ステップＳ５１２の応答として受信したアクセストークンを記憶し、フローを終了する。表１では、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”に対して取得できた、アクセストークン“ａｃｔｋ１１１２２２３３３”を記憶している様子を示す。

図５（Ｃ）は本実施の形態に係る、認可サーバー１５１がアクセストークンを発行するフローである。本フローは認可サーバー１５１がクライアント１１１からアクセストークンリクエストを受信したことで開始される。

ステップＳ５２１でアクセストークン発行モジュール３５４は、クライアント１１１から受信したアクセストークンリクエストから、認可リクエスト識別子を取得する。ステップＳ５２２でアクセストークン発行モジュール３５４は、アクセストークン発行可否を判断する。

ステップＳ５２３でアクセストークン発行モジュール３５４は、ステップＳ５２２の結果、アクセストークンを発行可能であると判断されたか確認する。アクセストークンを発行可能と判断された場合はステップＳ５２４に遷移する。またアクセストークンを発行不可能と判断された場合はステップＳ５２５に遷移する。

ステップＳ５２４でアクセストークン発行モジュール３５４は、ステップＳ５２１で取得した認可リクエスト識別子に関連付けられたユーザー識別子およびスコープに対応するアクセストークンを発行する。また発行したアクセストークンをクライアント１１１に返し、フローを終了する。表６はアクセストークン発行モジュール３５４で発行されたアクセストークンを管理する、アクセストークン管理テーブルの例である。

表６では、ユーザー“ｕｓｅｒ＿ａｂｃｄｅ”がスコープ“ｇｅｔ－ｄａｔａ”の権限委譲を行ったことを示すアクセストークンが、アクセストークン識別子“ａｃｔｋ１１１２２２３３３”として発行されていることを示す。なおステップＳ５２４でクライアント１１１に返すアクセストークンは、アクセストークン識別子だけでもよく、またアクセストークン識別子に加えユーザー識別子およびスコープを含む構造化されたデータでもよい。ステップＳ５２５でアクセストークン発行モジュール３５４は、アクセストークンを発行できないことをクライアント１１１に通知し、フローを終了する。

図５（Ｄ）は本実施の形態に係る、アクセストークン発行可否判断を行うステップＳ５２２の詳細フローである。ステップＳ５３１でアクセストークン発行モジュール３５４は、表２の認可確認状況管理テーブルを参照し、指定された認可リクエスト識別子に対応する認可結果を確認する。

ステップＳ５３２でアクセストークン発行モジュール３５４は、ステップＳ５３１の確認した認可結果が、認可されていることを表しているか判断する。認可されていることを表していた場合はステップＳ５３３に遷移し、その他の場合はステップＳ５３４に遷移する。ステップＳ５３３でアクセストークン発行モジュール３５４は、アクセストークンを発行可能と判断し、フローを終了する。ステップＳ５３４でアクセストークン発行モジュール３５４は、アクセストークンを発行不可能と判断し、フローを終了する。

図６は本実施の形態に係る、クライアントが認可開始リクエストを行ってからアクセストークンを入手し、リソースアクセスする際の全体のフローである。クライアント１１１は（１）で認可サーバーに対し認可開始リクエストを行い、応答として（２）で認可リクエスト識別子を取得する。（１）はステップＳ４０１およびステップＳ４１１に、（２）はステップＳ４０２およびステップＳ４１６にそれぞれ対応する。

認可サーバー１５１は認可開始リクエストを受けると、認可開始リクエストに含まれるリソース識別子のリソース所有者を解決するため、（３）でリソースサーバー１５２にリソース所有者の問い合わせを行う。また応答として（４）でリソース所有者のユーザー識別子を受信する。（３）はステップＳ４１２およびステップＳ４５１に、（４）はステップＳ４１３およびステップＳ４５２に、それぞれ対応する。

認可サーバー１５１はリソース所有者の解決が済むと、（５）でリソース所有者に関連付けられたユーザー端末１７１に対し認可確認リクエストを行う。ユーザー端末１７１では図７で示される認可確認画面１００１が表示され、ユーザーが認可操作を行う。ユーザーが認可操作を行った結果は、（６）として認可サーバーに返される。（５）はステップＳ４２４に、（６）はステップＳ４２５に、それぞれ対応する。認可サーバー１５１は（６）で認可結果を受信すると、（７）でクライアント１１１に認可完了通知を行う。（７）はＳ５０３に対応する。

クライアント１１１は（７）で認可完了通知を受信するか、もしくは定期的に、（８）で認可サーバー１５１に対してアクセストークンリクエストを行う。また応答として（９）でアクセストークンを受信する。（８）はステップＳ５１２およびステップＳ５２１に、（９）はステップＳ５１３およびステップＳ５２４に、それぞれ対応する。（５）もしくは（９）でアクセストークンを受信したクライアント１１１は、（１０）でリソースサーバー１５２に対しリソースアクセスを行い、応答として（１１）でリソースを取得する。

本実施の形態によれば、クライアントがアクセスしたいリソースは分かっているものの、そのリソースの所有者が分からない場合でも、認可開始リクエストを行えるようになる。すなわち、ユーザーを指定して権限委譲を求める代わりに、リソース識別子を指定して認可開始リクエストを行ってアクセストークンを取得できるようになる。

次に、本発明を実施するための第２の形態について図面を用いて説明する。なお第１の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。リソースサーバー上でリソースの所有者が変更された場合を考えると、変更前のリソース所有者が認可して発行されたアクセストークンでは、当該リソースに対してアクセスを許可すべきではない。

本実施の第２の形態は、前述の課題を鑑みて為されたものである。図８は本実施の第２の形態に係る、リソースサーバー１５２のモジュール構成を示す図である。リソースサーバー１５２はリソース管理モジュール３７１に加え、リソースアクセス制御モジュール３７２を持つ。図９（Ａ）は本実施の第２の形態に係る、クライアント１１１によるリソースサーバー１５２へのリソースアクセスのフローである。本フローはクライアント１１１がアクセストークンを取得したことを受けて開始される。

ステップＳ９０１でリソースアクセスモジュール３０４は、ステップＳ５１３で取得したアクセストークンを用いてリソースサーバー１５２にリソースアクセスを行う。ここでリソースアクセスにはアクセストークンと、操作対象となるリソースの識別子が含まれる。またアクセストークンはアクセストークン識別子だけ含んでいてもよく、またアクセストークン識別子に加えユーザー識別子およびスコープを含む構造化されたデータでもよい。ここではアクセストークンは、アクセストークン識別子に加えユーザー識別子およびスコープを含む構造化されたデータであるとする。構造化されたアクセストークンの例は以下の通りである。
｛“ａｃｃｅｓｓＴｏｋｅｎＩｄ”：”ａｃｔｋ１１１２２２３３３”，“ｕｓｅｒＩｄ”：”ｕｓｅｒ＿ａｂｃｄｅ”，”ｓｃｏｐｅ”：”ｇｅｔ－ｄａｔａ”｝

ステップＳ９０２でリソースアクセスモジュール３０４は、ステップＳ９０１でリソースを取得できたか判断する。リソースを取得できていた場合はステップＳ９０３に遷移し、取得できていなかった場合はステップＳ９０４に遷移する。ステップＳ９０３でリソースアクセスモジュール３０４は、ステップＳ９０１で取得したリソースに対し、所望の処理を行い、フローを終了する。

ステップＳ９０４でリソースアクセスモジュール３０４は、リソースを取得できなかった原因が、リソース所有者の変更であるか判断する。原因がリソース所有者の変更だった場合はステップＳ９０５に遷移し、その他の原因だった場合はフローを終了する。

ステップＳ９０５でリソースアクセスモジュール３０４は、新しいリソース所有者の権限委譲を受けるために、ステップＳ９０１でアクセスしようとしたリソースを指定して認可開始リクエストを行う。認可開始リクエストのフローは図４（Ａ）に示す通りである。

図９（Ｂ）は本実施の第２の形態に係る、リソースサーバー１５２におけるリソースアクセス処理のフローである。本フローはリソースサーバー１５２がクライアント１１１からリソースアクセスを受け付けることで開始される。

ステップＳ９１１でリソース管理モジュール３７１は、クライアント１１１からリソースアクセスを受け付ける。以下では、クライアント１１１によるリソースアクセスの対象となるリソースは、”／ｄａｔａｌａｋｅ／ｉｏｔ００１１／ｄａｔａ”で示されるリソースであるとする。ステップＳ９１２でリソースアクセス制御モジュール３７２は、ステップＳ９１１で受け付けたリソースアクセスに含まれるアクセストークンを取り出す。

ステップＳ９１３でリソースアクセス制御モジュール３７２は、ステップＳ９１２で取り出したアクセストークンに関連付けられたユーザー識別子を確認する。ここではアクセストークンが構造化されたデータであるとし、アクセストークンに直接記載されたユーザー識別子を取り出すこととする。アクセストークンが｛“ａｃｃｅｓｓＴｏｋｅｎＩｄ”：”ａｃｔｋ１１１２２２３３３”，“ｕｓｅｒＩｄ”：”ｕｓｅｒ＿ａｂｃｄｅ”，”ｓｃｏｐｅ”：”ｇｅｔ－ｄａｔａ”｝であれば、ユーザー識別子として”ｕｓｅｒ＿ａｂｃｄｅ”が取り出される。

ステップＳ９１４でリソースアクセス制御モジュール３７２は、ステップＳ９１１で受け付けたリソースアクセスの対象となるリソースのリソース所有者を取得する。表７は、リソース所有者が変更された後のリソース管理テーブルの例を示す。

表７では、リソース所有者変更前の表４と比べ、”／ｄａｔａｌａｋｅ／ｉｏｔ００１１／ｄａｔａ”で示されるリソースの所有者が変更されている。新たなリソース所有者のユーザー識別子は“ｕｓｅｒ＿ｆｇｈｉｊ”である。ここで、ステップＳ９１１で対象となったリソースが”／ｄａｔａｌａｋｅ／ｉｏｔ００１１／ｄａｔａ”であるとしているため、取得されるユーザー識別子は“ｕｓｅｒ＿ｆｇｈｉｊ”である。

ステップＳ９１５でリソースアクセス制御モジュール３７２は、ステップＳ９１３で取り出したユーザー識別子と、ステップＳ９１４で取り出したユーザー識別子を比較する。両者が一致していた場合はステップＳ９１６に遷移し、不一致だった場合はステップＳ９１７に遷移する。ここではそれぞれのユーザー識別子が”ｕｓｅｒ＿ａｂｃｄｅ”および“ｕｓｅｒ＿ｆｇｈｉｊ”であるため、不一致と判断される。

ステップＳ９１６でリソース管理モジュール３７１は、クライアント１１１にリソースを返しフローを終了する。ステップＳ９１７でリソース管理モジュール３７１は、リソースの所有者が変更されたためリソースアクセスできないことをクライアント１１１に通知しフローを終了する。なおここで、リソースアクセスできないことを通知されたクライアント１１１は、図９（Ａ）のフローのステップＳ９０５に従い、ステップＳ９０１でアクセスしようとしたリソースのリソース識別子を指定して認可開始リクエストを行う。認可開始リクエストのフローは図４（Ａ）に示す通りである。

本実施の第２の形態によれば、リソースサーバー上でリソースの所有者が変更された場合に、変更前のリソース所有者が認可して発行されたアクセストークンを用いて当該リソースにアクセスできなくなるため、セキュリティが向上する。

次に、本発明を実施するための第３の形態について図面を用いて説明する。なお第１または２の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。

リソース所有者変更後、新たなリソース所有者に認可を求めるタイミングが、クライアント１１１がリソースサーバー１５２にアクセスした時点とした場合、次の問題がある。すなわち、新たなリソース所有者が認可操作するまで、クライアント１１１は、当該リソースにアクセスできなくなる。

本実施の第３の形態は、前述の課題を鑑みて為されたものである。図１０は本実施の第２の形態に係る、認可サーバー１５１およびリソースサーバー１５２のモジュール構成を示す図である。図１０（Ａ）は認可サーバー１５１のモジュール構成を示す図であり、認可サーバー１５１は認可リクエスト更新モジュール３５５を持つ。図１０（Ｂ）はリソースサーバー１５２のモジュール構成を示す図であり、リソースサーバー１５２はリソース所有者変更モジュール３７３を持つ。

図１１（Ａ）は本実施の第３の形態に係る、リソースサーバー１５２におけるリソース所有者変更のフローである。本フローはリソースサーバー１５２が、リソース所有者の変更を受け付けることで開始される。

ステップＳ１１０１でリソース所有者変更モジュール３７３は、リソース所有者の変更を受け付ける。ここではリソース“／ｄａｔａｌａｋｅ／ｉｏｔ００１１／ｄａｔａ”の所有者を“ｕｓｅｒ＿ｋｌｍｎｏ”に変更することとする。ステップＳ１１０２でリソース所有者変更モジュール３７３は、指定されたリソースの所有者を変更する。表８は、リソース所有者が変更された後のリソース管理テーブルの例を示す。

表８では、表７と比べ、”／ｄａｔａｌａｋｅ／ｉｏｔ００１１／ｄａｔａ”で示されるリソースの所有者が変更されている。新たなリソース所有者のユーザー識別子は“ｕｓｅｒ＿ｋｌｍｎｏ”である。ステップＳ１１０３でリソース所有者変更モジュール３７３は、リソース所有者が変更されたことを認可サーバー１５１に通知する。

図１１（Ｂ）は本実施の第３の形態に係る、認可サーバー１５１における認可リクエスト更新のフローである。本フローは認可サーバー１５１が、リソースサーバー１５２から、リソース所有者の変更通知を受け付けることで開始される。実施例１および２では、クライアント１１１から認可開始リクエストを受信したことを条件に、ユーザー端末１７１の特定処理、および認可確認リクエストの送信処理を行った。しかし、実施例３では変更通知を受け付けることで特定処理および送信処理が開始されるのが特徴であり、これにより、認可開始リクエストを受信したタイミングでクライアント１１１へアクセストークンの送信が可能になる。

ステップＳ１１１１で認可リクエスト更新モジュール３５５は、リソースサーバー１５２からリソース所有者の変更通知を受け付ける。ここでリソース所有者の変更通知は、”／ｄａｔａｌａｋｅ／ｉｏｔ００１１／ｄａｔａ”のリソース所有者が“ｕｓｅｒ＿ｋｌｍｎｏ”になったことを示しているとする。ステップＳ１１１２で認可リクエスト更新モジュール３５５は、表１の認可確認状況管理テーブルから、所有者が変更されたリソースに対応する認可リクエストを抽出する。ここでは認可リクエスト識別子が“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”および“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿４４４４４”が抽出される。

ステップＳ１１１３で認可リクエスト更新モジュール３５５は、ステップＳ１１１２で抽出した認可リクエストのユーザー識別子および認可結果を更新する。表９は更新後の認可確認状況管理テーブルの例である。

表９では、認可リクエスト識別子が“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”および“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿４４４４４”の認可リクエストで、ユーザー識別子が“ｕｓｅｒ＿ｋｌｍｎｏ”となっている。また認可結果は“（空欄）”になっている。これは新しいリソース所有者である“ｕｓｅｒ＿ｋｌｍｎｏ”に対してまだ認可確認を行っていないためである。

ステップＳ１１１４で認可リクエスト更新モジュール３５５はステップＳ１１１３で更新された認可リクエストに対し、図４（Ｃ）で示す認可確認リクエストフローを実施する。

なお図４（Ｃ）で示す認可確認リクエストフローでは、新しいリソース所有者に対して認可確認リクエストが送信される。ここで新しいリソース所有者が認可操作を行うと、認可サーバー１５１は、図５（Ａ）に示されるように、クライアント１１１に対し、新しいリソース所有者が認可を行ったことを通知する。

ここで通知する内容は、ステップＳ５０１で取得した認可リクエスト識別子でもよく、またユーザーの認可に対応して発行したアクセストークンでもよい。通知に先立ち予めアクセストークンを発行する際は、図５（Ｃ）に示されるようなフローを実行する。あるいはクライアント１１１は、認可サーバー１５１に対して、任意のタイミングで図５（Ｂ）に示すようなアクセストークンリクエストを送信してもよい。ここで認可サーバー１５１は、図１１（Ｂ）で認可リクエストに関連付けられたリソース所有者が更新された後であれば、新しいリソース所有者のアクセストークンを発行する。

本実施の第３の形態によれば、リソースサーバー上でリソースの所有者が変更された場合に迅速に対応できるようになる。すなわち、変更後の新たなリソース所有者に対して認可確認リクエストを行うことができるため、クライアント１１１によるアクセストークンリクエスト前にリソース所有者による認可操作を済ますことができるようになる。そのため利便性が向上する。

１１１ クライアント
１５１ 認可サーバー
１５２ リソースサーバー
１７１ ユーザー端末

Claims (13)

1. ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムにおける前記認可サーバーであって、
   前記クライアントがアクセスするリソースに対応するリソース識別子を含んだ認可開始リクエストを受信する受信手段と、
   前記受信手段により受信された認可開始リクエストに含まれる前記リソース識別子とともに、前記リソース識別子に対応するリソースの所有者であるユーザーを解決するための要求を前記リソースサーバーへ送信する送信手段と、
   前記要求に対する応答として取得したユーザーの情報に関連づく端末情報を特定する特定手段と、
   特定された端末情報に対応するユーザー端末に対して認可確認リクエストを送信し、応答として認可確認の結果を受信する確認手段と、
   前記確認手段により受信された認可確認の結果に応じて前記アクセストークンの発行を制御し、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ発行した前記アクセストークンを送信する発行手段と、を有することを特徴とする認可サーバー。
2. ユーザー識別子と端末情報を関連付けたユーザー管理テーブルを記憶する記憶手段を有し、
   前記特定手段は、前記要求に対する応答としてユーザー識別子を取得し、取得したユーザー識別子に関連付けられた端末情報を前記ユーザー管理テーブルから特定することを特徴とする請求項１に記載の認可サーバー。
3. 特定された端末情報に対応するユーザー端末に対して認可確認リクエストを送信する場合、ユーザー端末からのアクセスなく、認可確認リクエストを送信することを特徴とする請求項１または２に記載の認可サーバー。
4. 発行されたアクセストークンを用いて前記リソースを取得できなかった前記クライアントから認可開始リクエストを受信した場合、前記送信手段は、リソースの所有者であるユーザーを解決するための要求を前記リソースサーバーへ再び送信することを特徴とする請求項１乃至３の何れか１項に記載の認可サーバー。
5. 前記リソースサーバーから前記リソースの所有者の変更通知を受信した場合、前記クライアントから認可開始リクエストを受信するよりも前に、前記ユーザー端末に対して認可確認リクエストを送信することを特徴とする請求項１乃至３の何れか１項に記載の認可サーバー。
6. 前記クライアントから認可開始リクエストを受信したタイミングで前記認可確認リクエストに対する応答として認可確認の結果を受信しており、かつその認可確認の結果が許可であると確認された場合は、あらかじめ発行したアクセストークンを送信することを特徴とする請求項５に記載の認可サーバー。
7. ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムにおける前記認可サーバーで実行される制御方法であって、
   前記クライアントがアクセスするリソースに対応するリソース識別子を含んだ認可開始リクエストを受信する受信ステップと、
   前記受信ステップにおいて受信された認可開始リクエストに含まれる前記リソース識別子とともに、前記リソース識別子に対応するリソースの所有者であるユーザーを解決するための要求を前記リソースサーバーへ送信する送信ステップと、
   前記要求に対する応答として取得したユーザーの情報に関連づく端末情報を特定する特定ステップと、
   特定された端末情報に対応するユーザー端末に対して認可確認リクエストを送信させ、応答として認可確認の結果を受信する確認ステップと、
   前記確認ステップにおいて受信された認可確認の結果に応じて前記アクセストークンの発行を制御し、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ発行した前記アクセストークンを送信する発行ステップと、を含むことを特徴とする制御方法。
8. ユーザー識別子と端末情報を関連付けたユーザー管理テーブルを記憶する記憶ステップを含み、
   前記特定ステップでは、前記要求に対する応答としてユーザー識別子を取得し、取得したユーザー識別子に関連付けられた端末情報を前記ユーザー管理テーブルから特定することを特徴とする請求項７に記載の制御方法。
9. 特定された端末情報に対応するユーザー端末に対して認可確認リクエストを送信する場合、ユーザー端末からのアクセスなく、認可確認リクエストを送信することを特徴とする請求項７または８に記載の制御方法。
10. 発行されたアクセストークンを用いて前記リソースを取得できなかった前記クライアントから認可開始リクエストを受信した場合、前記送信ステップでは、リソースの所有者であるユーザーを解決するための要求を前記リソースサーバーへ再び送信することを特徴とする請求項７乃至９の何れか１項に記載の制御方法。
11. 前記リソースサーバーから前記リソースの所有者の変更通知を受信した場合、前記クライアントから認可開始リクエストを受信するよりも前に、前記ユーザー端末に対して認可確認リクエストを送信することを特徴とする請求項７乃至１０の何れか１項に記載の制御方法。
12. 前記クライアントから認可開始リクエストを受信したタイミングで前記認可確認リクエストに対する応答として認可確認の結果を受信しており、かつその認可確認の結果が許可であると確認された場合は、あらかじめ発行させたアクセストークンを送信することを特徴とする請求項１１に記載の制御方法。
13. 請求項７乃至１２の何れか１項に記載の制御方法をコンピューターに実行させるためのプログラム。

Images