JP2007524884A - 階層的な役割ベース資格のためのシステム及び方法 - Google Patents

Abstract

【課題】エンタープライズ・アプリケーションにおけるリソースの許可及び管理に関する技術を提供する。
【解決手段】リソースに階層的に関連した少なくとも１つの役割へのプリンシパルのマッピングを提供する段階、この少なくとも１つの役割に基づいてポリシーの評価を与える段階、及びポリシーの評価に基づいてリソースへのアクセスをプリンシパルに許可するか否かの判断を与える段階を含む、リソースへのアクセスを適応制御する許可のためのシステム及び方法。
【選択図】図５

Description

著作権通知
この特許文書の開示の一部分は、著作権保護を受ける材料を含んでいる。著作権所有者は、米国特許商標事務所の特許ファイル又は記録に現れるような特許文書又は特許開示の何人によるファクシミリ複製にも異議を唱えないが、それ以外は全ての著作権を有するものである。
相互参照
本出願は、本明細書においてその全内容が引用により組み込まれる以下の現在特許出願中の出願に関するものである：「役割及びリソースポリシー管理の方法」、米国特許出願出願番号第１０／３６７，４６２号、発明人「Ｐｈｉｌｉｐ Ｂ．Ｇｒｉｆｆｉｎ」他、２００３年２月１４日申請、「委託管理の方法」、米国特許出願出願番号第１０／３６７，１９０号、発明人「Ｐｈｉｌｉｐ Ｂ．Ｇｒｉｆｆｉｎ」他、２００３年２月１４日申請、及び「役割及びリソースポリシー管理最適化の方法」、米国特許出願出願番号第１０／３６６，７７８号、発明人「Ｐｈｉｌｉｐ Ｂ．Ｇｒｉｆｆｉｎ」、２００３年２月１４日申請。
本発明の開示は、エンタープライズ・アプリケーションにおけるリソースの許可及び管理に関する。

エンタープライズ・アプリケーションは、組織の内部及び外部の顧客に対して商品及びサービスの利用可能性を増すことができる。エンタープライズ・アプリケーションの配備に付随する１つの問題は、許可又はアクセス管理である。顧客及びシステム管理者の両方は、ある一定のアクションを行う（例えば、顧客の口座を修正する）又はある一定のコンテントへのアクセスを得るための特権が与えられる必要がある。典型的な許可システムは、特にそれらがエンタープライズ・アプリケーションにおけるビジネス論理に密接に結び付けられている場合には、実施及び維持するのに複雑で時間を費やす可能性がある。

米国特許出願出願番号第１０／３６７，４６２号 米国特許出願出願番号第１０／３６７，１９０号 米国特許出願出願番号第１０／３６６，７７８号

本発明は、同じ参照が類似の要素を示す添付図面の図において限定的ではなく例示的に説明されるものである。本開示における「実施形態」又は「一実施形態」という言及は、必ずしも同じ実施形態に対してではなく、このような言及は、少なくとも１つを意味する点に注意すべきである。
一実施形態では、エンタープライズ・アプリケーションは、ビジネス、科学、又は他の機能及びタスクの実行を容易にする１つ又はそれ以上のリソースを含む。別の実施形態では、エンタープライズ・アプリケーションは、「ウェブアプリケーション」、「エンタプライズＪａｖａ（登録商標）Ｂｅａｎｓ」、及び「リソースアダプタ」を単一の配備可能なユニットに束ねる「Ｊａｖａ（登録商標）２エンタプライズエディション（Ｊ２ＥＥ）」配備ユニットとすることができる。「Ｊａｖａ（登録商標）」プログラミング言語とそのランタイムライブラリ及び環境は、米国カリフォルニア州サンタクララ所在のサン・マイクロシステムズ・インコーポレーテッドから入手可能である。エンタープライズ・アプリケーションは、ソフトウエア、ファームウエア、及びハードウエア要素を含むことができる。ソフトウエア、ファームウエア、及びハードウエアは、任意に組み合わせるか又は別々の論理的構成要素に分割することができる。更に、このような構成要素は、それらが組み合わされるか又は分割される方法に関わらず、同じコンピュータで実行することができ、又は１つ又はそれ以上のネットワークによって接続された異なるコンピュータ間に任意に分配することができることは当業者には明らかであろう。

一実施形態では、リソースは、任意の個人と、オブジェクト又はエンティティ（例えば、ネットワークと、コンピュータと、コンピュータユーザと、銀行口座と、電子メールメッセージと、バーチャルメモリ、スレッド、及びファイルストレージのコンピュータオーペレーティングシステムの態様と、その他）を含む場所又は物と、方法又は処理（例えば、小切手帳を決算する、デバイスドライバをインストールする、バーチャルメモリを割り当てる、ファイルを削除する、その他）と、イベントの発生又は未発生（例えば、コンピュータにログオンにするためのユーザによる試み、状態の変更、その他）と、リソースの編成又は関連付け（例えば、リスト、ツリー、マップ、階層、その他）とに対応することができる。

一実施形態では、リソースは、階層的な分類（それ自体をリソースとすることができる）に分けることができる。非制限的な例として、エンタープライズ・アプリケーションでは、ブックレットのような特定のリソースを参照する必要がある場合がある。ブックレットを参照するためには、ブックレットがどのウェブページにあるか、そのウェブページがどのポータルに属するか、そのウェブページを所有するのはどのウェブアプリケーション（又は「ｗｅｂ ａｐｐ」）か、及びその「ｗｅｂ ａｐｐ」がどのドメインに属するかを知る必要がある。これらの構成要素の各々はリソースと考えられ、以下のようなリソースパス（例えば、スラッシュによって分けられた一連の構成要素）として説明することができる。
ｄｏｍａｉｎ／ｗｅｂ＿ａｐｐ／ｐｏｒｔａｌ／ｄｅｓｋｔｏｐ／ｐａｇｅ／ｂｏｏｋｌｅｔ

第１リソースは、リソース階層の「最上部」にあるｄｏｍａｉｎである。階層を下に下がって、次の構成要素はｗｅｂ＿ａｐｐである。ｗｅｂ＿ａｐｐは、ｄｏｍａｉｎの「子」又は「子孫」であり、ｄｏｍａｉｎは、ｗｅｂ＿ａｐｐの「親」である。ｄｏｍａｉｎは、ｗｅｂ＿ａｐｐより上位であり、ｗｅｂ＿ａｐｐは、ｄｏｍａｉｎより下位である。同様に、ｐｏｒｔａｌは、ｗｅｂ＿ａｐｐの子であり、ｄｅｓｋｔｏｐの親である。ｐａｇｅは、ｄｅｓｋｔｏｐの子であり、その子としてブックレットを有する。リソースの深さは、そのパスにおける構成要素の数である。例えば、ｂｏｏｋｌｅｔの深さは６（１から数えると仮定して）、ｐｏｒｔａｌの深さは３である。一実施形態では、リソースの深さは無制限とすることができる。一実施形態では、リソースは特性又は機能を有することができる。非制限的な例として、ブックレットリソースは、エンドユーザによってカスタマイズされる能力を有することができるであろう。機能は、以下のように階層に付加することができると考えられる。
ｄｏｍａｉｎ／ｗｅｂ＿ａｐｐ／ｐｏｒｔａｌ／ｄｅｓｋｔｏｐ／ｐａｇｅ／ｂｏｏｋｌｅｔ．ｃｕｓｔｏｍｉｚｅ

