JP4787617B2 - アプリケーション特有のアクセス制御を別個のサーバを用いてサポートするための手法 - Google Patents

Description

発明の分野
この発明は、アプリケーションの動作へのユーザアクセスを制御することに関し、特に、アプリケーションの動作へのユーザアクセスを、アプリケーションとは別個のサーバを用いて制御することに関する。

発明の背景
コンピュータ処理相互作用のクライアント−サーバモデルは、幅広く用いられている。クライアント−サーバモデルによれば、クライアントプロセスは、要求を含むメッセージをサーバプロセスに送信し、サーバプロセスは、サービスを提供することによって応答する。サーバプロセスはまた、クライアントプロセスへの応答とともにメッセージを返してもよい。クライアントプロセスおよびサーバプロセスは往々にして、ホストと呼ばれる異なるコンピュータ装置上で実行され、ネットワーク通信用の１つ以上のプロトコルを用いて、ネットワークを介して通信する。

「サーバ」という用語は従来、サービスを提供するプロセス、またはプロセスが動作するホストコンピュータを指すために使用されている。同様に、「クライアント」という用語は従来、要求を行なうプロセス、またはプロセスが動作するホストコンピュータを指すために使用される。ここで使用されているように、「クライアント」および「サーバ」という用語は、文脈から特に明らかとなっていない限り、ホストコンピュータというよりもむしろプロセスを指している。

データベースサーバは、データベースクライアントからの要求に応答して、データベースサービスを提供する。たとえば、データベースサーバは、要求において受信されたデータを、データベースサーバによって管理されるある特定のデータベース内の１つ以上のデータコンテナに書込む。または、データベースサーバは、要求において特定された条件を満たすそれらのコンテナのうちの１つ以上から、データを検索する。もしくは、それは両方とも行なう。多くの状況において、データベースクライアントは、データベースサーバとは異なる中層のアプリケーションであり、それは１人以上のアプリケーションユーザのために会計サービスといった他のサービスを実行する。アプリケーション自体はクライアント−サーバ動作用に構成されていてもよく、そのため、アプリケーションユーザは、アプリケーションサーバにアプリケーション要求を行なうアプリケーションクライアントを動作させる。

データベースサーバのすべてのユーザに、データベースサーバによって管理される全データベースオブジェクト内の全データへのアクセスが付与されるわけではない。したがって、データベース内のデータへのデータベースユーザのアクセスを制御するアクセス制御を実現することは、データベースサーバにとってよくあることである。多くのアクセス制御メカニズムが公知である。たとえば、マーシー（Murthy）に記載されている均一なアクセス制御メカニズムは、データベースユーザには記憶コンテナの階層、または定義された列を有するテーブルのリレーショナルデータベース、もしくはその双方に編成されているように見えるデータ内容についてのアクセス制御を提供する。

アクセス制御はしばしば、データベース動作を実行する特権として実現されており、データベース内のある特定のデータ項目またはデータ項目の群について、１組の１つ以上の
特権がデータベースの各ユーザに関連付けられている。たとえば、基本データベース動作、たとえばテーブルなどのデータベースオブジェクト内に存在し得るデータ項目のデータを読出す、挿入する、削除する動作、またはデータベースオブジェクト自体を作成する、修正する、または削除する動作を実行するために、基本的な特権が定義されている。

基本データベース動作を実行する特権は、データベースのいくつかのレベルのうちのある特定のレベルに関連付けられてもよい。データベースのレベルは、たとえば、データ項目のレベル、いくつかのデータ項目のデータベースオブジェクトのレベル、いくつかのデータベースオブジェクトの階層のノードのレベル、および、データベースオブジェクトのいくつかの子孫ノードの親ノードのレベルを含む。ある特権がある特定のレベルに関連付けられると、その特権はそのレベルでの全項目に当てはまるかもしれない。

いくつかのデータベース管理システムでは、特権の階層が定義されていてもよく、階層における各ノードは、データベースの１つ以上のレベルに対して基本動作のある組合せを実行する特権を表わしている。特権のこの階層をサポートするため、いくつかのデータベース管理システムにおけるデータベースサーバは、特権を記述し、ユーザおよびデータ項目を特権と関連付け、特権についての情報を高速メモリキャッシュに効率よく記憶および検索して、データベースユーザが、要求されたデータ項目またはデータベースオブジェクトに対して、要求されたデータベース動作を実行してもよいかどうかを迅速に判断するインフラストラクチャを提供する。

データベース動作を実行する特権に基づいてデータベースへのアクセス制御をサポートするインフラストラクチャは、データベース動作の細分性でアクセス制御を提供する。しかしながら、データベース動作レベルの細分性でアクセス制御を提供する能力は、データベースを使用するアプリケーションにおいて定義されている動作に基づいてアクセスを制御したい場合には、特に有用ではない。そのような動作をここに「アプリケーション特有の」動作と呼ぶ。

たとえば、ある企業のために発注書を管理するアプリケーションでは、アプリケーション特有の動作は、新しい発注書の作成、発注書の承認、購入を行なうための発注書の発行、ある特定の発注書への請求書の関連付け、配送された注文の受領確認、および関連付けられた請求書の支払による発注書の清算を含む。あるアプリケーションユーザにこれらのアプリケーション特有の動作の一部のみを実行する特権が与えられる場合、アクセス制御は、アプリケーション特有の動作のレベルの細分性で提供されなければならない。アクセス制御のこのレベルの細分性はデータベースサーバによって提供されないため、アプリケーション特有の動作の特権を使用する各アプリケーションの開発者は、異なるユーザのための異なる特権を管理するアクセス制御ソフトウェアを設計し、実現しなければならない。

各アプリケーションについてアクセス制御ソフトウェアを開発することにはいくつかの欠点がある。一欠点は、アクセス制御を実現するソフトウェアを生成するために開発資源が消費されるため、アプリケーションの開発費が増加することである。アクセス制御がより高度化するにつれ、開発費もより高くなる。逆に、アクセス制御の開発にかける金額が少なくなるほど、実現されるアクセス制御は高度ではなくなる。別の欠点は、新しいアプリケーション用に開発されるアクセス制御が往々にして、長年にわたっていくつかのシステムおよびサーバ用に既に開発されているアクセス制御ほど効率的ではないことである。たとえば、データベースサーバの中には、ユーザ特権を示すデータの効率的なキャッシングの使用を含め、計算用資源を最小限しか使用しないアクセス制御を備えて進化してきた
ものもある。

