JP7131408B2 - 情報処理システム、認証基盤、認可情報検証方法、及びプログラム - Google Patents

Description

本発明は、情報処理システム、認証基盤、認可情報検証方法、及びプログラムに関する。

近年、インターネット上に展開された所謂クラウドサービスが利用されている。クラウドサービスでは、サービスとしてＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を公開している。例えばアプリケーションや他のクラウドサービスは、ＡＰＩを介してサービスが提供する機能を利用できる。

また、ＡＰＩでは、例えば「ＯＡｕｔｈ ２．０」と呼ばれる認可の連携を実現させるための標準プロトコルの採用が進んでいる。例えば「ＯＡｕｔｈ ２．０」は、サービスＡが管理するユーザのデータを取得するＡＰＩに対して、そのユーザから認められた範囲でサービスＢがアクセスできる。このときサービスＡは、サービスＢからアクセスされる範囲を明らかにした上で、サービスＢによるＡＰＩへのアクセスに対してユーザの認可を得ることになっている。

このアクセスされる範囲を「ＯＡｕｔｈ ２．０」ではスコープと呼称し、スコープによりデータへのアクセス許容量が決定される。サービスＢはユーザの認可を得たことを証明するアクセストークンを受け取り、以降のサービスＡのＡＰＩへのアクセスは、そのアクセストークンを用いて実現できる（例えば、特許文献１を参照）。

例えばクラウドサービスでは、認証基盤が生成するアクセストークンを使って、様々なサービスがＡＰＩを提供している。しかし、従来技術では、認証基盤が一のサービスに生成したアクセストークンから、一のサービスが他のサービスで利用可能なアクセストークンを生成できるという問題があった。なお、特許文献１には、このような問題について記載されていない。

本発明の一実施形態は、認可情報の検証時に、サービスと利用機能との対応関係の正当性を判定できる情報処理システムを提供することを目的とする。

上記目的を達成するため、本発明の一実施形態は、認可情報の正当性を検証する認証基盤と、前記認可情報の正当性の検証結果に基づき、クライアントに１以上の利用機能をサービスとして提供する１以上のサービス提供サーバと、を有する情報処理システムであって、前記認証基盤は、前記サービスの識別情報と前記利用機能との対応関係を管理するサービス情報管理部と、前記サービスの識別情報と前記利用機能とが指定された前記認可情報の検証時に、指定された前記サービスの識別情報と前記利用機能との対応関係の正当性を前記サービス情報管理部が管理する前記対応関係に基づいて判定する認可情報管理部と、を有する。

本発明の一実施形態によれば、認可情報の検証時に、サービスと利用機能との対応関係の正当性を判定できる。

本実施形態に係る情報処理システムの一例のシステム構成を示す図である。 本実施形態に係るコンピュータの一例のハードウェア構成図である。 本実施形態に係るＭＦＰの一例のハードウェア構成図である。 本実施形態に係る情報処理システムの一例の機能構成を示す図である。 サービス情報の一例の構成図である。 アクセストークン情報の一例の構成図である。 本実施形態に係る情報処理システムの処理の一例のシーケンス図である。 アクセストークンの検証処理の一例を示すフローチャート図である。 本実施形態に係る情報処理システムの一例の機能構成を示す図である。 本実施形態に係る情報処理システムの処理の一例のシーケンス図である。 本実施形態に係る情報処理システムの処理の一例のシーケンス図である。 サービス間の関係を定義する関係定義情報の一例の構成図である。

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。

［第一の実施形態］
＜システム構成＞
まず、本実施形態に係る情報処理システム１のシステム構成について、図１を参照しながら説明する。図１は、本実施形態に係る情報処理システム１の一例のシステム構成を示す図である。

図１に示す情報処理システム１は、クライアント１０と、サービス提供サーバ１２ａ及び１２ｂと、認証基盤１４と、を含み、インターネット等の広域的なネットワーク１６を介して通信可能に接続されている。なお、以下の説明ではサービス提供サーバ１２ａ及び１２ｂを、適宜、サービス提供サーバ１２と総称する。

サービス提供サーバ１２は、一台以上の情報処理装置で実現され、ネットワーク１６を介して、クライアント１０にサービスとしてＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供する。クライアント１０はユーザが操作する機器や情報処理端末で実現され、ＡＰＩを介してサービス提供サーバ１２が提供する機能を利用する。

例えばクライアント１０は、画像形成装置、ＰＪ（Projector：プロジェクタ）、ＩＷＢ（Interactive White Board：相互通信が可能な電子式の黒板機能を有する白板）、デジタルサイネージ等の出力装置、ＨＵＤ（Head Up Display）装置、産業機械、撮像装置、集音装置、医療機器、ネットワーク家電、自動車（Connected Car）、ノートＰＣ（Personal Computer）、携帯電話、スマートフォン、タブレット端末、ゲーム機、ＰＤＡ（Personal Digital Assistant）、デジタルカメラ、ウェアラブルＰＣ、デスクトップＰＣ等である。

また、認証基盤１４は、一台以上の情報処理装置で実現され、アクセストークン管理処理とサービス情報管理処理とを行う。アクセストークン管理処理は、ユーザの認可を得たことを証明するアクセストークンの生成、生成したアクセストークンのアクセストークン情報の管理、及びアクセストークンの検証を行う。サービス情報管理処理は、サービス提供サーバ１２が提供するサービスと、そのサービスが提供する機能との対応関係をサービス情報として管理する。なお、図１に示す情報処理システム１の構成は一例である。