図１は、本発明の一実施形態による例示的なリソース階層を示すものである。非制限的な例として、この階層は、エンタープライズ・アプリケーション内のリソースを表すことができる。「Ｗｅｂ Ａｐｐ１」と「Ｗｅｂ Ａｐｐ２」は、ウェブアプリケーションである。ウェブアプリケーションリソースは、「ワールド・ワイド・ウェブ」上でアクセス可能なエンタープライズ・アプリケーションの一部である。「Ｐｏｒｔａｌ １」及び「Ｐｏｒｔａｌ ２」は、ポータルリソースであり、「Ｗｅｂ Ａｐｐ１」の子である。「Ｐｏｒｔａｌ ３」は、「Ｗｅｂ Ａｐｐ２」の子である。一実施形態では、「Ｗｅｂ Ａｐｐ１」及び「Ｗｅｂ Ａｐｐ２」は、１つ又はそれ以上のドメインの子（図示せず）とすることができる１つ又はそれ以上のエンタープライズ・アプリケーションの子（図示せず）とすることができる。ポータルは、情報及びリソースの統一されて潜在的にパーソナライズされたビューを提供するデータ及びアプリケーションへのアクセスのポイントである。一般的に、ポータルは、ウェブサイト上の１つ又はそれ以上のページ（Ｐａｇｅ １、Ｐａｇｅ ２、Ｐａｇｅ Ａ、Ｐａｇｅ Ｂ、Ｐａｇｅ Ｘ、及びＰａｇｅ Ｙ）として実施される。ポータルページは、アプリケーション、生のデータ給送、静的な情報、及びマルチメディア・プレゼンテーションのような多くの要素を統合することができる。

「Ｄｅｓｋｔｏｐ Ａ」、「Ｄｅｓｋｔｏｐ Ｂ」、及び「Ｄｅｓｋｔｏｐ Ｃ」は、特定のユーザ又はユーザのグループのためにカスタマイズされたポータルの１つ又はそれ以上のビューを包含する。各デスクトップ内のページは、ポートレット（Ｐｏｒｔｌｅｔ Ａ、Ｐｏｒｔｌｅｔ Ｂ、及びＰｏｒｔｌｅｔ Ｃ）とブックレット（Ｂｏｏｋｌｅｔ １及びＢｏｏｋｌｅｔ ２）を包含することができる。ポートレットは、ポータルページにそれ自体を提供する独立型アプリケーションである。一実施形態では、ブックレットは、１つ又はそれ以上のページ又はブックレットの集合である。リソース「Ｗｅｂ Ａｐｐ １／Ｐｏｒｔａｌ １／Ｄｅｓｋｔｏｐ Ａ／Ｐａｇｅ ２／Ｂｏｏｋｌｅｔ １／Ｐａｇｅ Ａ」は、機能「Ｃａｐ ３」を有する。同様に、「Ｗｅｂ Ａｐｐ １／Ｐｏｒｔａｌ １／Ｄｅｓｋｔｏｐ Ａ／Ｐａｇｅ ２／Ｂｏｏｋｌｅｔ １／Ｂｏｏｋｌｅｔ ２」は、機能「Ｃａｐ ４」を有し、「Ｗｅｂ Ａｐｐ １／Ｐｏｒｔａｌ １／Ｄｅｓｋｔｏｐ Ａ／Ｐａｇｅ ２／Ｂｏｏｋｌｅｔ １／Ｂｏｏｋｌｅｔ ２／Ｐａｇｅ Ｙ／Ｐｏｒｔｌｅｔ Ａ」は、機能「Ｃａｐ １」及び「Ｃａｐ ２」を有する。

エンタープライズ・アプリケーションは、資格の使用によってそのリソース及び／又は機能へのアクセスを管理することができる。一実施形態では、資格の評価は、１つ又はそれ以上の役割を動的にプリンシパルに関連付けることによってセキュリティポリシーを判断する段階から構成される。一実施形態では、役割は、プリンシパルに関する知識、通信セッションに関する知識、システムの現在の状態、及び／又は任意の他の関連情報を含む情報を考慮に入れる規則に基づくことができる。

一実施形態では、ユーザは、エンタープライズ・アプリケーションを使用する個人を意味する。グループは、ユーザの任意の集合とすることができる。一実施形態では、グループのメンバーは、ジョブタイトルのような共通のトレーツを共用する。処理は、ソフトウエア又はファームウエアコンピュータプログラム、又は任意の細分性のその一部分（例えば、タスク、スレッド、軽量処理、分散オブジェクト、「エンタプライズＪａｖａ（登録商標）Ｂｅａｎ」、又は任意の他のコンピュータ演算）とすることができる。ユーザ、グループ、及び処理は、サブジェクトと考えることができる。サブジェクトは、認証システムに適切な証明（例えば、パスワード、社会保証番号など）を与える段階に基づいて認証することができる。認証された状態で、サブジェクトは、資格を評価する目的のためのプリンシパルと考えられる。プリンシパルとは、認証の結果としてユーザ、グループ、又は処理に割り当てられるアイデンティティである。プリンシパルはまた、匿名のユーザ、グループ、又は処理（例えば、認証されなかったサブジェクト）を意味することもある。

一実施形態では、役割定義は、所定のコンテキストにおける所定のプリンシパルを評価する場合に真又は偽を評価する１つ又はそれ以上の表現を包含する。別の実施形態では、表現は、リソースへのアクセスが認められる確実性の程度を評価することができる。表現は、互いの内側にネストすることができ、関数、演算、又は論理オペレータなどを包含することができる。一実施形態では、表現は、真又は偽を評価するブール表現を形成するように組み合わされる（例えば、「ａｎｄ」、「ｏｒ」、及び「ｎｏｔ」のようなブールオペレータを用いて）。役割が真と評価する場合、問題のプリンシパルは役割を満たすものと考えられる。

役割表現は、所定のコンテキストでリソースにアクセスしようとするプリンシパルについて動的に評価される。コンテキストは、プリンシパルが役割に属するか否かを判断することに関連した任意の情報を包含することができる。非制限的な例として、コンテキストは、プリンシパルの属性（例えば、名前、年齢、住所など）及び／又は通信セッションに関する情報のいずれかを含むことができる。別の実施形態では、コンテキストは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）又はハイパーテキスト転送プロトコル（機密保護）（ＨＴＴＰＳ）要求からの情報を含むことができる。この情報は、文字符号化、遠隔ユーザ、許可スキーム、コンテント長、サーバポート、コンテキストパス、要求ＵＲＩ、要求方法、スキーム、サーブレットパス、コンテントタイプ、遠隔ホスト、要求プロトコル、ロケール、サーバネーム、遠隔アドレス、問合せストリング、パス情報などに関連することができる。コンテキストが表現を評価することに関係する「任意の」情報を含むことができることは当業者には明らかであろう。

一実施形態では、表現は述部を含むことができる。本明細書に開示する発明は、説明するここでの述部に限定されない。「ユーザ」述部は、問題のプリンシパルが述部に対する引き数として供給されたプリンシパルである場合に真と評価する。「グループ」述部は、問題のプリンシパルが指定されたグループのメンバーである場合に真と評価する。