さらに、個別に開発されたアクセス制御メカニズムを有する多数のアプリケーションのアドミニストレータは、特権の階層を表現し、それらの特権へのアプリケーションユーザおよびデータ項目の関連付けを表現するために、異質のインターフェイスに取組まなければならない場合がある。多数のアプリケーションにわたって同じアクセス制御インフラストラクチャが利用可能である場合、それら多数のアプリケーションについてのアドミニストレータは、特権および関連するユーザならびにデータ項目についての情報を、より少ない集中力およびエラーでより容易に入力することができる。

前述の記載に基づき、データベースアプリケーションが、データベースサーバの効率的なアクセス制御メカニズムを利用できるようにするための明らかな要望が存在している。どのアプリケーションも、別個のサーバにおいて既に実現されている高度化した、かつ効率的なアクセス制御メカニズムを利用できるようにするための要望が、一般に存在している。

この項に記載されたアプローチは追求可能であるが、それらは必ずしも、以前に考えられまたは追求されてきたアプローチであるとは限らない。したがって、ここに特に示されていない限り、この項に記載されたアプローチは、この背景の項に存在するというだけの理由で、本出願の請求項に対する先行技術として考えられるべきではない。

この発明を、添付図面の図において、限定のためではなく例示のために説明する。図中、同じ参照番号は同様の要素を示す。

発明の詳細な説明
アプリケーション特有の動作に対するアクセス制御を別個のサーバを用いてサポートするための方法および装置が記載される。以下の記載では、説明のため、数多くの特定の詳細がこの発明の完全な理解を提供するために述べられる。しかしながら、この発明がこれらの特定の詳細なしで実践され得ることは明らかである。他の点では、この発明を不必要に不明瞭にしないよう、周知の構造および装置はブロック図の形で示される。

以下に、ある実施例が、データベースサーバ、およびデータベースクライアントであるアプリケーションの状況で説明される。この状況では、アプリケーションはデータベースサーバを、アプリケーション用のデータを記憶するためだけでなく、データベース動作ではない代わり、アプリケーションに特有の動作である動作についてアクセス制御をサポートするためにも使用する。この発明の実施例はこの状況に限定されないが、アプリケーション特有の動作に対するアクセス制御をサポートするために任意の別個のサーバに頼る任意のアプリケーションを含んでいてもよい。アプリケーションとサーバとは別個のプロセスであるが、実施例によっては、双方が同じコンピュータホスト上で実行されてもよい。

一実施例によれば、アプリケーション特有の動作のためのアクセス制御は、アプリケーションが、第１の組のアプリケーション特有の動作を実行するための特権の第１の階層を記述するデータをサーバに送信することによって、達成される。アプリケーションはまた、サーバに、アプリケーションの第１のユーザを特権の第１の階級におけるある特権に関連付けるデータを送信する。ある特定のユーザがある特定のアプリケーション特有の動作を実行するよう許可されているかどうかを判断するために、アプリケーションはサーバに要求を送信する。要求は、特定のユーザおよび特定のアプリケーション特有の動作を示す。要求の受信に応答して、サーバは、アプリケーションから以前に受信したデータに基づき、ある特定のユーザがアプリケーションにある特定のアプリケーション特有の動作を実
行させてもよいかどうかを判断する。応答がアプリケーションに送信される。応答は、その特定のユーザがアプリケーションにその特定のアプリケーション特有の動作を実行させてもよいかどうかを示す。

これらの手法のいくつかの実施例では、アプリケーションによってサーバに送信されたデータは、アプリケーションの第１のユーザを、サーバに記憶された特定の型のデータ項目についての第１の階層におけるある特権と関連付ける。実施例によっては、アプリケーションはサーバに、いくつかの異なるユーザ、またはいくつかの異なるデータ項目、もしくはその双方についての特権情報を提供してもよい。

アクセス制御は一般に、動作を実行する特権の階層として表現可能である。階層は周知の数学的構成体である。一般に、階層は多数レベルのノードから構成されている。各レベルのノードは各々、異なるレベルの１つ以上のノードにリンクされている。トップレベルの下のレベルの各ノードは、上のレベルの１つ以上の親ノードの子ノードである。ツリー階層では、各子ノードは親ノードを１つしか持たないが、親ノードは多数の子ノードを有していてもよい。ツリー階層では、親ノードがリンクされていないノードはルートノードであり、子ノードがリンクされていないノードはリーフノードである。ツリー階層は通常、単一のルートノードを有する。ツリー階層は、１つ以上の子特権を含む親特権を記述するために使用可能である。

特権の階層において、各リーフリードは、アクセスが制御されるべき１つのアプリケーション特有の動作を実行する特権に対応している。２つ以上のアプリケーション特有の動作を実行する特権は、２つ以上のアプリケーション特有の動作に対応するリーフノードについての階層における先祖ノードに対応している。

図１は、ある企業の発注書（ＰＯ）を管理するアプリケーションのためにアプリケーション特有の動作を実行する特権の例示的な階層１００を示すブロック図である。例示的な階層１００では、各ノード１１０は、発注書（ＰＯ）に関連する１つ以上のアプリケーション特有の動作を実行する特権に対応している。省略記号１１１は、追加の特権をもしあれば表わす追加のノードを表わしている。他の実施例では、特権の階層は、より多いまたはより少ないレベルの、より多いまたはより少ないノードを有していてもよい。

階層１００における各リーフノードは、アクセスが制御されるべきアプリケーション特有の動作のうちの１つを実行する各特権に対応している。例示された実施例では、単独のアプリケーション特有の動作についての特権、および対応するリーフノードを表１に列挙する。これらの特権のいずれも、アプリケーションについてのアドミニストレータの判断で、アプリケーションのどのユーザに付与されてもよい。

階層１００はまた、２つ以上のアプリケーション特有の動作についての特権を表わす親ノードを含んでいる。親ノード１１０ｃでのApprove_POと名付けられた特権は、ノード１１０ｇでのサービスを承認する特権、ノード１１０ｈでの設備を承認する特権、ノード１１０ｉでの供給品を承認する特権を含んでいる。親ノード１１０ｅでのAccept_Deliveryと名付けられた特権は、ノード１１０ｊでの配送されたサービスを受入れる特権、ノード１１０ｋでの配送された設備を受入れる特権、ノード１１０ｌでの配送された供給品を受入れる特権を含んでいる。そのような親ノードでの特権は、部長といったアプリケーションのある監督ユーザに付与されてもよい。ノード１１０ａでのPO_ALLについての特権は、ノード１１０ｂでのＰＯを作成する特権、ノード１１０ｃでのＰＯを承認する特権、ノード１１０ｄでの承認されたＰＯの購入を行なう特権、ノード１１０ｅでのＰＯの下で購入品の配送を受入れる特権、およびノード１１０ｆでのＰＯの下で配送された購入品についての支払を行なう特権を含んでいる。PO_ALLについての特権は、発注書に関するアプリケーション特有の動作をすべて実行する特権を含む。

