信用証明に基づくアクセス制御のサポート記述
サポート記述は、別のエンティティにより所有され、あるいは管理されるリソースにアクセスする1つのエンティティからの要求を許可するかどうかを決定するために必要な証明を安全に効果的に構築し、あるいは確認することを援助するために提供される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にアクセス制御に係わり、より詳細には、分散型のアクセス制御システムにおける信用証明に基づくアクセス制御に関する
【背景技術】
【０００２】
コンピュータ環境は、様々なエンティティとリソースを含むことができる。エンティティは、ユーザ、オペレーティングシステム、アプリケーション、プロセス、スレッド、およびオブジェクトなどを含むことができる。リソースは、情報、ファイル、ネットワーク接続、プロパティ、およびオブジェクトの方法などを備えうる。一般に、１つのエンティティ（「クライアント」）が別のエンティティ（「サーバ」）により所有され、あるいは管理されたリソースにアクセスしたいとき、クライアントはサーバにアクセス要求を発行する。サーバは、アクセス要求を許可するかどうかを決定するためにリソースを管理するプログラム「リソースマネージャ」を使用することができる。決定処理は、一般にアクセス制御処理と呼ばれる。リソースマネージャは、上記リソースのために予め設定されたアクセスポリシー（「使用ポリシー」）を参考にすることにより決定する。リソースマネージャ、リソース、および上記関連する使用ポリシーは、上記サーバの一部と見なされうる。リソースマネージャ、および上記関連する使用ポリシーは、アクセス制御システムを構成する。
【０００３】
従来のアクセス制御システムは、どのエンティティがリソースにアクセスできるかに関して静的および閉鎖的となる傾向がある。このようなアクセス制御システムにおいて、クライアントは、通常サーバにローカルに知られた認証されたエンティティであり、決定するのに必要な情報は、一般にサーバ上でローカルに利用可能である。結果として、サーバは、局所的なアクセス制御の全体的な複雑さを管理する必要があり、管理業務のいくつかを他のエンティティに委任することができない。
【０００４】
インターネットのような分散型のダイナミックなコンピュータ環境の発展は、静的および閉鎖的なアクセス制御システムを不十分なものにさせた。例えば、サーバにローカルに知られていないエンティティが、サーバ上のリソースへのアクセスを要求しうる。エンティティは、その決定処理の間使用するためにリソースマネージャに情報を供給する。エンティティにより供給された情報は、要求されたアクセスをエンティティに許可する前に、エンティティに証明するように要求するサーバからの提案への応答となりうる。このような応答は、証明（ｐｒｏｏｆ）とも呼ばれる。上記エンティティは、上記アクセス要求に従い信用証明記述を提供しうる。信用証明記述は、誰が上記エンティティであるかを識別するための情報を供給する。信用証明記述は、誰が上記エンティティであるか決定するのを援助するために使用される証明情報以上のものを備えうる。また、信用証明記述は、追加のポリシー記述を備えうる。ポリシー記述の認証性と完全性が現在の暗号技術により保障されることができるため、リソースの所有者は、リモートでポリシー記述を作成し、ポリシー記述をクライアントに供給する。次いで、クライアントは、リソースのリソースマネージャにポリシー記述を提示する。次いで、リソースマネージャは、ポリシー記述の正確性をチェックし、リソースの所有者と情報を交換する。結局、リソースマネージャは、ポリシー記述において表現されたようにリソースの所有者の意思に一致した方法でアクセスを供給しうる。
【０００５】
暗号により保護された記述を通してリモートでポリシーを構成する権能は、アクセス制御システムが従来の閉鎖的かつ静的なモデルを逸脱する多くの機会を提供する。例えば、クライアントは、当該クライアントを予め定められたグループのメンバーであると認証するエンティティにより作成された記述を提示する可能性がある。また、クライアントは、リソースの所有者により記載され、グループのメンバーがエンティティに従いリソースにアクセスする可能性があるという言う記述を提示する可能性もある。同時に、これらの記述は、クライアントがリソースにアクセスすることができなければならないことを暗示する。このような例において、リソースマネージャは、クライアントを認証されたグループのメンバーであると認証するエンティティについての事前の知識がない可能性がある。また、リソースマネージャは、リソースの所有者がこの特定のアクセス制御決定の目的についてのみ認証権能をエンティティに委任したことを事前に知らない可能性がある。
【０００６】
ＩＳＯ権利表現言語（XrML 2.x）および委任論理(Delegation Logic)のような特定のアプローチは、アクセス制御決定が記述自体から象徴的に計算されるように、論理形式の記述を表現する。更に具体的には、これらのアプローチは、述語計算にこれらの基礎を有し、アクセスが所有者の意思に従い許可されなければならないかどうかについてのこれらのコンピュータ処理は、証明を発見することに等しい。証明に基づくアプローチには、いくつかの利点がある。最も重要な利点は、それがなぜアクセスが許可されるべきであるかについて数学的に証明できる理由を提供することである。もう１つの利点は、所有者の意思を見出すために、表現の意味をいくつかの他の形態に翻訳する必要がないことである。つまり、推論は表現レベルそのものでなされることができる。
【０００７】
種々の委任シナリオを可能とするために、リソースマネージャは、クライアントにより供給された記述を処理する必要があり、要求されたアクセスを許可するかしないかについて決定する必要がある。複数の記述が測定可能でかつ管理可能な方法によるアクセスを暗示するのを許容するため、リソースマネージャは、クライアントにより供給された記述に内在する意味と固有の意思を論証する必要がある。このような論証処理は、「証明計算(computing the proof)」、あるいは「定理証明（theorem proving）」と呼ばれうる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、定理証明の処理は、煩雑になる可能性がある。宣言型の認証システムは、ＰＲＯＬＯＧのような宣言型のプログラム言語と密接な関係にある。定理証明は、Ｃ＋＋、Ｃ＃、あるいは、ＪＡＶＡのようなプログラムシステムに多く見られるような命令的な意味論とコンピュータ的に等しい。そのように、定理証明は、任意の計算問題、すなわち任意のコンピュータプログラムをコード化するのに使用される可能性がある。そのように、理論上の限界は、どれくらい速く証明が計算されることができるかに関して存在する。例えば、完全な述語計算のための最悪のケースでは、Ｃ＋＋、およびＣ＃等において答えられない質問が存在するのと同じように、証明計算時に終了することを保障できる既存のアルゴリズムが存在しない場合がある。結果として、アクセス制御に関する決定は、このクラスの問題には決して到達できない可能性がある。開いた末端は、リソースマネージャを敵の攻撃に公開しうる。例えば、クライアントは、限りないサイズの証明を構築することを含む証明計算をリソースマネージャに厳しく仕事を課すために、偽りのアサーションを組み込む可能性がある。また、偽りのアサーションは、証明の不存在を結論付けるために、リソースマネージャに時間と空間の限りない量を消費させるようにする可能性がある。リソースマネージャが終わりのない計算を入るとき、リソースマネージャは他のエンティティへのサービスを否定しなければならない。このような状況はサービス不能攻撃と呼ばれ、それはネットワーク経路サービスを遮断し、ネットワークを使用不能な状態にする可能性がある。
【０００９】
それゆえ、終わりのない計算によりもたらされるサービス不能攻撃のような否定的な結果を避けるために、リソースマネージャの煩わしい計算から証明を取り除く必要がある。
【００１０】
本発明は、サポート記述、すなわち安全で効果的な確認のために証明を構築するのを援助する追加のアサーションを提供することにより上述で特定された必要性について対処する。追加のアサーションは、証明計算の代わりに、リソースマネージャが証明を検査し確認することを可能にする。
【課題を解決するための手段】
【００１１】
本発明の１つの態様は、サーバコンポーネント、クライアントコンポーネント、および１以上のサポート記述、すなわち追加のアサーションを備えるシステムを提供する。サーバコンポーネントは、リソースを所有し、あるいは管理する何れかのエンティティである。リソースは、誰がリソースにアクセスできるか指示する使用ポリシーに関連する。クライアントコンポーネントは、リソースにアクセスすることを要求するいずれかのエンティティである。システムは、１以上のエンティティ（「補助クライアント」）により補われる可能性がある。クライアントコンポーネントおよび／または補助クライアントは、サーバコンポーネントに信用証明記述および／または追加のアサーションのような情報を供給する。信用証明記述は、クライアントコンポーネントが誰であるかについて識別する。上記信用証明記述は、上記クライアントコンポーネントが予め定められたグループのメンバーであることを認証する記述のような補助クライアントの何れかにより供給される認証記述も含みうる。クライアントコンポーネントは、サーバコンポーネントのための信用されたエンティティでない可能性がある。サーバコンポーネントがクライアントコンポーネントにより供給される情報から生じる証明が正しいことを確認できる限り、サーバコンポーネントはクライアントコンポーネントに要求されたアクセスを許可する。
【００１２】
１以上のアサーションは、クライアントコンポーネントが要求されたアクセスを許可されるべきであることを実証する証明を構築する方法を指示するために使用される。１以上のアサーションは、サーバコンポーネントにより供給される可能性があり、要求されたアクセスが許可されるべきであることを実証する証明を構築するために、クライアントコンポーネントにより使用される可能性がある。あるいは、クライアントコンポーネントは、次いでアクセス要求が許可されるべきであることを実証する証明を構築するサーバコンポーネントに、１以上のアサーションと信用証明記述を供給することができる。アサーションは、値を変数に割り当てることができ、信用証明あるいは使用ポリシーの１つに必須の節を証明することができる。本発明の一態様によれば、１以上のアサーションは、要求されたアクセスが許可されるべきかどうかを決定するのに必要な証明の全ての代わりに、その一部のみを構築する方法を指示することができる。
【００１３】
本発明の別の態様は、クライアントコンポーネントからのアクセス要求を受信するとすぐに、サーバコンポーネントがクライアントコンポーネントに提案を送信する方法を提供する。提案は、クライアントコンポーネントが要求されたアクセスを許可されるべきであることを実証する証明を構築するのを援助するさらなるアサーションを含む。
【００１４】
本発明の更なる別の態様は、信用証明記述と追加のアサーションに従い、クライアントコンポーネントがサーバコンポーネントにアクセス要求を送信する方法を提供する。追加のアサーションは、サーバコンポーネントに要求されたアクセスを許可するべきかどうかの結果を引き出すために信用証明記述を使用する方法について指示する。
【００１５】
追加のアサーションを供給するのが、クライアントコンポーネント、あるいはサーバコンポーネントであるかどうかに関わりなく、サーバコンポーネントは追加のアサーションを適用することから生じる証明を検査し、証明が正しいかどうかを決定する。もし証明が正しければ、アクセス要求が許可される。そうでなければ、アクセス要求は拒否される。要約すると、本発明は、サポート記述、すなわち証明を安全に効率的に能率的に構築し確認する援助となる追加のアサーション、を提示することにより証明の煩わしい計算により提示される問題を軽減する。従って、本発明は、要求されたアクセスを許可するべきかどうかを決定する証明の計算の代わりに、リソースマネージャの仕事を単純に証明の有効性をチェックすることに減少する。
【００１６】
上述の態様と本発明に付随する利点の多くは、添付の図面と組み合わされるとき、以下の詳細な説明を参照にしてよりよく理解されるとさらにすぐに理解されるようになる。
【発明を実施するための最良の形態】
【００１７】
図１は、本発明の態様を実施する例示的なシステム１００を示すブロック図である。図１に示すように、システム１００は、サーバ１０２コンポーネント（「サーバ」）と、クライアント１０４コンポーネント（「クライアント」）と、任意の１以上の補助クライアント１１２とを備える。サーバ１０２は、少なくとも１つのリソース１０６と、誰が上記リソース１０６にアクセスできるかを指示する対応する使用ポリシー１０８とを備える。サーバ１０２は、上記クライアント１０４および／または補助クライアント１１２により提出されるアクセス要求と信用証明１１８を検査するリソースマネージャ１１０を更に備える可能性がある。クライアント１０４は、サーバ１０２上の上記リソース１０６にアクセスすることを要求する何れかのエンティティである。
【００１８】
システム１００は、１以上の補助クライアント１１２により補助される可能性がある。補助クライアント１１２は、サーバ１０２かあるいはクライアント１０４の何れかに情報を提供することができる。例えば、もしクライアント１０４が企業である場合、補助クライアント１１２はその企業の子会社あるいはパートナーである可能性がある。本発明の典型的な実施形態において、補助クライアント１１２はそれ自身に共同事業者を有する可能性があり、そのそれぞれはそれ自身に関連要素などを有する可能性もある。関連要素の全ての異なる層は、全体で補助クライアント１１２と見なされる。
【００１９】
クライアント１０４は、リソース１０６にアクセスするために、リソースマネージャ１１０にアクセス要求および／または信用証明１１８を送信する。信用証明、すなわち信用証明記述は、クライアント１０４がリソース１０６にアクセスする資格があることを証明するために使用される。信用証明記述は、クライアント１０４および／または１以上の補助クライアント１１２で供給されうる。補助クライアント１１２は、クライアント１０４に、あるいは直接サーバ１０２に信用証明を送信しうる。リソースマネージャは受信されたアクセス要求および／または信用証明１１８を処理し、使用ポリシー１０８に従い受信されたアクセスを許可するべきかどうかを決定する。次いでリソースマネージャは、アクセス要求に関する決定１２０をクライアント１０４に送信し返す。
【００２０】
更に重要なことは、本発明の典型的な実施形態において、システム１００は、更に追加のアサーション１１４を具備する。追加のアサーションは、クライアント１０４および／または１以上の補助クライアント１１２によりサーバ１０２に供給されうる。このような状況においては、追加のアサーション１１４は、リソースマネージャ１１０に使用ポリシー１０８により特定される必要条件を満たすために受信された信用証明を処理する方法について指示する。本発明のいくつかの典型的な実施形態において、追加のアサーション１１４は、リソースマネージャ１１０がクライアント１０４からアクセス要求を受信するとすぐに、リソースマネージャ１１０によりクライアント１０４へ供給されうる。クライアント１０４は、リソース１０６へのアクセスを要求するための証明を構築するために、追加のアサーション１１４を使用する。追加のアサーション１１４は、アクセス要求を許可するべきかどうか決定するための証明計算から、リソースマネージャ１１０を開放する。その代わりに、追加のアサーション１１４は、リソースマネージャが証明の正確さを検査するのみとすることを可能にする。図４は、典型的な追加のアサーションを示し、詳細は後述される。
【００２１】
システム１００は、本発明がどこで適用できるかについて示すただの典型的な実施形態である。システム１００のコンポーネントは、単一のコンピュータシステム上に存在する可能性があり、ネットワーク上に分散される可能性もある。一般的に言って、システム１００は、サーバ１０２のようなコンポーネントがリソース１０６に要求されたアクセスを許可する決定１２０のような決定を行うための情報を提供するためにクライアント１０４のような別のコンポーネントを必要とする何れかの状況の中にでも存在することができる。そのような状況は、例えば、別のサーバマシンへのサーバマシン、別のクライアントマシンへのクライアントマシン、同じマシン内の２つのエンティティ、および信頼されたネットワーク内の２つの異なる処理などを具備する。要約すると、本発明は１つのエンティティが決定を行うために別のエンティティから情報を必要とするいずれの場合でも適用可能である。
【００２２】
本発明の典型的な実施形態は、単なるデータのみとは対照的に、論理形式により使用ポリシー、信用証明記述、およびアサーションを表現するアクセス制御言語を使用する。分散型のアクセス制御システムにおいて、クライアント１０４は、リソースへのアクセスを要求するために必要な信用証明記述を発行を補助クライアント１１２の複数の層に委任する可能性がある。もしデータが信用証明記述のために使用された場合には、１つのエンティティから別のエンティティへデータを転送するそれぞれのレベルにおいて、データの意味が検査され、および計算される必要がある。その一方で、もし信用証明記述が論理フォーマットで表現された場合には、分散型のアクセス制御システムは、信用証明記述の表現が固有の意味を明らかにする時ので、滑らかに、そして無限にスケールすることができる。
【００２３】
本発明の典型的な実施形態において、例えば使用ポリシー記述および信用証明記述のような記述は、多くのアクセス制御言語で広く使用される３つの概念を使用する。第１の概念は、ポリシー記述の変数の使用である。例えば、リソース１０６のための使用ポリシー１０８は、「Ｐａｒａｍａは、Ｘを読むことができる」と記述する可能性があり、ここで、変数「Ｘ」は一般的に定量化された変数、すなわち変数Ｘはどんな値でもとることができることを示す。ポリシー記述は、変数Ｘがとることができる値を制限する制約を具備する可能性もある。例えば、使用ポリシー１０８は、「Ｐａｒａｍａは、Ｘがテキストファイルである、Ｘを読むことができる。」と記述する可能性がある。本発明の記述により利用される第２の概念は、ポリシー記述が誰がリソースにアクセスするための信用証明記述あるいはアサーションを証明できるかを特定する権能を有するということである。例えば、使用ポリシー１０８は、「ａｃｍｅ．ｃｏｍは、リソース１０６へのアクセスを許可するアサーションを行うができる。」と記述する可能性がある。本発明の典型的な実施形態における記述は、記述が他のアサーションに基づくアサーションを含むことを許容する第３の概念を使用する。例えば、使用ポリシー１０８は、「Ｐａｒａｍａは、そのＰａｒａｍａが企業Ａに従い、企業Ａの従業員であるならば、リソース１０６にアクセスすることができる。」と記述する可能性がある。
【００２４】
本発明の典型的な実施形態において、上記クライアント１０４および／または１以上の補助クライアント１１２は、関連する信用証明記述を所有しうる。あるいは、信用証明記述は、他のどこかに記録されうる。次いで、信用証明記述への参照のみが、サーバ１０２に送信される。
【００２５】
図２〜５は、典型的な使用ポリシー記述２００、信用証明記述３００、追加のアサーション４００、および使用ポリシー記述２００と信用証明記述３００と追加のアサーション４００を統合した統合記述５００を示す。図２〜５において使用される典型的な記述は、上述の３つの概念を表現し、あるいは組み合わせる。図２〜５は、図１を参照して記載される。これらの典型的な記述において使用される実施形態は、システム１００の典型的なエンティティを反映する。例えば、「Ｃｏｎｔｏｓａ．ｃｏｍ」はサーバ１０２である可能性があり、「Ｐａｒａｍａ」は、「Ｃｏｎｔｏｓａ．ｃｏｍ」上のウェブサービスにアクセスすることを要求するクライアント１０４である可能性があり、「Ｆａｂｒｉｋａｍ．ｃｏｍ」と「Ｆａｂｒｉｋａｍ．ｃｏｍ」のパートナーである「Ａｃｍｅ．ｃｏｍ」は、補助クライアント１１２である可能性がある。
【００２６】
図２は、使用ポリシー１０８のような使用ポリシーにより供給されうる１つの典型的な使用ポリシー記述２００を示す。使用ポリシー記述２００は、「Ｃｏｎｔｏｓａ．ｃｏｍ」が、「ＸがＦａｂｒｉｋａｍ．ｃｏｍにより許可されるゴールドスターメンバーであるならば、ＸはＣｏｎｔｏｓａ．ｃｏｍウェブサービスにアクセスすることができる。」と言うことを記述する。Ｘが「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスにアクセスすることを要求するクライアントであると仮定する。使用ポリシー記述２００に従い、もしＸが「Ｆａｂｒｉｋａｍ．ｃｏｍ」により許可されるゴールドスターメンバーであることを証明することができれば、次いでＸは「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスにアクセスすることができる。
【００２７】
システム１００のような分散型のアクセス制御システムにおいて、分散のレベルが増加するとき、サーバ１０２はクライアント１０４を知らない可能性がある。サーバ１０２は、クライアントについての記述を作成するために、他のエンティティに頼る可能性がある。それゆえ、サーバ１０２がクライアント１０４から受信する信用証明記述は、クライアント１０４および／または１以上の補助クライアント１１２を含むいくつかのエンティティにより供給される信用証明記述を備える可能性がある。図３は、サーバ「Ｃｏｎｔｏｓａ．ｃｏｍ」がクライアント「Ｐａｒａｍａ」および／または補助クライアント「Ｆａｂｒｉｋａｍ．ｃｏｍ」および「Ａｃｍｅ．ｃｏｍ」から受信する可能性のある１組の信用証明記述３００を示す。図３に示すように、信用証明記述３００Ａは、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が「もしＸがＦａｂｒｉｋａｍ．ｃｏｍのパートナーであるならば、Ｘはゴールドスターメンバー証明書を発行することができる。」と言うことを記述する。この記述は、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が、「Ｆａｂｒｉｋａｍ．ｃｏｍ」のパートナーが誰であるかを指定することも暗示している。信用証明記述３００Ｂは、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が「Ａｃｍｅ．ｃｏｍは、Ｆａｂｒｉｋａｍ．ｃｏｍパートナーである。」と言うことを記述する。信用証明記述３００Ｃは、「Ａｃｍｅ．ｃｏｍ」が「Ｐａｒａｍａは、ゴールドスターメンバーである。」と言うことを記述する。
【００２８】
ここで、「Ｐａｒａｍａ」が「Ｃｏｎｔｏｓａ．ｃｏｍ」にアクセス要求し、信用証明記述３００を提示すると仮定する。従来通りに、「Ｃｏｎｔｏｓａ．ｃｏｍ」のリソースマネージャは、「Ｐａｒａｍａ」が要求されたアクセスを有するべきか、有してはならないかの証明を計算するために使用ポリシー記述２００と信用証明記述３００を通して機能する必要がある。上記リソースマネージャは、どの信用証明記述が使用ポリシーに適用できるかを決定するために、信用証明記述のそれぞれを通して見る。上記信用証明記述は、リソースマネージャが決定をするのを可能にする転送論理を供給する。もしリソースマネージャが発生する可能性のある多くの信用証明記述を受信するならば、例えば補助クライアントの多くの層が「Ｐａｒａｍａ」への信用証明記述の供給に関わるとき、リソースマネージャにより実行される計算処理は、任意に難しくなる可能性がある。多くの信用証明記述が存在するとき、サーバが証明を促すように信用証明記述を配置することは困難になる。たぶん、計算処理は、決して終わらない。サーバ１０２は限りない検索スペースを潜在的に必要とする可能性があり、実際に、要求されたアクセスを許可するべきかどうか判明するのにどれくらい時間がかかるかについて、演繹的に知ることはできない。
【００２９】
本発明の一態様は、関連する信用証明記述を使用して証明を構築する方法を指示する追加のアサーションを提供することによりこの問題に対処する。例えば、アサーションは使用ポリシー記述において値を変数に割り当てることができる。アサーションは、またユーザポリシー記述において１つの必須の節を指示することもできる。図４は、典型的なクライアント「Ｐａｒａｍａ」が典型的なサーバ「Ｃｏｎｔｏｓａ．ｃｏｍ」に供給する可能性のある典型的な追加のアサーション４００を示す。図４に示すように、アサーション４００Ａは、「記述＃１においてＸをＰａｒａｍａと入れ替えなさい」と記述する。アサーション４００Ｂは、「記述＃２においてＸをＡｃｍｅ．ｃｏｍと入れ替えなさい」と記述する。アサーション４００Ｃは、「記述＃６を満足するために、記述＃３を使用しなさい」と記述する。アサーション４００Ｄは、「記述＃７において記述＃４を正しいと判定しなさい」と記述する。アサーション４００Ｅは、「記述＃５を満足するために、記述＃８を使用しなさい」と記述する。
【００３０】
追加のアサーション４００は、証明に到達するために信用証明記述３００をまとめる方法を「Ｃｏｎｔｏｓａ．ｃｏｍ」のリソースマネージャに通知する。その結果、「Ｐａｒａｍａ」が信用証明記述３００のために可能な結果のすべての種類を検索することにより「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスにアクセスできるかどうか立証するための潜在的に未決定な量の仕事に向かう代わりに、「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスのリソースマネージャは、ただ明白な追加のアサーション４００の指示従う必要があるだけである。追加のアサーションは、このように本発明が証明に到達するための使用ポリシーと信用証明記述を処理する組織的で効率的な方法を提供することを可能にする。
【００３１】
図５は、ユーザポリシー記述２００と信用証明の統合記述３００上の追加のアサーション３００における指示を実行する「Ｃｏｎｔｏｓａ．ｃｏｍ」のリソースマネージャから生じた統合記述５００を示す。図５に示すように、統合記述５００Ａは、「Ｃｏｎｔｏｓａ．ｃｏｍ」が「ＰａｒａｍａがＦａｂｒｉｋａｍ．ｃｏｍ．により許可されるゴールドスターメンバーであるならば、Ｐａｒａｍａはリソースにアクセスすることができる」と言うことを記述する。統合記述５００Ｂは、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が「Ａｃｍｅ．ｃｏｍがＦａｂｒｉｋａｍ．ｃｏｍ．によるＦａｂｒｉｋａｍ．ｃｏｍのパートナーであるならば、Ａｃｍｅ．ｃｏｍはゴールドスターメンバー証明書を発行することができる」と言うことを記述する。統合記述５００Ｃは、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が「Ａｃｍｅ．ｃｏｍは、ゴールドスターメンバー証明書を発行することができる」と言うことを記述する。統合記述５００Ｄは、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が「Ｐａｒａｍａは、ゴールドスターメンバーである」と言うことを記述する。統合記述５００Ｅは、このように「Ｃｏｎｔｏｓａ．ｃｏｍ」が「Ｐａｒａｍａは、Ｃｏｎｔｏｓａ．ｃｏｍウェブサービスにアクセスすることができる。」と言うことと結論を下す。
【００３２】
それゆえ、典型的なサーバ「Ｃｏｎｔｏｓａ．ｃｏｍ」のためのリソースマネージャは、「Ｃｏｎｔｏｓａ．ｃｏｍ」が「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスへの「Ｐａｒａｍａ」のアクセスを暗黙のうちに認証したことを直接的な方法で結論付けるために、追加のアサーション４００を使用することができる。追加のアサーション４００のそれぞれに適用するとき、「Ｃｏｎｔｏｓａ．ｃｏｍ」がチェックする必要とすることは、このアサーションを適用することが可能であるということだけである。言い換えると、アサーションを提示するエンティティは、使用ポリシー記述２００と信用証明記述３００により暗示されない何かを「Ｃｏｎｔｏｓａ．ｃｏｍ」にさせることができない。
【００３３】
追加のアサーションは、サーバかクライアントの何れかに提供されることができる。クライアントあるいは補助クライアントからの追加のアサーションを受信するとすぐに、サーバのリソースマネージャは、証明を構築するために追加のアサーションを使用し、次いで証明を計算する代わりに証明を検査する。本発明の典型的な実施形態において、サーバが一組の信用証明記述と追加のアサーションを受信し、読み通すとすぐに、サーバは要求されたアクセス要求を許可するべきかどうかを把握することができる。
【００３４】
あるいは、サーバはクライアントに追加のアサーションを供給することができる。クライアントからアクセス要求を受信するとすぐに、サーバは提案で応じることができる。上記提案は、要求されたアクセスを獲得するためにサーバのために証明を構築する方法をクライアントに指示する追加のアサーションを含む可能性がある。このように、サーバは、クライアントから必要とされた証明を受信する。サーバがする必要があることは、証明が要求されたリソースと関連する使用ポリシーに従い有効な結論を提供するかどうか決定するために、証明を検査することだけである。
【００３５】
本発明の典型的な実施形態において、サーバはクライアントにより供給される証明を信頼する必要はない。サーバは、信用証明記述と追加のアサーションの正確さをチェックすることができる。これは、サーバのリソースマネージャが証明でないものを証明であるとだまされて信じることはできないので、信用証明記述と追加のアサーションが信頼されたエンティティから来る必要がないことを意味する。アサーションが実施をリソースマネージャに頼む段階は、使用ポリシーにおける変数の置き換えのような既に使用ポリシーにより暗示される動作しか、作成するべきではない。それゆえ、クライアントは間違いの証明に到達するためにサーバを誘導するために、サーバにうそをつくことができない。もし供給される追加のアサーションが間違いならば、サーバは証明を発見することができない。追加のアサーションは、サーバが証明を作成するのを援助できるだけであり、偽の証明を作成するようにサーバをだますことはできない。もし追加のアサーションが間違いならば、サーバは証明に到達することができない。これは、迷路を進むことに類似している。証明計算は、困難でありうる迷路から経路を発見するようである。反対に、与えられた経路が正しい経路であるかどうか確認することは、より簡単である。もし与えられた経路が迷路の出口に通じるならば、与えられた経路は正しい経路である。追加のアサーションは、「与えられた経路」に等しい。もしそれらがサーバを証明に到達させられるならば、与えられた追加のアサーションの一組は正しく、もしサーバがそれらを使用して証明に到達することができなければ、与えられた追加のアサーションは間違いであり、無視される。
【００３６】
本発明の典型的な実施形態において、サーバあるいはクライアントにより提供される追加のアサーションは、要求されたアクセスを許可するべきかどうかを決定するために必要な全ての証明の代わりに、一部分の証明のみを作成する可能性がある。例えば、サーバは何れのエンティティにもその使用ポリシーを明らかにしないことを決定する可能性がある。従って、サーバは、クライアントが必要に応じて隠されたユーザポリシーによりクライアントの識別を証明することを可能とする追加のアサーションを供給するのみである。例えば、「Ｃｏｎｔｏｓａ．ｃｏｍ」は使用ポリシー記述２００を明らかにしないことを決定する可能性がある。それゆえ、「Ｃｏｎｔｏｓａ．ｃｏｍ」は、使用ポリシー記述２００についての知識を有さないクライアントで、それが「Ｆａｂｒｉｋａｍ．ｃｏｍ」により認証されるゴールドスターメンバーであることを証明することを典型的なクライアント「Ｐａｒａｍａ」に要求する。あるいは、サーバは、定理証明で上述されたような終りのない計算の危険となりやすい従来の定理証明器と関連する。そのような危険を軽減するために、追加のアサーションは、証明の「難しい」部分を構築するために使用されることができ、従来の定理証明の単純で、安全な変形をマイナーな隙間を満たすために残したままにしておく。このようなアプローチにおいて、証明の安全で表現力豊かな計算を提供するために、定理の検証と証明は一緒に働く。
【００３７】
本発明の典型的な実施形態において、図１の中でも示されるサーバ１０２は、監査コンポーネント１１６を含む。監査コンポーネント１１６は、要求されたアクセスを許可するか、許可しないかについてのリソースマネージャの論理処理を記録して、保存する。監査コンポーネント１１６により記録される情報は、リソースマネージャが結論に到達するために処理する論理処理および／または様々な記述を識別する可能性がある。それゆえ、監査情報は、誰がリソースにアクセスしたかどうかだけでなく、なぜアクセスが許可されたかについても明らかにする可能性がある。監査情報は、アクセス制御システムがどのように動作するか、誰がリソースを要求したか、なぜ要求が許可されたか、およびどのように要求が許可されたかを分析することに役立つ。例えば、監査情報は、「Ｐａｒａｍａ」が「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスの利用を要求したことと、「Ｐａｒａｍａ」が「Ｆａｂｒｉｋａｍ．ｃｏｍ」により認証されるゴールドスターメンバーであることが証明されたのでアクセスが許可されたこととを提供する可能性がある。本発明の典型的な実施形態において、監査情報は、使用された追加のアサーションのセットを含む。
【００３８】
図６は、例えばサーバ１０２のようなサーバがアクセス要求を処理し、アクセス要求を許可するべきかどうかの決定に到達する典型的なルーチン６００を示す。具体的には、ルーチン６００は、サーバがアクセス要求を受信したかどうかを決定することにより開始される。決定ブロック６０２を参照する。もしサーバがアクセス要求を受信しない場合には、ルーチン６００は更に進まない。もしサーバがアクセス要求を受信した場合には、ルーチン６００は、クライアントに要求されたアクセスが許可される前に、サーバがアクセス要求を送信するクライアントに証明することを望む提案を応答することに進む。ブロック６０４を参照する。提案は、要求されたリソースのための使用ポリシーを識別する可能性がある。提案は、これらの使用ポリシーにおいて複数の使用ポリシー記述といくつかの変数の間の関係を識別する証明構築を含む可能性がある。提案は、クライアントに証明構築を具現化する方法を指示する追加のアサーションを更に具備する可能性がある。例えば、追加のアサーションは、クライアントに、使用ポリシー記述において状態を満足する方法および／または使用ポリシー記述において変数のための特定の値を発見する方法について提案する可能性がある。
【００３９】
次いで、ルーチン６００は、提案に応答してクライアントから証明を受信するために待機する。ルーチン６００は、そのような証明を受信したかどうかを決定する。決定ブロック６０６を参照する。もし決定ブロック６０６の答えが「ＮＯ」である場合には、ルーチン６００はそれ以上進まない。もしルーチン６００がクライアントから証明を受信する場合には、ルーチン６００は証明の検査に進む。ブロック６０８を参照する。受信された証明の検査において、ルーチン６００は、証明が正しいかどうか決定する。決定ブロック６１０を参照する。正しい証明は、クライアントが要求されたリソースにアクセスする権利があることと、証明が真実の記述を構成することとを実証する。もし決定ブロック６１０の答えが、受信された証明が正しいことを意味する「ＹＥＳ」である場合には、ルーチン６００は、アクセス要求の許可に進む。ブロック６１４を参照する。一方、決定ブロック６１０の答えが、受信された証明が誤っていることを意味する「ＮＯ」である場合には、ルーチン６００は、アクセス要求を拒否する。ブロック６１２を参照する。次いで、ルーチン６００は終了する。
【００４０】
図７は、クライアントがサーバのリソースにアクセスするためのサーバからの許可を求める典型的なルーチン７００を示す。具体的には、ルーチン７００は、クライアントがサーバのリソースにアクセスしたいかどうかを決定することにより開始される。決定ブロック７０２を参照する。もし答えが「ＮＯ」である場合には、ルーチン７００はさらに進まない。もしクライアントがサーバのリソースにアクセスしたい場合には、ルーチン７００はアクセス要求をサーバに送信する。ブロック７０４を参照する。次いで、ルーチン７００は、サーバから提案を受信するために待機する。ルーチン７００は、提案が受信されたどうかを決定する。決定ブロック７０６を参照する。もし答えが「ＮＯ」である場合には、ルーチン７００はさらに進まない。もしクライアントがサーバから提案を受信する場合には、ルーチン７００は提案に従い証明の構築に進む。ブロック７０８を参照する。証明は、提案において特定される必要条件を満足するデータと論理段階を含む。もし提案が証明を構築する方法を指示する追加のアサーションを含む場合には、証明は追加のアサーションに従い構築される。もし受信された提案が追加のアサーションを含まない場合には、構築された証明はクライアントが誰であるかを識別する信用証明記述を含む。構築された証明は、サーバにアクセス要求を許可するべきかどうかの決定に到達するために供給された信用証明記述を使用する方法について指示する追加のアサーションを含む可能性がある。次いで、ルーチン７００は、構築された証明をサーバに送信する。ブロック７１０を参照する。ルーチン７００は終了する。本発明の典型的な実施形態において、もしクライアントがサーバがアクセス要求を決定するために何を必要とするかを前もって知っている場合には、クライアントは、アクセス要求をサーバに送信するときに必要な信用証明記述と追加のアサーションも供給する。その結果、サーバは提案を送信する必要がない。
【００４１】
本発明の好ましい実施形態が示され、記述される一方で、様々な変化が本発明の精神および範囲から逸脱することなくその中でなされることができることはいうまでもない。
【図面の簡単な説明】
【００４２】
【図１】本発明の態様を実施するための例示的なシステムを示すブロック図である。
【図２】典型的な使用ポリシー記述を示すテキストの図である。
【図３】クライアントにより供給される典型的な信用証明記述を示すテキストの図である。
【図４】アクセス要求の証明を援助する典型的な追加のアサーションを示すテキストの図である。
【図５】図２において示された使用ポリシー記述と、図３において示された信用証明記述と、図４において示された追加のアサーションとを統合する結果である典型的な統合記述を示すテキストの図である。
【図６】サーバがアクセス要求を処理するための典型的なルーチンを示すフローチャートである。
【図７】クライアントがサーバ上でリソースにアクセスする許可を求めるための典型的なルーチンを示すフローチャートである。
【技術分野】
【０００１】
本発明は、一般的にアクセス制御に係わり、より詳細には、分散型のアクセス制御システムにおける信用証明に基づくアクセス制御に関する
【背景技術】
【０００２】
コンピュータ環境は、様々なエンティティとリソースを含むことができる。エンティティは、ユーザ、オペレーティングシステム、アプリケーション、プロセス、スレッド、およびオブジェクトなどを含むことができる。リソースは、情報、ファイル、ネットワーク接続、プロパティ、およびオブジェクトの方法などを備えうる。一般に、１つのエンティティ（「クライアント」）が別のエンティティ（「サーバ」）により所有され、あるいは管理されたリソースにアクセスしたいとき、クライアントはサーバにアクセス要求を発行する。サーバは、アクセス要求を許可するかどうかを決定するためにリソースを管理するプログラム「リソースマネージャ」を使用することができる。決定処理は、一般にアクセス制御処理と呼ばれる。リソースマネージャは、上記リソースのために予め設定されたアクセスポリシー（「使用ポリシー」）を参考にすることにより決定する。リソースマネージャ、リソース、および上記関連する使用ポリシーは、上記サーバの一部と見なされうる。リソースマネージャ、および上記関連する使用ポリシーは、アクセス制御システムを構成する。
【０００３】
従来のアクセス制御システムは、どのエンティティがリソースにアクセスできるかに関して静的および閉鎖的となる傾向がある。このようなアクセス制御システムにおいて、クライアントは、通常サーバにローカルに知られた認証されたエンティティであり、決定するのに必要な情報は、一般にサーバ上でローカルに利用可能である。結果として、サーバは、局所的なアクセス制御の全体的な複雑さを管理する必要があり、管理業務のいくつかを他のエンティティに委任することができない。
【０００４】
インターネットのような分散型のダイナミックなコンピュータ環境の発展は、静的および閉鎖的なアクセス制御システムを不十分なものにさせた。例えば、サーバにローカルに知られていないエンティティが、サーバ上のリソースへのアクセスを要求しうる。エンティティは、その決定処理の間使用するためにリソースマネージャに情報を供給する。エンティティにより供給された情報は、要求されたアクセスをエンティティに許可する前に、エンティティに証明するように要求するサーバからの提案への応答となりうる。このような応答は、証明（ｐｒｏｏｆ）とも呼ばれる。上記エンティティは、上記アクセス要求に従い信用証明記述を提供しうる。信用証明記述は、誰が上記エンティティであるかを識別するための情報を供給する。信用証明記述は、誰が上記エンティティであるか決定するのを援助するために使用される証明情報以上のものを備えうる。また、信用証明記述は、追加のポリシー記述を備えうる。ポリシー記述の認証性と完全性が現在の暗号技術により保障されることができるため、リソースの所有者は、リモートでポリシー記述を作成し、ポリシー記述をクライアントに供給する。次いで、クライアントは、リソースのリソースマネージャにポリシー記述を提示する。次いで、リソースマネージャは、ポリシー記述の正確性をチェックし、リソースの所有者と情報を交換する。結局、リソースマネージャは、ポリシー記述において表現されたようにリソースの所有者の意思に一致した方法でアクセスを供給しうる。
【０００５】
暗号により保護された記述を通してリモートでポリシーを構成する権能は、アクセス制御システムが従来の閉鎖的かつ静的なモデルを逸脱する多くの機会を提供する。例えば、クライアントは、当該クライアントを予め定められたグループのメンバーであると認証するエンティティにより作成された記述を提示する可能性がある。また、クライアントは、リソースの所有者により記載され、グループのメンバーがエンティティに従いリソースにアクセスする可能性があるという言う記述を提示する可能性もある。同時に、これらの記述は、クライアントがリソースにアクセスすることができなければならないことを暗示する。このような例において、リソースマネージャは、クライアントを認証されたグループのメンバーであると認証するエンティティについての事前の知識がない可能性がある。また、リソースマネージャは、リソースの所有者がこの特定のアクセス制御決定の目的についてのみ認証権能をエンティティに委任したことを事前に知らない可能性がある。
【０００６】
ＩＳＯ権利表現言語（XrML 2.x）および委任論理(Delegation Logic)のような特定のアプローチは、アクセス制御決定が記述自体から象徴的に計算されるように、論理形式の記述を表現する。更に具体的には、これらのアプローチは、述語計算にこれらの基礎を有し、アクセスが所有者の意思に従い許可されなければならないかどうかについてのこれらのコンピュータ処理は、証明を発見することに等しい。証明に基づくアプローチには、いくつかの利点がある。最も重要な利点は、それがなぜアクセスが許可されるべきであるかについて数学的に証明できる理由を提供することである。もう１つの利点は、所有者の意思を見出すために、表現の意味をいくつかの他の形態に翻訳する必要がないことである。つまり、推論は表現レベルそのものでなされることができる。
【０００７】
種々の委任シナリオを可能とするために、リソースマネージャは、クライアントにより供給された記述を処理する必要があり、要求されたアクセスを許可するかしないかについて決定する必要がある。複数の記述が測定可能でかつ管理可能な方法によるアクセスを暗示するのを許容するため、リソースマネージャは、クライアントにより供給された記述に内在する意味と固有の意思を論証する必要がある。このような論証処理は、「証明計算(computing the proof)」、あるいは「定理証明（theorem proving）」と呼ばれうる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、定理証明の処理は、煩雑になる可能性がある。宣言型の認証システムは、ＰＲＯＬＯＧのような宣言型のプログラム言語と密接な関係にある。定理証明は、Ｃ＋＋、Ｃ＃、あるいは、ＪＡＶＡのようなプログラムシステムに多く見られるような命令的な意味論とコンピュータ的に等しい。そのように、定理証明は、任意の計算問題、すなわち任意のコンピュータプログラムをコード化するのに使用される可能性がある。そのように、理論上の限界は、どれくらい速く証明が計算されることができるかに関して存在する。例えば、完全な述語計算のための最悪のケースでは、Ｃ＋＋、およびＣ＃等において答えられない質問が存在するのと同じように、証明計算時に終了することを保障できる既存のアルゴリズムが存在しない場合がある。結果として、アクセス制御に関する決定は、このクラスの問題には決して到達できない可能性がある。開いた末端は、リソースマネージャを敵の攻撃に公開しうる。例えば、クライアントは、限りないサイズの証明を構築することを含む証明計算をリソースマネージャに厳しく仕事を課すために、偽りのアサーションを組み込む可能性がある。また、偽りのアサーションは、証明の不存在を結論付けるために、リソースマネージャに時間と空間の限りない量を消費させるようにする可能性がある。リソースマネージャが終わりのない計算を入るとき、リソースマネージャは他のエンティティへのサービスを否定しなければならない。このような状況はサービス不能攻撃と呼ばれ、それはネットワーク経路サービスを遮断し、ネットワークを使用不能な状態にする可能性がある。
【０００９】
それゆえ、終わりのない計算によりもたらされるサービス不能攻撃のような否定的な結果を避けるために、リソースマネージャの煩わしい計算から証明を取り除く必要がある。
【００１０】
本発明は、サポート記述、すなわち安全で効果的な確認のために証明を構築するのを援助する追加のアサーションを提供することにより上述で特定された必要性について対処する。追加のアサーションは、証明計算の代わりに、リソースマネージャが証明を検査し確認することを可能にする。
【課題を解決するための手段】
【００１１】
本発明の１つの態様は、サーバコンポーネント、クライアントコンポーネント、および１以上のサポート記述、すなわち追加のアサーションを備えるシステムを提供する。サーバコンポーネントは、リソースを所有し、あるいは管理する何れかのエンティティである。リソースは、誰がリソースにアクセスできるか指示する使用ポリシーに関連する。クライアントコンポーネントは、リソースにアクセスすることを要求するいずれかのエンティティである。システムは、１以上のエンティティ（「補助クライアント」）により補われる可能性がある。クライアントコンポーネントおよび／または補助クライアントは、サーバコンポーネントに信用証明記述および／または追加のアサーションのような情報を供給する。信用証明記述は、クライアントコンポーネントが誰であるかについて識別する。上記信用証明記述は、上記クライアントコンポーネントが予め定められたグループのメンバーであることを認証する記述のような補助クライアントの何れかにより供給される認証記述も含みうる。クライアントコンポーネントは、サーバコンポーネントのための信用されたエンティティでない可能性がある。サーバコンポーネントがクライアントコンポーネントにより供給される情報から生じる証明が正しいことを確認できる限り、サーバコンポーネントはクライアントコンポーネントに要求されたアクセスを許可する。
【００１２】
１以上のアサーションは、クライアントコンポーネントが要求されたアクセスを許可されるべきであることを実証する証明を構築する方法を指示するために使用される。１以上のアサーションは、サーバコンポーネントにより供給される可能性があり、要求されたアクセスが許可されるべきであることを実証する証明を構築するために、クライアントコンポーネントにより使用される可能性がある。あるいは、クライアントコンポーネントは、次いでアクセス要求が許可されるべきであることを実証する証明を構築するサーバコンポーネントに、１以上のアサーションと信用証明記述を供給することができる。アサーションは、値を変数に割り当てることができ、信用証明あるいは使用ポリシーの１つに必須の節を証明することができる。本発明の一態様によれば、１以上のアサーションは、要求されたアクセスが許可されるべきかどうかを決定するのに必要な証明の全ての代わりに、その一部のみを構築する方法を指示することができる。
【００１３】
本発明の別の態様は、クライアントコンポーネントからのアクセス要求を受信するとすぐに、サーバコンポーネントがクライアントコンポーネントに提案を送信する方法を提供する。提案は、クライアントコンポーネントが要求されたアクセスを許可されるべきであることを実証する証明を構築するのを援助するさらなるアサーションを含む。
【００１４】
本発明の更なる別の態様は、信用証明記述と追加のアサーションに従い、クライアントコンポーネントがサーバコンポーネントにアクセス要求を送信する方法を提供する。追加のアサーションは、サーバコンポーネントに要求されたアクセスを許可するべきかどうかの結果を引き出すために信用証明記述を使用する方法について指示する。
【００１５】
追加のアサーションを供給するのが、クライアントコンポーネント、あるいはサーバコンポーネントであるかどうかに関わりなく、サーバコンポーネントは追加のアサーションを適用することから生じる証明を検査し、証明が正しいかどうかを決定する。もし証明が正しければ、アクセス要求が許可される。そうでなければ、アクセス要求は拒否される。要約すると、本発明は、サポート記述、すなわち証明を安全に効率的に能率的に構築し確認する援助となる追加のアサーション、を提示することにより証明の煩わしい計算により提示される問題を軽減する。従って、本発明は、要求されたアクセスを許可するべきかどうかを決定する証明の計算の代わりに、リソースマネージャの仕事を単純に証明の有効性をチェックすることに減少する。
【００１６】
上述の態様と本発明に付随する利点の多くは、添付の図面と組み合わされるとき、以下の詳細な説明を参照にしてよりよく理解されるとさらにすぐに理解されるようになる。
【発明を実施するための最良の形態】
【００１７】
図１は、本発明の態様を実施する例示的なシステム１００を示すブロック図である。図１に示すように、システム１００は、サーバ１０２コンポーネント（「サーバ」）と、クライアント１０４コンポーネント（「クライアント」）と、任意の１以上の補助クライアント１１２とを備える。サーバ１０２は、少なくとも１つのリソース１０６と、誰が上記リソース１０６にアクセスできるかを指示する対応する使用ポリシー１０８とを備える。サーバ１０２は、上記クライアント１０４および／または補助クライアント１１２により提出されるアクセス要求と信用証明１１８を検査するリソースマネージャ１１０を更に備える可能性がある。クライアント１０４は、サーバ１０２上の上記リソース１０６にアクセスすることを要求する何れかのエンティティである。
【００１８】
システム１００は、１以上の補助クライアント１１２により補助される可能性がある。補助クライアント１１２は、サーバ１０２かあるいはクライアント１０４の何れかに情報を提供することができる。例えば、もしクライアント１０４が企業である場合、補助クライアント１１２はその企業の子会社あるいはパートナーである可能性がある。本発明の典型的な実施形態において、補助クライアント１１２はそれ自身に共同事業者を有する可能性があり、そのそれぞれはそれ自身に関連要素などを有する可能性もある。関連要素の全ての異なる層は、全体で補助クライアント１１２と見なされる。
【００１９】
クライアント１０４は、リソース１０６にアクセスするために、リソースマネージャ１１０にアクセス要求および／または信用証明１１８を送信する。信用証明、すなわち信用証明記述は、クライアント１０４がリソース１０６にアクセスする資格があることを証明するために使用される。信用証明記述は、クライアント１０４および／または１以上の補助クライアント１１２で供給されうる。補助クライアント１１２は、クライアント１０４に、あるいは直接サーバ１０２に信用証明を送信しうる。リソースマネージャは受信されたアクセス要求および／または信用証明１１８を処理し、使用ポリシー１０８に従い受信されたアクセスを許可するべきかどうかを決定する。次いでリソースマネージャは、アクセス要求に関する決定１２０をクライアント１０４に送信し返す。
【００２０】
更に重要なことは、本発明の典型的な実施形態において、システム１００は、更に追加のアサーション１１４を具備する。追加のアサーションは、クライアント１０４および／または１以上の補助クライアント１１２によりサーバ１０２に供給されうる。このような状況においては、追加のアサーション１１４は、リソースマネージャ１１０に使用ポリシー１０８により特定される必要条件を満たすために受信された信用証明を処理する方法について指示する。本発明のいくつかの典型的な実施形態において、追加のアサーション１１４は、リソースマネージャ１１０がクライアント１０４からアクセス要求を受信するとすぐに、リソースマネージャ１１０によりクライアント１０４へ供給されうる。クライアント１０４は、リソース１０６へのアクセスを要求するための証明を構築するために、追加のアサーション１１４を使用する。追加のアサーション１１４は、アクセス要求を許可するべきかどうか決定するための証明計算から、リソースマネージャ１１０を開放する。その代わりに、追加のアサーション１１４は、リソースマネージャが証明の正確さを検査するのみとすることを可能にする。図４は、典型的な追加のアサーションを示し、詳細は後述される。
【００２１】
システム１００は、本発明がどこで適用できるかについて示すただの典型的な実施形態である。システム１００のコンポーネントは、単一のコンピュータシステム上に存在する可能性があり、ネットワーク上に分散される可能性もある。一般的に言って、システム１００は、サーバ１０２のようなコンポーネントがリソース１０６に要求されたアクセスを許可する決定１２０のような決定を行うための情報を提供するためにクライアント１０４のような別のコンポーネントを必要とする何れかの状況の中にでも存在することができる。そのような状況は、例えば、別のサーバマシンへのサーバマシン、別のクライアントマシンへのクライアントマシン、同じマシン内の２つのエンティティ、および信頼されたネットワーク内の２つの異なる処理などを具備する。要約すると、本発明は１つのエンティティが決定を行うために別のエンティティから情報を必要とするいずれの場合でも適用可能である。
【００２２】
本発明の典型的な実施形態は、単なるデータのみとは対照的に、論理形式により使用ポリシー、信用証明記述、およびアサーションを表現するアクセス制御言語を使用する。分散型のアクセス制御システムにおいて、クライアント１０４は、リソースへのアクセスを要求するために必要な信用証明記述を発行を補助クライアント１１２の複数の層に委任する可能性がある。もしデータが信用証明記述のために使用された場合には、１つのエンティティから別のエンティティへデータを転送するそれぞれのレベルにおいて、データの意味が検査され、および計算される必要がある。その一方で、もし信用証明記述が論理フォーマットで表現された場合には、分散型のアクセス制御システムは、信用証明記述の表現が固有の意味を明らかにする時ので、滑らかに、そして無限にスケールすることができる。
【００２３】
本発明の典型的な実施形態において、例えば使用ポリシー記述および信用証明記述のような記述は、多くのアクセス制御言語で広く使用される３つの概念を使用する。第１の概念は、ポリシー記述の変数の使用である。例えば、リソース１０６のための使用ポリシー１０８は、「Ｐａｒａｍａは、Ｘを読むことができる」と記述する可能性があり、ここで、変数「Ｘ」は一般的に定量化された変数、すなわち変数Ｘはどんな値でもとることができることを示す。ポリシー記述は、変数Ｘがとることができる値を制限する制約を具備する可能性もある。例えば、使用ポリシー１０８は、「Ｐａｒａｍａは、Ｘがテキストファイルである、Ｘを読むことができる。」と記述する可能性がある。本発明の記述により利用される第２の概念は、ポリシー記述が誰がリソースにアクセスするための信用証明記述あるいはアサーションを証明できるかを特定する権能を有するということである。例えば、使用ポリシー１０８は、「ａｃｍｅ．ｃｏｍは、リソース１０６へのアクセスを許可するアサーションを行うができる。」と記述する可能性がある。本発明の典型的な実施形態における記述は、記述が他のアサーションに基づくアサーションを含むことを許容する第３の概念を使用する。例えば、使用ポリシー１０８は、「Ｐａｒａｍａは、そのＰａｒａｍａが企業Ａに従い、企業Ａの従業員であるならば、リソース１０６にアクセスすることができる。」と記述する可能性がある。
【００２４】
本発明の典型的な実施形態において、上記クライアント１０４および／または１以上の補助クライアント１１２は、関連する信用証明記述を所有しうる。あるいは、信用証明記述は、他のどこかに記録されうる。次いで、信用証明記述への参照のみが、サーバ１０２に送信される。
【００２５】
図２〜５は、典型的な使用ポリシー記述２００、信用証明記述３００、追加のアサーション４００、および使用ポリシー記述２００と信用証明記述３００と追加のアサーション４００を統合した統合記述５００を示す。図２〜５において使用される典型的な記述は、上述の３つの概念を表現し、あるいは組み合わせる。図２〜５は、図１を参照して記載される。これらの典型的な記述において使用される実施形態は、システム１００の典型的なエンティティを反映する。例えば、「Ｃｏｎｔｏｓａ．ｃｏｍ」はサーバ１０２である可能性があり、「Ｐａｒａｍａ」は、「Ｃｏｎｔｏｓａ．ｃｏｍ」上のウェブサービスにアクセスすることを要求するクライアント１０４である可能性があり、「Ｆａｂｒｉｋａｍ．ｃｏｍ」と「Ｆａｂｒｉｋａｍ．ｃｏｍ」のパートナーである「Ａｃｍｅ．ｃｏｍ」は、補助クライアント１１２である可能性がある。
【００２６】
図２は、使用ポリシー１０８のような使用ポリシーにより供給されうる１つの典型的な使用ポリシー記述２００を示す。使用ポリシー記述２００は、「Ｃｏｎｔｏｓａ．ｃｏｍ」が、「ＸがＦａｂｒｉｋａｍ．ｃｏｍにより許可されるゴールドスターメンバーであるならば、ＸはＣｏｎｔｏｓａ．ｃｏｍウェブサービスにアクセスすることができる。」と言うことを記述する。Ｘが「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスにアクセスすることを要求するクライアントであると仮定する。使用ポリシー記述２００に従い、もしＸが「Ｆａｂｒｉｋａｍ．ｃｏｍ」により許可されるゴールドスターメンバーであることを証明することができれば、次いでＸは「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスにアクセスすることができる。
【００２７】
システム１００のような分散型のアクセス制御システムにおいて、分散のレベルが増加するとき、サーバ１０２はクライアント１０４を知らない可能性がある。サーバ１０２は、クライアントについての記述を作成するために、他のエンティティに頼る可能性がある。それゆえ、サーバ１０２がクライアント１０４から受信する信用証明記述は、クライアント１０４および／または１以上の補助クライアント１１２を含むいくつかのエンティティにより供給される信用証明記述を備える可能性がある。図３は、サーバ「Ｃｏｎｔｏｓａ．ｃｏｍ」がクライアント「Ｐａｒａｍａ」および／または補助クライアント「Ｆａｂｒｉｋａｍ．ｃｏｍ」および「Ａｃｍｅ．ｃｏｍ」から受信する可能性のある１組の信用証明記述３００を示す。図３に示すように、信用証明記述３００Ａは、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が「もしＸがＦａｂｒｉｋａｍ．ｃｏｍのパートナーであるならば、Ｘはゴールドスターメンバー証明書を発行することができる。」と言うことを記述する。この記述は、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が、「Ｆａｂｒｉｋａｍ．ｃｏｍ」のパートナーが誰であるかを指定することも暗示している。信用証明記述３００Ｂは、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が「Ａｃｍｅ．ｃｏｍは、Ｆａｂｒｉｋａｍ．ｃｏｍパートナーである。」と言うことを記述する。信用証明記述３００Ｃは、「Ａｃｍｅ．ｃｏｍ」が「Ｐａｒａｍａは、ゴールドスターメンバーである。」と言うことを記述する。
【００２８】
ここで、「Ｐａｒａｍａ」が「Ｃｏｎｔｏｓａ．ｃｏｍ」にアクセス要求し、信用証明記述３００を提示すると仮定する。従来通りに、「Ｃｏｎｔｏｓａ．ｃｏｍ」のリソースマネージャは、「Ｐａｒａｍａ」が要求されたアクセスを有するべきか、有してはならないかの証明を計算するために使用ポリシー記述２００と信用証明記述３００を通して機能する必要がある。上記リソースマネージャは、どの信用証明記述が使用ポリシーに適用できるかを決定するために、信用証明記述のそれぞれを通して見る。上記信用証明記述は、リソースマネージャが決定をするのを可能にする転送論理を供給する。もしリソースマネージャが発生する可能性のある多くの信用証明記述を受信するならば、例えば補助クライアントの多くの層が「Ｐａｒａｍａ」への信用証明記述の供給に関わるとき、リソースマネージャにより実行される計算処理は、任意に難しくなる可能性がある。多くの信用証明記述が存在するとき、サーバが証明を促すように信用証明記述を配置することは困難になる。たぶん、計算処理は、決して終わらない。サーバ１０２は限りない検索スペースを潜在的に必要とする可能性があり、実際に、要求されたアクセスを許可するべきかどうか判明するのにどれくらい時間がかかるかについて、演繹的に知ることはできない。
【００２９】
本発明の一態様は、関連する信用証明記述を使用して証明を構築する方法を指示する追加のアサーションを提供することによりこの問題に対処する。例えば、アサーションは使用ポリシー記述において値を変数に割り当てることができる。アサーションは、またユーザポリシー記述において１つの必須の節を指示することもできる。図４は、典型的なクライアント「Ｐａｒａｍａ」が典型的なサーバ「Ｃｏｎｔｏｓａ．ｃｏｍ」に供給する可能性のある典型的な追加のアサーション４００を示す。図４に示すように、アサーション４００Ａは、「記述＃１においてＸをＰａｒａｍａと入れ替えなさい」と記述する。アサーション４００Ｂは、「記述＃２においてＸをＡｃｍｅ．ｃｏｍと入れ替えなさい」と記述する。アサーション４００Ｃは、「記述＃６を満足するために、記述＃３を使用しなさい」と記述する。アサーション４００Ｄは、「記述＃７において記述＃４を正しいと判定しなさい」と記述する。アサーション４００Ｅは、「記述＃５を満足するために、記述＃８を使用しなさい」と記述する。
【００３０】
追加のアサーション４００は、証明に到達するために信用証明記述３００をまとめる方法を「Ｃｏｎｔｏｓａ．ｃｏｍ」のリソースマネージャに通知する。その結果、「Ｐａｒａｍａ」が信用証明記述３００のために可能な結果のすべての種類を検索することにより「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスにアクセスできるかどうか立証するための潜在的に未決定な量の仕事に向かう代わりに、「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスのリソースマネージャは、ただ明白な追加のアサーション４００の指示従う必要があるだけである。追加のアサーションは、このように本発明が証明に到達するための使用ポリシーと信用証明記述を処理する組織的で効率的な方法を提供することを可能にする。
【００３１】
図５は、ユーザポリシー記述２００と信用証明の統合記述３００上の追加のアサーション３００における指示を実行する「Ｃｏｎｔｏｓａ．ｃｏｍ」のリソースマネージャから生じた統合記述５００を示す。図５に示すように、統合記述５００Ａは、「Ｃｏｎｔｏｓａ．ｃｏｍ」が「ＰａｒａｍａがＦａｂｒｉｋａｍ．ｃｏｍ．により許可されるゴールドスターメンバーであるならば、Ｐａｒａｍａはリソースにアクセスすることができる」と言うことを記述する。統合記述５００Ｂは、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が「Ａｃｍｅ．ｃｏｍがＦａｂｒｉｋａｍ．ｃｏｍ．によるＦａｂｒｉｋａｍ．ｃｏｍのパートナーであるならば、Ａｃｍｅ．ｃｏｍはゴールドスターメンバー証明書を発行することができる」と言うことを記述する。統合記述５００Ｃは、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が「Ａｃｍｅ．ｃｏｍは、ゴールドスターメンバー証明書を発行することができる」と言うことを記述する。統合記述５００Ｄは、「Ｆａｂｒｉｋａｍ．ｃｏｍ」が「Ｐａｒａｍａは、ゴールドスターメンバーである」と言うことを記述する。統合記述５００Ｅは、このように「Ｃｏｎｔｏｓａ．ｃｏｍ」が「Ｐａｒａｍａは、Ｃｏｎｔｏｓａ．ｃｏｍウェブサービスにアクセスすることができる。」と言うことと結論を下す。
【００３２】
それゆえ、典型的なサーバ「Ｃｏｎｔｏｓａ．ｃｏｍ」のためのリソースマネージャは、「Ｃｏｎｔｏｓａ．ｃｏｍ」が「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスへの「Ｐａｒａｍａ」のアクセスを暗黙のうちに認証したことを直接的な方法で結論付けるために、追加のアサーション４００を使用することができる。追加のアサーション４００のそれぞれに適用するとき、「Ｃｏｎｔｏｓａ．ｃｏｍ」がチェックする必要とすることは、このアサーションを適用することが可能であるということだけである。言い換えると、アサーションを提示するエンティティは、使用ポリシー記述２００と信用証明記述３００により暗示されない何かを「Ｃｏｎｔｏｓａ．ｃｏｍ」にさせることができない。
【００３３】
追加のアサーションは、サーバかクライアントの何れかに提供されることができる。クライアントあるいは補助クライアントからの追加のアサーションを受信するとすぐに、サーバのリソースマネージャは、証明を構築するために追加のアサーションを使用し、次いで証明を計算する代わりに証明を検査する。本発明の典型的な実施形態において、サーバが一組の信用証明記述と追加のアサーションを受信し、読み通すとすぐに、サーバは要求されたアクセス要求を許可するべきかどうかを把握することができる。
【００３４】
あるいは、サーバはクライアントに追加のアサーションを供給することができる。クライアントからアクセス要求を受信するとすぐに、サーバは提案で応じることができる。上記提案は、要求されたアクセスを獲得するためにサーバのために証明を構築する方法をクライアントに指示する追加のアサーションを含む可能性がある。このように、サーバは、クライアントから必要とされた証明を受信する。サーバがする必要があることは、証明が要求されたリソースと関連する使用ポリシーに従い有効な結論を提供するかどうか決定するために、証明を検査することだけである。
【００３５】
本発明の典型的な実施形態において、サーバはクライアントにより供給される証明を信頼する必要はない。サーバは、信用証明記述と追加のアサーションの正確さをチェックすることができる。これは、サーバのリソースマネージャが証明でないものを証明であるとだまされて信じることはできないので、信用証明記述と追加のアサーションが信頼されたエンティティから来る必要がないことを意味する。アサーションが実施をリソースマネージャに頼む段階は、使用ポリシーにおける変数の置き換えのような既に使用ポリシーにより暗示される動作しか、作成するべきではない。それゆえ、クライアントは間違いの証明に到達するためにサーバを誘導するために、サーバにうそをつくことができない。もし供給される追加のアサーションが間違いならば、サーバは証明を発見することができない。追加のアサーションは、サーバが証明を作成するのを援助できるだけであり、偽の証明を作成するようにサーバをだますことはできない。もし追加のアサーションが間違いならば、サーバは証明に到達することができない。これは、迷路を進むことに類似している。証明計算は、困難でありうる迷路から経路を発見するようである。反対に、与えられた経路が正しい経路であるかどうか確認することは、より簡単である。もし与えられた経路が迷路の出口に通じるならば、与えられた経路は正しい経路である。追加のアサーションは、「与えられた経路」に等しい。もしそれらがサーバを証明に到達させられるならば、与えられた追加のアサーションの一組は正しく、もしサーバがそれらを使用して証明に到達することができなければ、与えられた追加のアサーションは間違いであり、無視される。
【００３６】
本発明の典型的な実施形態において、サーバあるいはクライアントにより提供される追加のアサーションは、要求されたアクセスを許可するべきかどうかを決定するために必要な全ての証明の代わりに、一部分の証明のみを作成する可能性がある。例えば、サーバは何れのエンティティにもその使用ポリシーを明らかにしないことを決定する可能性がある。従って、サーバは、クライアントが必要に応じて隠されたユーザポリシーによりクライアントの識別を証明することを可能とする追加のアサーションを供給するのみである。例えば、「Ｃｏｎｔｏｓａ．ｃｏｍ」は使用ポリシー記述２００を明らかにしないことを決定する可能性がある。それゆえ、「Ｃｏｎｔｏｓａ．ｃｏｍ」は、使用ポリシー記述２００についての知識を有さないクライアントで、それが「Ｆａｂｒｉｋａｍ．ｃｏｍ」により認証されるゴールドスターメンバーであることを証明することを典型的なクライアント「Ｐａｒａｍａ」に要求する。あるいは、サーバは、定理証明で上述されたような終りのない計算の危険となりやすい従来の定理証明器と関連する。そのような危険を軽減するために、追加のアサーションは、証明の「難しい」部分を構築するために使用されることができ、従来の定理証明の単純で、安全な変形をマイナーな隙間を満たすために残したままにしておく。このようなアプローチにおいて、証明の安全で表現力豊かな計算を提供するために、定理の検証と証明は一緒に働く。
【００３７】
本発明の典型的な実施形態において、図１の中でも示されるサーバ１０２は、監査コンポーネント１１６を含む。監査コンポーネント１１６は、要求されたアクセスを許可するか、許可しないかについてのリソースマネージャの論理処理を記録して、保存する。監査コンポーネント１１６により記録される情報は、リソースマネージャが結論に到達するために処理する論理処理および／または様々な記述を識別する可能性がある。それゆえ、監査情報は、誰がリソースにアクセスしたかどうかだけでなく、なぜアクセスが許可されたかについても明らかにする可能性がある。監査情報は、アクセス制御システムがどのように動作するか、誰がリソースを要求したか、なぜ要求が許可されたか、およびどのように要求が許可されたかを分析することに役立つ。例えば、監査情報は、「Ｐａｒａｍａ」が「Ｃｏｎｔｏｓａ．ｃｏｍ」ウェブサービスの利用を要求したことと、「Ｐａｒａｍａ」が「Ｆａｂｒｉｋａｍ．ｃｏｍ」により認証されるゴールドスターメンバーであることが証明されたのでアクセスが許可されたこととを提供する可能性がある。本発明の典型的な実施形態において、監査情報は、使用された追加のアサーションのセットを含む。
【００３８】
図６は、例えばサーバ１０２のようなサーバがアクセス要求を処理し、アクセス要求を許可するべきかどうかの決定に到達する典型的なルーチン６００を示す。具体的には、ルーチン６００は、サーバがアクセス要求を受信したかどうかを決定することにより開始される。決定ブロック６０２を参照する。もしサーバがアクセス要求を受信しない場合には、ルーチン６００は更に進まない。もしサーバがアクセス要求を受信した場合には、ルーチン６００は、クライアントに要求されたアクセスが許可される前に、サーバがアクセス要求を送信するクライアントに証明することを望む提案を応答することに進む。ブロック６０４を参照する。提案は、要求されたリソースのための使用ポリシーを識別する可能性がある。提案は、これらの使用ポリシーにおいて複数の使用ポリシー記述といくつかの変数の間の関係を識別する証明構築を含む可能性がある。提案は、クライアントに証明構築を具現化する方法を指示する追加のアサーションを更に具備する可能性がある。例えば、追加のアサーションは、クライアントに、使用ポリシー記述において状態を満足する方法および／または使用ポリシー記述において変数のための特定の値を発見する方法について提案する可能性がある。
【００３９】
次いで、ルーチン６００は、提案に応答してクライアントから証明を受信するために待機する。ルーチン６００は、そのような証明を受信したかどうかを決定する。決定ブロック６０６を参照する。もし決定ブロック６０６の答えが「ＮＯ」である場合には、ルーチン６００はそれ以上進まない。もしルーチン６００がクライアントから証明を受信する場合には、ルーチン６００は証明の検査に進む。ブロック６０８を参照する。受信された証明の検査において、ルーチン６００は、証明が正しいかどうか決定する。決定ブロック６１０を参照する。正しい証明は、クライアントが要求されたリソースにアクセスする権利があることと、証明が真実の記述を構成することとを実証する。もし決定ブロック６１０の答えが、受信された証明が正しいことを意味する「ＹＥＳ」である場合には、ルーチン６００は、アクセス要求の許可に進む。ブロック６１４を参照する。一方、決定ブロック６１０の答えが、受信された証明が誤っていることを意味する「ＮＯ」である場合には、ルーチン６００は、アクセス要求を拒否する。ブロック６１２を参照する。次いで、ルーチン６００は終了する。
【００４０】
図７は、クライアントがサーバのリソースにアクセスするためのサーバからの許可を求める典型的なルーチン７００を示す。具体的には、ルーチン７００は、クライアントがサーバのリソースにアクセスしたいかどうかを決定することにより開始される。決定ブロック７０２を参照する。もし答えが「ＮＯ」である場合には、ルーチン７００はさらに進まない。もしクライアントがサーバのリソースにアクセスしたい場合には、ルーチン７００はアクセス要求をサーバに送信する。ブロック７０４を参照する。次いで、ルーチン７００は、サーバから提案を受信するために待機する。ルーチン７００は、提案が受信されたどうかを決定する。決定ブロック７０６を参照する。もし答えが「ＮＯ」である場合には、ルーチン７００はさらに進まない。もしクライアントがサーバから提案を受信する場合には、ルーチン７００は提案に従い証明の構築に進む。ブロック７０８を参照する。証明は、提案において特定される必要条件を満足するデータと論理段階を含む。もし提案が証明を構築する方法を指示する追加のアサーションを含む場合には、証明は追加のアサーションに従い構築される。もし受信された提案が追加のアサーションを含まない場合には、構築された証明はクライアントが誰であるかを識別する信用証明記述を含む。構築された証明は、サーバにアクセス要求を許可するべきかどうかの決定に到達するために供給された信用証明記述を使用する方法について指示する追加のアサーションを含む可能性がある。次いで、ルーチン７００は、構築された証明をサーバに送信する。ブロック７１０を参照する。ルーチン７００は終了する。本発明の典型的な実施形態において、もしクライアントがサーバがアクセス要求を決定するために何を必要とするかを前もって知っている場合には、クライアントは、アクセス要求をサーバに送信するときに必要な信用証明記述と追加のアサーションも供給する。その結果、サーバは提案を送信する必要がない。
【００４１】
本発明の好ましい実施形態が示され、記述される一方で、様々な変化が本発明の精神および範囲から逸脱することなくその中でなされることができることはいうまでもない。
【図面の簡単な説明】
【００４２】
【図１】本発明の態様を実施するための例示的なシステムを示すブロック図である。
【図２】典型的な使用ポリシー記述を示すテキストの図である。
【図３】クライアントにより供給される典型的な信用証明記述を示すテキストの図である。
【図４】アクセス要求の証明を援助する典型的な追加のアサーションを示すテキストの図である。
【図５】図２において示された使用ポリシー記述と、図３において示された信用証明記述と、図４において示された追加のアサーションとを統合する結果である典型的な統合記述を示すテキストの図である。
【図６】サーバがアクセス要求を処理するための典型的なルーチンを示すフローチャートである。
【図７】クライアントがサーバ上でリソースにアクセスする許可を求めるための典型的なルーチンを示すフローチャートである。
【特許請求の範囲】
【請求項１】
変数および／または必須の節を含む論理形式を使用するアクセス制御言語を採用するシステムであって、
少なくとも１つのリソースおよび前記リソースにアクセスするための関連する使用ポリシーとリンク付けされたサーバコンポーネントと、
前記リソースへのアクセスを要求するクライアントコンポーネントと、
前記要求されたアクセスが許可されるべきであることを実証する証明を構築する方法を指示する１以上のアサーションと
を備えることを特徴とするシステム。
【請求項２】
前記クライアントコンポーネントは、サーバコンポーネントにとって信用されたエンティティではないことを特徴とする請求項１に記載のシステム。
【請求項３】
少なくとも１つの補助クライアントを更に備え、前記補助クライアントは前記クライアントコンポーネントのために情報を供給する任意のエンティティであることを特徴とする請求項１に記載のシステム。
【請求項４】
前記証明は、全ての必要な情報が受信された後でのみ構築されることを特徴とする請求項３記載のシステム。
【請求項５】
前記１以上のアサーションは、値を変数に置き換えることを指示することを特徴とする請求項１記載のシステム。
【請求項６】
前記１以上のアサーションは、少なくとも１つの必須の節を証明することを指示することを特徴とする請求項１記載のシステム。
【請求項７】
前記１以上のアサーションは、必須の節を再帰的に証明することを指示することを特徴とする請求項１記載のシステム。
【請求項８】
前記１以上のアサーションは、前記要求されたアクセスが許可されるべきであることを実証する証明の一部のみを構築する方法を指示することを特徴とする請求項１記載のシステム。
【請求項９】
前記１以上のアサーションは、前記要求されたアクセスが許可されるべきであることを実証する証明を構築するクライアントコンポーネントにより使用されることを特徴とする請求項１記載のシステム。
【請求項１０】
前記１以上のアサーションは、前記要求されたアクセスが許可されるべきであることを実証する証明を構築するサーバコンポーネントにより使用されることを特徴とする請求項１記載のシステム。
【請求項１１】
前記サーバコンポーネントは、前記要求されたアクセスがなぜ許可され、あるいは拒否されるのかを記録する監査コンポーネントをさらに備えることを特徴とする請求項１記載のシステム。
【請求項１２】
前記監査コンポーネントは、前記証明を記録することを特徴とする請求項１１記載のシステム。
【請求項１３】
前記サーバコンポーネントは、前記クライアントコンポーネントと少なくとも１つの補助クライアントからなるグループから選択された供給者から前記クライアントコンポーネントに関する少なくとも１つの信用証明記述を受信することを特徴とする請求項１記載のシステム。
【請求項１４】
前記信用証明記述は前記供給者以外の位置で記録され、前記供給者は前記信用証明記述を前記サーバコンポーネントに供給する間、前記信用証明記述を参照することを特徴とする請求項１記載のシステム。
【請求項１５】
使用ポリシーに関連付けされたリソースと関連するエンティティ（「サーバ」）と、前記リソースにアクセスすることを要求するエンティティ（「クライアント」）との間で通信するコンピュータ実行方法であって、
前記サーバが前記クライアントから前記リソースへのアクセス要求を受信するとすぐに、前記サーバは、前記クライアントが前記アクセス要求を許可されるべきであることを実証する証明を構築するのに前記クライアントの援助となる追加のアサーションを含む提案を前記クライアントに送信することと、
前記証明を受信するとすぐに前記サーバが前記証明を検査することと、
もし前記証明が正しければ前記サーバが前記アクセス要求を許可することと、
もし前記証明が正しくなければ前記サーバが前記アクセス要求を拒否することと
を備えることを特徴とするコンピュータ実行方法。
【請求項１６】
前記サーバから前記提案を受信するとすぐに、前記クライアントが前記証明を構築するために前記提案に含まれる追加のアサーションを使用する段階をさらに備えることを特徴とする請求項１５記載のコンピュータ実行方法。
【請求項１７】
使用ポリシーに関連付けされたリソースと関連するエンティティ（「サーバ」）と、前記リソースにアクセスすることを要求するエンティテイ（「クライアント」）との間で通信するコンピュータ実行方法であって、
前記クライアントが信用証明記述および１以上の追加のアサーションに従って前記サーバへアクセス要求を送信する段階を備え、１以上の追加のアサーションが前記要求されたアクセスが許可されるべきであることを実証する証明を構築する方法を前記サーバに指示することを特徴とするコンピュータ実行方法。
【請求項１８】
前記クライアントあるいは前記サーバ以外のエンティティが、いくつかの前記信用証明記述および前記１以上の追加のアサーションを供給する段階を備えることを特徴とする請求項１７記載のコンピュータ実行方法。
【請求項１】
変数および／または必須の節を含む論理形式を使用するアクセス制御言語を採用するシステムであって、
少なくとも１つのリソースおよび前記リソースにアクセスするための関連する使用ポリシーとリンク付けされたサーバコンポーネントと、
前記リソースへのアクセスを要求するクライアントコンポーネントと、
前記要求されたアクセスが許可されるべきであることを実証する証明を構築する方法を指示する１以上のアサーションと
を備えることを特徴とするシステム。
【請求項２】
前記クライアントコンポーネントは、サーバコンポーネントにとって信用されたエンティティではないことを特徴とする請求項１に記載のシステム。
【請求項３】
少なくとも１つの補助クライアントを更に備え、前記補助クライアントは前記クライアントコンポーネントのために情報を供給する任意のエンティティであることを特徴とする請求項１に記載のシステム。
【請求項４】
前記証明は、全ての必要な情報が受信された後でのみ構築されることを特徴とする請求項３記載のシステム。
【請求項５】
前記１以上のアサーションは、値を変数に置き換えることを指示することを特徴とする請求項１記載のシステム。
【請求項６】
前記１以上のアサーションは、少なくとも１つの必須の節を証明することを指示することを特徴とする請求項１記載のシステム。
【請求項７】
前記１以上のアサーションは、必須の節を再帰的に証明することを指示することを特徴とする請求項１記載のシステム。
【請求項８】
前記１以上のアサーションは、前記要求されたアクセスが許可されるべきであることを実証する証明の一部のみを構築する方法を指示することを特徴とする請求項１記載のシステム。
【請求項９】
前記１以上のアサーションは、前記要求されたアクセスが許可されるべきであることを実証する証明を構築するクライアントコンポーネントにより使用されることを特徴とする請求項１記載のシステム。
【請求項１０】
前記１以上のアサーションは、前記要求されたアクセスが許可されるべきであることを実証する証明を構築するサーバコンポーネントにより使用されることを特徴とする請求項１記載のシステム。
【請求項１１】
前記サーバコンポーネントは、前記要求されたアクセスがなぜ許可され、あるいは拒否されるのかを記録する監査コンポーネントをさらに備えることを特徴とする請求項１記載のシステム。
【請求項１２】
前記監査コンポーネントは、前記証明を記録することを特徴とする請求項１１記載のシステム。
【請求項１３】
前記サーバコンポーネントは、前記クライアントコンポーネントと少なくとも１つの補助クライアントからなるグループから選択された供給者から前記クライアントコンポーネントに関する少なくとも１つの信用証明記述を受信することを特徴とする請求項１記載のシステム。
【請求項１４】
前記信用証明記述は前記供給者以外の位置で記録され、前記供給者は前記信用証明記述を前記サーバコンポーネントに供給する間、前記信用証明記述を参照することを特徴とする請求項１記載のシステム。
【請求項１５】
使用ポリシーに関連付けされたリソースと関連するエンティティ（「サーバ」）と、前記リソースにアクセスすることを要求するエンティティ（「クライアント」）との間で通信するコンピュータ実行方法であって、
前記サーバが前記クライアントから前記リソースへのアクセス要求を受信するとすぐに、前記サーバは、前記クライアントが前記アクセス要求を許可されるべきであることを実証する証明を構築するのに前記クライアントの援助となる追加のアサーションを含む提案を前記クライアントに送信することと、
前記証明を受信するとすぐに前記サーバが前記証明を検査することと、
もし前記証明が正しければ前記サーバが前記アクセス要求を許可することと、
もし前記証明が正しくなければ前記サーバが前記アクセス要求を拒否することと
を備えることを特徴とするコンピュータ実行方法。
【請求項１６】
前記サーバから前記提案を受信するとすぐに、前記クライアントが前記証明を構築するために前記提案に含まれる追加のアサーションを使用する段階をさらに備えることを特徴とする請求項１５記載のコンピュータ実行方法。
【請求項１７】
使用ポリシーに関連付けされたリソースと関連するエンティティ（「サーバ」）と、前記リソースにアクセスすることを要求するエンティテイ（「クライアント」）との間で通信するコンピュータ実行方法であって、
前記クライアントが信用証明記述および１以上の追加のアサーションに従って前記サーバへアクセス要求を送信する段階を備え、１以上の追加のアサーションが前記要求されたアクセスが許可されるべきであることを実証する証明を構築する方法を前記サーバに指示することを特徴とするコンピュータ実行方法。
【請求項１８】
前記クライアントあるいは前記サーバ以外のエンティティが、いくつかの前記信用証明記述および前記１以上の追加のアサーションを供給する段階を備えることを特徴とする請求項１７記載のコンピュータ実行方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２００８−５３８６４１（Ｐ２００８−５３８６４１Ａ）
【公表日】平成２０年１０月３０日（２００８．１０．３０）
【国際特許分類】
【出願番号】特願２００８−５０７９１９（Ｐ２００８−５０７９１９）
【出願日】平成１８年４月２０日（２００６．４．２０）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０１５１１６
【国際公開番号】ＷＯ２００６／１１６１０３
【国際公開日】平成１８年１１月２日（２００６．１１．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成２０年１０月３０日（２００８．１０．３０）
【国際特許分類】
【出願日】平成１８年４月２０日（２００６．４．２０）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０１５１１６
【国際公開番号】ＷＯ２００６／１１６１０３
【国際公開日】平成１８年１１月２日（２００６．１１．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]