（表１）

表１は、７つの例示的な役割とそれに付随する表現を示している。一実施形態では、役割「匿名」は、常に満足される特別な役割である。別の実施形態では、「匿名」の役割は認証されなかったプリンシパルによって満足される。「銀行管理者」の役割は、ユーザ「ドナ」として認証されたプリンシパルによって満足される。「顧客サービス」の役割は、「マイケル」又は「ピーター」として認証された又はグループ「銀行出納係」に属するプリンシパルによって満足される。「貸付役人」役割は、「関連」グループ及び「訓練レベル２」グループの両方のメンバーであるが「ボブ」ではないプリンシパルによって満足される。役割は、動的なものとすることができる。非制限的な例として、役割は、日付及び／又は時間に依存することができる。一実施形態では、時間は、現在の日付の述部を使用して指定することができる。「銀行管理者」の役割は、「ドナ」により、ただし２００２年１０月１４日から２００２年１０月２５日、又は２００２年１１月１４日から２００２年１１月２５日まで満足される。多くのこのような日付又は時間述部（例えば、日付及び時間に基づく述部、又は時間だけに基づく述部など）が可能であることは当業者には明らかであろう。

上述の述部に加えて、「セグメント」述部（以降、「セグメント」と呼ぶ）も役割定義に含むことができる。セグメントは、問題のプリンシパルがセグメントの判断基準を満たす場合に真と評価する。セグメントは、ネストされて論理オペレータ、数学演算、方法呼出し、外部システムへの呼出し、機能呼出しなどを含むことができる１つ又はそれ以上の表現又は条件を用いて定義することができる。別の実施形態では、セグメントは、普通語で指定することができる。非制限的な例は、以下のようである。
「これらの条件の全てが適用される場合、プリンシパルは、Ｊａｖａ開発者である：
開発者は真に等しい
スキルレベルは「高」に等しい
好ましい言語は「Ｊａｖａ」に等しい」

この例において、説明されているセグメントは、「経験を積んだＪａｖａ開発者」である。「開発者は真に等しい」という条件は、コンテキストに包含されるか又はコンテキストによって参照される情報が問題のプリンシパルが組織のソフトウエア開発部門のユーザであることを示す場合、真と評価することになる。同様に、他の条件（「スキルレベルが「高」に等しい」、「好ましい言語が「Ｊａｖａ」に等しい」）は、コンテキストからの情報又はコンテキストによって参照される情報を使用して同様に評価することができる。別の実施形態では、条件は、通信セッションに関する情報に関するものとすることができる。情報が特定のプリンシパルに結び付けられるか否かに関わらず、条件が「任意の」情報に基づくことができることは当業者には明らかであろう。セグメントが全体として真と評価する場合、プリンシパルはセグメントを満たしたと呼ばれる。表１では、非制限的な例として、「ソフトウエア」の役割は、「Ｊａｖａ開発者」セグメントを満たすプリンシパルによって満足される。

更に別の非制限的な例は、以下のようである。
「これらの条件の全てが適用される場合、プリンシパルは、システム管理者である：
日時は、午前１２：００から午前７：００の間である
システムロードは「低」である
管理者スキルレベルは少なくとも５である」
この例において、２つの条件（「日時は、午前１２：００から午前７：００の間である」と「システムロードは「低」である」）は、特定のプリンシパルに無関係の情報に基づいている。セグメントは、時間が真夜中であり、システムがビジーでなく、更にプリンシパルがレベル５管理スキルを有する場合に、問題のプリンシパルについて真と評価する。表１では、非制限的な例として、「ＳｙｓＡｄｍｉｎ」の役割は、「ドナ」により、２００２年１０月１４日−２００２年１０月２５日、又は２００２年１１月１４日−２００２年１１月２５日の間のみ、又は「システム管理者」セグメントを満たすプリンシパルによって満足される。

一実施形態では、セグメントは、「拡張可能マークアップ言語（ＸＭＬ）」に固執することができる。ＸＭＬは、構造化文書を表すためのプラットフォーム独立言語である。ＸＭＬ文書を構成するテキストは構文解析すべきであるから、ＸＭＬ文書に記憶された情報を検索するには時間が掛かる可能性がある。時間を節約するために、別の実施形態では、セグメントを表すＸＭＬ文書が構文解析された時に、再度ファイルを構文解析する必要を排除するために、セグメントから抽出された情報をキャッシュに入れることができる。

図２は、役割及びセキュリティポリシーを更に示す図１の例示的な階層である。役割は、１つ又はそれ以上の役割の挿入リストが続く文字「Ｒ」で示される。同様に、ポリシーは、ポリシーが適用される役割のセット及び任意的な機能を含む挿入リストが続く文字「Ｐ」で示される。機能が存在しない場合、ポリシーは、全体としてリソースに適用される。一実施形態では、役割は、範囲がグローバルと考えることができ、又は特定のリソースに関連付けることができる。グローバルな役割は、任意のリソースの範囲内で考えられる。一実施形態では、リソースに関連する役割は、そのリソースの範囲内にある。別の実施形態では、役割は、リソースの範囲内及びその子孫の全てである。更に別の実施形態では、役割は、リソースの範囲内、及び同じ名称を有する役割が子孫に関連付けられるのでなければその子孫の全てである。このようにして、「ｍｏｒｅ ｌｏｃａｌ」役割は、その名称の「ｌｅｓｓ ｌｏｃａｌ」役割を塞ぐものである。

図２で、役割「Ａｎｏｎｙｍｏｕｓ」は、リソース「Ｗｅｂ Ａｐｐ １」に関連付けられる。一実施形態では、Ａｎｏｎｙｍｏｕｓは、「Ｗｅｂ Ａｐｐ １」の範囲内にあり、階層におけるその下の全てのリソースである。役割Ｇは、リソース「Ｄｅｓｋｔｏｐ Ａ」に関連付けられ、それ自体では「Ｄｅｓｋｔｏｐ Ａ」の範囲内にあり、その子孫である。役割Ｓは、リソース「Ｐａｇｅ Ａ」に関連付けられる。「Ｐａｇｅ Ａ」は子を持たない（すなわち、属性「Ｃａｐ ３」は子として数えられない）ので、役割Ｓの範囲は「Ｐａｇｅ Ａ」に限定される。リソース「Ｂｏｏｋｌｅｔ ２」は、役割Ｔ及びＵに関連付けられる。一実施形態では、役割Ｔは、「Ｂｏｏｋｌｅｔ ２」の範囲内にあり、その子孫の全てであるが、同じものは、役割Ｕについては真を保持しない。「Ｂｏｏｋｌｅｔ ２」の子孫（すなわち、「Ｐａｇｅ Ｙ」）は、同じ名称によって別の役割に関連付けられるので、「Ｂｏｏｋｌｅｔ ２」に関連する役割Ｕは、「Ｂｏｏｋｌｅｔ ２」及び「Ｐａｇｅ Ｘ」の範囲内のみにあることになる。一実施形態では、「Ｐａｇｅ Ｙ」に関連する役割Ｕは、しかしながら、「Ｐａｇｅ Ｙ」の子孫の全ての範囲（すなわち、「Ｐｏｒｔｌｅｔ Ａ」、「Ｐｏｒｔｌｅｔ Ｂ」、及び「Ｐｏｒｔｌｅｔ Ｃ」）内にある。役割Ｖ及びＷは、「Ｐｏｒｔｌｅｔ Ａ」の範囲内にある。