＜ハードウェア構成＞
《コンピュータ》
サービス提供サーバ１２及び認証基盤１４は例えば図２に示すハードウェア構成のコンピュータ５００により実現される。また、クライアント１０が情報処理端末の一例であるＰＣである場合も例えば図２に示すハードウェア構成のコンピュータ５００により実現される。

図２は、本実施形態に係るコンピュータ５００の一例のハードウェア構成図である。図２に示されているように、コンピュータ５００はＣＰＵ５０１、ＲＯＭ５０２、ＲＡＭ５０３、ＨＤ５０４、ＨＤＤ(Hard Disk Drive)コントローラ５０５、ディスプレイ５０６、外部機器接続Ｉ／Ｆ(Interface)５０８、ネットワークＩ／Ｆ５０９、データバス５１０、キーボード５１１、ポインティングデバイス５１２、ＤＶＤ－ＲＷ(Digital Versatile Disk Rewritable)ドライブ５１４、メディアＩ／Ｆ５１６を備えている。

これらのうち、ＣＰＵ５０１は、コンピュータ５００全体の動作を制御する。ＲＯＭ５０２は、ＩＰＬ等のＣＰＵ５０１の駆動に用いられるプログラムを記憶する。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。ＨＤ５０４は、プログラム等の各種データを記憶する。ＨＤＤコントローラ５０５は、ＣＰＵ５０１の制御にしたがってＨＤ５０４に対する各種データの読み出し又は書き込みを制御する。

ディスプレイ５０６は、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示する。外部機器接続Ｉ／Ｆ５０８は、各種の外部機器を接続するためのインターフェースである。この場合の外部機器は、例えば、ＵＳＢ(Universal Serial Bus)メモリやプリンタ等である。ネットワークＩ／Ｆ５０９は、ネットワーク１６を利用してデータ通信をするためのインターフェースである。データバス５１０は、ＣＰＵ５０１等の各構成要素を電気的に接続するためのアドレスバスやデータバス等である。

また、キーボード５１１は、文字、数値、各種指示などの入力のための複数のキーを備えた入力手段の一種である。ポインティングデバイス５１２は、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行う入力手段の一種である。ＤＶＤ－ＲＷドライブ５１４は、着脱可能な記録媒体の一例としてのＤＶＤ－ＲＷ５１３に対する各種データの読み出し又は書き込みを制御する。なお、ＤＶＤ－ＲＷに限らず、ＤＶＤ－Ｒ等であってもよい。メディアＩ／Ｆ５１６は、フラッシュメモリ等の記録メディア５１５に対するデータの読み出し又は書き込み（記憶）を制御する。

《機器》
情報処理システム１に含まれるクライアント１０が機器の一例であるＭＦＰである場合のハードウェア構成は例えば図３に示すようになる。図３は、本実施形態に係るＭＦＰ９００の一例のハードウェア構成図である。図３に示されているように、ＭＦＰ(Ｍultifunction Peripheral/Product/Printer)９００は、コントローラ９１０、近距離通信回路９２０、エンジン制御部９３０、操作パネル９４０、ネットワークＩ／Ｆ９５０を備えている。

これらのうち、コントローラ９１０は、コンピュータの主要部であるＣＰＵ９０１、システムメモリ（ＭＥＭ－Ｐ）９０２、ノースブリッジ（ＮＢ）９０３、サウスブリッジ（ＳＢ）９０４、ＡＳＩＣ(Application Specific Integrated Circuit)９０６、記憶部であるローカルメモリ（ＭＥＭ－Ｃ）９０７、ＨＤＤコントローラ９０８、及び、記憶部であるＨＤ９０９を有し、ＮＢ９０３とＡＳＩＣ９０６との間をＡＧＰ(Accelerated Graphics Port)バス９２１で接続した構成となっている。

これらのうち、ＣＰＵ９０１は、ＭＦＰ９００の全体制御を行う制御部である。ＮＢ９０３は、ＣＰＵ９０１と、ＭＥＭ－Ｐ９０２、ＳＢ９０４、及びＡＧＰバス９２１とを接続するためのブリッジであり、ＭＥＭ－Ｐ９０２に対する読み書きなどを制御するメモリコントローラと、ＰＣＩ(Peripheral Component Interconnect)マスタ及びＡＧＰターゲットとを有する。

ＭＥＭ－Ｐ９０２は、コントローラ９１０の各機能を実現させるプログラムやデータの格納用メモリであるＲＯＭ９０２ａ、プログラムやデータの展開、及びメモリ印刷時の描画用メモリなどとして用いるＲＡＭ９０２ｂとからなる。なお、ＲＡＭ９０２ｂに記憶されているプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。

