JP2015162057A - 情報処理システム及びプログラム - Google Patents

Abstract

【課題】クライアントから受け付けた要求に係る権限オブジェクトに応じて決定される関数により要求を処理する。
【解決手段】情報管理装置１０は、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理するオブジェクト情報管理部１１と、権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む実行する処理の要求を受け付けるリクエスト受付部１２と、権限オブジェクトに関連付けられた関数オブジェクトを取得する関数オブジェクト取得部１５と、関数オブジェクトにより要求を処理するリクエスト処理部１８を有する。
【選択図】図２

Description

本発明は、情報処理システム及びプログラムに関する。

オブジェクトを管理するサーバでは、処理の要求元であるクライアントが有する権限に応じてオブジェクトを処理（生成、取得、変更、削除等）することがある。ここで、サーバで管理するオブジェクトには生成、変更、削除等が行われることがあるため、クライアントに対してオブジェクトとは独立に権限を固定的に紐付けておくと、クライアントの権限に応じてオブジェクトを柔軟に処理することが困難となることがある。また、サーバにおいて実行される処理の指定を拡張可能に構成することで、システムの開発や利用性が向上することが期待される。

特開平０９−２５１４２５号公報

本発明の目的は、クライアントから受け付けた要求に係る権限オブジェクトに応じて決定される関数により要求を処理できる情報処理システム及びプログラムを提供することにある。

請求項１に係る発明は、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理する管理手段と、権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む実行する処理の要求を受け付ける受付手段と、前記権限オブジェクトに関連付けられた関数オブジェクトを取得する取得手段と、前記関数オブジェクトにより前記要求を処理する処理手段と、を含む情報処理システムである。

請求項２に係る発明は、前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとの情報の比較結果に基づいて、前記要求を受理するか否かを判断する判断手段を含み、前記処理手段は、前記要求を受理すると判断した場合に、前記関数オブジェクトにより前記要求を処理する請求項１に記載の情報処理システムである。

請求項３に係る発明は、前記判断手段は、前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとが一致する場合に、前記要求を受理する請求項２に記載の情報処理システムである。

請求項４に係る発明は、前記判断手段は、前記権限情報を認可したオブジェクトである所有者オブジェクトの親であるオブジェクト、さらに該所有者オブジェクトの親の親であるオブジェクトを順次接続した経路の中に、前記権限オブジェクトの親であるオブジェクトが含まれる場合に、前記要求を受理する請求項２に記載の情報処理システムである。

請求項５に係る発明は、前記判断手段は、前記権限オブジェクトが前記管理手段により管理されない場合には、前記要求を受理しない請求項２乃至４のいずれかに記載の情報処理システムである。

請求項６に係る発明は、前記判断手段は、前記権限オブジェクトが、前記権限情報を認可したオブジェクトである所有者オブジェクト、前記権限情報の委譲先を示すオブジェクトであるクライアントオブジェクト、前記権限情報により実行が許可される関数をそれぞれ指定するデータを含まない場合には、前記要求を受理しない請求項２乃至５のいずれかに記載の情報処理システムである。

請求項７に係る発明は、関数のソースコードを含むデータオブジェクトを登録する手段と、所与の所有者オブジェクト、所与のクライアントオブジェクト、前記データオブジェクトを指定する情報を含む権限オブジェクトを生成する生成手段と、を含む請求項６に記載の情報処理システムである。

請求項８に係る発明は、前記権限オブジェクトに含まれる情報により指定される前記データオブジェクトに含まれる関数のソースコードに基づいて関数オブジェクトが生成できない場合には、前記要求を受理しない請求項７に記載の情報処理システムである。

請求項９に係る発明は、前記取得手段は、前記権限オブジェクトに含まれる前記処理指定オブジェクトにより指定される前記データオブジェクトに含まれる関数のソースコードに基づいて生成された関数オブジェクトを取得する請求項７又は８に記載の情報処理システムである。

請求項１０に係る発明は、それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理する管理手段と、権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む実行する処理の要求を受け付ける受付手段と、前記権限オブジェクトに関連付けられた関数オブジェクトを取得する取得手段と、前記関数オブジェクトにより前記要求を処理する処理手段としてコンピュータを機能させるためのプログラムである。

請求項１及び１０に記載の発明によれば、クライアントから受け付けた要求に係る権限オブジェクトに応じて決定される関数により要求を処理できる。

請求項２に記載の発明によれば、クライアントから受け付けた要求に係る権限オブジェクトが適正である場合に要求を処理できる。

請求項３に記載の発明によれば、クライアントから受け付けた要求に係る権限オブジェクトの所有者が、権限オブジェクトの親である場合に要求を処理できる。

請求項４に記載の発明によれば、クライアントから受け付けた要求に係る権限オブジェクトの親が、権限オブジェクトの所有者の祖先に当たる場合に要求を処理できる。

請求項５に記載の発明によれば、不適正な権限に基づく要求に対する処理の実行を防止できる。

請求項６に記載の発明によれば、権限オブジェクトに関数オブジェクトが関連付けられていない場合にはクライアントからの要求を受理しないようにできる。