一実施形態では、セキュリティポリシー（以降、「ポリシー」と呼ぶ）は、リソース、役割のセット、及び任意的機能の間の関連性である。一般的に、ポリシーは、役割のセットが真と評価する全てのプリンシパルについてリソースへのアクセスを許可する。一実施形態では、ポリシーは、その役割のいずれかが所定のプリンシパルについて真と評価する場合に満足される。別の実施形態では、ポリシーは、その役割の全てが所定のプリンシパルについて真と評価する場合に満足される。別の実施形態では、セキュリティポリシー保全システムは、役割に依存するポリシーを有する役割を取り除く又は削除するのを防ぐことができる。当業者は、このようなシステムを実施するための多くの方法があることを認識するであろうが、１つの方法は、参照カウントを使用することによって特定の役割に依存するポリシーの数を把握することである。参照カウントがゼロに等しい場合だけに、特定の役割を除去に適格にすることになる。

更に別の実施形態では、役割のポリシーのセットは、ブールオペレータ、セットオペレータ、及びオペランドのための役割を含む表現とすることができる。ポリシーは、タプル＜ｒｅｓｏｕｒｃｅ，ｒｏｌｅｓ，［ｃａｐａｂｉｌｉｔｙ］＞として表すことができ、ｒｅｓｏｕｒｃｅは、リソースの名称を指定し、ｒｏｌｅｓは、役割のセットを指定し、ｃａｐａｂｉｌｉｔｙは、任意的機能である。ポリシーは、１つ又はそれ以上の役割に基づき、役割は、ユーザ及びグループに基づいている。従って、当業者は、ポリシーが本質的にユーザ、グループ、及び／又はセグメントに基づくことを認めるであろう。例証として、図２に示されている以下のような４つのポリシーがある。
Ｐ₁＝＜Ｗｅｂ Ａｐｐ １，｛Ａｎｏｎｙｍｏｕｓ｝＞
Ｐ₂＝＜Ｗｅｂ Ａｐｐ １／Ｐｏｒｔａｌ １／Ｄｅｓｋｔｏｐ Ａ／Ｐａｇｅ ２，｛Ｇ｝＞
Ｐ₃＝＜Ｗｅｂ Ａｐｐ １／．．．／Ｐａｇｅ Ｙ／Ｐｏｒｔｌｅｔ Ａ，｛Ｗ，Ｔ｝，Ｃａｐ １＞
Ｐ₄＝＜Ｗｅｂ Ａｐｐ １／．．．／Ｐａｇｅ Ｙ／Ｐｏｒｔｌｅｔ Ａ，｛Ｕ，Ｇ，Ａｎｏｎｙｍｏｕｓ｝，Ｃａｐ ２＞

非制限的な例証として、プリンシパルｐが、リソース「Ｃａｐ １」へのアクセスを試みていると仮定する。そうするために、「Ｃａｐ １」におけるセキュリティポリシーＰ₃は、ｐが役割Ｗ又はＰのいずれかを満たすことを要求する。一実施形態では、「Ｃａｐ １」の範囲内の全役割（すなわち、Ａｎｏｎｙｍｏｕｓ，Ｇ，Ｔ，Ｕ，Ｕ，Ｖ，及びＷ）は、ｐに対して判断される。ｐが満たす役割のいずれかがＷ又はＴに一致する場合、Ｐ₃は同様に満足され、「Ｃａｐ １」へのアクセスがｐについて許可される。

更に別の非制限的な例証として、プリンシパルｐが、リソース「Ｐｏｒｔｌｅｔ Ａ」のための機能「Ｃａｐ ２」へのアクセスを試みていると仮定する。そうするために、「Ｃａｐ ２」におけるセキュリティポリシーＰ₄は、ｐが役割Ｕ、Ｇ、又はＡｎｏｎｙｍｏｕｓの１つを満たすことを要求する。一実施形態では、「Ｐｏｒｔｌｅｔ Ａ」の範囲内の全役割（すなわち、Ａｎｏｎｙｍｏｕｓ、Ｇ、Ｔ、Ｕ、Ｖ、及びＷ）は、ｐに対して判断される。一実施形態では、リソース「Ｂｏｏｋｌｅｔ ２」に関連する役割Ｕが「Ｐｏｒｔａｌ Ａ」の範囲内にない点に注意すべきである。その代わり、同じ名称を有するが、より「ローカル」なリソース「Ｐａｇｅ Ｙ」に関連する役割がそれを塞ぐことになる。従って、ｐが満たす役割のいずれかがＵ、Ｇ、又はＡｎｏｎｙｍｏｕｓに一致する場合、Ｐ₄は満足され、「Ｃａｐ ２」へのアクセスがｐに対して許可される。しかし、一実施形態では、全てのプリンシパルが役割Ａｎｏｎｙｍｏｕｓを満たすので、Ｐ₄は常に満足されることになる。

更に別の非制限的な例として、ｐがリソース「Ｂｏｏｋｌｅｔ ２」に関連する機能「Ｃａｐ ４」にアクセスを試みていると仮定する。このリソースはポリシーを持たない。一実施形態では、アクセスは却下される。別の実施形態では、アクセスは許可される。更に別の実施形態では、ｐが「Ｂｏｏｋｌｅｔ ２」の親リソースにおけるポリシーを満たす場合にアクセスは許可される。表２は、図２のリソース階層を使用する親ポリシー検索の非制限的な例証である。しかし、特定の検索順序又は検索方法は、この開示の目的とは無関係である点に注意することは重要である。また別の実施形態では、明示的なポリシーのないリソースは、その親ポリシーに関する情報を含むことができ、従って、検索の必要性を回避することができる。

（表２）

一実施形態では、ポリシーのための検索は、以下のように進むことになる。検索の開始ポイントは、プリンシパルがアクセス（すなわち、「Ｃａｐ ４」）を試みる機能（すなわち、「Ｂｏｏｋｌｅｔ ２」）を有するリソースである。これは、現在のリソースである。ポリシーが特定の機能について現在のリソースに存在しない場合、段階２で、リソース自体に単にポリシーがあるか否かが判断される。ポリシーが見つからない場合、段階３で、現在のリソースは、その親（すなわち、「Ｂｏｏｋｌｅｔ １」）に等しく設定される。現在のリソースが「Ｃａｐ ４」に対してポリシーを持たない場合、「Ｂｏｏｋｌｅｔ １」自体にポリシーがあるか否かが判断される。ポリシーが見つからない場合、段階５で、現在のリソースがその親（すなわち、「Ｐａｇｅ ２」）に等しく設定される。現在のリソースで「Ｃａｐ ４」に対してポリシーが見つからない場合、段階６で「Ｐａｇｅ ２」自体にポリシーがあるか否かが判断される。これにはポリシーがあるので、検索は段階６で止まる。「Ｗｅｂ Ａｐｐ １／Ｐｏｒｔａｌ １／Ｄｅｓｋｔｏｐ Ａ／Ｐａｇｅ ２」は、ポリシーＰ₂を有する。従って、ｐが役割Ｇを満たす場合、「Ｃａｐ ４」へのアクセスがｐに対して許可される。