構造的概要
図２は、一実施例に従った、アプリケーション特有の動作に対するアクセス制御を、別個のデータベースサーバを用いてサポートするためのシステム２００を例示するブロック図である。システム２００は、アプリケーション２２０と、アプリケーションクライアント２１０と、データベースサーバ２３０とを含む。アプリケーション２２０は、１つ以上のアプリケーションクライアント２１０からの１つ以上のコマンドに応答して、１つ以上のアプリケーション特有の動作を実行する。

データベースサーバ２３０は、アプリケーション２２０のために１つ以上のデータベースオブジェクトのデータベースを管理する。データベースサーバ２３０は、永続的ストレージ２４０およびキャッシュ２３２を、データベースサーバ２３０の高速だが揮発性のメモリに含む。なお、データベースサーバ２３０はプロセスである。永続的ストレージ２４０およびキャッシュ２３２は、データベースサーバプロセス２３０に割当てられたホスト
の永続的ストレージおよびホストのメモリの一部である。その結果、アプリケーション２２０およびデータベースサーバ２３０は、ホストの永続的ストレージの異なる部分およびホストのメモリの異なる部分を用いて、またはホストのメモリの同じ部分を異なる時間に用いて、同じホスト上で実行されてもよい。データベースサーバの永続的ストレージ２４０内に、データベースサーバ２３０は、１つ以上のデータ構造２４２、２４４、および、１つ以上のデータベースオブジェクト（図示せず）内の１つ以上のデータ項目を記憶させる。データ構造２４２は、アプリケーション２２０のための１つ以上の特権階層を表わすデータを保持する。データ構造２４４は、アプリケーション２２０の１人以上のユーザおよび１つ以上のデータ項目を、アプリケーション２２０のためにデータ構造２４２に表わされた１つ以上の特権階層における１つ以上の特権と関連付けるデータを保持する。図２では２つのデータ構造として図示されているものの、他の実施例では、データ構造２４２、２４４のデータは、より多いまたはより少ないデータ構造に記憶されてもよい。

機能的概要
例示された実施例によれば、アプリケーション２２０がクライアントのために、アクセスが制御されるアプリケーション特有の動作を実行する前に、アプリケーション２２０は、そのクライアントに関連するユーザが、アプリケーション２２０がある特定のデータ項目に対してアプリケーション特有の動作を実行することを許可する特権を有するかどうかを判断するために、データベースサーバ２３０に要求を送信する。この要求、およびデータ構造２４２、２４４に記憶された情報に基づいて、データベースサーバ２３０はアプリケーション２２０に応答を返す。この応答は、アプリケーション２２０がその特定のデータ項目に対してアプリケーション特有の動作を実行することを許可する特権を、ユーザが有するかどうかを示すデータを含んでいる。

アプリケーション２２０についてのアドミニストレータは、データ構造２４２、２４４内の情報を提供する。例示された実施例では、アプリケーションアドミニストレータは、階層を記述するデータを記憶するために、拡張可能マークアップ言語（ＸＭＬ）文書を使用している。ＸＭＬは、構造化されたデータを記述するために、ワールドワイドウェブ・コンソーシアム（Ｗ３Ｃ）により公布されている基準によって定義されている、周知のかつ広範に使用されているマークアップ言語であり、データ要素の任意のツリー階層を可能にする。アプリケーションアドミニストレータは次に、データベースサーバ２３０によって提供されたインターフェイスと対話する。インターフェイスにより、アプリケーションアドミニストレータは、各データ項目またはデータ項目の群に当てはまる階層を記述するＸＭＬ文書を示し、アプリケーション２２０の各ユーザに当てはまる、各階層における１つ以上の特権を示すようになる。

実施例によっては、１つのアプリケーションについてのいくつかの特権階層の各々は、アプリケーション特有の動作が動作する、対応する型のデータ項目と関連付けられる。たとえば、特権階層１００は、ある企業の発注書を表わすデータ項目と関連付けられているが、同じ企業についての人事記録を表わすデータ項目とは関連付けられていない。人事記録に対して動作する特権は、特権階層１００とは異なる第２の特権階層（図示せず）において示される。そのような実施例では、データ構造２４２のデータは、各特権階層を、それらの特権によって許可された動作が動作する１つ以上の型のデータ項目と関連付ける。

アプリケーション特有の動作に対するアクセス制御をサポートするための方法
この方法を説明するため、例示的な一実施例を説明する。例示的な実施例では、アプリケーションアドミニストレータは、発注書オブジェクトに対するアプリケーション特有の動作についての特権の階層を記述する拡張可能マークアップ言語（ＸＭＬ）文書を生成する。他の実施例では、特権の階層を表わすために、他の構造化されたデータフォーマットが使用されてもよい。

例示的な実施例では、各ＸＭＬ要素は、特権の階層におけるある特権を表わすノードに対応している。表２は、表１に示す例示的な階層１００を記述するＸＭＬ文書の一例の一部を示している。

例示のため、表２に列挙されたラインを有するＸＭＬ文書は、アプリケーション２２０用のホストコンピュータ上のPOprivileges.xmlと名付けられたファイルに記憶されていると仮定される。各ＸＭＬ要素は名前を有する。ＸＭＬ要素の最初は、ＸＭＬ要素の名前を囲む記号“＜”“＞”によって表わされる。ＸＭＬ要素の最後は、ＸＭＬ要素の名前を囲む記号“＜／”“＞”によって表わされる。ある親要素の子要素はすべて、親要素の最初および最後を表わす記号の間に含まれる。ある要素に子がない場合、それはオプションで、記号“＜”“／＞”によって囲まれる要素の名前によって表わされ得る。