請求項７に記載の発明によれば、関数オブジェクトが関連付けられた権限オブジェクトを生成できる。

請求項８に記載の発明によれば、権限オブジェクトに適正な関数オブジェクトが関連付けられていない場合にはクライアントからの要求を受理しないようにできる。

請求項９に記載の発明によれば、権限オブジェクトに予め登録したソースコードに基づいて生成した関数オブジェクトを関連付けることができる。

本実施形態に係る情報処理システムのシステム構成図である。 情報管理装置の機能ブロック図である。 オブジェクトのデータ構成の一例を示す図である。 プロトタイプベースオブジェクト管理テーブルの一例を示す図である。 バリュー管理テーブルの一例を示す図である。 データオブジェクト管理テーブルの一例を示す図である。 アクセストークンの生成処理の一例を示すフロー図である。 ユーザ端末から受け付けたリクエストに対する処理の一例を示すフロー図である。 アクセストークンの検証処理の一例を示すフロー図である。 ユーザ端末から受け付けたデータ取得要求に対する処理の一例を示すフロー図である。 プロトタイプベースのオブジェクトにより構成される木構造の一例である。 オブジェクトが有するデータの一例を示す図である。

以下、本発明を実施するための実施の形態（以下、実施形態という）を、図面に基づいて説明する。

［１．システム構成の説明］
図１には、本実施形態に係る情報処理システムＳのシステム構成図を示した。図１に示されるように、情報処理システムＳは、情報管理装置１０と、１以上のユーザ端末５とを含み、情報管理装置１０とユーザ端末５とはそれぞれネットワーク２を介してデータ通信可能に接続される。

また、図１に示されるように、情報管理装置１０は、ハードウェア構成の一例として、制御部１０Ａ、記憶部１０Ｂ、通信部１０Ｃを備える。

制御部１０Ａは、ＣＰＵ（Central Processing Unit）を含み、記憶部１０Ｂに記憶されたプログラムに基づいて、各種の演算処理を実行するとともに情報管理装置１０の各部を制御する。

記憶部１０Ｂは、情報管理装置１０のオペレーティングシステム等の制御プログラムやデータを記憶するほか、制御部１０Ａのワークメモリとしても用いられる。プログラムは、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等の情報記憶媒体に格納された状態で情報管理装置１０に供給されてもよいし、インターネット等のデータ通信網を介して情報管理装置１０に供給されてもよい。

通信部１０Ｃは、例えばネットワークインターフェースカード（ＮＩＣ）を含み、ＮＩＣを介してネットワーク２に接続して、ネットワーク２に接続されるユーザ端末５と通信する。

本実施形態では、情報管理装置１０は、プロトタイプベースのオブジェクトを管理する。ここで、プロトタイプベースのオブジェクトとは、プロトタイプベースのオブジェクトの集合に唯一存在するルートオブジェクトを除けば、唯一つの親のオブジェクト（プロトタイプ）を持つオブジェクトのことであり、ルートオブジェクトは自身のプロトタイプを持たない。また、オブジェクトＡがオブジェクトＢのプロトタイプであるとき、オブジェクトＢはオブジェクトＡのアーティファクトであるともいう。オブジェクト間のプロトタイプ関係により、プロトタイプベースのオブジェクト全体の集合は木構造で表現される。また、オブジェクトにより構成される木構造を破壊しないならば、プロトタイプを再接続することで木構造を変形することが可能である。さらに、情報管理装置１０で管理するオブジェクトには、属性及び属性値を持たせることができる。ＲＥＳＴ（REpresentational State Transfer）アーキテクチャスタイルにおいては、オブジェクトをリソース、値を表現と呼ぶこともある。値を持つオブジェクトには、アクセストークンと呼ばれる権限情報を表すものがある。オブジェクトには、単にオブジェクト識別子とプロトタイプのみからなる純粋なアイデンティティのみを表すもの、任意のコンテント型の値を持つデータを表現するもの、アクセス資格を証明するクレデンシャルであるアクセストークン、あるいはオブジェクトの所有者であるリソースオーナーやリソースオーナーの認可のもとにオブジェクトへのアクセスを行うアプリケーション（クライアント）のようなエンティティを表すものが含まれることとしてよい。そして、これらのオブジェクトが１つの木構造の中に含まれる。

本実施形態では、情報管理装置１０は、ユーザ端末５から受け付けたリクエストに従って、管理するオブジェクトの追加、更新、情報の読み出し、削除等を実行する。また、情報管理装置１０は、アクセストークンと呼ばれる権限オブジェクトに対して、関数を識別する識別情報を関連付けておき、ユーザ端末５からリクエストとともに受け付けた権限オブジェクトに関連付けられた関数により、ユーザ端末５から受け付けたリクエストを処理することとする。以下では、以上の処理を実現するために、情報管理装置１０に備えられた機能の一例について詳細に説明する。

［２．情報管理装置１０に備えられた機能の説明］
次に、図２に示される情報管理装置１０の機能ブロック図に基づき、情報管理装置１０に備えられた機能の一例について説明する。図２に示されるように、情報管理装置１０は、オブジェクト情報管理部１１、リクエスト受付部１２、権限情報取得部１３、検証部１４、関数オブジェクト取得部１５、関数オブジェクト生成部１６、リクエスト処理部１７、処理データ提供部１８を備える。