別の実施形態では、機能は、特定のリソースタイプに関連付けられる。例えば、ブックレットは、他のリソースタイプ（例えば、ページ又はデスクトップ）と互換性のない又はこれを利用できない機能のタイプ（例えば、「Ｃａｐ ４」）を有することができる。従って、表２のようなポリシーの検索をする場合、機能が現在のリソースで互換性がない場合、そのリソースを検索から省くことができる。更に別の実施形態では、ポリシーが所定のリソースタイプについて見つからない場合、任意の利用可能なグローバルポリシーがあるか否かを判断するために、グローバルライブラリを調べることができる。

別の実施形態では、役割及びポリシーは、主リソース階層から離れて固有の階層に存在することができる。主階層で役割及び／又はポリシーをリソースに関連付ける必要のないアプリケーションでは、このような方法により、恐らく単一のレベルのみで浅い役割及び／又はポリシーツリーが可能になる。より小さな階層の検索は、範囲内に全ての役割を見つけ、更にポリシーを位置付けるのに必要な時間を潜在的に短縮することができる。

図３は、本発明の一実施形態による許可システムの図である。この図は、機能的に分かれているオブジェクトを示しているが、このような表示は、単に例証の目的のためである。図３に描かれたオブジェクトを任意に組み合わせるか、又は別々のソフトウエア、ファームウエア、又はハードウエア構成要素に分割することができることは当業者には明らかであろう。更に、このような構成要素は、これらが組み合わされるか又は分割される方法に関わらず、同じコンピュータで実行することができ、又は１つ又はそれ以上のネットワークによって接続した様々なコンピュータ間で任意に分配することができることも当業者には明らかであろう。

一実施形態では、セキュリティフレームワーク３００は、プラグイン構成要素を考慮した公開インタフェースを有するモジュラーセキュリティアーキテクチャである。非制限的な例として、フレームワークは、ライブラリ、インタフェースのセット、分散オブジェクト、又は相互通信するためのソフトウエア、ファームウエア、及び／又はハードウエア構成要素のための任意の他の手段とすることができる。フレームワークに接続されるのは、１つ又はそれ以上の役割マッパー構成要素（３０２−３０６）である。役割マッパーは、リソース階層及びコンテキストに基づいて１つ又はそれ以上の役割にプリンシパルをマップする（例えば、どの役割が適切であるかを判断する）。各役割マッパーは、これに関して固有の特化されたアルゴリズムを実行することができ、フレームワークによって提供される以上の情報及びリソースを使用することができる。同じくフレームワークに接続されるのは、１つ又はそれ以上のオーソライザ（３０８−３１０）である。オーソライザは、プリンシパルがリソースポリシーを満たすか否かに基づいて、リソースへのアクセスが許可されるか否かを判断する責任がある。各オーソライザは、これに関して固有の特化されたアルゴリズムを実行することができ、フレームワークによって提供される以上の情報及びリソースを使用することができる。最後に、アジュディケータ３１４は、許可モジュール間の結果のどのような違いも解決し、最終結果（例えば、「許可」、「却下」、又は「棄権」）を戻すものである。一実施形態では、任意の結果が「許可」である場合に裁定の結果が「許可」であるような最終結果の論理「ｏｒ」をアジュディケータは取ることができる。別の実施形態では、アジュディケータは、任意の結果が「却下」である場合に裁定の結果が「却下」であるような最終結果の論理「ａｎｄ」を取ることができる。更に別の実施形態では、アジュディケータは、最終結果を判断するために加重平均又は他の統計的手段を使用することができる。

処理は、当業者に明らかないくつかの方法でフレームワークと対話することができる。一実施形態では、呼出し処理は、フレームワーク３００にリソースアクセス要求(1)を提供する。この要求は、プリンシパルに関する情報、アクセスを要求されるリソース、及び任意のコンテキスト情報を含むことができる。別の実施形態では、要求は、この情報への参照を包含することができる。この情報は、次に、フレームワークによって１つ又はそれ以上の役割マッパー(2)に提供される。各役割マッパーは、固有の判断基準に基づいてどの役割がプリンシパルに適切かを判断する。別の実施形態では、各役割マッパーは、役割の検索を高速化するためにキャッシュを実施することができる。範囲内の全役割を見つけるためにリソースツリーをトラバースするのとは異なり、各役割マッパーは、アクセスが要求されるリソースとプリンシパルを含むキーに基づいて、リソースツリーから予め検索された役割をキャッシュに入れることができる。リソースツリーからの初期検索の後で、所定のリソース−プリンシパルの組合せに対する次の役割がキャッシュから直接取られる。

満足された役割のセットは、次に(3)でフレームワークに戻される。フレームワークは、(1)及び(3)から(4)のオーソライザモジュールに情報を提供することができる。許可モジュールは、ポリシーがこの情報及び固有の判断基準に基づいて満足されるか否かを独自に判断する。別の実施形態では、各オーソライザは、ポリシーの検索を高速化するためにキャッシュを実施することができる。範囲内のポリシーを見つけるためにリソースツリーをトラバースするのとは異なり、各オーソライザは、アクセスが要求されるリソース及びプリンシパルを含むキーに基づいて、リソースツリーから予め検索されたポリシーをキャッシュに入れることができる。リソースツリーからの初期検索後に、所定のリソース−プリンシパルの組合せに関する次のポリシーがキャッシュから直接取られる。オーソライザの結果（例えば、許可又は却下の決定による）は、(5)でフレームワークに提供され、(6)でアジュディケータに提供される。アジュディケータは、(7)でフレームワークに提供する最終決定を行うことになる。次に、フレームワークは、(8)でこの決定を呼出し処理に提供する。

エンタープライズ・アプリケーションが大きくかつ複雑になる時に、管理タスクの数も増加する。システム管理者が責任を負うタスクの数を低減するための１つの方法は、いくつかの管理者間でタスクを分散することである。委託管理は、役割の階層が管理機能を管理することを可能にするものである。非制限的な例として、管理機能は、顧客口座を管理する能力、管理機能を委託する能力、ユーザインタフェース要素（例えば、ポータル、ブックレット、デスクトップ、ポートレットなど）をカスタマイズ又は個人専用にする能力、エンタープライズ・アプリケーションの管理を行う能力などを含むことができる。別の実施形態では、任意の機能又は特性が委託される。一実施形態では、委託は、１つの役割におけるプリンシパルが、別の階層的に下位の役割に管理機能を有する、及び／又は管理機能を更に委託することを可能にする作用である。一実施形態では、委託役割は、１つの役割と同一であり、従って、述部（例えば、ユーザ、グループ、現在の日付、セグメントなど）を使用して定義することができる。

図４は、本発明の一実施形態による委託役割階層を示している。一実施形態では、委託役割は、委託の程度を管理するために委託階層に編成することができる。一実施形態では、委託役割は、エンタープライズ・アプリケーションのような単一のトップレベルリソースに関連付けられ、委託役割階層は、リソース階層とは別に維持することができる。セキュリティポリシーは、役割定義及び別に維持される役割階層を変更することができるプリンシパルを限定するために、エンタープライズ・アプリケーションに関連付けられる。別の実施形態では、任意の委託役割階層をミラーリングする架空リソース階層を利用することができ、これによって各委託役割は、階層における委託役割の適切な位置に対応するリソースに関連付けられる。セキュリティポリシーは、どのプリンシパルが関連の役割を修正することができるかを管理するために各リソースに関連付けることができる。階層のルートにおけるセキュリティポリシーは、架空階層自体の修正を許可されるプリンシパルを限定することができると考えられる。