表２のライン１および１７に示された省略記号は、ライン２〜１６に先行する、または続く、ＸＭＬ文書内のＸＭＬラインを表わしている。ＸＭＬライン２〜１６は、PO_ALL特権に対応する“PO_ALL”と名付けられたＸＭＬ要素を示している。PO_ALL要素は５つの子要素、つまり、ライン３のGenerate_PO、ライン４〜８のApprove_PO、ライン９のPurchase、ライン１０〜１４のAccept_Delivery、およびライン１５のPay_under_POを含む。ライン４〜８のApprove_PO要素は、３つの子要素、つまり、ライン５のApprove_Services、ライン６のApprove_Equipment、およびライン７のApprove_Suppliesを含む。ライン１０〜１４のAccept_Delivery要素は、３つの子要素、つまり、ライン１１のAccept_Services、ライン１２のAccept_Equipment、およびライン１３のAccept_Suppliesを含む。こうして、図２に一部が示されたＸＭＬ文書は、図１に示された発注書動作についての特権の階層１１０を記述している。

図３は、一実施例に従った、アプリケーション特有の動作に対するアクセス制御を別個のサーバを用いてサポートするための方法３００の一実施例を示すフローチャートである。図３ではステップがある特定の順序で示されているが、他の実施例では、ステップは異
なる順序で、または時間が重複して実行されてもよい。たとえば、ステップ３１０および３２０は、時間が重複していてもよい。

ステップ３１０で、サーバは、データ項目の型に対してアプリケーション特有の動作を実行するための特権の階層を示すデータを受信する。特権の階層を受信するための任意の方法が使用されてもよい。たとえば、ステップ３１０の最中、アプリケーションアドミニストレータは、表２に示すラインを有するＸＭＬ文書を形成し、その文書をファイルPOprivileges.xmlに記憶し、データベースサーバアクセス制御インターフェイスを採用して、アプリケーション特有のアクセス制御がデータベースサーバによって、ファイルPOprivileges.xml内の特権の階層を用いてサポートされるべきであることを示す。いくつかの実施例では、データベースサーバアクセス制御インターフェイスは、当該技術分野において周知のハイパーテキストマークアップ言語（ＨＴＭＬ）ページなどのグラフィカルユーザインターフェイスであり、それは、アプリケーション特有のアクセス制御を特定する入力をユーザに促す。いくつかの実施例では、データベースサーバアクセス制御インターフェイスは、当該技術分野において周知のアプリケーションプログラムインターフェイス（ＡＰＩ）であり、それは、データベースサーバアクセス制御機能を実行するために呼出されるルーチンおよびパラメータの名前および型を含んでいる。他の実施例では、サーバへの他のインターフェイスが採用される。

いくつかの実施例では、同じアプリケーションのために２つ以上の特権階層が受信される。たとえば、アプリケーションが企業システムである場合、アプリケーションは、発注書システムについての特権の階層だけでなく、他のシステム、たとえば人材システム、設備管理システム、製品製作追跡システム、および卸売販売システムなどについての特権の階層も含んでいてもよい。さまざまなシステムに当てはまる階層は往々にして、アプリケーションによってデータベースに記憶される異なる型のデータ項目に対するアプリケーション特有の動作を指す。たとえば、図１に示す特権の階層は、データベース内の発注書データベースオブジェクトに対して動作する表１に列挙された動作を指しており、一方、人材についての特権の階層は、データベース内の人事データベースオブジェクトに対する動作を指している。

２つ以上の特権階層を有するいくつかの実施例では、ステップ３１０の最中、各特権階層はデータ項目の型に関連付けられ、そのデータ項目の型も、特権の階層を示すデータとともに受信される。たとえば、表２のＸＭＬラインによって示される階層は、アプリケーションのためにデータベースサーバ２３０によって管理されるデータベース内の発注書データベースオブジェクトと関連付けられる。実施例によっては、関連付けはＸＭＬ文書内で行なわれ、実施例によっては、関連付けはデータベースサーバアクセス制御システムへのインターフェイスで行なわれる。実施例によっては、同じアプリケーションについての異なる階層が、階層名などの他の手段によって区別される。

ステップ３２０で、サーバは、各ユーザおよびデータ項目またはデータ項目の群についての特権を示すデータを受信する。そのようなデータを受信するための任意の方法が使用されてもよい。たとえば、ステップ３２０の最中、アプリケーションアドミニストレータは、ユーザ識別情報（ユーザＩＤ）を特権の階層１００における１つ以上の特権と関連付ける第２のＸＭＬ文書を形成し、データベースサーバアクセス制御インターフェイスを採用して、第２のＸＭＬ文書がユーザを特権と関連付けることを示す。インターフェイスは、ＨＴＭＬページ、ＡＰＩ、またはデータをサーバに供給するための何か他のインターフェイス、といったグラフィカルユーザインターフェイスであってもよい。実施例によっては、ＸＭＬ文書は、マーシーの均一なアクセス制御システムのためのアクセス制御リスト（ＡＣＬ）を、以下の表３に示すようなＸＭＬラインを用いて特定する。表３では、制御されたアプリケーション特有の動作が要求されるようにする何かを行なうアプリケーショ
ンをクライアントに命令させるユーザは、「プリンシパル」と呼ばれる。あるプリンシパルはユーザＩＤ“SCOTT”を有し、別のプリンシパルはユーザＩＤ“PETER”を有している。表３では、各ＡＣＬは、１つ以上のアクセス制御要素（ＡＣＥ）を含む。各ＡＣＥは、プリンシパルを名付ける１つのプリンシパル要素と、１つの特権要素とを含む。特権要素は、特権の階層における名前によって識別される１つ以上の特権のリストを含む。ライン１および１９の省略記号は、ＡＣＬの前および後の他のＸＭＬラインを示している。ライン１７の省略記号は、他のＡＣＥを特定する他のＸＭＬラインを示している。

表３の例のＡＣＬに示すように、ユーザSCOTTは、ＰＯを作成して供給品の配送を受入れてもよく、一方、ユーザPETERは、任意の種類のＰＯを承認してベンダーへの支払を認可してもよい。

多数の階層を有する実施例では、階層の各々でのユーザの特権は、ステップ３２０の最中に特定される。たとえば、ＡＣＬが使用される場合、発注書データ項目に当てはまる発注書階層での特権を特定する１組のＡＣＬと、人材データ項目に当てはまる人材階層での特権を特定する別の１組のＡＣＬがある。