情報管理装置１０に備えられる上記の各部の機能は、情報管理装置１０に備えられる制御部１０Ａが、記憶部１０Ｂやコンピュータ読み取り可能な情報記憶媒体に格納されたプログラムを読み込み実行することで実現されるものとしてよい。なお、プログラムは光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等の情報記憶媒体によって情報管理装置１０に供給されることとしてもよいし、インターネット等のデータ通信網を介して情報管理装置１０に供給されることとしてもよい。以下、情報管理装置１０に備えられる各部の機能の詳細について説明する。

オブジェクト情報管理部１１は、プロトタイプベースのオブジェクトの情報、データオブジェクトの情報を管理する。ここで、プロトタイプベースのオブジェクトには、権限情報が関連付けられたアクセストークンと呼ばれる権限オブジェクトを含む。プロトタイプベースのオブジェクトは変更可能（ミュータブル）なオブジェクトであり、典型的にはランダムに生成されたＩＤで識別される。データオブジェクトは変更不能（イミュータブル）なオブジェクトであり、典型的には対応するデータのハッシュ値として計算されたＩＤで識別される。また、データオブジェクトには、例えば、関数オブジェクトを生成するためのソースコード、ソースコードから生成された関数オブジェクトの識別情報等を含む関数データオブジェクトを含む。以下、図３に基づき、プロトタイプベースのオブジェクトと、データオブジェクトのデータ構成の一例について説明する。なお、図３に示した例では、データを構成する要素に対し、要素の具体的な内容を［要素］と表記している。

図３の（Ａ）には、プロトタイプベースのオブジェクトの基本的なデータ構成を示した。図３（Ａ）に示されるように、プロトタイプベースのオブジェクトは、オブジェクトの識別情報であるｉｄ、オブジェクトの親（プロトタイプ）オブジェクトの識別情報であるｐｒｏｔｏ、オブジェクトの型を示すｔｙｐｅ、オブジェクトのデータ内容を格納したデータオブジェクトの識別情報を表すｅｔａｇ、オブジェクトの生成日時を表すｔｉｍｅを含む。なお、プロトタイプベースのオブジェクトのデータ構成は、図３（Ａ）に示された例に限定されるものではなく、ｉｄ、ｐｒｏｔｏを含んでいれば、上述した要素以外の要素を含み構成されていても構わない。

図３の（Ｂ）には、アクセストークンのデータ構成を示した。図３の（Ｂ）に示されるように、アクセストークンは、｛“ｏｗｎｅｒ”： ｏｗｎｅｒ（オーナー）のオブジェクトＩＤ、“ｃｌｉｅｎｔ”： ｃｌｉｅｎｔ（クライアント）のオブジェクトＩＤ、“スコープ”：関数を識別する識別情報｝の情報を含む。本実施形態に係る情報処理システムＳでは、ユーザ端末５から受け付ける処理要求にはアクセストークンが添付されるが、ここで、オーナーが処理のリクエスタ、クライアントが処理の代理リクエスタとして扱われ、スコープには、関数データオブジェクトの識別情報が格納される。

図３の（Ｃ）には、データオブジェクト（関数データオブジェクト）のデータ構成を示した。図３の（Ｃ）に示されるように、関数データオブジェクトは、ソースコード（スクリプト）を格納したｃｏｎｔｅｎｔ、ソースコード（スクリプト）から生成（評価）された関数オブジェクトの識別情報であるｆｕｎｃ、データ内容のオクテット長を表すｌｅｎｇｔｈ、データが登録された日時を示すｔｉｍｅが含まれる。もちろん、データオブジェクトは図３の（Ｃ）に示した構成に限られるものではない。例えば、データオブジェクトに、データにアクセスしたクライアントのリストを格納するようにすることとしてもよく、この場合には、特定のオクテット配列にアクセスした全てのクライアントのリストを生成可能となる。

次に、図４乃至図６に基づき、図３に示したデータ構成のプロトタイプベースのオブジェクトとデータオブジェクトとを管理するための管理テーブルの一例について説明する。

まず、図４には、プロトタイプベースのオブジェクトの情報を管理するプロトタイプベースオブジェクト管理テーブルを示した。図４に示されるように、プロトタイプベースオブジェクト管理テーブルには、オブジェクトを識別するオブジェクトＩＤ、オブジェクトの親（プロトタイプ）であるプロトタイプオブジェクトを識別するプロトタイプＩＤ、オブジェクトの属性情報が関連付けて記憶される。例えば、オブジェクトの属性情報には、オブジェクトの型情報（ｔｙｐｅ）、オブジェクトに格納される（関連付けられる）値（バリュー）を格納したデータ（オブジェクト）の識別情報（ｅｔａｇ）、オブジェクトの生成日時（ｔｉｍｅ）等の情報が含まれる。

