(57)【要約】【課題】ＡＰＩサーバは多数のデータ取得要求を受け付けるため、データ取得要求に対するデータベース参照を伴う認可処理により、処理負荷と処理遅延が増加する。【解決手段】ＡＰＩサーバがデータ取得要求を認可した場合、要求されたデータと共に認可トークンをデータ要求元のサーバに送信し、データ要求サーバは後のデータ取得要求の際にデータ取得要求とともに認可トークンをＡＰＩサーバに送信し、ＡＰＩサーバは認可トークンを用いてデータ取得要求に対する認可の可否を判断する。【選択図】  図１
2017224212.tif 000002
【特許請求の範囲】
【請求項１】
第１の記憶資源と第１のプロセッサとを有するデータ要求サーバと、第２の記憶資源と第２のプロセッサとを有するデータ提供サーバと、を有する計算機システムであって、
前記第２の記憶資源は最上位ノードへのアクセス権が前記最上位ノードに対する下位ノードへのアクセス権を保証するツリー構造の認可関係を有するリソースデータを有し、
第１のプロセッサは、
(a)前記データ提供サーバに前記リソースデータの最下位ノードのデータの要求を送信し、
第２のプロセッサは、
(b)前記データ提供サーバが前記データの要求を受信すると、前記ツリー構造を前記最下位ノードから上位にたどり前記最下位ノードが属する最上位ノードを特定し、
(c)前記データの要求の前記特定された最上位ノードへのアクセス権の有無を判定し、
(d)前記判定でアクセス権を有する場合には、前記最下位ノードのデータと前記最下位ノードの上位ノードへのアクセスを認可する認可トークンとを前記データ要求サーバに送信し、
前記第１のプロセッサは、
(e)前記データ要求サーバが前記最下位ノードのデータと前記認可トークンとを受信すると前記第１の記憶資源に前記認可トークンを格納し、
(f)前記認可トークンの格納後、前記データ提供サーバに前記最下位ノードのデータの要求を送信する際前記認可トークンを付加して送信し、
(g)前記データ提供サーバが前記認可トークンの付加された前記最下位ノードのデータ要求を受信すると、前記最下位ノードのデータを前記データ要求サーバに送信する、  計算機システム。
【請求項２】
前記第１のプロセッサは、
(a)において前記データの要求に認証情報を付加して送信し、
前記第２のプロセッサは、
(c)において前記認証情報に基づいて前記データの要求の前記最上位ノードへのアクセス権の有無を判定する、
請求項１に記載の計算機システム。
【請求項３】
前記データの要求は前記上位ノードの識別情報を有し、
前記第２のプロセッサは、
(d)において前記最下位ノードのデータと前記上位ノードへのアクセスを認可する認可トークンとに前記上位ノードの識別情報を付加して送信し、
前記第１のプロセッサは、
(e)において前記上位ノードの識別情報を前記認可トークンと対応付けて前記第１の記憶資源に格納し、
(f)において前記データの要求が有する前記上位ノードの識別情報を参照し、前記第１の記憶資源に格納された前記上位ノードの識別情報と対応する前記認可トークンを前記データの要求に付加する、
請求項２に記載の計算機システム。
【請求項４】
前記認可トークンは、前記上位ノードの識別情報を有し、
前記第１のプロセッサは、
(g)において前記認可トークンが有する前記上位ノードの識別情報が特定するノードが、前記上位ノードと一致すると判定した場合に前記最下位ノードのデータを前記データ要求サーバに送信する、
請求項３に記載の計算機システム。
【請求項５】
前記認可トークンが有する前記上位ノードの識別情報は、前記データ提供サーバが有する秘密鍵で暗号化されており、
前記第２のプロセッサは、
(g)において、前記秘密鍵を用いて前記認可トークンが有する前記暗号化された上位ノードの識別情報を復号化し、前記認可トークンが有する前記上位ノードの識別情報が特定するノードが、前記上位ノードと一致するかを判定する、
請求項４に記載の計算機システム。
【請求項６】
前記認証情報はユーザ識別情報を有し、
前記ユーザ識別情報はさらに認可グループと対応付けられて管理され、
前記最上位のノードへのアクセス権は前記認可グループごとに設定され、
前記第１のプロセッサは、
(c)において、前記認証情報が有するユーザ識別情報に対応づけられた認可グループを特定し、前記特定された認可グループの前記最上位ノードへのアクセス権の有無を判定し、当該判定に基づき前記データの要求の前記最上位ノードへのアクセス権の有無を判定する、
請求項５に記載の計算機システム。
【請求項７】
前記第１のプロセッサは、
(c)において、前記特定された認可グループが前記最上位ノードへのアクセス権を有する場合に、前記特定された認可グループと対応づけられたユーザ情報を有する認証情報の付加されたデータの要求が前記最上位ノードへのアクセス権を有すると判定する、
請求項６に記載の計算機システム。
【請求項８】
第１の記憶資源と第１のプロセッサとを有するデータ要求サーバと、第２の記憶資源と第２のプロセッサとを有するデータ提供サーバと、を有する計算機システムの管理方法であって、
前記第２の記憶資源は最上位ノードへのアクセス権が前記最上位ノードに対する下位ノードへのアクセス権を保証するツリー構造の認可関係を有するリソースデータを有し、
(a)前記データ提供サーバに最下位ノードのデータの要求を送信し、
(b)前記データ提供サーバが前記データの要求を受信すると、前記ツリー構造を前記最下位ノードから上位にたどり前記最下位ノードが属する最上位ノードを特定し、
(c)前記データの要求の前記特定された最上位ノードへのアクセス権の有無を判定し、
(d)前記判定でアクセス権を有する場合には、前記最下位ノードのデータと前記最下位ノードの上位ノードへのアクセスを認可する認可トークンとを前記データ要求サーバに送信し、
(e)前記データ要求サーバが前記最下位ノードのデータと前記認可トークンとを受信すると前記第１の記憶資源に前記認可トークンを格納し、
(f)前記認可トークンの格納後、前記データ提供サーバに前記最下位ノードのデータの要求を送信する際前記認可トークンを付加して送信し、
(g)前記データ提供サーバが前記認可トークンの付加された前記最下位ノードのデータ要求を受信すると、前記最下位ノードのデータを前記データ要求サーバに送信する、
計算機システムの制御方法。
【請求項９】
(a)において前記データの要求に認証情報を付加して送信し、
(c)において前記認証情報に基づいて前記データの要求の前記最上位ノードへのアクセス権の有無を判定する、
請求項８に記載の計算機システムの制御方法。
【請求項１０】
前記データの要求は前記上位ノードの識別情報を有し、
(d)において前記第１のデータと前記上位ノードへのアクセスを認可する認可トークンとに前記上位ノードの識別情報を付加して送信し、
(e)において前記上位ノードの識別情報を前記認可トークンと対応付けて前記第１の記憶資源に格納し、
(f)において前記データの要求が有する前記上位ノードの識別情報を参照し、前記第１の記憶資源に格納された前記上位ノードの識別情報と対応する前記認可トークンを前記データの要求に付加する、
請求項９に記載の計算機システムの制御方法。
【請求項１１】
トークンの認可時の詳細処理
前記認可トークンは、前記上位ノードの識別情報を有し、
(g)において前記認可トークンが有する前記上位ノードの識別情報が特定するノードが、前記上位ノードと一致すると判定した場合に前記最下位ノードのデータを前記データ要求サーバに送信する、
請求項１０に記載の計算機システムの制御方法。
【請求項１２】
前記認可トークンが有する前記上位ノードの識別情報は、前記データ提供サーバが有する秘密鍵で暗号化されており、
(g)において、前記秘密鍵を用いて前記認可トークンが有する前記暗号化された上位ノードの識別情報を復号化し、前記認可トークンが有する前記上位ノードの識別情報が特定するノードが、前記上位ノードと一致するかを判定する、
請求項１１に記載の計算機システムの制御方法。
【請求項１３】
前記認証情報はユーザ識別情報を有し、
前記ユーザ識別情報はさらに認可グループと対応付けられて管理され、
前記最上位のノードへのアクセス権は前記認可グループごとに設定され、
(c)において、前記認証情報が有するユーザ識別情報に対応づけられた認可グループを特定し、前記特定された認可グループの前記最上位ノードへのアクセス権の有無を判定し、当該判定に基づき前記データの要求の前記最上位ノードへのアクセス権の有無を判定する、
請求項１２に記載の計算機システムの制御方法。
【請求項１４】
(c)において、前記特定された認可グループが前記最上位ノードへのアクセス権を有する場合に、前記特定された認可グループと対応づけられたユーザ情報を有する認証情報の付加されたデータの要求が前記最上位ノードへのアクセス権を有すると判定する、
請求項１３に記載の計算機システムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＡＰＩによりデータやサービスを提供する計算機システムに関する。
【背景技術】
【０００２】
近年、社内業務システムやソーシャルネットワーク、制御系システムなどからデータを取得し、それらをマッシュアップして価値を提供するＳｙｓｔｅｍ  ｏｆ  Ｅｎｇａｇｅｍｅｎｔ（ＳｏＥ）と呼ばれるアプリケーションが注目されている。各データ提供元はデータ取得のためのインタフェースをＷｅｂ  ＡＰＩの形式で提供するのが一般的である。
【０００３】
例えば、特許文献１では、ユーザからの要求に対してアプリケーションサーバが認証処理を実施し、認証結果を要求に付随させて標準化された通信方式でＡＰＩサーバに送信することで、ＡＰＩサーバからデータを取得する方式を開示している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１４６１６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記の発明では、認証されたユーザが要求データに対してアクセス権限があるか否かを判断する認可処理については言及されていない。要求データへの認可処理は、そのデータを備えるデータ提供側（以下、ＡＰＩサーバと呼称）で実施すると考えられる。しかし、Ｓｙｓｔｅｍ  ｏｆ  Ｒｅｃｏｒｄ  （ＳｏＲ）とも呼ばれる既存の業務システムは、本来は対象とするユーザ数（社員数など）がある程度決まっており、それを前提とした性能設計をしている。そのため、ＳｏＥアプリケーションから多数のデータ取得要求を受け付けると、認可処理に伴うデータベース（ＤＢ）アクセスにより処理負荷と応答遅延が大きくなる。特に、データ構造がツリー構造を構成し、要求データの親ノードを辿っていかなければ認可判断ができない場合、親ノードを辿るために複数回のＤＢアクセスが発生し、処理負荷と応答遅延は増大する。
【０００６】
大規模化を想定した分散データベースなどを採用したスケールアウト可能な構成であれば本問題は発生しないが、ＳｏＲとして設計、運用されてきたシステムの構成を変更することは難しく、ＡＰＩサーバとしてＳｏＥアプリケーションにデータを提供する際に問題となる。
【０００７】
本発明は上記問題を鑑みて為されたものであり、ＳｏＥアプリケーションが従来のＳｏＲアプリケーションからＡＰＩによりデータを取得する際、ＳｏＲアプリケーション側の認可処理に伴うＤＢアクセスを削減することで、処理負荷と応答遅延の増加を低減することを目的とする。
【課題を解決するための手段】
【０００８】
計算機システムは、第１の記憶資源と第１のプロセッサとを有するデータ要求サーバと、第２の記憶資源と第２のプロセッサとを有するデータ提供サーバと、を有する。第２の記憶資源は最上位ノードへのアクセス権が最上位ノードに対する下位ノードへのアクセス権を保証するツリー構造の認可関係を有するリソースデータを有する。第１のプロセッサは、データ提供サーバにリソースデータの最下位ノードのデータの要求を送信し、第２のプロセッサは、データ提供サーバがデータの要求を受信すると、ツリー構造を最下位ノードから上位にたどり最下位ノードが属する最上位ノードを特定する。第２のプロセッサはデータの要求の特定された最上位ノードへのアクセス権の有無を判定し、その判定でアクセス権を有する場合には、最下位ノードのデータと最下位ノードの上位ノードへのアクセスを認可する認可トークンとをデータ要求サーバに送信する。第１のプロセッサは、データ要求サーバが最下位ノードのデータと認可トークンとを受信すると第１の記憶資源に認可トークンを格納し、認可トークンの格納後、データ提供サーバに最下位ノードのデータの要求を送信する際に認可トークンを付加して送信し、データ提供サーバが認可トークンの付加された最下位ノードのデータ要求を受信すると、最下位ノードのデータをデータ要求サーバに送信する。
【発明の効果】
【０００９】
本発明により、スケーラビリティの無い従来のＳｏＲシステムであっても、認可処理のＤＢアクセスを削減し、処理負荷と応答遅延の増大を抑えることで、ＳｏＥアプリケーションに対してＡＰＩによるデータ提供を可能にする。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施例１におけるＷｅｂシステムの構成の例である。
【図２】本発明の実施例１におけるアプリケーションサーバまたはＡＰＩサーバのハードウェア構成の例である。
【図３】本発明の実施例１におけるアプリケーションサーバが送受信するデータ取得要求とデータ応答の例である。
【図４】本発明の実施例１におけるアプリケーションサーバが記憶するセッション情報の例である。
【図５】本発明の実施例１におけるＡＰＩサーバが記憶するリソースデータの例と、認可関係の概念図の例である。
【図６】本発明の実施例１におけるアプリケーションサーバがＡＰＩサーバからデータを取得する処理の例である。
【図７】本発明の実施例２におけるＷｅｂシステムの構成の例である。
【発明を実施するための形態】
【００１１】
以下、実施例について図面を用いて説明する。なお、以下の実施例では、Ｗｅｂブラウザ、アプリケーションサーバ、ＡＰＩサーバ間の通信プロコルとしてＨＴＴＰを利用した場合について説明するが、ＨＴＴＰと同様の機能を備える異なる通信プロトコルを利用しても良い。また、本実施例では説明のために通信内容やデータベースに格納する情報について平文で記載するが、実際には暗号化されていても良い。さらに、アプリケーションとサーバＡＰＩサーバがそれぞれ１台の装置上で動作する場合を説明するが、各機能が動作する物理的な位置は問わない。
【実施例１】
【００１２】
図１に本実施例の構成を示す。本実施例では、Ｗｅｂブラウザ１０とアプリケーションサーバ１００とが、通信ネットワークＮ１０を介して接続されており、アプリケーションサーバ１００とＡＰＩサーバ２００とが、通信ネットワークＮ２０を介して接続されている。通信ネットワークＮ１０とＮ２０は、例えばインターネットや社内ネットワーク（イントラネット）である。Ｗｅｂブラウザ１０はアプリケーションサーバ１００にコンテンツ取得要求２０を送信し、コンテンツ応答２２を受信する。アプリケーションサーバ１００はＡＰＩサーバ２００にデータ取得要求４０を送信し、データ応答６０を受信する。以下に、Ｗｅｂブラウザ１０とアプリケーションサーバ１００と、ＡＰＩサーバ２００とについて説明する。
【００１３】
Ｗｅｂブラウザ１０はアプリケーションサーバにコンテンツ取得要求２０を送信し、コンテンツ応答２２を受信してユーザに表示するコンテンツ取得表示機能１１を備える。例えば、コンテンツ取得要求２０はＨｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）におけるＧＥＴ要求であり、コンテンツはＨｙｐｅｒ  Ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＨＴＭＬ）ファイルなどである。Ｗｅｂブラウザ１０は一般的に使用されている公知の技術である。
【００１４】
アプリケーションサーバ１００は、コンテンツ生成応答機能１１０と、データ取得機能１２０と、セッション管理機能１３０と、認可情報記憶機能１５０と、認可情報付与機能１６０とを備え、セッション情報１４０を記憶する。アプリケーションサーバ１００はリアプリケーションサーバ２００にアプリケーションサーバ２００有するソースデータ２２０を要求するサーバである。
【００１５】
コンテンツ生成応答機能１１０は、Ｗｅｂブラウザからのコンテンツ取得要求２０を受信し、要求されたコンテンツを生成し、コンテンツ応答２２をＷｅｂブラウザに応答する。コンテンツ生成に際し、後述のデータ取得機能１２０は、コンテンツ生成に必要なデータがあれば、ＡＰＩサーバ２００から必要なデータを取得する。本コンテンツ生成応答機能１２０は一般的なアプリケーションサーバが備える公知の技術である。
【００１６】
セッション管理機能１３０は、Ｗｅｂブラウザ１０からの接続をセッションとして管理する。例えば、ユーザ１５によるアプリケーションサーバ１００へのログインから、ログアウトまたはタイムアウトまでを１つのセッションとして管理し、セッションが存在する間はユーザ１５のユーザＩＤやパスワードなど、セッションに関する情報を後述のセッション情報１４０に記憶する。セッション管理機能１３０は一般的なアプリケーションサーバが備える機能であり、公知の技術である。
【００１７】
データ取得機能１２０は、ＡＰＩサーバ２００に対してデータ取得要求４０を送信し、データ応答６０を取得する。例えばデータ取得要求はＨＴＴＰにおけるＧＥＴ要求であり、応答はＪａｖａＳｃｒｉｐｔ（登録商標）  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）形式のデータを含むＨＴＴＰ応答である。
データ取得機能１２０は、データ取得要求４０に対して、どのユーザによる要求かを識別可能にするためユーザ認証情報を付与する（図３、４６）。例えばユーザ認証情報は、セッション管理機能１３０がセッション情報１４０に格納したユーザＩＤとパスワードである。データ取得機能１２０は、ＡＰＩサーバからデータを取得する一般的なアプリケーションサーバが備える機能であり、公知の技術である。
【００１８】
認可情報記憶機能１５０は、ＡＰＩサーバ２００からのデータ応答６０に認可情報（図３、６４）が存在する場合、その情報をセッション情報１４０に記憶する。認可情報は、認可情報名（図３、６４−２）と、認可トークン（図３、６４−４）を含み、それぞれをセッション情報１４０の認可情報名（図４、Ｄ１４６−２）と認可トークン（図４、Ｄ１４６−４）として格納する。
【００１９】
認可情報付与機能１６０は、データ取得機能１２０が送信するデータ取得要求４０の要求ＵＲＬ（図３、４４）に、セッション情報１４０の認可情報名１４６−２が含まれる場合、対応する認可トークン１４６−４をデータ取得要求４０に認可トークン（図３、４８）として付加する。
【００２０】
ＡＰＩサーバ２００は、データ応答機能２１０と、認可処理機能２３０と、認可情報付与機能２５０と、認可情報判定機能２４０とを備え、リソースデータ２２０とを記憶する。
ＡＰＩサーバ２００はリソースデータ２２０をアプリケーションサーバ１００に提供するサーバである。
【００２１】
データ応答機能２１０は、アプリケーションサーバ１００からデータ取得要求４０を受信し、データ取得要求４０の要求ＵＲＬ（図３、４４）に対応する要求データを、リソースデータ２２０から取得して、アプリケーションサーバ１００に応答する。
【００２２】
要求データの応答に際し、後述の認可処理機能２３０または認可情報判定機能２４０は要求元ユーザに該要求データのアクセス権があるか否かを判定する。その結果、アクセス権がある場合にのみデータ応答機能２１０はデータ応答６０を応答し、アクセス権がない場合はエラーを応答する。
データ応答機能２１０は、一般的なＡＰＩサーバが備える機能であり、公知の技術である。
【００２３】
認可処理機能２３０は、アプリケーションサーバ１００から受信したデータ取得要求４０の認証情報（図３、４６）から要求元ユーザを特定し、該ユーザに要求データに対するアクセス権があるか否かを判定する認可判断を実施する。認可判断の処理フロー例については図５にて説明する。認可処理機能２３０は、データに対してアクセス制御を実施する一般的なＡＰＩサーバが備える機能であり、公知である。
【００２４】
認可情報判定機能２４０は、データ取得要求４０に認可トークン（図３、４８）が付与されている場合、認可処理機能２３０に代わり、データ取得要求４０の該認可トークンを利用して認可判断を実施する。認可判断の処理フロー例については図５にて後述する。
【００２５】
認可情報付与機能２５０は、認可処理機能２３０によりデータ取得要求４０が認可された場合、認可情報（図３、６４）を生成し、要求データのデータ応答６０に付与する。認可情報生成方法については図３にて後述する。
【００２６】
リソースデータ２２０は、ＡＰＩサーバ２００が提供するデータを管理するリレーショナルデータベースで、複数のテーブルを備える。本リソースデータ２２０に格納するデータは、別システムまたは手動により管理者やユーザが入力、更新、削除などを行う。また、各データに対する認可判断も本データベースに基づいて処理を行う。データ構造の内容については図５にて説明する。リソースデータ２２０は、一般的なリレーショナルデータベースで実現できる、公知の技術である。
【００２７】
図２は、アプリケーションサーバ１００やＡＰＩサーバ２００を実現する電子計算機の物理構成を示した図である。本実施形態の電子計算機は、プログラムを実行し、各処理機能を実現するプロセッサＨ２０１と、実行するプログラムやデータを一時的に保持するメモリ装置Ｈ２０２と、外部からの指示や情報を入力するための入力装置Ｈ２０３と、プログラムの実体、指示，情報等を格納し，データの記憶手段として使用されるディスク装置Ｈ２０４と，外部装置とのデータのやり取りを制御する通信制御装置Ｈ２０５と，装置内部でデータのやり取りをおこなうためのバスなどの内部通信線Ｈ２０６と，電子計算機の内部と外部装置とのデータのやり取りするための外部通信回線Ｈ２０７を備える。
【００２８】
本発明において、データの記憶手段はディスクに限られず、記憶媒体であればsolid state drive（SSD）等であってもよい。
【００２９】
上記プログラムは予め，電子計算機内のメモリ装置Ｈ２０２またはディスク装置Ｈ２０４に格納されていても良いし，必要なときに，上記電子計算機が利用可能な，着脱可能な記憶媒体から，または通信媒体（ネットワーク，または，ネットワークを伝播する搬送波またはデジタル信号）を介して他の装置から，導入されてもよい。
【００３０】
また，各処理機能の処理内容は，ディスク装置Ｈ２０４に格納されているプログラムを，プロセッサＨ２０１が読み出して実行することにより，具現化されるものである
図３は、アプリケーションサーバ１００が送信するデータ取得要求４０と、ＡＰＩサーバ２００が応答するデータ応答６０の一例である。
データ取得要求４０は、ＨＴＴＰのＧＥＴ要求であり、本要求のＨＴＴＰヘッダを要求ヘッダ４２と呼称する。
要求ヘッダ４２は、要求ＵＲＬ４４と、認証情報４６とを含む。また、認可トークン４８を含んでも良い
要求ＵＲＬ４４は、データ取得要求４０が取得を要求するリソースデータ２２０のデータを一意に定める。指定可能なＵＲＬと、該ＵＲＬで取得できるデータとの対応はＡＰＩサーバ側で事前に決定し、アプリケーションサーバ１００と情報を共有する。要求ＵＲＬ４４が、指定可能なＵＲＬではない場合、データ応答機能２１０はアプリケーションサーバ１００にエラーを応答する。
【００３１】
要求ヘッダ４２は、要求元のユーザ（図１、１５）を識別可能にする認証情報４６を備える。認証情報４６は例えば、ＨＴＴＰヘッダのＡｕｔｈｏｒｉｚｔｉｏｎヘッダとして記載され、ユーザ名とパスワードをテキスト化（ＢＡＳＥ６４エンコード）したものである。認証情報の形式や付与方法、認証方法は公知の技術であり、その他の形式（例えばＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ）や、ＨＴＴＰヘッダ以外に付与（例えばＵＲＬパラメータ）する方式であっても良い。
【００３２】
認可トークン４８は要求ＵＲＬ４４の内容に従って、認可情報付与機能１６０により付与される。
【００３３】
データ応答６０はＨＴＴＰ応答であり、本応答のＨＴＴＰヘッダを応答ヘッダ６２、ＨＴＴＰ本文を要求データ６６と呼称する。
応答ヘッダ６２は、認可情報６４を含んでも良い。
【００３４】
認可情報６４は、認可情報名６４−２と、認可トークン６４−４とを含む。
認可情報６４は、データ取得要求４０を認可処理機能２３０が認可する際の認可関係（図５、Ｌ１０）における要求データ（図５、Ｌ１２）の親ノード（図５、Ｌ１４）の情報を基に、認可情報付与機能２５０が生成、付与する。
認可情報６４は認可情報名６４−２と、認可トークン６４−４を含む。
認可情報名６４−２は、該親ノードを格納するレコードの識別名（Ｄ２６、Ｄ３６）の値を使用する。
【００３５】
認可トークン６４−４は、リソースデータ２２０内で該親ノードのデータを一意に特定する識別子である。本実施例ではテーブル名とレコードのＩＤを結合した文字列を、ＡＰＩサーバが備える秘密鍵にて暗号化し、テキスト化（例えばＢＡＳＥ６４エンコード）したものを使用する。
【００３６】
要求データ６６は、データ取得要求４０が要求したリソースデータ２２０が備えるデータを含む。
【００３７】
図４は、アプリケーションサーバ１００が記憶するセッション情報１４０の一例である。
セッション情報１４０は、アプリケーションサーバ１００がＷｅｂブラウザからの一連の要求をセッションとして一意に識別するために独自に設定するセッション番号Ｄ１４２と、該セッションを利用するユーザの認証情報Ｄ１４４と、認可情報Ｄ１４６とを備える。
【００３８】
認証情報Ｄ１４４は、例えばユーザがアプリケーションサーバ１００にログインする際に入力したユーザＩＤとパスワードをセッション管理機能１３０がＤ１４４−２とＤ１４４−４に記憶する。アプリケーションサーバへのログイン機能や認証と、そのデータの保持方法は一般的な技術であり、公知である。
【００３９】
認可情報Ｄ１４６は、データ取得機能１２０がＡＰＩサーバ２００から取得したデータ応答６０に認可情報６４が付与されている場合、認可情報記憶機能１５０が、認可情報６４が含む認可情報名と認可トークンとを、認可情報名Ｄ１４６−２と認可トークン１４６−４に記憶する。
【００４０】
セッション管理機能１３０は、ユーザによる明示的なログアウトやタイムアウトによりセッションが終了したと判断すると、セッション情報１４０から終了したセッションに該当するセッション番号のレコードを削除する。
セッション情報１４０は、上記に示した項目以外にもセッションに紐づく情報を記憶しても良い。
【００４１】
図５は、リソースデータ２２０が記憶するデータベースの内容の一例（Ｄ１０、Ｄ２０，Ｄ３０、Ｄ４０）と、論理的な認可関係の概念図（Ｌ１０）である。本実施例では、ＡＰＩサーバ２００は、複数拠点に配置された撮影機により撮影された画像と、各拠点、撮影機、画像に関する情報を備え、それらをＡＰＩにより提供するサーバであることを想定する。これは、ＡＰＩサーバ２００の一例であり、データの種類や形式、テーブル構成を限定するものではない。
【００４２】
本実施例では、リソースデータ２２０は、画像情報テーブルＤ１０と、撮影機情報テーブルＤ２０と、拠点情報テーブルＤ３０と、ユーザ情報テーブルＤ４０とを備える。
【００４３】
ユーザ情報テーブルＤ４０は、各ユーザのユーザＩＤ（Ｄ４２）と、各ユーザが所属する所属グループ（Ｄ４４）の対応を記憶する。
【００４４】
画像情報テーブルＤ１０は、画像名（Ｄ１２）や、その画像を撮影した撮影機（Ｄ１４）、画像ファイル（Ｄ１６）、各画像に関する情報を記憶する。
【００４５】
撮影機テーブルＤ２０は、撮影機の名称（Ｄ２２）と、その撮影機が設置されている拠点（Ｄ２４）や、各撮影機に関する情報を記憶する。また、後述の認可関係Ｌ１０にて該撮影機で撮影した画像に対するデータ取得の要求ＵＲＬ４４が共通して含む文字列を識別名（Ｄ２６）として記憶する。また、撮影機テーブルＤ２０は、各レコードを一意に識別するレコードのＩＤ（Ｄ２１）を備える。ＩＤはデータベースソフトウェアの機能により自動的に採番される。
【００４６】
拠点情報テーブルＤ３０は、各拠点（Ｄ３２）と、その拠点以下の情報にアクセス権のある認可グループ（Ｄ３４）の対応を記憶する。また、後述の認可関係Ｌ１０にて該拠点に設置された撮影機に対するデータ取得の要求ＵＲＬ４４が共通して含む文字列を識別名（Ｄ３６）として記憶する。また、拠点情報テーブルＤ３０は、各レコードを一意に識別するレコードのＩＤ（Ｄ３１）を備える。ＩＤはデータベースソフトウェアの機能により自動的に採番される。
【００４７】
本実施例では、ユーザが属する所属グループは拠点に対してアクセス権限があるか否かが定められ、拠点に対してアクセス権があれば、その配下の撮影機、ならびに画像に対してもアクセス権を持つツリー構造の認可関係を備える。この論理的な認可関係の概念をＬ１０として示す。拠点のノードを最上位のノードであるルート（根）として、ツリー構造を取っており、撮影機や画像が下位のノードとして存在する。本実施例では画像が最下位のノードであるリーフ（葉）となる。このようなツリー構造による認可関係の管理は、拠点の統廃合や機器の委譲などに柔軟に対応することを目的とする。
【００４８】
図５（a）〜（e）を用いて、ＡＰＩサーバ２００の認可処理機能２３０が、データ取得要求４０に対して認可判断するフローについて説明する。
例えば、データ応答機能２１０がデータ取得要求４０を受信し、該要求の要求ＵＲＬ４４が「ｈｔｔｐ：／／ｒｅｓｏｕｃｅ／ｄｅｖｉｃｅ１／ｉｍａｇｅｓ／ＩＭＧ０１」である場合、データ応答機能２１０は、事前に定めたＵＲＬとデータの対応から、図５(a)の画像情報テーブルＤ１０に格納されている画像名Ｄ１２が「ＩＭＧ０１」である画像Ｄ１６の画像（画像Ｔ１と呼称）を選択し、アクセス権の有無を認可処理機能２３０に問い合わせる。
【００４９】
認可処理機能２３０は、データ取得要求４０が備える認証情報４６から、ユーザＩＤを取得し、ユーザ情報テーブルＤ４０を照会して、該ユーザが所属する所属グループ（Ｄ４４）を取得する。
【００５０】
例えば、ユーザＩＤが「Ｊｏｈｎ」であった場合、所属グループは「Ｇｒｏｕｐ−Ａ」と「Ｇｒｏｕｐ−Ｃ」となる。
【００５１】
次に画像Ｔ１がどの所属グループに対して認可されているか判断するため、図５（e）の論理的な認可関係Ｌ１０のツリー構造を画像Ｔ１から根に向かって辿る。
【００５２】
まず、図５(a)の画像情報テーブルＤ１０を照会して、画像Ｔ１に対応する撮影機Ｄ１４（Ｄｅｖ１）を取得する。
次に、図５(ｂ)の撮影機情報テーブルＤ２０を照会して、該撮影機（Ｄｅｖ１）が設置されている拠点Ｄ２２（Ｐｌａｎｔ−Ａ）を取得する。
その後、図５(ｃ)の拠点情報テーブルＤ３０を照会して、該拠点（Ｐｌａｎｔ−Ａ）に対応する認可グループＤ３４（Ｇｒｏｕｐ−Ａ、Ｇｒｏｕｐ−Ｂ）を取得する。
【００５３】
この結果、先の処理でユーザ「Ｊｏｈｎ」は所属グループ「Ｇｒｏｕｐ−Ａ」に所属していると判定しているため、ユーザ「Ｊｏｈｎ」は該画像Ｔ１にアクセス権があると判断する。
【００５４】
同様に図５を用いて、ＡＰＩサーバ２００の認可情報判定機能２４０が、データ取得要求４０に対して認可判断するフローについて説明する。
データ取得要求４０が認可トークン（図３、４８）を備える場合、認可処理機能２３０に代わり、認可情報判定機能２４０が認可を判断する。
【００５５】
認可情報判定機能２４０は、データ取得要求４０が備える認可トークン（図３、４８）をＡＰＩサーバ２００が備える秘密鍵で復号化し、認可トークンが含むテーブル名とレコードのＩＤを取得する。
次に、図５(a)の画像情報テーブルＤ１０を照会して、画像Ｔ１に対応する認可関係Ｌ１０の親ノード（上位のノード）にあたる撮影機（Ｄｅｖ１）のテーブル名とレコードのＩＤ（Ｄ２１）が、先の認可トークンのテーブル名とレコードのＩＤと一致するかどうかを判断する。一致する場合、認可情報機能判定２４０は該データ要求４０を認可する。一致しない場合は、認可しないと判断する。
【００５６】
図６は、アプリケーションサーバ１００がＡＰＩサーバ１００からデータを取得する際のシーケンスの一例である。本実施例ではＷｅｂブラウザ１０からのコンテンツ取得要求を契機に、アプリケーションサーバ１００がＡＰＩサーバ１００からデータ取得を行うが、データ取得の契機はＷｅｂブラウザ１０からの要求以外であっても良く、例えば、事前に定めた間隔で定期的に実行しても良い。
【００５７】
初めに、Ｗｅｂブラウザ１０からのログイン要求（Ｓ１０）をアプリケーションサーバ１００が受信し、ログイン処理（Ｓ１２）を実施する。ログインしたユーザのユーザＩＤやパスワードなどをセッション管理機能１３０がセッション情報１４０に格納する。本セッション情報はユーザのログアウト処理（Ｓ３６）まで保持される。ログイン要求、ログイン処理は一般的な技術であるため詳細は省略する。
【００５８】
次に、Ｗｅｂブラウザ１０からのコンテンツ取得要求（Ｓ１４）をアプリケーションサーバ１００が受信すると、コンテンツを生成するために必要なデータをＡＰＩサーバ２００から取得するため、データ取得機能１２０がデータ取得要求（Ｓ１６）をＡＰＩサーバ２００に送信する。この際、データ取得機能１２０は、先のログイン処理（Ｓ１２）で取得したユーザのユーザＩＤ、パスワードを基にユーザ認証情報４６を生成し、データ取得要求Ｓ１６に付与する。
【００５９】
ＡＰＩサーバ２００のデータ応答機能２１０がデータ取得要求Ｓ１６を受信し、該データ取得要求Ｓ１６が認可トークンを含まない場合、認可処理機能２３０が受信したデータ取得要求Ｓ１６に対して認可処理（Ｓ１８）を実施する。認可処理（Ｓ１８）は図５の説明に示した通りである。
【００６０】
認可処理機能２３０がデータ取得要求Ｓ１６を認可すると、データ応答機能２１０が要求されたデータをアプリケーションサーバ１００に応答する。その際、認可情報付与機能２５０は、認可関係Ｌ１０における要求データの親ノードに関する認可情報を生成し、データ応答Ｓ２８に付与する。認可情報の生成は図３の説明にて示した通りである。
【００６１】
アプリケーションサーバ１００が該データ応答Ｓ２８を受信すると、認可情報記憶機能１５０がデータ応答Ｓ２８に付与された認可情報６４をセッション情報１４０に記憶する。
【００６２】
続けてアプリケーションサーバ１００は、コンテンツ生成に必要となる別データをＡＰＩサーバ２００から取得するため、データ取得要求Ｓ２４をＡＰＩサーバ２００に送信する。
【００６３】
その際、認可情報付与機能１６０は要求ＵＲＬ４４がセッション情報１４０に格納した認可情報Ｄ１４６の認可情報名Ｄ１４６−２を含むか否かを判断し、要求ＵＲＬ４４に認可情報名Ｄ１４６−２が含まれていれば、認可情報名Ｄ１４６−２に対応する認可トークンＤ１４６−４をデータ取得要求Ｓ２４に付与する。
【００６４】
ＡＰＩサーバ２００がデータ取得要求Ｓ２４を受信し、該データ取得要求Ｓ２４が認可トークンを含む場合、認可処理機能２３０に代わり、認可情報判定機能２４０が、受信したデータ取得要求Ｓ２４が要求するデータに対して認可処理（Ｓ２６）を実施する。認可処理（Ｓ２６）は図５の説明に示した通りである。
【００６５】
認可情報判定機能２４０がデータ取得要求Ｓ２４を認可すると、データ応答機能２１０が要求されたデータをデータ応答Ｓ２８として応答する。認可情報判定機能２４０によりデータ取得要求Ｓ２４が認可される場合、認可情報付与機能２５０は認可情報を付与しない。
【００６６】
アプリケーションサーバ１００は、必要に応じてＳ２４からＳ２８の処理を繰り返し、コンテンツ生成に必要なデータをすべてＡＰＩサーバ２００から取得したのち、コンテンツを生成（Ｓ３０）し、Ｗｅｂブラウザ１０に応答する（Ｓ３２）。
【００６７】
以上、本実施例によれば、データ取得要求に対する応答に、要求データの親ノードの認可情報を付与し、該親ノード配下のデータ取得要求については該認可情報を使用して認可判断を実施することで、データベースの参照回数を抑えることができる。
【００６８】
これにより、既存の業務システムでもＡＰＩサーバとしてデータを提供する場合、処理負荷と遅延を抑えることができる。
【実施例２】
【００６９】
図７に第２の実施例の構成を示す。第２の実施例は、アプリケーションサーバ１００ＢがＡＰＩサーバに対してＨＴＴＰのＫｅｅｐ−Ａｌｉｖｅ機能などにより一つのＴＣＰセッションで複数のデータ取得要求を送信する場合、ＡＰＩサーバが該ＴＣＰセッションに紐づけて認可情報をＡＰＩサーバのメモリ上に保持し、該認可情報を使用してデータ取得要求の認可判断を行う実施例である。
【００７０】
第２の実施例は、ＡＰＩサーバ２００Ｂが実施例１の認可情報付与機能２５０に代わり、認可情報一時記憶機能２６０を備え、認可情報判定機能２４０に代わり認可情報判定機能２４０Ｂを備え、アプリケーションサーバ１００Ｂが実施例１の認可情報記憶機能１５０と認可情報付与機能１６０とを備えない点で実施例１と異なる。
【００７１】
アプリケーションサーバ１００Ｂは、公知の一般的なアプリケーションサーバである。
【００７２】
ＡＰＩサーバ２００Ｂの認可情報一時記憶機能２６０は、認可処理機能２３０がデータ取得要求４０を認可すると、認可関係（Ｌ１０）における要求データ（Ｌ１２）の親ノード（Ｌ１４）の情報を基に、該親ノードを格納するレコードの識別名（Ｄ２６、Ｄ３６）の値を認可情報名２６０−２として記憶し、リソースデータ２２０内で該親ノードのデータを一意に特定する識別子として、データベース名とレコードＩＤ（Ｄ２１、Ｄ３１）を結合した文字列（例えば、「撮影機テーブル：３」）を認可トークン２６０−４として記憶する。
【００７３】
これら認可情報名２６０−２と認可トークン２６０−４は、データ取得要求４０のＴＣＰセッションと紐づけて記憶し、ＴＣＰセッション切断時には破棄する。
【００７４】
ＡＰＩサーバ２００Ｂの認可情報判定機能２４０Ｂは、データ応答機能２１０がデータ取得要求４０を受信すると、認可情報一時機能２６０が保持する認可情報名２６０−２がデータ取得要求４０の要求ＵＲＬ４４に含まれているかどうか判定し、要求ＵＲＬ４４に含まれる場合、対応する認可トークン２６０−４と、認可関係Ｌ１０における要求ノードの親ノードが一致するかどうか判定する。一致する場合、認可情報判定機能２４０Ｂは、データ取得要求４０を認可する。一致しない場合は、認可処理機能２３０と同様の方式で認可判断を実施する。
【００７５】
以上、本実施例によれば、ＡＰＩサーバ側で要求データの親ノードの認可情報を保持し、該親ノードの認可関係配下のデータについては、該認可情報を使用して認可判断を実施することで、データベースの参照回数を抑えることができる。
【００７６】
これにより、ＨＴＴＰのＫｅｅｐ−Ａｌｉｖｅの機能により１つのＴＣＰセッションで複数のＨＴＴＰ要求を送信する場合は、アプリケーションサーバに独自の機能を必要とすることなく、ＡＰＩサーバの処理負荷、応答遅延を抑えることができる。
【符号の説明】
【００７７】
１０：Ｗｅｂサーバ、    １１：コンテンツ取得表示機能、１００：アプリケーションサーバ、１１０：コンテンツ生成応答機能、１２０：データ取得機能、１３０：セッション管理機能、１４０：セッション情報、１５０：認可情報記憶機能、１６０：認可情報付与機能、２００：ＡＰＩサーバ、２１０データ応答機能、２２０：リソースデータ、２３０：認可処理機能、２４０：認可情報判定機能、２５０：認可情報付与機能、４０：データ取得要求、４２：要求ヘッダ、４４：要求ＵＲＬ、４６：認証情報、４８：認可トークン、６０：データ応答、６２：応答ヘッダ、６４：認可情報、６６：要求データ
【図１】
2017224212.tif 000003
【図２】
2017224212.tif 000004
【図３】
2017224212.tif 000005
【図４】
2017224212.tif 000006
【図５】
2017224212.tif 000007
【図６】
2017224212.tif 000008
【図７】
2017224212.tif 000009