ステップ３４０で、サーバは、アプリケーションからアクセス制御要求を受信する。この要求は、ある特定のユーザ、ある特定のアプリケーション特有の動作、およびその動作が実行されるべきデータ項目を示すデータを含む。すべてのデータ項目に当てはまる階層がたった１つである実施例では、データ項目は省略されてもよい。１つのアプリケーションについて多数の階層を有する実施例では、使用されるべき特権階層は、データ項目の型に基づいて、データ項目から推論される。データ項目の型は、１つ以上のデータ項目またはデータベースオブジェクトを示す。実施例によっては、特定のアプリケーション特有の動作を示すデータは、アプリケーション特有の動作の１つ以上についてのある特定の特権を示すデータである。

例示のため、ユーザSCOTTがクライアント２１０ａを介してアプリケーション２２０を動作させ、ユーザPETERがクライアント２１０ｂを介してアプリケーション２２０を動作させると仮定する。さらに、ユーザSCOTTが事務用品について作成したばかりの、以下「ＰＯ１２３４５」と呼ばれるある特定の発注書を、ユーザSCOTTが承認しようとしたと仮定する。これは、ユーザSCOTTが発注書データ項目ＰＯ１２３４５に対してApprove_Services特権を必要とするアプリケーション特有の動作を実行しようとしていることを示すデータを含むアクセス制御要求を、アプリケーション２２０に生成させる。データベースサーバは、ステップ３４０の最中に要求を受信する。

ステップ３５０で、サーバは、アプリケーションが特定のユーザのために特定の動作を実行してもよいかどうかを、特定のデータ項目について特定のユーザに関連付けられた特権に基づいて判断する。たとえば、データベースサーバ２３０は、アプリケーション２２０がSCOTTのためにApprove_Services特権を必要とする動作を実行してもよいかどうかを、発注書データ項目に関連する階層における発注書データ項目についてSCOTTに関連付けられた特権に基づいて判断する。

ステップ３５０の最中、サーバは適切な階層を判断する。たとえば、データベースサーバ２３０は、データベースサーバ２３０によって保持されたデータベースメタデータに基づいて、ＰＯ１２３４５が発注書型のデータベースオブジェクトであることを判断する。データベースサーバ２３０は次に、表２に部分的に列挙されたＸＭＬ文書のうち、ステップ３１０の最中に受信された特権の階層が適切な階層であると判断する。

ステップ３５０の最中、サーバは、ユーザが要求に示された特権を有するかどうかを判断する。たとえば、データベースサーバ２３０は、ユーザSCOTTが、発注書データ項目について表３に列挙されたＡＣＬの、ライン３〜９のＡＣＥに現われているものの、特権Approve_Servicesがライン５〜８に列挙された特権の中には列挙されていないと判断する。したがって、ユーザSCOTTは、このアプリケーション特有の動作を実行する特権を持っていない。

ステップ３９０で、サーバはアプリケーションに応答を返す。この応答は、アプリケーションが特定のユーザのために特定の動作を実行してもよいかどうかを示すデータを含んでいる。たとえば、データベースサーバ２３０はアプリケーション２２０に、アプリケーション２２０がクライアント２１０ａに関連するユーザSCOTTのためにサービス承認動作を実行すべきではないことを示す応答を返す。この応答に基づき、アプリケーションは動作を実行しない。実施例によっては、アプリケーションは、この応答に基づいて、ユーザがアプリケーション特有の動作を実行するよう許可されてはいないというメッセージを、ユーザのクライアントに送信する。たとえば、この応答に基づいて、アプリケーション２２０は、ユーザSCOTTがサービスについての発注書を承認するよう許可されてはいないというメッセージを、クライアント２１０ａに送信する。

ビットマップを用いたユーザ特権の表現
ステップ３５０の最中、上述のように、サーバは、ユーザが要求に示された特権を有しているかどうかを判断する。アプリケーションのアクティブなクライアントを動作させているユーザの特権を高速メモリのキャッシュに保持することは有利である。より多くのユーザ特権がキャッシュに記憶されるにつれ、サーバはより迅速に要求に応答して、アプリケーション特有の動作のアクセス制御をサポートすることができる。ユーザ特権がよりコンパクトに表現可能になるにつれ、よれ多くのユーザがキャッシュに記憶され得る。一実施例によれば、サーバは、各ユーザに関連する特権を、キャッシュにおいてビットマップを用いて表わす。たとえば、データベースサーバ２３０は、ユーザ特権をキャッシュ２３
２にビットマップを用いて記憶する。

この実施例では、サーバは、階層における各リーフノードをビット位置に関連付ける。たとえば、階層１００について表１に列挙された９つのリーフノードは、ビット位置１〜９に関連付けられる。ある特定のユーザに付与された特権を示すデータをサーバが受信すると（永続的ストレージからそのようなデータを読出すことも含む）、サーバは、付与された特権に対応しているビットを、「オン」値、たとえば「１」に設定し、付与されていない特権に対応しているビットを、「オフ」値、たとえば「０」に設定する。親ノードに対応している特権が付与される場合、その親ノードの子孫であるすべてのリーフノードに対応しているビットは、オン値にセットされる。たとえば、表３に列挙されたＸＭＬラインにおいてユーザSCOTTおよびPETERに付与された特権は、表４に列挙されたビットマップによって表わされ、ここでは、ビット位置は右（最下位ビット）から左（最上位）へ数える。

SCOTTには、第１のリーフノード１１０ｂである、ＰＯを作成する特権が付与されており、そのため、第１の（右端の）ビットにオン値「１」が設定される。SCOTTには、第８のリーフノード１１０ｌである、配送された供給品を受入れる特権も付与されており、そのため、右から８番目のビットにオン値「１」が設定される。PETERにはＰＯを承認する特権が付与されており、それは、サービスを承認するリーフノード１１０ｇ、設備を承認するリーフノード１１０ｈ、および供給品を承認するリーフノード１１０ｉにとっての親ノードである。したがって、これら３つのリーフノード１１０ｇ、１１０ｈ、１１０ｉに対応するビットは、オン値「１」に設定される。これらのビットは、ビットマップの右から２番目〜４番目の位置にある。PETERには、第９のリーフノード１１０ｆである、配送に対して支払う特権も付与されており、そのため、右から９番目のビット、つまり左端のビットにオン値「１」が設定される。

多数の階層を有するいくつかの実施例では、すべての階層のリーフノードは単一のビットマップにアセンブルされる。他の実施例では、異なる階層のリーフノードは異なるビットマップにアセンブルされる。いくつかの実施例では、ビット位置は、階層名および特権名に基づいてハッシュ関数を使用して判断されてもよい。