図５には、プロトタイプベースのオブジェクトのｅｔａｇに対応するデータを格納したバリュー管理テーブルの一例を示した。図５に示されるように、バリュー管理テーブルには、ｅｔａｇのＩＤ（キー）に関連付けてバリューの情報が記憶される。例えば、アクセストークンであれば、バリューは｛“ｏｗｎｅｒ”： ｏｗｎｅｒ（オーナー）のオブジェクトＩＤ、“ｃｌｉｅｎｔ”： ｃｌｉｅｎｔ（クライアント）のオブジェクトＩＤ、“スコープ”：関数を識別する識別情報｝というａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎのタイプのデータ形式に記述される。

図６には、データオブジェクト（ここでは関数データオブジェクト）の情報を管理するデータオブジェクト管理テーブルの一例を示した。図６に示されるように、データオブジェクト管理テーブルには、データオブジェクトを識別するデータＩＤ、関数オブジェクトのソースコード（スクリプト）を格納したｃｏｎｔｅｎｔ、ソースコードを評価して生成した関数オブジェクトの識別情報（ｆｕｎｃ）、データ内容のオクテット長を表すｌｅｎｇｔｈ、データが登録された日時を示すｔｉｍｅが関連付けて記憶される。

リクエスト受付部１２は、ユーザ端末５からオブジェクト情報管理部１１で管理されるオブジェクトの処理に関するリクエストを受け付ける。リクエスト受付部１２は、例えばユーザ端末５からＨＴＴＰリクエストの形式でリクエストを受け付けることとしてよい。

権限情報取得部１３は、リクエスト受付部１２で受け付けたリクエストに係るアクセストークン（権限オブジェクト）の情報を取得する。例えば、権限情報取得部１３は、アクセストークンの情報は、ＨＴＴＰリクエストのＡｕｔｈｏｒｉｚａｔｉｏｎフィールドから得てもよいし、アクセストークンの情報を含むクッキーが存在すれば、クッキーから得てもよい。

検証部１４は、権限情報取得部１３で取得されたアクセストークン（権限オブジェクト）の情報が正当なものであるか否かを検証する。以下、検証部１４による検証処理の具体例について説明する。

まず、検証部１４は、権限情報取得部１３で取得されたアクセストークンのＩＤが、オブジェクト情報管理部１１で管理するプロトタイプベースオブジェクト管理テーブルに含まれているか否か（第１の条件の適否）を判断し、含まれていない場合には検証失敗と判断する。

次に、検証部１４は、第１の条件が満たされている場合に、アクセストークンのデータ形式（タイプ）が所定の型（すなわち、ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ）であるか否か（第２の条件の適否）を判断し、所定の型でない場合には検証失敗と判断する。

次に、検証部１４は、第２の条件が満たされている場合に、アクセストークンのバリューの値（ｏｗｎｅｒ、ｃｌｉｅｎｔ、ｓｃｏｐｅの値）を取得し、ｏｗｎｅｒ、ｃｌｉｅｎｔ、ｓｃｏｐｅのそれぞれの値がオブジェクト情報管理部１１で管理されるデータであるか否か（第３の条件の適否）を判断し、いずれかの値がオブジェクト情報管理部１１で管理されるデータでない場合には検証失敗と判断する。

次に、検証部１４は、第３の条件が満足されている場合に、オブジェクト情報管理部１１からアクセストークンのプロトタイプの情報を取得し、アクセストークンのプロトタイプが、アクセストークンのオーナーと一致しているか、オーナーのプロトタイプチェーン（オーナーの親、さらにその親へとオーナーの祖先を順に接続した経路）に含まれるか否か（第４の条件の適否）を判断し、上記のいずれにも合致しない場合には検証失敗と判断する。

次に、検証部１４は、第４の条件が満足されている場合に、アクセストークンのスコープの情報に関数オブジェクトが割り当てられているか否か（第５の条件の適否）を判断し、スコープに関数オブジェクトが割り当てられていない場合には検証失敗と判断し、スコープに関数オブジェクトが割り当てられている場合には検証成功と判断する。なお、スコープに関数オブジェクトが割り当てられているか否かは、スコープの情報に基づいて関数オブジェクト取得部１５により関数オブジェクトが取得されるか否かに基づいて判断することとしてよい。

関数オブジェクト取得部１５は、アクセストークンのスコープの情報に基づいて、オブジェクト情報管理部１１から、スコープに関連付けられた関数オブジェクトの情報を取得する。例えば、関数オブジェクト取得部１５は、アクセストークンのスコープの情報（データオブジェクトのＩＤ）に基づいて、オブジェクト情報管理部１１で管理されるデータオブジェクト管理テーブルの中から対応するレコードを検索する。そして、関数オブジェクト取得部１５は、検索されたレコードのｆｕｎｃ属性を参照し、ｆｕｎｃ属性に値が格納されている場合には、ｆｕｎｃ属性の値を関数オブジェクトの識別情報として得る。また、関数オブジェクト取得部１５は、検索されたレコードのｆｕｎｃ属性に値が格納されていない場合には、ｃｏｎｔｅｎｔ属性に格納されたソースコードに基づく関数オブジェクトの生成（評価）を関数オブジェクト生成部１６に依頼する。