再度図４を参照すると、役割Ａｄｍｉｎ＿Ｒｏｌｅは、委託役割階層のトップにある。一実施形態では、この役割におけるプリンシパルは、その管理機能又は委託権限で限界を持っていない。非制限的な例として、Ａｄｍｉｎ＿Ｒｏｌｅのプリンシパルは、委託役割及び委託階層の定義を修正することができる。一実施形態では、委託役割のプリンシパルは、委託階層でその下にある役割にのみ管理機能を委託することができる。Ａｄｍｉｎ＿Ｒｏｌｅは、２つの子、Ａ＿Ｒｏｌｅ及びＢ＿Ｒｏｌｅを有する。Ａ＿Ｒｏｌｅは、１つの子、Ｃ＿Ｒｏｌｅを有し、Ｃ＿Ｒｏｌｅは、２つの子、Ｄ＿Ｒｏｌｅ及びＥ＿Ｒｏｌｅを有する。非制限的な例として、Ａｄｍｉｎ＿Ｒｏｌｅは、階層でその下にある全ての他の役割に委託することができる。同様に、Ａ＿Ｒｏｌｅは、Ｃ＿Ｒｏｌｅ、Ｄ＿Ｒｏｌｅ、及びＥ＿Ｒｏｌｅに委託することができる。ところが、Ｃ＿Ｒｏｌｅは、Ｄ＿Ｒｏｌｅ及びＥ＿Ｒｏｌｅに委託できるのみである。ツリーのリーフ、Ｄ＿Ｒｏｌｅ、Ｅ＿Ｒｏｌｅ、及びＢ＿Ｒｏｌｅは、子を持たないので委託できない。別の実施形態では、階層のノードは、１つよりも多い親に関連付けることができる。これによって、１つよりも多い上位の役割は、下位の役割に委託することができる。

一実施形態では、委託は、セキュリティポリシーによって表すことができる。ポリシーは、委託されたリソース／機能に関連付けられ、リソース／機能は、委託された役割に基づいている。図５は、本発明の一実施形態における例示的な委託セキュリティポリシーを示している。この例に関しては、図４の委託階層が保持されると仮定する。図５のルートリソースに注意すると、「Ｅｎｔｅｒｐｒｉｓｅ Ａｐｐ １」は、以下の役割、すなわち、Ａｄｍｉｎ＿Ｒｏｌｅ、Ａ＿Ｒｏｌｅ、Ｂ＿Ｒｏｌｅ、Ｃ＿Ｒｏｌｅ、Ｄ＿Ｒｏｌｅ、及びＥ＿Ｒｏｌｅに関連付けられる。図５に示す階層は、他のリソース、役割、及びポリシーを含むことができるであろうが、例証の目的に限定されるものである。一実施形態では、委託は、機能が委託されるリソースにポリシーを作成する。例えば、リソース「Ｗｅｂ Ａｐｐ １」は、Ａｄｍｉｎ機能と関連のセキュリティポリシーＰ（Ｄ＿Ｒｏｌｅ）とを有する。Ｃ＿Ｒｏｌｅ、Ａ＿Ｒｏｌｅ、又はＡｄｍｉｎ＿Ｒｏｌｅの役割におけるプリンシパルは、「Ｗｅｂ Ａｐｐ １」のためのＡｄｍｉｎ機能をＤ＿Ｒｏｌｅに委託することによってこのポリシーを作成したものである。（Ａｄｍｉｎだけでなくどの機能も委託することができることは、当業者には明らかであろう。）従って、Ｄ＿Ｒｏｌｅを満たすプリンシパルは、「Ｗｅｂ Ａｐｐ １」の管理を実行することができる。しかし、「Ｗｅｂ Ａｐｐ １」が委託機能を持たないので、Ｄ＿Ｒｏｌｅを満たすプリンシパルは、「Ｗｅｂ Ａｐｐ １」のＡｄｍｉｎ機能を更に委託することはできない。

リソース「Ｄｅｓｋｔｏｐ Ａ」は、２つの機能、ＡｄｍｉｎとＤｅｌｅｇａｔｅを有し、この各々はポリシーを有する。両方に付けられたポリシーＰ（Ａ＿Ｒｏｌｅ）は、Ａｄｍｉｎ＿Ｒｏｌｅの役割におけるプリンシパルが、Ｒｏｌｅ＿Ａに両方の管理者「Ｄｅｓｋｔｏｐ Ａ」への機能を委託したこと、更にこの機能を委託することを示すものである。従って、Ｒｏｌｅ＿Ａにおけるプリンシパルは、Ａｄｍｉｎ及びＤｅｌｅｇａｔｅ機能の両方を階層的に下位の委託役割（すなわち、Ｃ＿Ｒｏｌｅ、Ｄ＿Ｒｏｌｅ、及びＥ＿Ｒｏｌｅ）に更に委託することができる。例えば、リソース「Ｄｅｓｋｔｏｐ Ｂ」は、ポリシーＰ（Ｃ＿Ｒｏｌｅ）を有する機能Ａｄｍｉｎを有する。このポリシーは、Ａ＿Ｒｏｌｅ又はＡｄｍｉｎ＿Ｒｏｌｅの役割におけるプリンシパルによって適切に配置されたものである。Ｃ＿Ｒｏｌｅの役割におけるプリンシパルは、管理者「Ｄｅｓｋｔｏｐ Ｂ」になることはできるが、この機能を更に委託することはできない。

一実施形態では、階層的に上位の委託役割におけるプリンシパルによって既に委託されたノードへの委託は許可されない。図４及び５を参照すると、更に非制限的な例証として、リソース「Ｐｏｒｔａｌ ２」がポリシーＰ（Ａ＿Ｒｏｌｅ）を有する場合、Ｃ＿Ｒｏｌｅの役割におけるプリンシパルは、Ｃ＿Ｒｏｌｅよりも上位の役割（すなわち、Ａ＿Ｒｏｌｅ）に委託されたので、「Ｐｏｒｔａｌ ２」を委託することはできない。
別の実施形態では、ユーザグループ管理の態様を委託することができる。非制限的な例として、ユーザグループは、エンタープライズ・アプリケーションリソースの子としてこれらをビューすることにより階層に編成される。委託することができる機能は、ユーザプロフィール管理、グループの数をビューする能力、及びユーザ及びグループを作成し、更新し、更に取り除く能力を含んでいる。

一実施形態は、コンピュータ技術に熟練した者には明らかなように、本開示の教示に従ってプログラムされた従来の汎用又は特殊用途向けデジタルコンピュータ又はマイクロプロセッサを使用して実施することができる。適切なソフトウエアコーディングは、ソフトウエア技術に熟練した者には明らかなように、本開示の教示に基づいて熟練のプログラマーによって容易に準備することができる。本発明はまた、当業者には容易に明らかなように、集積回路の準備により又は従来の構成要素回路の適切なネットワークを相互接続することにより実施することができる。