ＳＢ９０４は、ＮＢ９０３とＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。ＡＳＩＣ９０６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣ(Integrated Circuit)であり、ＡＧＰバス９２１、ＰＣＩバス９２２、ＨＤＤ９０８およびＭＥＭ－Ｃ９０７をそれぞれ接続するブリッジの役割を有する。このＡＳＩＣ９０６は、ＰＣＩターゲットおよびＡＧＰマスタ、ＡＳＩＣ９０６の中核をなすアービタ（ＡＲＢ）、ＭＥＭ－Ｃ９０７を制御するメモリコントローラ、ハードウェアロジックなどにより画像データの回転などを行う複数のＤＭＡＣ(Direct Memory Access Controller)、並びに、スキャナ部９３１及びプリンタ部９３２との間でＰＣＩバス９２２を介したデータ転送を行うＰＣＩユニットとからなる。なお、ＡＳＩＣ９０６には、ＵＳＢ(Universal Serial Bus)のインターフェースや、ＩＥＥＥ１３９４(Institute of Electrical and Electronics Engineers 1394）のインターフェースを接続するようにしてもよい。

ＭＥＭ－Ｃ９０７は、コピー用画像バッファ及び符号バッファとして用いるローカルメモリである。ＨＤ９０９は、画像データの蓄積、印刷時に用いるフォントデータの蓄積、フォームの蓄積を行うためのストレージである。ＨＤ９０９は、ＣＰＵ９０１の制御にしたがってＨＤ９０９に対するデータの読出又は書込を制御する。ＡＧＰバス９２１は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレータカード用のバスインタフェースであり、ＭＥＭ－Ｐ９０２に高スループットで直接アクセスすることにより、グラフィックスアクセラレータカードを高速にすることができる。

また、近距離通信回路９２０には、近距離通信回路９２０ａが備わっている。近距離通信回路９２０は、ＮＦＣ、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の通信回路である。

更に、エンジン制御部９３０は、スキャナ部９３１及びプリンタ部９３２によって構成されている。また、操作パネル９４０は、現在の設定値や選択画面、コピー開始指示を受け付けるスタートキー等を表示させ、操作者からの入力を受け付けるタッチパネル等のパネル表示部９４０ａ、並びに、濃度の設定条件などの画像形成に関する条件の設定値を受け付けるテンキー等からなる操作パネル９４０ｂを備えている。コントローラ９１０は、ＭＦＰ９００全体の制御を行い、例えば、描画、通信、操作パネル９４０からの入力等を制御する。スキャナ部９３１又はプリンタ部９３２には、誤差拡散やガンマ変換などの画像処理部分が含まれている。

なお、ＭＦＰ９００は、操作パネル９４０のアプリケーション切り替えキーにより、ドキュメントボックス機能、コピー機能、プリンタ機能、およびファクシミリ機能を順次に切り替えて選択することが可能となる。ドキュメントボックス機能の選択時にはドキュメントボックスモードとなり、コピー機能の選択時にはコピーモードとなり、プリンタ機能の選択時にはプリンタモードとなり、ファクシミリモードの選択時にはファクシミリモードとなる。

また、ネットワークＩ／Ｆ９５０は、ネットワーク１６を利用してデータ通信をするためのインターフェースである。近距離通信回路９２０及びネットワークＩ／Ｆ９５０は、ＰＣＩバス９２２を介して、ＡＳＩＣ９０６に電気的に接続されている。

＜機能構成＞
図４は、本実施形態に係る情報処理システムの一例の機能構成を示す図である。図４の情報処理システム１に含まれるクライアント１０は、トークン発行要求部２０と、機能利用部２２と、を有する。これら各機能部は、クライアント１０にインストールされた１以上のプログラムが、ＣＰＵ５０１等に実行させる処理により実現される。

トークン発行要求部２０はＡＰＩを利用するサービス提供サーバ１２に対してトークン発行要求を行うことで、そのサービス提供サーバ１２が提供するＡＰＩの利用に必要なアクセストークンを取得する。機能利用部２２はアクセストークンを指定してサービス提供サーバ１２に機能利用要求を行うことで、サービス提供サーバ１２がＡＰＩを介して提供する機能を利用する。

また、図４の情報処理システム１に含まれるサービス提供サーバ１２は、ＡＰＩ提供部３０を有する。ＡＰＩ提供部３０は、トークン生成要求部３２と、トークン送受信部３４と、機能実行部３６と、機能利用要求受付部３８と、トークン検証要求部４０と、サービス情報登録要求部４２と、を有する。これら各機能部は、クライアント１０にインストールされた１以上のプログラムが、ＣＰＵ５０１等に実行させる処理により実現される。

ＡＰＩ提供部３０は、クライアント１０にサービスとしてＡＰＩを提供する。トークン生成要求部３２は、クライアント１０からのトークン発行要求を受け付けると、サービスＩＤを指定して認証基盤１４にトークン生成要求を行う。トークン送受信部３４は、認証基盤１４から受信したアクセストークンをクライアント１０に送信する。

機能利用要求受付部３８はアクセストークンを指定した機能利用要求をクライアント１０から受け付ける。トークン検証要求部４０は、サービスＩＤ、機能名などを指定して認証基盤１４にアクセストークンの検証要求を行い、アクセストークンの検証結果を認証基盤１４から受信する。

機能実行部３６はアクセストークンの検証結果に正当性があれば、クライアント１０から要求された機能を実行し、その実行結果を送信する。サービス情報登録要求部４２は認証基盤１４に対して事前にサービス情報登録要求を行う。なお、サービス情報の詳細は後述する。

また、図４の情報処理システム１に含まれる認証基盤１４は、アクセストークン管理部５０と、サービス情報管理部７０と、を有する。アクセストークン管理部５０は、トークン生成要求受付部５２と、サービス情報要求部５４と、チェック部５６と、トークン生成部５８と、トークン検証要求受付部６０と、トークン検証部６２と、検証結果送信部６４と、アクセストークン情報保存部６６と、を有する。サービス情報管理部７０は、サービス情報提供部７２と、サービス情報登録部７４と、サービス情報保存部７６と、を有している。

アクセストークン管理部５０はユーザの認可を得たことを証明するアクセストークンの生成、生成したアクセストークンのアクセストークン情報の管理、及びアクセストークンの検証などのアクセストークン管理処理を行う。サービス情報管理部７０はサービス提供サーバ１２が提供するサービスと、そのサービスが提供する機能との対応関係をサービス情報として管理するサービス情報管理処理を行う。

トークン生成要求受付部５２はサービスＩＤとスコープとを指定したトークン生成要求をサービス提供サーバ１２から受け付ける。サービス情報要求部５４はサービスＩＤを指定してサービス情報管理部７０にサービス情報取得要求を行い、サービスＩＤに対応するサービス情報を取得する。チェック部５６は取得したサービス情報を参照し、トークン生成要求で指定されていたサービスＩＤとスコープとの対応関係が正しいか（対応関係に正当性があるか）をチェックする。

トークン生成部５８はトークン生成要求で指定されていたサービスＩＤとスコープとの対応関係に正当性があれば、アクセストークンを生成し、サービス提供サーバ１２に送信する。トークン検証要求受付部６０はサービスＩＤを指定したアクセストークンの検証要求を受け付ける。

トークン検証部６２は、サービス情報要求部５４が取得したサービス情報と、検証要求のあったアクセストークンのアクセストークン情報とを参照し、アクセストークンの検証要求で指定されていたサービスＩＤとスコープとの対応関係が正しいか（対応関係に正当性があるか）を後述のように検証する。検証結果送信部６４はアクセストークンの検証結果をサービス提供サーバ１２に送信する。アクセストークン情報保存部６６は、アクセストークン情報を保存する。

サービス情報提供部７２は、サービスＩＤを指定したサービス情報取得要求をアクセストークン管理部５０から受け付け、そのサービスＩＤに対応するサービス情報をサービス情報保存部７６から読み出して、アクセストークン管理部５０に送信する。サービス情報登録部７４はサービス提供サーバ１２からサービス情報登録要求を受け付け、サービス情報をサービス情報保存部７６に登録する。サービス情報保存部７６は、サービス情報を保存する。

図５はサービス情報の一例の構成図である。図５のサービス情報は、事前にサービス提供サーバ１２から登録され、サービスＩＤとスコープとの組み合わせを管理している。図５のサービス情報は、サービスＩＤ、サービス名、スコープ、及び名称を項目として有している。

サービスＩＤは、サービスの識別情報の一例である。サービス名は、サービスの名称である。スコープは、ＡＰＩで提供する機能単位のことであり、定義する粒度をサービスごとに決定できる。例えばサービスの一例であるユーザ管理サービスに対して、ユーザ情報の読み取り、書き込み、削除といったスコープを定義できる。名称は、スコープが示す機能単位の機能名である。

図６はアクセストークン情報の一例の構成図である。アクセストークン情報は、アクセストークンと、アクセストークンを発行したユーザと、アクセストークンにより利用するスコープと、アクセストークンにより利用するサービスのサービスＩＤとの組み合わせを管理している。

図６のアクセストークン情報は、ＩＤ、アクセストークン、ユーザＩＤ、スコープ、及びサービスＩＤを項目として有している。ＩＤは、アクセストークン情報の識別情報の一例である。アクセストークンはユーザに発行したアクセストークンの情報であって、例えばユニークでランダムな英数字の組み合わせで表された情報である。ユーザＩＤは、アクセストークンを発行したユーザの識別情報の一例である。スコープはアクセストークンによりユーザが利用できる機能を示す情報である。サービスＩＤはアクセストークンによりユーザが利用できるサービスを示す情報である。

＜処理＞
次に、本実施形態に係る情報処理システム１の処理について説明する。図７は本実施形態に係る情報処理システム１の処理の一例のシーケンス図である。

ステップＳ１０において、ユーザが操作するクライアント１０は、ＡＰＩを利用するサービス提供サーバ１２に対し、ユーザＩＤ及び利用スコープを指定してトークン発行要求を行う。ステップＳ１０で指定する利用スコープは、アクセストークンにより利用するスコープを表す。

クライアント１０からのトークン発行要求を受け付けると、サービス提供サーバ１２はステップＳ１２に進み、サービス提供サーバ１２の（自身の）サービスＩＤを、ステップＳ１０のトークン発行要求で指定されたユーザＩＤ及び利用スコープに追加で指定して、認証基盤１４にトークン生成要求を行う。

サービスＩＤ、ユーザＩＤ、及び利用スコープを指定したトークン生成要求をサービス提供サーバ１２から受け付けた認証基盤１４のアクセストークン管理部５０は、ステップＳ１４に進む。ステップＳ１４においてアクセストークン管理部５０はトークン生成要求で指定されていたサービスＩＤを指定してサービス情報管理部７０にサービス情報取得要求を行う。

サービス情報管理部７０は、サービスＩＤを指定したサービス情報取得要求をアクセストークン管理部５０から受け付け、そのサービスＩＤに対応するサービス情報をサービス情報保存部７６から読み出して、アクセストークン管理部５０に送信する。このようにアクセストークン管理部５０は、トークン生成要求で指定されていたサービスＩＤに対応するサービス情報を取得する。

ステップＳ１６に進み、アクセストークン管理部５０は取得した例えば図５のサービス情報を参照し、トークン生成要求で指定されていたサービスＩＤと利用スコープとの対応関係が正しいか（対応関係に正当性があるか）をチェックする。

アクセストークン管理部５０は、トークン生成要求で指定されていたサービスＩＤと利用スコープとの対応関係と図５のサービス情報の定義とが一致していれば、サービスＩＤと利用スコープとの対応関係が正しい（対応関係に正当性がある）と判定する。また、アクセストークン管理部５０は、トークン生成要求で指定されていたサービスＩＤと利用スコープとの対応関係と図５のサービス情報の定義とが一致していなければ、サービスＩＤと利用スコープとの対応関係が正しくない（対応関係に正当性がない）と判定する。

ステップＳ１８に進み、アクセストークン管理部５０はトークン生成要求で指定されていたサービスＩＤと利用スコープとの対応関係に正当性があれば、アクセストークンを生成し、サービス提供サーバ１２に送信する。サービス提供サーバ１２は、認証基盤１４から受信したアクセストークンをクライアント１０に送信する。

アクセストークンを受信したクライアント１０はステップＳ２０において、ＡＰＩを利用するサービス提供サーバ１２に対し、アクセストークンを指定してサービス提供サーバ１２に機能利用要求を行う。

クライアント１０からの機能利用要求を受け付けたサービス提供サーバ１２はステップＳ２２に進む。サービス提供サーバ１２はサービス提供サーバ１２の（自身の）サービスＩＤと、機能名とクライアント１０を操作するユーザのユーザＩＤとを、ステップＳ２０の機能利用要求で指定されたアクセストークンに追加で指定して、認証基盤１４にアクセストークンの検証要求を行う。

サービスＩＤ、機能名、ユーザＩＤ、及びアクセストークンを指定したアクセストークンの検証要求を受け付けた認証基盤１４のアクセストークン管理部５０はステップＳ２４に進む。ステップＳ２４においてアクセストークン管理部５０はアクセストークンの検証要求で指定されていたサービスＩＤを指定してサービス情報管理部７０にサービス情報取得要求を行う。

サービス情報管理部７０は、サービスＩＤを指定したサービス情報取得要求をアクセストークン管理部５０から受け付け、そのサービスＩＤに対応するサービス情報をサービス情報保存部７６から読み出して、アクセストークン管理部５０に送信する。このようにアクセストークン管理部５０は、アクセストークンの検証要求で指定されていたサービスＩＤに対応するサービス情報を取得する。

そして、ステップＳ２６に進み、アクセストークン管理部５０は検証要求のあったアクセストークンの検証を行う。ステップＳ２６で行うアクセストークンの検証は、アクセストークンの有効性、ユーザＩＤの一致性、及び利用スコープの一致性などの検証を行う通常の検証に加えて、利用スコープとサービスＩＤとの対応関係の正当性、及びサービスＩＤの一致性の検証が行われる。

なお、ステップＳ２６で行う利用スコープとサービスＩＤとの対応関係の正当性の検証では、アクセストークンの検証要求で指定されていたサービスＩＤと機能名との対応関係と図５のサービス情報の定義とが一致しているか（正当か）を判定する。

また、ステップＳ２６で行うサービスＩＤの一致性の検証では、検証要求のあったアクセストークンのアクセストークン情報を参照し、アクセストークンの検証要求で指定されていたサービスＩＤとアクセストークン情報のサービスＩＤとが同一か（正しいか）を検証する。

アクセストークン管理部５０はアクセストークンの検証結果をサービス提供サーバ１２に送信する。アクセストークンの検証結果を受信したサービス提供サーバ１２は、アクセストークンの検証結果に正当性があれば、ステップＳ２８に進み、クライアント１０から要求された機能を実行する。サービス提供サーバ１２は、実行結果をステップＳ３０でクライアント１０に送信する。

アクセストークンの検証結果に正当性がなければ、サービス提供サーバ１２はステップＳ３２に進み、クライアント１０から要求された機能を実行できなかったことを示す情報をクライアント１０に送信する。

ステップＳ２６におけるアクセストークンの検証処理は、例えば図８のフローチャートに示す手順で行われる。図８はアクセストークンの検証処理の一例を示すフローチャート図である。

ステップＳ５０においてアクセストークン管理部５０は、サービス提供サーバ１２から検証要求のあったアクセストークンの有効性があるか否かを判定する。なお、ステップＳ５０におけるアクセストークンの有効性の判定は、サービス提供サーバ１２から検証要求のあったアクセストークンが図６のアクセストークン情報で管理されているか否かにより判定される。サービス提供サーバ１２から検証要求のあったアクセストークンが図６のアクセストークン情報で管理されていれば、アクセストークン管理部５０はアクセストークンの有効性があると判定する。アクセストークン管理部５０はアクセストークンの有効性があればステップＳ５２に進み、アクセストークンの有効性がなければステップＳ６２に進む。

ステップＳ５２においてアクセストークン管理部５０はアクセストークンの検証要求で指定されていたユーザＩＤ（クライアント１０を操作するユーザのユーザＩＤ）と、検証要求のあったアクセストークンのアクセストークン情報に含まれるユーザＩＤとの一致性があるか否かを判定する。ユーザＩＤの一致性があれば、アクセストークン管理部５０はステップＳ５４に進み、ユーザＩＤの一致性がなければ、ステップＳ６２に進む。

ステップＳ５４においてアクセストークン管理部５０はアクセストークンの検証要求で指定されていた機能名が示すスコープと、検証要求のあったアクセストークンのアクセストークン情報に含まれるスコープとの一致性があるか否かを判定する。利用スコープの一致性があれば、アクセストークン管理部５０はステップＳ５６に進み、利用スコープの一致性がなければ、ステップＳ６２に進む。

ステップＳ５６においてアクセストークン管理部５０は、サービス提供サーバ１２から検証要求のあったアクセストークンの利用スコープとサービスＩＤとの対応関係の正当性があるか否かを判定する。なお、ステップＳ５６における利用スコープとサービスＩＤとの対応関係の正当性の判定は、アクセストークンの検証要求で指定されていたサービスＩＤと機能名との対応関係と図５のサービス情報の定義とが一致しているか否かにより判定される。

アクセストークンの検証要求で指定されていたサービスＩＤと機能名が示すスコープとの対応関係が図５のサービス情報に定義されていれば、アクセストークン管理部５０はアクセストークンの検証要求で指定されていたサービスＩＤと機能名との対応関係に、正当性があると判定する。アクセストークン管理部５０は、アクセストークンの検証要求で指定されていたサービスＩＤと機能名との対応関係に、正当性があればステップＳ５８に進み、正当性がなければステップＳ６２に進む。

ステップＳ５８においてアクセストークン管理部５０は、サービス提供サーバ１２からの検証要求で指定されていたサービスＩＤと、検証要求のあったアクセストークンが示すサービスＩＤ（図６のアクセストークン情報のサービスＩＤ）との一致性があるか否かを判定する。サービスＩＤの一致性があれば、アクセストークン管理部５０はステップＳ６０に進み、サービスＩＤの一致性がなければ、ステップＳ６２に進む。

ステップＳ６０において、アクセストークン管理部５０はアクセストークンの検証結果を正当性ありと判定する。このように、アクセストークン管理部５０はアクセストークンの有効性、ユーザＩＤの一致性、及び利用スコープの一致性、利用スコープとサービスＩＤとの対応関係の正当性、及びサービスＩＤの一致性の全てがある場合にアクセストークンの検証結果を正当性ありと判定する。

一方、アクセストークン管理部５０はステップＳ６２において、アクセストークンの検証結果を正当性なしと判定する。このように、アクセストークン管理部５０はアクセストークンの有効性、ユーザＩＤの一致性、及び利用スコープの一致性、利用スコープとサービスＩＤとの対応関係の正当性、及びサービスＩＤの一致性が一つでもない場合にアクセストークンの検証結果を正当性なしと判定する。

＜まとめ＞
本実施形態では、サービス提供サーバ１２が提供するサービスにサービスＩＤを発行すると共に、サービスＩＤとスコープとの対応関係を管理する。そして、アクセストークンの生成及び検証時にサービス提供サーバ１２は、サービスＩＤを追加で指定することにより利用スコープとサービスＩＤとの対応関係の正当性、及びサービスＩＤの一致性を検証できるようにしている。

このように本実施形態によれば、認証基盤１４におけるアクセストークンの生成及び検証時において、サービス提供サーバ１２のサービスと、アクセストークンが示すスコープとの対応関係の正当性を検証（判定）する仕組みを実現できる。また、本実施形態によれば１つの認証基盤１４で様々なサービスがＡＰＩを介して機能を提供できる。

なお、ステップＳ２６のアクセストークンの検証処理では、利用スコープとサービスＩＤとの対応関係の正当性、及びサービスＩＤの一致性の検証を行わなければ、一のサービスから他のサービスでも利用できるアクセストークンを発行できてしまう。例えばＩＷＢを活用するサービスが、ＭＦＰのワークフローアプリを利用できる権限をユーザに与えることが可能となる。そこで、本実施形態では、利用スコープとサービスＩＤとの対応関係の正当性、及びサービスＩＤの一致性を検証できるようにしたことで、一のサービスから他のサービスでも利用できるアクセストークンを発行できてしまうケースを防ぐことが可能となる。

［第二の実施形態］
第二の実施形態に係る情報処理システム１は、サービス提供サーバ１２の構成が第一の実施形態に係る情報処理システム１と異なる。なお、第二の実施形態は一部を除いて第一の実施形態と同一であるため、適宜説明を省略する。

図９は、本実施形態に係る情報処理システムの一例の機能構成を示す図である。図９の情報処理システム１の機能構成は、図４とサービス提供サーバ１２の機能構成が異なっている。図９の情報処理システム１に含まれるサービス提供サーバ１２は、ＡＰＩ提供部３０とトークン検証エージェント部１００とを有する。

ＡＰＩ提供部３０は、トークン生成要求部３２と、トークン送受信部３４と、機能実行部３６と、サービス情報登録要求部４２と、機能実行要求受付部４４とを有する。これら各機能部は、クライアント１０にインストールされた１以上のプログラムが、ＣＰＵ５０１等に実行させる処理により実現される。

トークン生成要求部３２、トークン送受信部３４、機能実行部３６、及びサービス情報登録要求部４２は図４と同様である。機能実行要求受付部４４はトークン検証エージェント部１００からの機能実行要求を受け付ける。

また、トークン検証エージェント部１００は、トークン発行要求部１０２と、トークン送受信部１０４と、機能利用要求受付部１０６と、トークン検証要求部１０８と、機能実行要求部１１０とを有する。これら各機能部は、クライアント１０にインストールされた１以上のプログラムが、ＣＰＵ５０１等に実行させる処理により実現される。

トークン発行要求部１０２はクライアント１０から受信したトークン発行要求をＡＰＩ提供部３０に送信する。トークン送受信部１０４はＡＰＩ提供部３０から受信したアクセストークンをクライアント１０に送信する。機能利用要求受付部１０６はアクセストークン及び機能名を指定した機能利用要求をクライアント１０から受け付ける。

トークン検証要求部１０８は、サービスＩＤ、機能名などを指定して認証基盤１４にアクセストークンの検証要求を行い、アクセストークンの検証結果を認証基盤１４から受信する。機能実行要求部１１０はＡＰＩ提供部３０に対して機能名を指定して機能実行要求を行う。

次に、第二の実施形態に係る情報処理システム１の処理について説明する。図１０は本実施形態に係る情報処理システム１の処理の一例のシーケンス図である。なお、図１０のシーケンス図は一部を除いて図７のシーケンス図と同一であるため、同一部分について適宜説明を省略する。

ステップＳ１００において、ユーザが操作するクライアント１０は、ＡＰＩを利用するサービス提供サーバ１２に対し、ユーザＩＤ及び利用スコープを指定してトークン発行要求を行う。ステップＳ１００で指定する利用スコープは、アクセストークンにより利用するスコープを表す。

ステップＳ１０２において、サービス提供サーバ１２のトークン検証エージェント部１００はクライアント１０からのトークン発行要求をＡＰＩ提供部３０に送信する。クライアント１０からのトークン発行要求を受け付けると、ＡＰＩ提供部３０はステップＳ１０４に進み、サービス提供サーバ１２の（自身の）サービスＩＤを、ステップＳ１０２のトークン発行要求で指定されたユーザＩＤ及び利用スコープに追加で指定して、認証基盤１４にトークン生成要求を行う。

ステップＳ１０６～Ｓ１１０の処理は図７のステップＳ１４～Ｓ１８の処理と同一であるため、説明を省略する。サービス提供サーバ１２は、認証基盤１４から受信したアクセストークンをクライアント１０に送信する。

アクセストークンを受信したクライアント１０はステップＳ１１２において、ＡＰＩを利用するサービス提供サーバ１２に対し、アクセストークン及び機能名を指定して機能利用要求を行う。

クライアント１０からの機能利用要求を受け付けたサービス提供サーバ１２のトークン検証エージェント部１００はステップＳ１１４に進む。トークン検証エージェント部１００はサービス提供サーバ１２の（自身の）サービスＩＤと、クライアント１０を操作するユーザのユーザＩＤとを、ステップＳ１１２の機能利用要求で指定されたアクセストークンに追加で指定して、認証基盤１４にアクセストークンの検証要求を行う。

ステップＳ１１６～Ｓ１１８の処理は図７のステップＳ２４～Ｓ２６の処理と同一であるため、説明を省略する。アクセストークンの検証結果を受信したサービス提供サーバ１２のトークン検証エージェント部１００は、アクセストークンの検証結果に正当性があればステップＳ１２０に進み、クライアント１０から要求された機能の実行をＡＰＩ提供部３０に要求する。ステップＳ１２２に進み、ＡＰＩ提供部３０はクライアント１０から要求された機能を実行する。

ステップＳ１２４に進み、ＡＰＩ提供部３０は、実行結果をトークン検証エージェント部１００に送信する。トークン検証エージェント部１００は、実行結果をステップＳ１２６でクライアント１０に送信する。

アクセストークンの検証結果に正当性がなければ、トークン検証エージェント部１００はステップＳ１２８に進み、クライアント１０から要求された機能を実行できなかったことを示す情報をクライアント１０に送信する。

第二の実施形態に係る情報処理システム１では、それぞれのサービス提供サーバ１２のＡＰＩ提供部３０の前段にトークン検証エージェント部１００を配置し、機能利用時のアクセストークンの検証を、ＡＰＩ提供部３０でなく共通のトークン検証エージェント部１００で実施する構成としている。これにより、第二の実施形態に係る情報処理システム１のＡＰＩ提供部３０はアクセストークンの検証に関する処理を行わずに済み、機能の実行に集中できる。

また、第二の実施形態に係る情報処理システム１のＡＰＩ提供部３０は機能利用時のアクセストークンの検証を、ＡＰＩ提供部３０でなく共通のトークン検証エージェント部１００で実施することで実装が容易となる。

図１０に示したシーケンス図の処理は、図１１に示すシーケンス図のようにステップＳ１０４及びＳ１０６の処理で、更にサービスパスワードを追加で指定することで、安全性を高めることができる。アクセストークンの発行時にサービスを検証するため、機能利用時のアクセストークンの検証では、サービスパスワードによる保護は不要である。

なお、サービスパスワードで保護する場合、トークン検証エージェント部１００は特権で認証基盤１４にアクセスできるようにする必要がある。トークン検証エージェント部１００は、サービス提供サーバ１２に共通で配布するものであるため、特権を持たせることに問題はない。サービスパスワードは、例えば任意の文字列（１２３４５、ａｂｃｄｅなどの任意文字列）で構成される。その他の処理は、図１０のシーケンス図の処理と同一であるため、説明を省略する。

また、本実施形態に係る情報処理システム１において、プロジェクタの投影サービスとＩＷＢの表示サービスとを実行したい場合など、近しいサービスのスコープを同時に要求したほうが効率の良いケースが考えられる。そこで、例えばサービスＡとサービスＣとが近しいサービスである場合、図１２のように近しいサービス間の関係を定義する。

図１２はサービス間の関係を定義する関係定義情報の一例の構成図である。図１２の関係定義情報「関係１」によれば、例えばサービスＡがアクセストークンの発行を求めている場合に、サービスＣのスコープを要求されてもアクセストークンの発行を許可できるようになる。このように、図１２の関係定義情報によれば、他のサービスを経由した本来であれば実行ＮＧのケースを、特定のサービス間であれば許容することで、利便性を向上させることができる。

さらに、図５の事前にサービス提供サーバ１２から登録されたサービス情報は、管理する期限を設けるようにしてもよい。期限が過ぎたサービス情報は削除することで、サービス情報の定期的な棚卸しを可能とする。このようにサービス情報を管理する期限を設けることにより、図５のサービス情報の鮮度の維持と管理の容易化を実現できる。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。上記で説明した本実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路により実装されるプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたＡＳＩＣ（Application Specific Integrated Circuit）、ＤＳＰ（digital signal processor）、ＦＰＧＡ（field programmable gate array）や従来の回路モジュール等のデバイスを含むものとする。

なお、アクセストークンは特許請求の範囲に記載した認可情報の一例である。ＡＰＩは提供するサービスの一例である。スコープは利用機能の一例である。アクセストークン管理部５０は認可情報管理部の一例である。トークン検証エージェント部１００は認可情報検証部の一例である。ＡＰＩ提供部３０は機能提供部の一例である。サービスパスワードはサービスの秘密情報の一例である。

１ 情報処理システム
１０ クライアント
１２、１２ａ、１２ｂ サービス提供サーバ
１４ 認証基盤
１６ ネットワーク
２０ トークン発行要求部
２２ 機能利用部
３０ ＡＰＩ提供部
３２ トークン生成要求部
３４ トークン送受信部
３６ 機能実行部
３８ 機能利用要求受付部
４０ トークン検証要求部
４２ サービス情報登録要求部
４４ 機能実行要求受付部
５０ アクセストークン管理部
５２ トークン生成要求受付部
５４ サービス情報要求部
５６ チェック部
５８ トークン生成部
６０ トークン検証要求受付部
６２ トークン検証部
６４ 検証結果送信部
６６ アクセストークン情報保存部
７０ サービス情報管理部
７２ サービス情報提供部
７４ サービス情報登録部
７６ サービス情報保存部
１００ トークン検証エージェント部
１０２ トークン発行要求部
１０４ トークン送受信部
１０６ 機能利用要求受付部
１０８ トークン検証要求部
１１０ 機能実行要求部

特開２０１７－２２０１１３号公報

Claims (9)

1. 認可情報の正当性を検証する認証基盤と、前記認可情報の正当性の検証結果に基づき、クライアントに１以上の利用機能をサービスとして提供する１以上のサービス提供サーバと、を有する情報処理システムであって、
   前記認証基盤は、
   前記サービスの識別情報と前記利用機能との対応関係を管理するサービス情報管理部と、
   前記サービスの識別情報と前記利用機能とが指定された前記認可情報の検証時に、指定された前記サービスの識別情報と前記利用機能との対応関係の正当性を前記サービス情報管理部が管理する前記対応関係に基づいて判定する認可情報管理部と、
   を有する情報処理システム。
2. 前記認可情報管理部は、前記サービスの識別情報と前記利用機能とが指定された前記認可情報の生成要求時に、指定された前記サービスの識別情報と前記利用機能との対応関係の正当性を前記サービス情報管理部が管理する前記対応関係に基づいて判定し、正当性があると判定すると、前記認可情報を生成して生成要求元の前記サービスに送信すること
   を特徴とする請求項１記載の情報処理システム。
3. 前記認可情報管理部は、前記サービスの識別情報と前記サービスの秘密情報と前記利用機能とが指定された前記認可情報の生成要求時に、指定された前記サービスの識別情報と前記サービスの秘密情報と前記利用機能との対応関係の正当性を前記サービス情報管理部が管理する前記対応関係に基づいて判定し、正当性があると判定すると、前記認可情報を生成して前記生成要求元の前記サービスに送信すること
   を特徴とする請求項２記載の情報処理システム。
4. 前記認可情報管理部は、前記サービスの関係を関係定義情報に定義し、正当性があると判定した一のサービスとの関係を関係定義情報に定義されている他のサービスの前記認可情報を生成して前記他のサービスに送信すること
   を有する請求項３記載の情報処理システム。
5. 前記サービス提供サーバは、
   前記認証基盤に、前記サービスの識別情報と前記利用機能とを指定した前記認可情報の検証要求を行い、前記認証基盤から前記サービスの識別情報と前記利用機能とを指定した前記認可情報の正当性の検証結果を受信する認可情報検証部と、
   正当性ありの前記認可情報の正当性の検証結果を受信した前記認可情報検証部からの機能実行要求に基づき、クライアントに前記認可情報に指定されていた前記利用機能を提供する機能提供部と、
   を有する請求項１乃至４何れか一項記載の情報処理システム。
6. 前記サービス情報管理部は、前記サービスの識別情報と前記利用機能との対応関係を管理する期限を設けたこと
   を特徴とする請求項１乃至５何れか一項記載の情報処理システム。
7. １以上の情報処理装置を含む認証基盤であって、
   認可情報の正当性の検証結果に基づき、１以上のサービス提供サーバがクライアントに１以上の利用機能を提供するサービスの識別情報と前記利用機能との対応関係を管理するサービス情報管理部と、
   前記サービスの識別情報と前記利用機能とが指定された前記認可情報の検証時に、指定された前記サービスの識別情報と前記利用機能との対応関係の正当性を前記サービス情報管理部が管理する前記対応関係に基づいて判定する認可情報管理部と、
   を有する認証基盤。
8. 認可情報の正当性を検証する認証基盤と、前記認可情報の正当性の検証結果に基づき、クライアントに１以上の利用機能をサービスとして提供する１以上のサービス提供サーバと、を有する情報処理システムの認可情報検証方法であって、
   前記認証基盤は、
   前記サービスの識別情報と前記利用機能との対応関係を管理するサービス情報管理ステップと、
   前記サービスの識別情報と前記利用機能とが指定された前記認可情報の検証時に、指定された前記サービスの識別情報と前記利用機能との対応関係の正当性を前記サービス情報管理ステップで管理する前記対応関係に基づいて判定する認可情報管理ステップと、
   を有する認可情報検証方法。
9. １以上の情報処理装置を含む認証基盤を、
   認可情報の正当性の検証結果に基づき、１以上のサービス提供サーバがクライアントに１以上の利用機能を提供するサービスの識別情報と前記利用機能との対応関係を管理するサービス情報管理部、
   前記サービスの識別情報と前記利用機能とが指定された前記認可情報の検証時に、指定された前記サービスの識別情報と前記利用機能との対応関係の正当性を前記サービス情報管理部が管理する前記対応関係に基づいて判定する認可情報管理部、
   として機能させるためのプログラム。

Images