関数オブジェクト生成部１６は、関数オブジェクト生成部１６による依頼に係るソースコードを関数として評価できるかを判断し、関数として評価できない場合には関数オブジェクト取得部１５にエラーを返し、関数として評価できる場合にはソースコードに基づいて生成した関数オブジェクトの識別情報を関数オブジェクト取得部１５に返す。

関数オブジェクト取得部１５は、関数オブジェクト生成部１６からエラーが返ってきた場合には、検証部１４に関数オブジェクトの未割り当てを報告し、関数オブジェクト生成部１６から関数オブジェクトの識別情報が返ってきた場合には、その関数オブジェクトの識別情報を対応するレコードのｆｕｎｃ属性の値に格納するとともに、検証部１４にスコープに割り当てられた関数オブジェクトの識別情報を報告する。

リクエスト処理部１７は、リクエスト受付部１２で受け付けたリクエストについて権限情報取得部１３で取得したアクセストークン（権限オブジェクト）についての検証部１４１４から通知された検証結果と、該受け付けたアクセストークンについて関数オブジェクト取得部１５で取得された関数オブジェクトに基づいて、リクエスト受付部１２で受け付けたリクエストの処理を制御する。例えば、リクエスト処理部１７１５は、リクエスト受付部１２で受け付けたリクエストに係るアクセストークンについての検証結果が検証失敗である場合には、リクエストに係る処理を不受理としてエラーを処理データ提供部１８に出力することとしてよい。また、リクエスト処理部１７１５は、リクエスト受付部１２で受け付けたリクエストに係るアクセストークンについての検証結果が検証成功である場合には、リクエスト受付部１２１２で受け付けたリクエストを、該リクエストに関して受け付けたアクセストークンについて関数オブジェクト取得部１５で取得された関数オブジェクトに基づいて処理し、その実行結果を処理データ提供部１８１６に出力する。

処理データ提供部１８は、リクエスト処理部１７による処理結果を、リクエストの要求元であるユーザ端末５に対して提供する。

［３．処理の一例についての説明］
次に、図７乃至図１０に示されたフロー図に基づいて、情報処理システムＳで実行される処理の一例について詳細に説明する。

［３．１．トークンの生成処理］
まず、図７に示したフロー図に基づいて、情報管理装置１０が実行するアクセストークンの生成処理の一例について説明する。まず、図７のフローにおいては、アクセストークンｔが既に存在し、アクセストークンｔはオブジェクトの生成、取得、更新、削除が可能なスコープを有していることとする。

図７に示されるように、情報管理装置１０は、例えばユーザ端末５からアクセストークンｔを利用した、所望の関数のソースコードをバリューとして持つオブジェクト（関数データオブジェクト）ｆの生成要求を受け付けると（Ｓ１０１）、オブジェクトｆを生成する（Ｓ１０２）。ここで、情報管理装置１０は、Ｓ１０２で生成したオブジェクトｆの識別情報（ＩＤ）をユーザ端末５に通知することとしてよい。

さらに、情報管理装置１０は、例えばユーザ端末５からアクセストークンｔを利用した、オーナーｏ、クライアントｃ、スコープｆ（オブジェクトｆの識別情報）としたアクセストークンＴの生成要求を受け付けると（Ｓ１０３）、アクセストークンＴを生成する（Ｓ１０４）。そして、情報管理装置１０は、Ｓ１０４で生成したアクセストークンＴの情報（アクセストークンＴのＩＤ）を例えばユーザ端末５に提供して（Ｓ１０５）、処理を終了する。

［３．２．リクエストの処理］
次に、図８に示したフロー図に基づいて、情報管理装置１０がアクセストークンＴを利用したリクエストの処理の一例について説明する。

［３．２．１．リクエストの処理（Ｓ２０１〜Ｓ２０３）］
情報管理装置１０は、例えばユーザ端末５からリクエストを受け付けると（Ｓ２０１）、リクエストに係るアクセストークン（ここではアクセストークンＴとする）を取得する（Ｓ２０２）。例えば、情報管理装置１０は、アクセストークンのオブジェクトＩＤを、ユーザ端末５からのＨＴＴＰリクエストにおけるＡｕｔｈｏｒｉｚａｔｉｏｎフィールドから得てもよいし、アクセストークンの情報を含むクッキーが存在すれば、クッキーから得てもよい。

情報管理装置１０は、Ｓ２０２で取得したアクセストークンに基づく検証処理を実行する（Ｓ２０３）。ここで、アクセストークンに基づく検証処理の詳細については、図９に示したフロー図に基づき説明する。

［３．２．２．アクセストークンの検証処理］
図９には、アクセストークンの検証処理のフロー図を示した。図９に示されるように、情報管理装置１０は、検証対象となるアクセストークンのＩＤが、オブジェクト情報管理部１１で管理するＩＤの中に存在するか否かを判断する（Ｓ３０１）。例えば、情報管理装置１０は、オブジェクト情報管理部１１で管理するプロトタイプベースオブジェクト管理テーブルのオブジェクトＩＤの中に検証対象となるアクセストークンのＩＤが含まれるか否かにより、上記の判断を行うこととしてよい。そして、情報管理装置１０は、検証対象となるアクセストークンのＩＤが、オブジェクト情報管理部１１で管理するＩＤの中に存在する場合には（Ｓ３０１：Ｙ）、Ｓ３０２に進み、検証対象となるアクセストークンのＩＤが、オブジェクト情報管理部１１で管理するＩＤの中に存在しない場合には（Ｓ３０１：Ｎ）、検証失敗として（Ｓ３１２）、リターンする。