ビットマップを用いた例示的な一実施例では、ステップ３５０の最中、データベースサーバ２３０は、ある特定のデータ項目についてのある特定のユーザのビットマップが既にキャッシュ２３２内にあるかどうかを判断する。そうである場合、永続的ストレージ２４０に記憶されたデータからビットマップを検索する動作が回避可能である。そうではない場合、ユーザについてのビットマップが永続的ストレージ２４０から検索され、キャッシュ２３２に追加される。キャッシュ２３２に検索されたビットマップを置く十分なスペースがない場合、キャッシュ内のスペースは、当該技術分野において公知の任意の手法を用いて解放される。たとえば、最も以前に使用されたビットマップに割当てられたメモリが、特定のユーザのビットマップのために利用可能になる。

データベースサーバ２３０は次に、アプリケーション特有の動作についての特権、またはステップ３４０で受信されたアクセス制御要求に示された特権に関連するビット位置を判断する。たとえば、表２に表わされた階層を用いて、データベースサーバは、Approve_Services特権に関連するサービス承認動作が第２のリーフノードに、したがってビットマップの２番目のビットに関連付けられていると判断する。

ステップ３５０の最中、データベースサーバ２３０は次に、そのビット位置におけるビットがオン値に設定されているかどうかを判断する。たとえば、データベースサーバは、表４に列挙されたSCOTTについてのビットマップにおいて、２番目のビットがオン値に設定されていないと判断する。したがって、データベースサーバは、SCOTTがサービスを承認する特権を持っていないと判断する。

データベースサーバ２３０がPETERからＰＯ１２３４５を承認するよう求める要求を受信すると、ステップ３５０の最中、データベースサーバ２３０は、表４に列挙されたPETERについてのビットマップにおいて、２番目の値がオン値に設定されていると判断する。したがって、データベースサーバは、PETERがサービスを承認する特権を有すると判断する。

ここに記載されたような、ユーザの特権を判断するためにキャッシュ２３２およびビットマップを使用することは、非常に効率的である。アプリケーションの開発者は、広範なソフトウェア開発なしで、データベースまたは内容管理サーバといった別個のサーバによる特権のそのような効率的な判断を利用してもよい。アプリケーションアドミニストレータは、別個のサーバ用に既に構築されているインターフェイスをしばしば使用して、特権およびユーザ特権の階層を別個のサーバに１回供給するだけである。単にアクセス制御要求を別個のサーバに送るために、新しいアプリケーションが開発され、または既存のアプリケーションが修正される。特権がアプリケーション特有の動作にとって利用可能かどうかを効率よく判断するためにアプリケーションを開発する必要はない。たとえば、アプリケーションは、キャッシュ２３２を管理し、またはユーザ特権のビットマップを形成するために開発される必要はない。

ハードウェア概要
図４は、この発明の一実施例が実現され得るコンピュータシステム４００を示すブロック図である。コンピュータシステム４００は、情報を通信するためのバス４０２または他の通信メカニズムと、情報を処理するためにバス４０２と結合されたプロセッサ４０４とを含む。コンピュータシステム４００はまた、プロセッサ４０４により実行されるべき命令および情報を記憶するためにバス４０２に結合された、ランダムアクセスメモリ（ＲＡＭ）または他のダイナミック記憶装置といったメインメモリ４０６も含む。メインメモリ４０６は、プロセッサ４０４により実行されるべき命令の実行中に一時的な変数または他の中間情報を記憶するためにも使用されてもよい。コンピュータシステム４００はさらに、プロセッサ４０４用の命令およびスタティック情報を記憶するためにバス４０２に結合された読出専用メモリ（ＲＯＭ）４０８または他のスタティック記憶装置を含む。磁気ディスクまたは光ディスクといった記憶装置４１０が、情報および命令を記憶するために提供され、バス４０２に結合されている。

コンピュータシステム４００は、情報をコンピュータユーザに表示するためのブラウン管（ＣＲＴ）などのディスプレイ４１２に、バス４０２を介して結合されていてもよい。英数字キーおよび他のキーを含む入力装置４１４が、情報およびコマンド選択をプロセッサ４０４に通信するためにバス４０２に結合されている。ユーザ入力装置の別の種類は、方向情報およびコマンド選択をプロセッサ４０４に通信し、ディスプレイ４１２上のカー
ソルの動きを制御するための、マウス、トラックボール、またはカーソル方向キーといったカーソル制御４１６である。この入力装置は通常、２つの軸、つまり第１の軸（たとえばｘ）および第２の軸（たとえばｙ）において２つの自由度を有しており、それによりこの装置は平面における場所を特定することができる。

この発明は、ここに説明された手法を実現するためのコンピュータシステム４００の使用に関する。この発明の一実施例によれば、それらの手法は、プロセッサ４０４がメインメモリ４０６に含まれる１つ以上の命令の１つ以上のシーケンスを実行するのに応じて、コンピュータシステム４００によって実行される。そのような命令は、記憶装置４１０などの別のコンピュータ読み取り可能な媒体からメインメモリ４０６に読込まれてもよい。メインメモリ４０６に含まれる命令のシーケンスの実行により、プロセッサ４０４は、ここに説明されたプロセスステップを実行するようになる。代替的な実施例では、この発明を実現するために、ソフトウェア命令の代わりに、またはソフトウェア命令と組合わせて、ハードワイヤード回路が使用されてもよい。このため、この発明の実施例は、ハードウェア回路とソフトウェアとのどの特定の組合せにも限定されない。

ここで用いられるような用語「コンピュータ読み取り可能な媒体」とは、プロセッサ４０４に命令を実行用に提供することに関与するあらゆる媒体を指す。そのような媒体は、不揮発性媒体、揮発性媒体、および通信媒体を含むもののそれらに限定されない多くの形態を取り得る。不揮発性媒体はたとえば、記憶装置４１０などの光ディスクまたは磁気ディスクを含む。揮発性媒体は、メインメモリ４０６などのダイナミックメモリを含む。通信媒体は、バス４０２を構成する配線を含む、同軸ケーブル、銅線および光ファイバを含む。通信媒体はまた、無線周波数および赤外線データ通信中に発生するものといった音波または光波の形も取り得る。

コンピュータ読み取り可能な媒体の一般的な形態は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、または任意の他の磁気媒体、ＣＤ−ＲＯＭ、任意の他の光媒体、パンチカード、紙テープ、孔のパターンを有する任意の他の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、任意の他のメモリチップまたはカートリッジ、以下に説明するような搬送波、または、コンピュータがそこから読み取り可能な任意の他の媒体を含む。