一実施形態は、コンピュータを本明細書に示す特徴のいずれかを実行するようにプログラムするのに使用することができる命令をその上に／その中に記憶した記憶媒体（又は複数の媒体）であるコンピュータプログラム製品を含む。記憶媒体は、以下に限定されるものではないが、フロッピーディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、及び磁気光ディスクを含む任意の種類のディスクと、ＲＯＭと、ＲＡＭと、ＥＰＲＯＭと、ＥＥＰＲＯＭと、ＤＲＡＭと、ＶＲＡＭと、フラッシュメモリデバイスと、磁気又は光カードと、ナノシステム（分子メモリＩＣを含む）と、又は命令及び／又はデータを記憶するのに適する任意の種類の媒体又はデバイスとを含むことができる。

コンピュータ可読媒体（又は複数の媒体）のいずれか１つに記憶することにより、本発明は、汎用／特殊用途向けコンピュータ又はマイクロプロセッサの両方のハードウエアを制御し、かつ本発明の結果を利用する人間ユーザ又は他の機構とこれらのコンピュータ又はマイクロプロセッサが対話することを可能にするためのソフトウエアを含むものである。このようなソフトウエアは、以下に限定されるものではないが、デバイスドライバ、オペレーティングシステム、実行環境／コンテナー、及びユーザアプリケーションを含むことができる。

本発明の好ましい実施形態の以上の説明は、例証及び説明の目的で提供されたものである。これは、網羅的なものではなく、又は開示された正確な形態に本発明を限定するものでもない。多くの修正及び変形が当業者には明らかであろう。実施形態は、本発明の原理及びその実際的な応用を最も良く説明するように選択されて記述され、それによって他の当業者が、想定される特定の使用に適する様々な修正と共に本発明及び様々な実施形態を理解することを可能にするものである。本発明の範囲は、特許請求の範囲及びその均等物によって規定されるものとする。

本発明の一実施形態による例示的なリソース階層を示す図である。 役割及びセキュリティポリシーを更に説明する、図１の例示的な階層を示す図である。 本発明の一実施形態による許可システムの図である。 本発明の一実施形態による委託役割階層を示す図である。 本発明の一実施形態における例示的な委託セキュリティポリシーを示す図である。

符号の説明

Ａｄｍｉｎ＿Ｒｏｌｅ、Ａ＿Ｒｏｌｅ、Ｂ＿Ｒｏｌｅ、Ｃ＿Ｒｏｌｅ、Ｄ＿Ｒｏｌｅ、Ｅ＿Ｒｏｌｅ 役割
「Ｗｅｂ Ａｐｐ １」 リソース
Ｐ（Ｄ＿Ｒｏｌｅ） セキュリティポリシー

Claims (60)

1. リソースへのアクセスを適応制御するための許可の方法であって、
   リソースに階層的に関係した少なくとも１つの役割へのプリンシパルのマッピングを提供する段階と、
   前記少なくとも１つの役割に基づいてポリシーの評価を与える段階と、
   前記ポリシーの前記評価に基づいて、前記リソースへのアクセスを前記プリンシパルに許可するか否かの判断を与える段階と、
   を含むことを特徴とする方法。
2. 前記プリンシパルが認証されたユーザ、グループ、又は処理であることを可能にする段階、
   を含むことを特徴とする請求項１に記載の方法。
3. 前記マッピングを提供する段階は、前記少なくとも１つの役割が前記プリンシパルによって満足されるか否かを判断する段階を含む、
   ことを特徴とする請求項１に記載の方法。
4. 前記少なくとも１つの役割が、コンテキストにおける前記プリンシパルに対して真であるか又は偽であるかを判断する段階、
   を含むことを特徴とする請求項１に記載の方法。
5. 前記少なくとも１つの役割は、（１）別のブール表現及び（２）述部の少なくとも一方を含むことができるブール表現である、
   ことを特徴とする請求項１に記載の方法。
6. 前記述部は、ユーザ、グループ、時間、及びセグメントの１つである、
   ことを特徴とする請求項５に記載の方法。
7. 前記述部は、前記プリンシパル及びコンテキストに対して評価することができる、
   ことを特徴とする請求項５に記載の方法。
8. 前記述部は、普通語で指定することができるセグメントである、
   ことを特徴とする請求項５に記載の方法。
9. 前記ポリシーは、前記リソースと役割のセットとの間の関連性である、
   ことを特徴とする請求項１に記載の方法。
10. 前記少なくとも１つの役割が前記役割のセット内にある場合に、前記リソースへのアクセスを許可する段階、
    を含むことを特徴とする請求項９に記載の方法。
11. リソースへのアクセスを適応制御するための許可の方法であって、
    リソースへアクセスしようと試みるプリンシパルに適用可能な少なくとも１つの役割に基づいてポリシーの評価を与える段階と、
    前記評価に基づいて前記リソースへのアクセスの許可を与える段階と、
    を含み、
    前記リソース、前記ポリシー、及び前記少なくとも１つの役割は、階層的に関連している、
    ことを特徴とする方法。
12. 前記プリンシパルが認証されたユーザ、グループ、又は処理であることを可能にする段階、
    を含むことを特徴とする請求項１１に記載の方法。
13. 前記少なくとも１つの役割は、該少なくとも１つの役割がプリンシパルによって満足される場合に該プリンシパルに適用可能である、
    ことを特徴とする請求項１１に記載の方法。
14. 前記少なくとも１つの役割をコンテキストにおける前記プリンシパルに対して真又は偽と評価する段階、
    を含むことを特徴とする請求項１１に記載の方法。
15. 前記少なくとも１つの役割は、（１）別のブール表現及び（２）述部の少なくとも一方を含むことができるブール表現である、
    ことを特徴とする請求項１１に記載の方法。
16. 前記述部は、ユーザ、グループ、時間、及びセグメントの１つである、
    ことを特徴とする請求項１５に記載の方法。
17. 前記述部を前記プリンシパル及びコンテキストに対して評価する段階、
    を含むことを特徴とする請求項１５に記載の方法。
18. 前記セグメントの述部は、普通語で指定することができる、
    ことを特徴とする請求項１６に記載の方法。
19. 前記ポリシーは、前記リソースと役割のセットとの間の関連性である、
    ことを特徴とする請求項１１に記載の方法。
20. 前記少なくとも１つの役割が前記役割のセット内にある場合に、前記リソースへのアクセスを許可する段階、
    を含むことを特徴とする請求項１９に記載の方法。
21. リソースへのアクセスを適応制御するための許可の方法であって、
    プリンシパル及びリソースに関連する情報をセキュリティフレームワークに提供する段階と、
    少なくとも１つの役割を前記プリンシパルに関連付けることにより少なくとも１つのセキュリティポリシーを評価することに基づいて許可結果を提供するために、前記セキュリティフレームワークを利用する段階と、
    を含み、
    前記リソース、前記セキュリティポリシー、及び前記少なくとも１つの役割は、階層的に関連している、
    ことを特徴とする方法。
22. 前記プリンシパルが認証されたユーザ、グループ、又は処理であることを可能にする段階、
    を含むことを特徴とする請求項２１に記載の方法。
23. 少なくとも１つの役割をプリンシパルに関連付ける段階は、該少なくとも１つの役割が該プリンシパルによって満足されるか否かを判断する段階を含む、
    ことを特徴とする請求項２１に記載の方法。