情報管理装置１０は、Ｓ３０１で検証対象となるアクセストークンのＩＤが、オブジェクト情報管理部１１で管理するＩＤの中に存在する場合には（Ｓ３０１：Ｙ）、アクセストークンのＩＤをキーとしてアクセストークンのデータを参照し、アクセストークンのデータ形式が正当であるか否かを判断する（Ｓ３０２）。例えば、情報管理装置１０は、アクセストークンに設定されたｔｙｐｅ属性がａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎである場合には正当と判断し、そうでない場合には正当でないと判断することとしてよい。そして、情報管理装置１０は、アクセストークンのデータ形式が正当である場合には（Ｓ３０２：Ｙ）、Ｓ３０３に進み、アクセストークンのデータ形式が正当でない場合には（Ｓ３０２：Ｎ）、検証失敗として（Ｓ３１２）、リターンする。

情報管理装置１０は、アクセストークンのデータ形式が正当である場合には（Ｓ３０２：Ｙ）、さらにアクセストークンについて指定されたオーナー、クライアント、スコープのバリュー（ＩＤ）を取得し（Ｓ３０３）、オーナー、クライアント、スコープで指定されるオブジェクトＩＤがオブジェクト情報管理部１１で管理するＩＤの中に存在するか否かを判断する（Ｓ３０４）。例えば、情報管理装置１０は、オーナー、クライアント、スコープで指定されるオブジェクトＩＤがプロトタイプベースオブジェクト管理テーブルかデータオブジェクト管理テーブルのいずれかに含まれているか否かに基づいて上記の判断を行うこととしてよい。そして、情報管理装置１０は、アクセストークンについて指定されたオーナー、クライアント、スコープのオブジェクトＩＤがオブジェクト情報管理部１１で管理するＩＤの中に含まれる場合には（Ｓ３０４：Ｙ）、Ｓ３０５に進み、オーナー、クライアント、スコープのオブジェクトＩＤがオブジェクト情報管理部１１で管理するＩＤの中に含まれない場合には（Ｓ３０４：Ｎ）、検証失敗として（Ｓ３１２）、リターンする。

情報管理装置１０は、アクセストークンについて指定されたオーナー、クライアント、スコープのオブジェクトＩＤがオブジェクト情報管理部１１で管理するＩＤの中に含まれる場合には（Ｓ３０４：Ｙ）、アクセストークンのプロトタイプの情報（親オブジェクトのオブジェクトＩＤ）を取得する（Ｓ３０５）。そして、情報管理装置１０は、アクセストークンのプロトタイプオブジェクトが、アクセストークンについて指定されたオーナーと一致するか、オーナーのプロトタイプチェーン（オーナーの祖先のオブジェクトを順に接続した経路）に含まれるか否かを判断し（Ｓ３０６）、含まれると判断する場合には（Ｓ３０６：Ｙ）、Ｓ３０７に進み、含まれないと判断する場合には（Ｓ３０６：Ｎ）、検証失敗として（Ｓ３１２）、リターンする。

情報管理装置１０は、アクセストークンのプロトタイプオブジェクトが、アクセストークンについて指定されたオーナーと一致するか、オーナーのプロトタイプチェーンに含まれる場合には（Ｓ３０６：Ｙ）、アクセストークンについて指定されたスコープのオブジェクトＩＤのデータを参照する（Ｓ３０７）。例えば、情報管理装置１０は、スコープのオブジェクトＩＤをキーとして、データオブジェクト管理テーブルに格納されるレコードの情報を参照することとしてよい。

情報管理装置１０は、Ｓ３０７で参照したスコープのデータに、関数オブジェクトが割り当てられているか否かを判断する（Ｓ３０８）。例えば、情報管理装置１０は、スコープのデータにおけるｆｕｎｃ属性に識別情報が格納されているか否かに基づいて上記の判断を行うこととしてよい。そして、情報管理装置１０は、スコープに関数オブジェクトが割り当てられている場合には（Ｓ３０８：Ｙ）、検証成功として（Ｓ３０９）、リターンする。また、情報管理装置１０は、スコープに関数オブジェクトが割り当てられていない場合には（Ｓ３０８：Ｎ）、スコープのデータに含まれるソースコードが関数として評価できるか否かを判断する（Ｓ３１０）。そして、情報管理装置１０は、Ｓ３１０でスコープのデータに含まれるソースコードが関数として評価できる場合には（Ｓ３１０：Ｙ）、ソースコードに基づいて関数オブジェクトを生成して、生成した関数オブジェクトのＩＤをスコープのｆｕｎｃ属性に格納してスコープのデータを更新する（Ｓ３１１）。また、情報管理装置１０は、Ｓ３１０でスコープのデータに含まれるソースコードが関数として評価できない場合には（Ｓ３１０：Ｎ）、検証失敗として（Ｓ３１２）、リターンする。