コンピュータ読み取り可能な媒体のさまざまな形態は、プロセッサ４０４への１つ以上の命令の１つ以上のシーケンスを実行用に保持することに関与していてもよい。たとえば、命令はまず、遠隔コンピュータの磁気ディスク上に保持されてもよい。遠隔コンピュータは命令をそのダイナミックメモリにロードし、電話回線を通してモデムを用いて命令を送信することができる。コンピュータシステム４００にとってローカルなモデムは、電話回線上のデータを受信し、赤外線送信機を用いてデータを赤外線信号に変換することができる。赤外線検出器は赤外線信号で搬送されたデータを受信でき、適切な回路がデータをバス４０２上に配置することができる。バス４０２はデータをメインメモリ４０６に搬送し、そこからプロセッサ４０４が命令を検索して実行する。メインメモリ４０６によって受信された命令は、プロセッサ４０４による実行の前または後のいずれかで、記憶装置４１０上に随意に記憶されてもよい。

コンピュータシステム４００はまた、バス４０２に結合された通信インターフェイス４１８も含む。通信インターフェイス４１８は、ローカルネットワーク４２２に接続されたネットワークリンク４２０に双方向データ通信結合を提供する。たとえば、通信インターフェイス４１８は、データ通信接続を対応する種類の電話回線に提供するデジタル相互サービス網（ＩＳＤＮ）カード、またはモデムであってもよい。別の例として、通信インターフェイス４１８は、データ通信接続を互換性があるＬＡＮに提供するローカルエリアネ
ットワーク（ＬＡＮ）カードであってもよい。無線リンクも実現され得る。任意のそのような実現化例では、通信インターフェイス４１８は、さまざまな種類の情報を表わすデジタルデータストリームを搬送する電気信号、電磁信号、または光信号を送信および受信する。

ネットワークリンク４２０は通常、１つ以上のネットワークを介して、他のデータ装置にデータ通信を提供する。たとえば、ネットワークリンク４２０は、ローカルネットワーク４２２を介して、ホストコンピュータ４２４に、またはインターネットサービスプロバイダ（ＩＳＰ）４２６により運営されるデータ装置に、接続を提供してもよい。ＩＳＰ４２６は次に、現在一般に「インターネット」４２８と呼ばれている全世界的パケットデータ通信ネットワークを介して、データ通信サービスを提供する。ローカルネットワーク４２２およびインターネット４２８は双方とも、デジタルデータストリームを搬送する電気信号、電磁信号または光信号を使用する。コンピュータシステム４００へ、またはコンピュータシステム４００からデジタルデータを搬送する、さまざまなネットワークを通る信号、ネットワークリンク４２０上の信号、および通信インターフェイス４１８を通る信号は、情報を運ぶ搬送波の例示的な形態である。

コンピュータシステム４００は、ネットワーク、ネットワークリンク４２０および通信インターフェイス４１８を介して、メッセージを送信し、プログラムコードを含むデータを受信する。インターネットの例では、サーバ４３０は、アプリケーションプログラム用の要求されたコードを、インターネット４２８、ＩＳＰ４２６、ローカルネットワーク４２２、および通信インターフェイス４１８を介して送信してもよい。

受信されたコードは、受信された際にプロセッサ４０４によって実行されてもよく、および／または、後での実行用に記憶装置４１０または他の不揮発性ストレージに記憶されてもよい。このように、コンピュータシステム４００は、搬送波の形をしたアプリケーションコードを取得し得る。

前述の明細書において、この発明を、その特定の実施例を参照して説明してきた。しかしながら、この発明のより幅広い精神および範囲を逸脱することなく、様々な修正および変更がそれになされてもよいことは、明らかである。したがって、明細書および図面は、限定的な意味というよりもむしろ例示的な意味で考慮されるべきである。

アプリケーション特有の動作を実行する特権の例示的な階層を示すブロック図である。 一実施例に従った、アプリケーション特有の動作に対するアクセス制御を別個のデータベースサーバを用いてサポートするためのシステムを示すブロック図である。 一実施例に従った、アプリケーション特有の動作に対するアクセス制御を別個のサーバを用いてサポートするための方法の一実施例を示すフローチャートである。 この発明の一実施例が実現され得るコンピュータシステムを示すブロック図である。

Claims (16)

1. アプリケーションによって実行されるアプリケーション特有の動作を制御するための方法であって、
   アプリケーションと通信可能な、アプリケーションとは別個のサーバが、アプリケーションから特権情報を受信するステップを含み、前記特権情報は、特権定義を含み、前記特権定義は、
   前記アプリケーション特有の動作と、
   各アプリケーション特有の動作に対する、前記アプリケーション特有の動作を許可する個々の特権とを定義し、
   前記アプリケーション特有の動作は、ある特定のアプリケーション特有の動作を含み、前記方法はさらに、
   特権情報を受信した後、特定のアプリケーション特有の動作を実行するためのアクセス制御要求をアプリケーションからサーバが受信するステップと、
   アクセス制御要求を受信することに応答して、特定のアプリケーション特有の動作がある特定の１組の条件の下で許可されているかどうかを、特権情報に基づいてサーバが判断するステップと、
   判断した後、特定のアプリケーション特有の動作が前記特定の１組の条件の下で許可されているかどうかを示す応答を、サーバがアプリケーションに送信するステップとを含む、方法。
2. 特権情報を受信するステップは、アプリケーションのユーザを、特権情報における１つ以上の特権と関連付けるユーザ特権定義を、前記サーバが受信するステップを含み、サーバは、特定のアプリケーション特有の動作が特定の１組の条件の下で許可されているかどうかを、ユーザ特権定義に基づいて判断する、請求項１に記載の方法。
3. アクセス制御要求を受信することに応答して、ある特定のユーザのためにアプリケーションが特定のアプリケーション特有の動作を実行してもよいかどうかを、特権情報に基づいてサーバが判断するステップをさらに含み、
   アクセス制御要求は、特定のユーザおよびある特定のアプリケーション特有の動作を示し、
   サーバに応答をアプリケーションへ送信させるステップは、特定のユーザのためにアプリケーションが特定のアプリケーション特有の動作を実行してもよいかどうかを示す応答を、アプリケーションへ送信するステップを含む、請求項１に記載の方法。