24. 前記少なくとも１つの役割をコンテキストにおける前記プリンシパルに対して真又は偽と評価する段階、
    を含むことを特徴とする請求項２１に記載の方法。
25. 前記少なくとも１つの役割は、（１）別のブール表現及び（２）述部の少なくとも一方を含むことができるブール表現である、
    ことを特徴とする請求項２１に記載の方法。
26. 前記述部は、ユーザ、グループ、時間、及びセグメントの１つである、
    ことを特徴とする請求項２５に記載の方法。
27. 前記述部は、前記プリンシパル及びコンテキストに対して評価することができる、
    ことを特徴とする請求項２５に記載の方法。
28. 前記述部は、普通語で指定することができるセグメントである、
    ことを特徴とする請求項２５に記載の方法。
29. 前記ポリシーは、前記リソースと役割のセットとの間の関連性である、
    ことを特徴とする請求項２１に記載の方法。
30. 前記少なくとも１つの役割が前記役割のセット内にある場合に、前記リソースへのアクセスを許可する段階、
    を含むことを特徴とする請求項２９に記載の方法。
31. リソースへのアクセスを制御するようになった許可のためのシステムであって、
    リソースに階層的に関係した少なくとも１つの役割にプリンシパルをマップするための少なくとも１つの役割マッパーと、
    前記少なくとも１つの役割マッパーに連結され、該少なくとも１つの役割に基づいてポリシーが満足されるかを判断するための少なくとも１つのオーソライザと、
    前記少なくとも１つのオーソライザに連結され、該少なくとも１つのオーソライザの判断に基づいて最終決定を与えるためのアジュディケータと、
    を含むことを特徴とするシステム。
32. 前記プリンシパルは、認証されたユーザ、グループ、又は処理である、
    ことを特徴とする請求項３１に記載のシステム。
33. マッピング段階は、前記少なくとも１つの役割が前記プリンシパルによって満足されるか否かを判断する段階を含む、
    ことを特徴とする請求項３１に記載のシステム。
34. 前記少なくとも１つの役割は、コンテキストにおける前記プリンシパルに対して真又は偽を評価する、
    ことを特徴とする請求項３１に記載のシステム。
35. 前記少なくとも１つの役割は、別のブール表現及び述部の少なくとも一方を含むことができるブール表現である、
    ことを特徴とする請求項３１に記載のシステム。
36. 前記述部は、ユーザ、グループ、時間、及びセグメントの１つである、
    ことを特徴とする請求項３５に記載のシステム。
37. 前記述部は、前記プリンシパル及びコンテキストに対して評価することができる、
    ことを特徴とする請求項３５に記載のシステム。
38. 前記セグメントの述部は、普通語で指定することができる、
    ことを特徴とする請求項３６に記載のシステム。
39. 前記ポリシーは、前記リソースと役割のセットとの間の関連性である、
    ことを特徴とする請求項３１に記載のシステム。
40. 前記リソースへのアクセスは、前記少なくとも１つの役割が前記役割のセット内にある場合に許可される、
    ことを特徴とする請求項３６に記載のシステム。
41. 命令を記憶した機械可読媒体であって、
    プロセッサによって実行された時に、命令よりシステムが、
    リソースと階層的に関連した少なくとも１つの役割にプリンシパルをマップし
    前記少なくとも１つの役割に基づいてポリシーを評価し、
    前記ポリシーの前記評価に基づいて前記リソースへのアクセスを許可するか否かを判断する、
    ことを特徴とする媒体。
42. 実行された時に前記システムに対して、
    前記プリンシパルが認証されたユーザ、グループ、又は処理であることを可能にさせる、
    命令を更に含むことを特徴とする請求項４１に記載の機械可読媒体。
43. マッピング段階は、前記少なくとも１つの役割が前記プリンシパルによって満足されるか否かを判断する段階を含む、
    ことを特徴とする請求項４１に記載の機械可読媒体。
44. 実行された時に前記システムに対して、
    前記少なくとも１つの役割をコンテキストにおける前記プリンシパルに対して真又は偽と評価させる、
    命令を更に含むことを特徴とする請求項４１に記載の機械可読媒体。
45. 前記少なくとも１つの役割は、別のブール表現及び述部の少なくとも一方を含むことができるブール表現である、
    ことを特徴とする請求項４１に記載の機械可読媒体。
46. 前記述部は、ユーザ、グループ、時間、及びセグメントの１つである、
    ことを特徴とする請求項４５に記載の機械可読媒体。
47. 前記述部は、前記プリンシパル及びコンテキストに対して評価することができる、
    ことを特徴とする請求項４５に記載の機械可読媒体。
48. 前記セグメントの述部は、普通語で指定することができる、
    ことを特徴とする請求項４６に記載の機械可読媒体。
49. 前記ポリシーは、前記リソースと役割のセットとの間の関連性である、
    ことを特徴とする請求項４１に記載の機械可読媒体。
50. 実行された時に前記システムに対して、
    前記少なくとも１つの役割が前記役割のセット内にある場合に前記リソースへのアクセスを許可させる、
    命令を更に含むことを特徴とする請求項４９に記載の機械可読媒体。
51. エンタープライズ・アプリケーション内のリソースへのアクセスを適応制御するための許可の方法であって、
    リソースと階層的に関係した少なくとも１つの役割へのプリンシパルのマッピングを提供する段階と、
    前記少なくとも１つの役割に基づいてポリシーの評価を与える段階と、
    前記ポリシーの前記評価に基づいて、前記リソースへのアクセスを前記プリンシパルに許可するか否かの判断を与える段階と、
    を含み、
    前記少なくとも１つの役割、前記ポリシー、及び前記リソースは、エンタープライズ・アプリケーションの一部である、
    ことを特徴とする方法。
52. 前記プリンシパルが、認証されたユーザ、グループ、又は処理であることを可能にする段階、
    を含むことを特徴とする請求項５１に記載の方法。
53. 前記マッピングを提供する段階は、前記少なくとも１つの役割が前記プリンシパルによって満足されるか否かを判断する段階を含む、
    ことを特徴とする請求項５１に記載の方法。
54. 前記少なくとも１つの役割が、コンテキストにおける前記プリンシパルに対して真であるか又は偽であるかを判断する段階、
    を含むことを特徴とする請求項５１に記載の方法。
55. 前記少なくとも１つの役割は、（１）別のブール表現及び（２）述部の少なくとも一方を含むことができるブール表現である、
    ことを特徴とする請求項５１に記載の方法。
56. 前記述部は、ユーザ、グループ、時間、及びセグメントの１つである、
    ことを特徴とする請求項５５に記載の方法。
57. 前記述部は、前記プリンシパル及びコンテキストに対して評価することができる、
    ことを特徴とする請求項５５に記載の方法。
58. 前記述部は、普通語で指定することができるセグメントである、
    ことを特徴とする請求項５５に記載の方法。
59. 前記ポリシーは、前記リソースと役割のセットとの間の関連性である、
    ことを特徴とする請求項５１に記載の方法。
60. 前記少なくとも１つの役割が前記役割のセット内にある場合に前記リソースへのアクセスを許可する段階、
    を含むことを特徴とする請求項５９に記載の方法。

Images