以上が、アクセストークンに基づく検証処理の流れである。ここで再び図８に示したフロー図に戻り説明を続ける。

［３．２．３．リクエストの処理（Ｓ２０４〜Ｓ２０８）］
図８に示されるように、情報管理装置１０は、アクセストークンについての検証処理を終えると（Ｓ２０３）、アクセストークンの検証処理の結果が検証成功である場合には（Ｓ２０４：Ｙ）、アクセストークンのスコープに割り当てられた関数オブジェクトを取得する（Ｓ２０５）。例えば、情報管理装置１０は、アクセストークンのスコープのデータにおけるｆｕｎｃ属性に格納された識別情報により識別される関数オブジェクトを取得することとしてよい。

次に、情報管理装置１０は、Ｓ２０５で取得したアクセストークンに関連付けられた関数オブジェクトに基づいて、Ｓ２０１で受け付けたリクエストを処理する（Ｓ２０６）。そして、情報管理装置１０は、Ｓ２０６で処理した結果生成した処理データを、リクエストに対する応答として、リクエスト元であるユーザ端末５に対して提供して（Ｓ２０７）、処理を終える。

また、情報管理装置１０は、Ｓ２０４でアクセストークンの検証処理の結果が検証失敗である場合には（Ｓ２０４：Ｎ）、リクエスト元であるユーザ端末５に対してエラーを通知して（Ｓ２０８）、処理を終える。ここで、情報管理装置１０は、検証失敗の内容（原因）に応じて対応するエラーコードをユーザ端末５に対して通知することとしてよい。

以上の説明した情報管理装置１０によれば、アクセストークンに任意のサーバサイド処理を対応付けておくことが可能となる。これにより、一つのエンドポイントに対して、アクセストークンに紐付くスコープの値を変更することで、実行される処理を切り替えることもできる。

［３．３．リクエストの処理の具体例について］
次に、図１０に示されたフロー図、図１１及び図１２に示したオブジェクトの構成例に基づいて、情報管理装置１０において実行されるリクエストの処理の一例について説明する。以下に説明する例においては、プロトタイプベースのオブジェクトにユーザ端末５に提供するコンテンツ（例えばウェブページ）を構成する要素及びその値を、属性及び属性値としたデータが付与されていることとする。まず、図１１及び図１２に基づいて、オブジェクトの構成例について説明する。

図１１には、プロトタイプベースのオブジェクトを木構造に表した図を示した。図１１に示されるように、「ｒｏｏｔ」オブジェクトＰ１はルートオブジェクトであり、「ｇｅｎｅｒｉｃ」オブジェクトＰ１１はＰ１をプロトタイプとするオブジェクトである。さらに、「ｃｕｓｔｏｍｅｒ」オブジェクトＰ１１１と、「Ａ社」オブジェクトＰ１１２は、Ｐ１１をプロトタイプとするオブジェクトである。「Ｂ社」オブジェクトＰ１１１１、「Ｃ社」オブジェクトＰ１１１２は、Ｐ１１１をプロトタイプとするオブジェクトである。「開発」オブジェクトＰ１１２１、「営業」オブジェクトＰ１１２２は、Ｐ１１２をプロトタイプとするオブジェクトである。「ユーザａ」オブジェクトＰ１１２１１は、Ｐ１１２１をプロトタイプとするオブジェクトである。「アクセストークンＴａ」オブジェクトＰ１１２１１１、「ａのカスタムコンテンツ」Ｐ１１２１１２は、Ｐ１１２１１をプロトタイプとするオブジェクトである。

図１２には、図１１に示された各オブジェクトに属性として付与されたデータの一例を示した。各オブジェクトデータには、’属性’と’属性値’の組が１以上含まれている。

次に、図１０に示されたフロー図に基づいて、プロトタイプベースのオブジェクトからリクエストに係るデータを読み出して応答する処理について説明する。なお、図１０に示す例では、情報管理装置１０がユーザ端末５からのリクエストの際に受け付けたアクセストークンには、オブジェクトのデータの読み出し（ｒｅａｄ）が許可される関数が関連付けられていることとする。

図１０に示されるように、情報管理装置１０は、例えばユーザ端末５からリクエストＵＲＩであるｕｒｉを取得すると（Ｓ４０１）、ｕｒｉがオブジェクトＩＤの形式である場合には（Ｓ４０２：Ｙ）、ｕｒｉで指定されるオブジェクトＩＤのデータが存在するか否かを判断し（Ｓ４０３）、データが存在する場合には（Ｓ４０３：Ｙ）、データを読み出してリクエストの応答として返し（Ｓ４０４）。データが存在しない場合には（Ｓ４０３：Ｎ）、エラーを通知して（Ｓ４０５）、処理を終了する。

また、情報管理装置１０は、Ｓ４０１で取得したｕｒｉがオブジェクトＩＤの形式でない場合には（Ｓ４０２：Ｎ）、ｕｒｉには属性名が指定されているものと判断し、ユーザ端末５から受け付けたリクエストに係るアクセストークンのクライアントの情報により指定されるオブジェクトを注目オブジェクトに設定する（Ｓ４０６）。