4. 特権情報を受信する前記ステップは、第１の１組の特権を、複数のアプリケーション特有の動作が動作する第１の型のデータ項目と関連付ける第１のデータを受信するステップを含み、
   アクセス制御要求を受信する前記ステップは、ある特定のデータ項目も示す要求を受信するステップを含み、
   特定のユーザのためにアプリケーションが特定のアプリケーション特有の動作を実行してもよいかどうかをサーバが判断する前記ステップは、特定のデータ項目が第１の型のデータ項目の構成要素であるかどうかを判断するステップをさらに含む、請求項３に記載の方法。
5. 前記第１の型のデータ項目とは異なる第２の型のデータ項目に対して第２の複数のアプリケーション特有の動作を実行するための第２の１組の特権を記述する第２のデータを、サーバがアプリケーションから受信するステップを含み、
   特定のユーザのためにアプリケーションが特定のアプリケーション特有の動作を実行してもよいかどうかをサーバが判断する前記ステップは、特定の型の特定のデータ項目に基づく、請求項４に記載の方法。
6. 特定のユーザのためアプリケーションが特定のアプリケーション特有の動作を実行してもよいかどうかをサーバが判断する前記ステップは、１人以上のユーザの各々を特権の１つ以上の組の各々における１つ以上の特権と関連付ける情報を高速メモリ内のキャッシュにサーバが記憶するステップを含む、請求項３に記載の方法。
7. サーバが、各ユーザに関連するデータ項目の型を示すデータをキャッシュに記憶するステップを含む、請求項６に記載の方法。
8. 特定のユーザのためにアプリケーションが特定のアプリケーション特有の動作を実行してもよいかどうかをサーバが判断する前記ステップは、１人以上のユーザの各々を特権の１つ以上の組の各々における１つ以上の特権と関連付ける、各ユーザについてのビットマップをサーバがキャッシュに記憶するステップをさらに含み、
   特権の各組は、１つ以上のレベルの特権の階層を形成し、
   ビットマップにおける異なる各ビット位置は、特権の１つ以上の組の各階層における１つの異なるリーフノードに対応しており、
   リーフノードは、子ノードを持たない階層のノードである、請求項６に記載の方法。
9. アプリケーションによって実行されるアプリケーション特有の動作を制御するための方法であって、
   アプリケーションと通信可能な、アプリケーションとは別個のサーバへ、アプリケーション特有の動作と、ある特定のアプリケーション特有の動作を含む第１の複数のアプリケーション特有の動作を実行するための特権の第１の組を記述する第１のデータとを定義する特権定義を含む特権情報を送信するステップと、
   特権情報を送信した後、ある特定のアプリケーション特有の動作がある特定の１組の条件の下で許可されているかどうかを特権情報に基づいて判断するようサーバに求めるアクセス制御要求を、アプリケーションがサーバへ送信するステップと、
   アクセス制御要求をサーバへ送信した後、特定のアプリケーション特有の動作を、前記特定の１組の条件の下でアプリケーションが実行してもよいかを示す応答をサーバからアプリケーションが受信するステップと、
   応答を受信した後、アプリケーション特有の動作が前記特定の１組の条件の下で許可されていたとサーバが示した場合のみ、アプリケーションが特定のアプリケーション特有の動作を許可するステップとを含む、方法。
10. アプリケーションがサーバへ特権情報を送信するステップは、
    アプリケーションの第１のユーザを第１の１組の特権におけるある特権と関連付ける第２のデータを、アプリケーションに接続され、アプリケーションとは別個のサーバに、アプリケーションが送信するステップを含む、請求項９に記載の方法。
11. ある特定のユーザから、ある特定のアプリケーション特有の動作を実行するためのコマンドをアプリケーションが受信するステップを含み、
    アクセス制御要求をアプリケーションがサーバへ送信するステップは、コマンドを受信することに応答して、アプリケーションが、アクセス制御要求をサーバに送信するステップを含み、
    アクセス制御要求は、特定のユーザおよび特定のアプリケーション特有の動作を示し、
    特定のアプリケーション特有の動作を前記特定の１組の条件の下でアプリケーションが実行してもよいかどうかを示す応答をサーバから受信するステップは、第１のデータおよび第２のデータに基づいて、特定のユーザのためにアプリケーションが特定のアプリケーション特有の動作を実行してもよいかどうかを示す応答をサーバから受信するステップを含み、前記方法はさらに、
    特定のユーザのためにアプリケーションが特定のアプリケーション特有の動作を実行してもよいと応答が示す場合にのみ、特定のアプリケーション特有の動作をアプリケーションが実行するステップを含む、請求項１０に記載の方法。
12. 特権情報を送信する前記ステップは、第１の１組の特権を、複数のアプリケーション特有の動作が動作する第１の型のデータ項目とも関連付ける第１のデータを送信するステップを含み、
    アクセス制御要求を送信する前記ステップは、ある特定のデータ項目も示す要求を送信するステップを含み、
    応答を受信する前記ステップは、特定のデータ項目が第１の型のデータ項目の構成要素であるかどうかに基づいて応答を受信するステップをさらに含む、請求項１０に記載の方法。
13. 前記方法は、異なる第２の型のデータ項目に対して第２の複数のアプリケーション特有の動作を実行するための異なる第２の１組の特権を定義する第３のデータを含むサーバに、アプリケーションが特権情報を送信するステップを含み、
    第２のデータを送信する前記ステップは、アプリケーションの第２のユーザを特権の前記異なる第２の１組におけるある特権とも関連付ける第２のデータを送信するステップを含み、
    アクセス制御応答を受信する前記ステップは、ある特定の型の特定のデータ項目が、特定のアプリケーション特有の動作を含むある特定の複数のアプリケーション特有の動作についてのある特定の１組の特権と関連しているかどうかに基づいて、応答を受信するステップを含む、請求項１２に記載の方法。
14. アプリケーションは、１人以上のユーザの各々を、第１の組の特権を含む特権の１つ以上の組の各々における１つ以上の特権と関連付ける情報を、高速メモリ内のキャッシュに記憶していない、請求項１０に記載の方法。
15. １つ以上のプロセッサにより実行される場合、１つ以上のプロセッサに請求項１〜１４のいずれかに記載された方法を実行させる命令の１つ以上のシーケンスを記憶した、コンピュータ読み取り可能な不揮発性媒体。
16. １つ以上のプロセッサにより実行されると、１つ以上のプロセッサに請求項１〜１４のいずれかに記載された方法を実行させるプログラム。

Images