そして、情報管理装置１０は、注目オブジェクトに付与されたデータの中に、ｕｒｉで指定された属性が含まれているか否かを判断し（Ｓ４０７）、含まれている場合には（Ｓ４０７：Ｙ）、注目オブジェクトに付与されたデータをリクエストに係る属性の属性値として返して（Ｓ４０８）、処理を終了する。

また、情報管理装置１０は、注目オブジェクトに付与されたデータの中に、ｕｒｉで指定された属性が含まれていない場合には（Ｓ４０７：Ｎ）、現在の注目オブジェクトの親（すなわちプロトタイプ）のオブジェクトがあるときには（Ｓ４０９：Ｙ）、現在の注目オブジェクトの親を新たな注目オブジェクトに設定して（Ｓ４１０）、Ｓ４０７に戻る。また、情報管理装置１０は、Ｓ４０９で現在の注目オブジェクトの親（すなわちプロトタイプ）のオブジェクトがないときには（Ｓ４０９：Ｎ）、対応するデータなしとしてエラーを通知して（Ｓ４０５）、処理を終了する。

以上のオブジェクト構成及びリクエストの処理によれば、データの読み出しの関数は共通としつつも、アクセストークンで指定されるクライアントのオブジェクトと、そのプロトタイプチェーン上にあるオブジェクトに付与された属性及び属性値に応じて、ユーザ端末５に対してリクエストに係る属性の値を提供できる。

なお、以上説明した実施形態は具体例として示したものであり、本明細書にて開示される発明をこれら具体例の構成やデータ格納例そのものに限定するものではない。当業者はこれら開示された実施形態に種々の変形、例えば、データ構造、処理の実行順を変更したりしてもよい。本明細書にて開示される発明の技術的範囲は、そのようになされた変形をも含むものと理解すべきである。

Ｓ 情報処理システム、５ ユーザ端末、１０ 情報管理装置、１１ オブジェクト情報管理部、１２ リクエスト受付部、１３ 権限情報取得部、１４ 検証部、１５ 関数オブジェクト取得部、１６ 関数オブジェクト生成部、１７ リクエスト処理部、１８ 処理データ提供部。

Claims (10)

1. それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理する管理手段と、
   権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む実行する処理の要求を受け付ける受付手段と、
   前記権限オブジェクトに関連付けられた関数オブジェクトを取得する取得手段と、
   前記関数オブジェクトにより前記要求を処理する処理手段と、を含む
   情報処理システム。
2. 前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとの情報の比較結果に基づいて、前記要求を受理するか否かを判断する判断手段を含み、
   前記処理手段は、前記要求を受理すると判断した場合に、前記関数オブジェクトにより前記要求を処理する
   請求項１に記載の情報処理システム。
3. 前記判断手段は、前記権限情報を認可したオブジェクトである所有者オブジェクトと、前記権限オブジェクトの親であるオブジェクトとが一致する場合に、前記要求を受理する
   請求項２に記載の情報処理システム。
4. 前記判断手段は、前記権限情報を認可したオブジェクトである所有者オブジェクトの親であるオブジェクト、さらに該所有者オブジェクトの親の親であるオブジェクトを順次接続した経路の中に、前記権限オブジェクトの親であるオブジェクトが含まれる場合に、前記要求を受理する
   請求項２に記載の情報処理システム。
5. 前記判断手段は、前記権限オブジェクトが前記管理手段により管理されない場合には、前記要求を受理しない
   請求項２乃至４のいずれかに記載の情報処理システム。
6. 前記判断手段は、前記権限オブジェクトが、前記権限情報を認可したオブジェクトである所有者オブジェクト、前記権限情報の委譲先を示すオブジェクトであるクライアントオブジェクト、前記権限情報により実行が許可される関数をそれぞれ指定するデータを含まない場合には、前記要求を受理しない
   請求項２乃至５のいずれかに記載の情報処理システム。
7. 関数のソースコードを含むデータオブジェクトを登録する手段と、
   所与の所有者オブジェクト、所与のクライアントオブジェクト、前記データオブジェクトを指定する情報を含む権限オブジェクトを生成する生成手段と、を含む
   請求項６に記載の情報処理システム。
8. 前記権限オブジェクトに含まれる情報により指定される前記データオブジェクトに含まれる関数のソースコードに基づいて関数オブジェクトが生成できない場合には、前記要求を受理しない
   請求項７に記載の情報処理システム。
9. 前記取得手段は、前記権限オブジェクトに含まれる前記処理指定オブジェクトにより指定される前記データオブジェクトに含まれる関数のソースコードに基づいて生成された関数オブジェクトを取得する
   請求項７又は８に記載の情報処理システム。
10. それぞれ親又は子の少なくとも一方が定められたオブジェクトの情報を管理する管理手段と、
    権限情報が関連付けられたオブジェクトである権限オブジェクトの指定を含む実行する処理の要求を受け付ける受付手段と、
    前記権限オブジェクトに関連付けられた関数オブジェクトを取得する取得手段と、
    前記関数オブジェクトにより前記要求を処理する処理手段
    としてコンピュータを機能させるためのプログラム。

Images