(57)【要約】  例示的な実施形態において、２つに分岐したセキュリティ・スキームが、否定の使用を許さない第１のレベルと、否定の使用を許す第２のレベルとを有する。別の例示的な実施形態において、許可照会テーブルが、それぞれのリソース特有のオペレーションを、関連するそれぞれの許可照会にマップする。さらに別の例示的な実施形態において、許可照会は、否定を有することを許されるが、個々のアサーションは、否定を有することを許されない。
2010503123.tif 000002
【特許請求の範囲】
【請求項１】
許可照会テーブルを含むセキュリティ・スキームを含むシステムであって、
前記許可照会テーブルは、各フィールドが、リソース特有のオペレーションを関連する許可照会にマッピングしている複数のフィールドを含むことを特徴とするシステム。
【請求項２】
前記関連する許可照会は、１つまたは複数の所定の空のスロットを有する関連する許可照会テンプレートを含むことを特徴とする請求項１に記載のシステム。
【請求項３】
前記セキュリティ・スキームは、前記リソース特有のオペレーションに関係する実際の主体または実際のリソースのいずれかを前記１つまたは複数の所定の空のスロットに代入することによって、前記許可照会テンプレートを前記許可照会に変換することを特徴とする請求項２に記載のシステム。
【請求項４】
前記セキュリティ・スキームは、複数のアサーションのうちの少なくとも１つが前記リソース特有のオペレーションに関係する複数のアサーションを有するアサーション・コンテクストと併せて、前記関連する許可照会を評価し、前記セキュリティ・スキームは、否定要素を有するアサーションをまったく許さないシンタックス・バリデータをさらに含むことを特徴とする請求項１に記載のシステム。
【請求項５】
前記許可照会テーブルは、否定演算子を含む許可照会を有する少なくとも１つのフィールドを含むことを特徴とする請求項４に記載のシステム。
【請求項６】
前記セキュリティ・スキームは、
前記関連する許可照会と、
少なくとも１つが前記リソース特有のオペレーションに関係する複数のアサーションを含む、該複数のアサーションを有するアサーション・コンテクストと
を許可エンジンに与え、
前記許可エンジンは、前記アサーション・コンテクストと併せて前記関連する許可照会を評価して、許可判定を行う
ことを特徴とする請求項１に記載のシステム。
【請求項７】
前記関連する許可照会は、複数のアサートされる事実を含み、
前記許可エンジンは、前記アサーション・コンテクストから推定された有効なアサーションを、前記関連する許可照会の前記アサートされる事実とマッチングしようと試みる
ことを特徴とする請求項６に記載のシステム。
【請求項８】
前記関連する許可照会の個々のアサートされる事実は、マッチングする有効なアサーションが、前記アサーション・コンテクストから推定されることが可能である場合、「ＴＲＵＥ」ブール・ステータスで事実上、置き換えられることが可能であり、マッチングする有効なアサーションが、前記アサーション・コンテクストから推定されることが可能でない場合、「ＦＡＬＳＥ」ブール・ステータスで事実上、置き換えられることが可能であることを特徴とする請求項７に記載のシステム。
【請求項９】
個別のアサートされる事実が、「ＴＲＵＥ」ブール・ステータスで事実上、置き換えられることが可能である場合、前記許可エンジンは、前記個別のアサートされる事実をＴＲＵＥにすることができる変数置換のセットを生成することを特徴とする請求項８に記載のシステム。
【請求項１０】
セキュリティ・スキームにおいて、許可照会テーブルを使用する方法であって、
リソース特有のオペレーションを前記許可照会テーブルに与えること、および
前記許可照会テーブルを使用して、前記リソース特有のオペレーションに関連する許可照会を確認すること
を含むことを特徴とする方法。
【請求項１１】
識別されたリソースに、主体に代行してアクセスする要求をリソース・ガード・モジュールにおいて受け取ること、および
前記リソース・ガード・モジュールにおいて、前記要求を前記リソース特有のオペレーションに変換すること
をさらに含み、
前記与えること、および前記確認することは、セキュリティ・ポリシー・モジュールによって行われることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記確認される許可照会は、１つまたは複数の所定の空のスロットを有する許可照会テンプレートを含み、さらに、
前記リソース・ガード・モジュールにおいて、前記識別されたリソースおよび前記主体を前記１つまたは複数の所定の空のスロットに代入することによって、前記許可照会テンプレートを前記確認される許可照会に変換すること
をさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
（ｉ）前記リソース特有のオペレーションから導き出されたアサーション・コンテクストと、（ｉｉ）前記確認される許可照会と、を評価アルゴリズムに適用すること、
前記アサーション・コンテクストの有効な・アサーションを、前記確認される許可照会のアサートされる事実とマッチングすること、
前記マッチングすることに応答して、前記確認される許可照会に対してＴＲＵＥ／ＦＡＬＳＥ置き換えプロセスを実行すること、
前記実行することの後、前記確認された許可照会を論理的に評価すること、
前記確認される許可照会が、論理的にＴＲＵＥに評価された場合、前記リソース特有のオペレーションを許可することを決定すること、および
前記確認された許可照会が、論理的にＦＡＬＳＥに評価された場合、前記リソース特有のオペレーションを拒否することを決定すること
をさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１４】
第１のレベルと、第２のレベルとを有する２つに分岐したセキュリティ・スキームを実装するデバイスであって、
前記第１のレベルは、否定の使用を許さず、前記第２のレベルは、否定の使用を許すことを特徴とするデバイス。
【請求項１５】
前記第１のレベルは、アサーション・レベルを含むことを特徴とする請求項１４に記載のデバイス。
【請求項１６】
前記アサーション・レベルには、トークン・アサーションおよびポリシー・アサーションが取り込まれることを特徴とする請求項１５に記載のデバイス。
【請求項１７】
前記２つに分岐したセキュリティ・スキームは、否定を含むアサーションをまったく許さないシンタックス・バリデータを含むことを特徴とする請求項１５に記載のデバイス。
【請求項１８】
前記第２のレベルは、照会レベルを含むことを特徴とする請求項１４に記載のデバイス。
【請求項１９】
前記照会レベルには、少なくともアサートされる事実および論理演算子から形成された許可照会が取り込まれ、前記論理演算子は、ＡＮＤ、ＯＲ、およびＮＯＴを含み、各許可照会は、リソース特有のオペレーションに関連付けられることを特徴とする請求項１８に記載のデバイス。
【請求項２０】
前記第１のレベルは、アサーションを取り込むアサーション・レベルを含み、前記第２のレベルは、少なくともアサートされる事実から形成される許可照会を取り込む照会レベルを含み、前記２つに分岐したセキュリティ・スキームは、前記アサーション・レベルからの有効なアサーションを、ある特定の許可照会の１つまたは複数のアサートされる事実とマッチングしようと試みることによって、該特定の許可照会を評価することを特徴とする請求項１４に記載のデバイス。
【発明の詳細な説明】
【背景技術】
【０００１】
コンピュータ、およびその他の電子デバイスが、人々の職業生活および個人生活に浸透している。職業環境において、人々は、プロジェクト共同作業中に機密情報を交換し、共有する。個人環境において、人々は、電子商取引、および個人情報の伝送に関与する。これら、および他の多数の事例において、電子セキュリティが、重要であると考えられる。
【０００２】
電子セキュリティ・パラダイムは、職業情報を機密に保ち、個人情報をプライベート（非公開）に保つことができる。電子セキュリティ・パラダイムには、何らかのレベルの暗号化、および／またはウイルス、ワーム、およびスパイ・ウェアなどのマルウェア（malware）からの保護を必要とする可能性がある。情報の暗号化と、マルウェアからの保護はともに、これまでに、特にここ数年、大きな注目を集めてきている。
【０００３】
しかし、情報へのアクセスを制御することも、電子情報の安全を確保する同等に重要な側面である。このことは、電子情報の共有および／または転送から利益が引き出されるシナリオに関して特に当てはまる。そのようなシナリオにおいて、ある人々は、アクセスを許可されるべきである一方で、他の人々は、排除されるべきである。
【０００４】
アクセス制御は、初期の頃の時間分割システム以来、共有されるコンピュータおよびアプリケーション・サーバの一般的な特徴である。それには、いくつかの異なるアプローチが存在し、情報へのアクセスを制御するのに使用されてきた。これらのアプローチは、共通の基礎（基盤）を、何らかのリソースへのアクセスを要求するエンティティの認証を許されるアクセスに対して許可を与える機構と組み合わせる際に、共有する。認証機構には、パスワード、ケルベロス（Kerberos）、およびｘ．５０９証明書が含まれる。これらの機構の目的は、リソースを制御するエンティティが、要求元のエンティティ（requesting entity）を、またはリソース制御エンティティが必要とする、このエンティティについての情報を、確実に識別することを可能にすることである。
【０００５】
許可の例には、ＡＣＬ（access control lists；アクセス制御リスト）、ならびにＸＡＣＭＬ（extensible Access Control Markup Language；拡張アクセス制御マークアップ言語）またはＰＥＲＭＩＳ（PrivilEge and Role Management Infrastructure）などのポリシーベースの機構が含まれる。これらの機構は、いずれのエンティティが、ファイルシステムにおけるファイル、ハードウェア・デバイス、データベース情報などの所与のリソースにアクセスすることができるかを規定する。これらの機構は、要求側についての認証された情報と、リソースへの許されるアクセスとの間のマッピングを提供することによって、この許可を実行する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
コンピュータシステムが、インターネットなどの大きなネットワークを介して、より、全世界的に接続されるようになってきたので、これらの機構は、進化するアクセス制御要件を進化させようとする場合に、多少、限界があり、柔軟性を欠くことが分かってきた。地理的に散らばったユーザおよびコンピュータリソースのシステムは、複数の管理ドメインにまたがるシステムを含め、特に、いくつかの難題をもたらし、これらの難題は、現在展開されている技術において十分に対処されていない。
【課題を解決するための手段】
【０００７】
概要  
例示的な実施形態において、分岐したセキュリティ・スキームが、否定の使用を許さない第１のレベルと、否定の使用を許す第２のレベルとを有する。別の例示的な実施形態において、許可照会（authorization query）テーブルが、それぞれのリソース特有のオペレーションを、関連するそれぞれの許可照会にマップする。さらに別の例示的な実施形態において、許可照会は、否定を有することを許されるが、個々のアサーション（assertions；表明）は、否定を有することを許されない。
【０００８】
この概要は、詳細な説明において後段でさらに説明される選定された概念を、簡略化された形態で概説するように与えられる。この概要は、主張される主題の重要な特徴、または不可欠な特徴を特定することは意図しておらず、主張される主題の範囲を確定する助けとして使用されることも意図していない。さらに、他の方法、システム、スキーム、装置、デバイス、媒体、プロシージャ、ＡＰＩ、構成、プロトコルなどの実装が、本明細書で説明される。
【０００９】
同一の符号が、すべての図面において、同様の、さらに／または対応する態様、特徴、および構成要素を指すように使用される。
【図面の簡単な説明】
【００１０】
【図１】例示的なセキュリティ・スキームが実施されることが可能である、例示的な一般的な環境を示すブロック図である。
【図２】２つのデバイスと、いくつかの例示的なセキュリティ関連の構成要素とを有する例示的なセキュリティ環境を示すブロック図である。
【図３】例示的なセキュリティ関連のデータが、セキュリティ関連の構成要素の間で交換される図２の例示的なセキュリティ環境を示すブロック図である。
【図４】本明細書で説明されるセキュリティ関連の実装のために使用されることが可能である例示的なデバイスを示すブロック図である。
【図５】一般的なセキュリティ・スキームに関する例示的なアサーション・フォーマットを示すブロック図である。
【図６】第１のレベルと、第２のレベルとを有する例示的な分岐したセキュリティ・スキームを示すブロック図である。
【図７】例示的な許可照会確認と、例示的な許可照会評価とを示す一般的なブロック図である。
【図８】リソース・アクセス要求に応答する例示的な許可照会確認を示す、より詳細なブロック図である。
【図９】アサーション・コンテクストを所与として例示的な許可照会評価を示す、より詳細なブロック図である。
【図１０】許可照会を確認し、評価するための方法の例を示す流れ図である。
【発明を実施するための形態】
【００１１】
例示的なセキュリティ環境  
図１は、例示的なセキュリティ・スキーム１００が実装されることが可能である、例示的な一般的な環境を示すブロック図である。セキュリティ・スキーム１００は、セキュリティの統合されたアプローチを表す。図示されるとおり、セキュリティ・スキーム１００は、いくつかのセキュリティ概念、すなわち、セキュリティ・トークン１００（Ａ）、セキュリティ・ポリシー１００（Ｂ）、および評価エンジン１００（Ｃ）を含む。一般に、セキュリティ・トークン１００（Ａ）とセキュリティ・ポリシー１００（Ｂ）は共同で、評価エンジン１００（Ｃ）に入力を与える。評価エンジン１００（Ｃ）は、これらの入力を受け入れ、何らかのリソースへのアクセスが許されるべきか、拒否されるべきかを示す許可出力を生成する。
【００１２】
説明される実施形態では、セキュリティ・スキーム１００は、ハードウェア、ソフトウェア、ファームウェア、これらの幾つかの組合せ、などから成ることが可能な、１つまたは複数のデバイス１０２に、オーバーレイ（overlay）され、および／または、組み込まれることが可能である。図示されるとおり、「ｄ」が何らかの整数である「ｄ」個のデバイスが、１つまたは複数のネットワーク１０４を介して互いに接続される。より具体的には、デバイス１０２（１）、デバイス１０２（２）、デバイス１０２（３）．．．デバイス１０２（ｄ）が、ネットワーク１０４を介して通信することができる。
【００１３】
各デバイス１０２は、セキュリティ・スキームの少なくとも一部分を実装することができる任意のデバイスであることが可能である。そのようなデバイスの例には、コンピュータ（例えば、クライアント・コンピュータ、サーバ・コンピュータ、パーソナル・コンピュータ、ワークステーション、デスクトップ、ラップトップ、パームトップなど）、ゲーム機（例えば、コンソール、ポータブル・ゲーム・デバイスなど）、セットトップボックス、テレビ、家庭用電子機器（例えば、ＤＶＤプレーヤ／レコーダ、カム・コーダ、ＤＶＲ（デジタル・ビデオ・レコーダ）など）、ＰＤＡ（パーソナル・デジタル・アシスタント）、移動電話機、ポータブル・メディ・アプレーヤ、以上の何らかの組合せなどが含まれるが、以上には限定されない。例示的な電子デバイスが、図４を特に参照して、本明細書の後段で説明される。
【００１４】
ネットワーク１０４が、一緒にリンクされ、及び／または互いの上に重ねられた任意の１つまたは複数のネットワークから形成されることが可能である。ネットワーク１０４の例には、インターネット、電話網、イーサネット（登録商標）、ＬＡＮ（ローカル・エリア・ネットワーク）、ＷＡＮ（ワイド・エリア・ネットワーク）、ケーブル・ネットワーク、ファイバ・ネットワーク、ＤＳＬ（デジタル加入者線）ネットワーク、セルラーネットワーク、Ｗｉ−Ｆｉ（登録商標）ネットワーク、ＷｉＭＡＸ（登録商標）ネットワーク、ＶＰＮ（仮想プライベート・ネットワーク）、これら幾つかの組合せなどが含まれるが、以上には限定されない。ネットワーク１０４は、複数のドメイン、１つまたは複数のＧｒｉｄネットワークなどを含むことが可能である。これらのネットワークのそれぞれ、またはネットワークの組合せは、任意のネットワーキング標準に従って動作することが可能である。
【００１５】
図示されるとおり、デバイス１０２（１）が、デバイス１０２（１）と対話しているユーザ１０６に対応する。デバイス１０２（２）が、デバイス１０２（２）上で実行されているサービス１０８に対応する。デバイス１０２（３）が、リソース１１０に関連付けられている。リソース１１０は、デバイス１０２（３）の一部であっても、デバイス１０２（３）とは別個であってもよい。
【００１６】
ユーザ１０６、サービス１０８、ならびに任意の所与のデバイス１０２などのマシンが、例示的なエンティティの網羅的でないリストを形成する。これらのエンティティは、時々、リソース１１０にアクセスすることを望む可能性がある。セキュリティ・スキーム１００が、適切に認証され、許可されたエンティティが、リソース１１０にアクセスすることを許す一方で、他のエンティティが、リソース１１０にアクセスするのを防止することを確実にする。
【００１７】
図２は、２つのデバイス１０２（Ａ）および１０２（Ｂ）と、いくつかの例示的なセキュリティ関連の構成要素とを有する例示的なセキュリティ環境２００を示すブロック図である。セキュリティ環境２００は、ＳＴＳ（セキュリティ・トークン・サービス）オーソリティ（authority）などのオーソリティ２０２も含む。デバイス１０２（Ａ）は、エンティティ２０８に対応する。デバイス１０２（Ｂ）は、リソース１１０に関連付けられている。セキュリティ・スキーム１００は、より複雑な環境において実装されることも可能であるものの、この比較的単純な２デバイス・セキュリティ環境２００を使用して、例示的なセキュリティ関連の構成要素が説明される。
【００１８】
図示されるとおり、デバイス１０２（Ａ）は、２つのセキュリティ関連の構成要素、すなわち、セキュリティ・トークン２０４およびアプリケーション２１０を含む。セキュリティ・トークン２０４は、１つまたは複数のアサーション２０６を含む。デバイス１０２（Ｂ）は、５つのセキュリティ関連の構成要素、すなわち、許可コンテクスト２１２（authorization context）、リソース・ガード（resource guard）２１４、監査ログ（audit log）２１６、許可エンジン２１８、およびセキュリティ・ポリシー２２０を含む。セキュリティ・ポリシー２２０は、信頼−許可ポリシー（trust and authorization policy）２２２、許可照会（authorization query）テーブル２２４、および監査ポリシー（audit policy）２２６を含む。
【００１９】
各デバイス１０２は、異なる仕方で構成さることが可能であり、それでも、セキュリティ・スキーム１００のすべて、または一部分を実装することができることが可能である。例えば、デバイス１０２（Ａ）が、複数のセキュリティ・トークン２０４および／またはアプリケーション２１０を有することが可能である。別の例として、デバイス１０２（Ｂ）が、監査ログ２１６または監査ポリシー２２６を含まないことが可能である。また、他の構成も可能である。
【００２０】
説明される実施形態において、オーソリティ２０２が、アサーション２０６を有するセキュリティ・トークン２０４をエンティティ２０８に発行する。アサーション２０６は、本明細書の後段で説明され、「セキュリティ・ポリシー・アサーション言語の特性（Security Policy Assertion Language Example Characteristics）」という名称のセクションを含む。したがって、エンティティ２０８は、セキュリティ・トークン２０４に関連付けられる。動作において、エンティティ２０８は、アプリケーション２１０を使用して、セキュリティ・トークン２０４の効力を使用してリソース１１０にアクセスすることを望む。
【００２１】
リソース・ガード２１４は、リソース１１０にアクセスする要求を受信し、デバイス１０２（Ｂ）のその他のセキュリティ関連の構成要素を使用して、認証−許可プロセスを事実上、管理する。信頼−許可ポリシー２２２は、名前が暗示するとおり、セキュリティ環境２００内で、エンティティを信頼し、およびアクションを許可することに向けられたポリシーを含む。信頼−許可ポリシー２２２は、例えば、セキュリティ・ポリシー・アサーション（図２に明示せず）を含むことが可能である。許可照会テーブル２２４は、アクセス要求などの要求されたアクションを、適切な許可照会にマップする。監査ポリシー２２６は、セキュリティ環境２００におけるセキュリティ・スキーム１００を実装することと関係する監査責任（audit responsibilities）および監査タスクを定義する。
【００２２】
許可コンテクスト２１２は、要求元のエンティティ（requesting entity）を認証するのに使用される、セキュリティ・トークン２０４からのアサーション２０６、ならびに信頼−許可ポリシー２２２からのセキュリティ・ポリシー・アサーション、を収集する。許可コンテクスト２１２における、これらの収集されたアサーションは、アサーション・コンテクストを形成する。このため、許可コンテクスト２１２は、様々なアサーションに加え、他の情報も含むことが可能である。
【００２３】
許可コンテクスト２１２からのアサーション・コンテクスト、および許可照会テーブル２２４からの許可照会が、許可エンジン２１８に供給される。このアサーション・コンテクストおよび許可照会を使用して、許可エンジン２１８は、許可判定（authorization decision）を行う。リソース・ガード２１４は、この許可判定に基づいて、アクセス要求に応答する。監査ログ２１６は、例えば、要求されたリソース１１０のＩＤ、および／または許可エンジン２１８によって実行されるアルゴリズム評価論理、などの監査情報を含む。
【００２４】
図３は、例示的なセキュリティ関連のデータが、セキュリティ関連の構成要素の間で交換される、例示的なセキュリティ環境２００を示すブロック図である。セキュリティ関連のデータは、例示的なアクセス要求動作の支援を目的に交換される。この例示的なアクセス要求動作において、エンティティ２０８が、アプリケーション２１０を使用してリソース１１０にアクセスすることを望み、アクセスすることの許可を、セキュリティ・トークン２０４で知らせる。このため、アプリケーション２１０は、アクセス要求*をリソース・ガード２１４に送信する。図３についてのこの説明において、アスタリスク（すなわち、「*」）は、説明されるセキュリティ関連のデータが、図３に明示されていることを示す。
【００２５】
説明される実施形態において、エンティティ２０８は、トークン*、セキュリティ・トークン２０４で自らをリソース・ガード２１４に認証*する。リソース・ガード２１４は、トークン・アサーション*を許可コンテクスト２１２に転送する。これらのトークン・アサーションは、セキュリティ・トークン２０４のアサーション２０６（図２の）である。セキュリティ・ポリシー２２０が、許可照会テーブル*をリソース・ガード２１４に供給する。許可照会テーブルは、許可照会テーブル・モジュール２２４に由来する。リソース・ガード２１４に送信される許可照会テーブルは、現在のアクセス要求と直接に関係する１つまたは複数の部分に限定されることが可能である。
【００２６】
ポリシー・アサーションが、セキュリティ・ポリシー２２０によって信頼−許可ポリシー２２２から抽出される。このポリシー・アサーションには、信頼関連のアサーションと許可関連のアサーションがともに含まれることが可能である。セキュリティ・ポリシー２２０は、ポリシー・アサーション*を許可コンテクスト２１２に転送する。許可コンテクスト２１２は、トークン・アサーションとポリシー・アサーションを組み合わせて、アサーション・コンテクストにする。このアサーション・コンテクスト*は、丸で囲まれた「Ａ」によって示されるとおり、許可コンテクスト２１２から許可エンジン２１８に供給される。
【００２７】
許可照会が、許可照会テーブルから確認される。リソース・ガード２１４が、この許可照会（ａｕｔｈ．ｑｕｅｒｙ*）を許可エンジン２１８に供給する。許可エンジン２１８は、評価アルゴリズムにおいて、この許可照会およびアサーション・コンテクストを使用して、許可判定を作り出す。この許可判定（ａｕｔｈ．ｄｃｎ．*）が、リソース・ガード２１４に戻される。エンティティ２０８が、リソース・ガード２１４によってリソース１１０へのアクセス*を許可されるかどうかは、この許可判定に依存する。この許可判定が肯定的である場合、アクセスは許可される。反対に、許可エンジン２１８によって発行された許可判定が否定的である場合、リソース・ガード２１４は、リソース１１０へのアクセスをエンティティ２０８に許可しない。
【００２８】
また、許可プロセスは、許可プロセスを補完するセマンティクスを使用して監査されることも可能である。この監査は、許可プロセスの監視、および／または、例えば、許可エンジン２１８によって論理的に実行される評価アルゴリズムの、中間結果および／または最終結果の格納を、引き起こす可能性がある。その目的で、セキュリティ・ポリシー２２０が、監査ポリシー２２６からの監査ポリシー*を許可エンジン２２８に供給する。少なくとも、監査が要求されると、監査情報を有する監査レコード*が、許可エンジン２１８から監査ログ２１６に転送されることが可能である。代替として、監査情報は、例えば、許可判定の一環として、または別個に、リソース・ガード２１４を介して監査ログ２１６にルーティングされてもよい。
【００２９】
図４は、本明細書で説明されるセキュリティ関連の実施形態のために使用されることが可能である例示的なデバイス１０２のブロック図である。複数のデバイス１０２が、１つまたは複数のネットワーク１０４を介して通信することができる。図示されるとおり、２つのデバイス１０２（Ａ／Ｂ）および１０２（ｄ）が、ネットワーク１０４を介する通信交換を行うことが可能である。２つのデバイス１０２が特に示されているものの、１つまたは２つ以上のデバイス１０２が、実施形態に依存して、使用されることが可能である。
【００３０】
一般に、デバイス１０２は、クライアント・デバイスまたはサーバ・デバイス、ワークステーション、または他の汎用コンピュータ・デバイス、ＰＤＡ、移動電話機、ゲーム・プラットフォーム、エンターテイメント・デバイス、図１に関連して前段で列挙したデバイスの１つ、以上の何らかの組合せなどの、任意のコンピュータ・デバイスまたは処理対応のデバイスを表すことが可能である。図示されるとおり、デバイス１０２は、１つまたは複数のＩ／Ｏ（入出力）インターフェース４０４、少なくとも１つのプロセッサ４０６、および１つまたは複数の媒体４０８を含む。媒体４０８は、プロセッサ実行可能命令４１０を含む。
【００３１】
デバイス１０２の説明される実施形態において、Ｉ／Ｏインターフェース４０４には、（ｉ）ネットワーク１０４を介して通信するためのネットワーク・インターフェース、（ｉｉ）ディスプレイ・スクリーン上で情報を表示するためのディスプレイ・デバイス・インターフェース、および（ｉｉｉ）１つまたは複数のマン−マシン・インターフェースなどが含まれることが可能である。（ｉ）ネットワーク・インターフェースの例には、ネットワーク・カード、モデム、１つまたは複数のポートなどが含まれる。（ｉｉ）ディスプレイデバイス・インターフェースの例には、グラフィックス・ドライバ、グラフィックス・カード、スクリーンまたはモニタに関するハードウェア・ドライバまたはソフトウェア・ドライバなどが含まれる。印刷デバイス・インターフェースも同様に、Ｉ／Ｏインターフェース４０４の一部として含まれることが可能である。（ｉｉｉ）マン−マシン・インターフェースの例には、マン−マシン・インターフェース・デバイス４０２（例えば、キーボード、リモート、マウス、または他のグラフィカル・ポインティング・デバイスなど）に有線または無線で通信するインターフェースが含まれる。
【００３２】
一般に、プロセッサ４０６は、プロセッサ実行可能命令４１０などの、プロセッサ実行可能命令を実行する、遂行する、及び／または、達成することができる。媒体４０８は、１つまたは複数のプロセッサ・アクセス可能媒体から成る。つまり、媒体４０８は、デバイス１０２による機能の実行を実現するようにプロセッサ４０６によって実行可能であるプロセッサ実行可能命令４１０を含むことが可能である。
【００３３】
このため、セキュリティ関連の実施形態に関する実現は、プロセッサ実行可能命令の一般的な文脈において説明されることが可能である。一般に、プロセッサ実行可能命令には、特定のタスクを実行し、及び／または可能にし、及び／または特定の抽象データ型を実装する、ルーチン、プログラム、アプリケーション、コーディング、モジュール、プロトコル、オブジェクト、構成要素、メタデータおよびメタデータの定義、データ構造、ＡＰＩ（アプリケーション・プログラミング・インターフェース）、スキーマなどが含まれる。プロセッサ実行可能命令は、別個の記憶媒体の中に配置されること、異なるプロセッサによって実行されること、および／または様々な伝送媒体を介して伝搬されること、または様々な伝送媒体上に存在することが可能である。
【００３４】
プロセッサ４０６は、任意の適用可能な製造可能技術を使用して実装されることが可能である。媒体４０８は、デバイス１０２の一部として含まれる、及びに／またはデバイス１０２がアクセスすることができる任意の利用可能な媒体であることが可能である。媒体４０８には、揮発性媒体と不揮発性媒体、リムーバブルな媒体とリムーバブルでない媒体、ならびに記憶媒体と伝送媒体（例えば、無線通信チャネルまたは有線通信チャネル）が含まれる。例えば、媒体４０８には、プロセッサ実行可能命令４１０の、より長期の大容量格納のためのディスク／フラッシュ・メモリ／光媒体のアレイ、現在、実行されている命令の、より短期の格納のためのＲＡＭ（ランダム・アクセス・メモリ）、通信（例えば、セキュリティ関連のデータ）を伝送するためのネットワーク１０４上のリンクなどが含まれることが可能である。
【００３５】
特に図示されるとおり、媒体４０８は、少なくともプロセッサ実行可能命令４１０を備える。一般に、プロセッサ実行可能命令４１０は、プロセッサ４０６によって実行されると、デバイス１０２が、様々な流れ図に示されるアクションを含め、本明細書で説明される様々な機能を実行することを可能にする。単に例として、プロセッサ実行可能命令４１０には、セキュリティ・トークン２０４、アサーション２０６の少なくとも１つ、許可コンテクスト・モジュール２１２、リソース・ガード２１４、監査ログ２１６、許可エンジン２１８、セキュリティ・ポリシー２２０（例えば、信頼−許可ポリシー２２２、許可照会テーブル２２４、および／または監査ポリシー２２６など）、以上の何らかの組合せなどが含まれることが可能である。図４に明示されないものの、プロセッサ実行可能命令４１０には、アプリケーション２１０および／またはリソース１１０が含まれることも可能である。
【００３６】
セキュリティ・ポリシー・アサーション言語の特性例  
このセクションは、セキュリティ・ポリシー・アサーション言語（ＳｅｃＰＡＬ）の実施形態の例示的な特性を説明する。このセクションのＳｅｃＰＡＬ実施形態は、比較的インフォーマルな仕方で、単に例として説明される。このＳｅｃＰＡＬ実施形態は、エンドツーエンド・ソリューションを作成することにおける、セキュリティ・ポリシーおよびセキュリティ・トークンのオブリゲーション義務（obligation；義務）の広い範囲に対処する能力を有する。これらのセキュリティ・ポリシー義務およびセキュリティ・トークン・オブリゲーションには、例として、限定としてではなく、明示的な信頼関係を記述すること、セキュリティ・トークン発行ポリシーを表現すること、ＩＤ、属性、能力、および／または委譲ポリシーを含むセキュリティ・トークンを提供すること、リソース許可ポリシーおよび委譲ポリシーを表現することなどが含まれる。
【００３７】
説明される実施形態では、ＳｅｃＰＡＬは、セキュリティを、柔軟性があり、扱いやすい仕方で表現するための宣言型の論理ベースの言語である。ＳｅｃＰＡＬは、包括的であることが可能であり、さらに、ＳｅｃＰＡＬは、信頼関係、許可ポリシー、委譲ポリシー、ＩＤアサーションおよび属性アサーション、能力アサーション、取消し、監査要件などを表現するための、一定の方式に従う機構（uniform mechanism）を提供することができる。この一定の方式により、セキュリティ・スキームを理解可能にし、解析可能にするという点で具体的な利点がもたらされる。また、この一定の方式に従う機構は、異種のセキュリティ技術間のセマンティクス変換および調整の必要性を回避することによって、または少なくとも大幅に減らすことを可能にすることによって、セキュリティの確実性も向上させる。
【００３８】
ＳｅｃＰＡＬ実施形態は、以下の例示的な特性のいずれを含むことも可能である。すなわち、［１］ＳｅｃＰＡＬは、比較的理解するのが容易であり得る。ＳｅｃＰＡＬは、ＳｅｃＰＡＬのアサーションが、英語の文として読み取られることを可能にする定義シンタックスを使用することが可能である。また、ＳｅｃＰＡＬの文法は、制限的であり、したがって、ユーザが、明確に定義されたセマンティクスを有する少数の主語−動詞−目的語（例えば、主語−動詞句）構文だけを理解することしか要求しない。最後に、アサーションのコレクションに基づいて、推測可能な事実を評価するためのアルゴリズムは、少数の比較的単純な規則に依存することが可能である。
【００３９】
［２］ＳｅｃＰＡＬは、ＳｅｃＰＡＬの実施形態における業界標準のインフラストラクチャを活用して、ＳｅｃＰＡＬの採用、および既存のシステムへの統合を容易にすることができる。例えば、形式的なモデルからの単純明快なマッピングであるＸＭＬ（拡張マークアップ言語）シンタックスが使用されることが可能である。このことにより、標準のパーサおよびシンタックス正確性検証ツールの使用が可能になる。また、このことにより、完全性、発信元の証拠、および機密性に関して、Ｗ３Ｃ  ＸＭＬのデジタル署名標準および暗号化標準の使用も可能になる。
【００４０】
［３］ＳｅｃＰＡＬは、分散ポリシー作成および分散ポリシー構成をサポートすることによって、分散ポリシー管理を可能にすることができる。このことにより、ポリシー、またはポリシーの諸部分が、割り当てられた管理責務に基づいて、どこで作成されるかを支配する様々な動作モデルへの柔軟性のある適合が可能になる。ポリシー・オブジェクトにデジタル署名し、ポリシー・オブジェクトを暗号化する標準のアプローチの使用により、これらのオブジェクトのセキュアな配信が可能になる。［４］ＳｅｃＰＡＬは、効率的で、安全な評価を可能にする。評価が終了し、正しい答えをもたらすことを確実にするのに、入力に対する簡単なシンタックス検査で十分である。
【００４１】
［５］ＳｅｃＰＡＬは、ＩＤ管理のために、要求されるポリシー、許可判定、監査、およびＰＫＩ（公開鍵インフラストラクチャ）をサポートするアクセス制御要件のための完全なソリューションを提供することができる。これに対して、他のほとんどのアプローチは、これらの広範なセキュリティ問題の１つのサブセットに的を絞り、対処することをかんとかやり遂げるだけである。［６］ＳｅｃＰＡＬは、Ｇｒｉｄ環境、およびその他のタイプの分散システムに関するセキュリティ問題を扱うことを含むが、これには限定されない、いくつかの目的に十分なだけ表現豊かである可能性がある。特定のシステムのニーズへの適合を許しながら、言語セマンティクスおよび評価プロパティを維持する仕方で、拡張性が可能にされる。
【００４２】
図５は、一般的なセキュリティ・スキームに関する例示的なアサーション・フォーマット５００を示すブロック図である。本明細書で別に説明される実施形態において使用されるセキュリティ・スキーム・アサーションは、例示的なアサーション・フォーマット５００とは異なる可能性がある。しかし、アサーション・フォーマット５００は、セキュリティ・スキーム・アサーションに関する１つの例示的なフォーマットの基本的な例示であり、一般的なセキュリティ・スキームの様々な態様の例示的な説明される実施形態を理解するための基礎を提供する。
【００４３】
アサーション・フォーマット５００の一番上の行に示されるとおり、一般的なレベルにおける例示的なアサーションは、主体（principal）部分５０２、述べる（say）部分５０４、および主張（claim）部分５０６を含む。原文どおりに、アサーション・フォーマット５００の一般的なレベルは、主体が主張を述べる（ｐｒｉｎｃｉｐａｌ  ｓａｙｓ  ｃｌａｉｍ）と表されることが可能である。
【００４４】
アサーション・フォーマット５００の次の行で、主張部分５０６が、例示的な構成部分に分離されている。このため、例示的な主張部分５０６は、事実部分５０８、場合部分５１０、「ｎ」個の条件付き事実1...n部分５０８（１．．．ｎ）、およびｃ部分５１２を含む。添え字「ｎ」は、何らかの整数値を表す。凡例５２４に示されるとおり、ｃ部分５１２は、制約部分を表す。単一の制約だけしか図示されていないものの、ｃ部分５１２は、実際には、複数の制約（例えば、ｃ1．．．ｃm）を表すことが可能である。場合部分５１０の右側の条件付き事実部分５０８（１．．．ｎ）および制約５１２（１．．．ｍ）のセットは、先行詞（ａｎｔｅｃｅｄｅｎｔ）と呼ばれることが可能である。
【００４５】
原文どおりに、主張部分５０６は、以下によって表されることが可能である。すなわち、事実1．．．、事実n、ｃの場合、事実（ｆａｃｔ  ｉｆ  ｆａｃｔ1，．．．，ｆａｃｔn，ｃ）。このため、全体的なアサーション・フォーマット５００は、テキストで以下のように表されることが可能である。すなわち、事実1、．．．、事実n、ｃの場合、主体が、事実を述べる（ｐｒｉｎｃｉｐａｌ  ｓａｙｓ  ｆａｃｔ  ｉｆ  ｆａｃｔ1，．．．，ｆａｃｔn，ｃ）。しかし、アサーションは、以下の程度に単純であることも可能である。すなわち、主体が、事実を述べる。アサーションの、この省略された３部分バージョンにおいて、場合部分５１０で始まり、ｃ部分５１２まで続く条件付き部分は、省略される。
【００４６】
また、各事実部分５０８は、構成部分にさらに細分されることも可能である。例示的な構成部分は、ｅ部分５１４および動詞句部分５１６である。凡例５２４によって示されるとおり、ｅ部分５１４は、表現部分を表す。原文どおりに、事実部分５０８は、以下によって表されることが可能である。すなわち、ｅ  ｖｅｒｂｐｈｒａｓｅ。
【００４７】
各ｅ部分、つまり、表現部分５１４は、２つの例示的なオプションの１つをとることが可能である。これら２つの例示的な表現オプションは、定数５１４（ｃ）および変数５１４（ｖ）である。主体は、定数５１４（ｃ）および／または変数５１４（ｖ）に含まれることが可能である。
【００４８】
また、各動詞句部分５１６は、３つの例示的なオプションの１つをとることも可能である。これら３つの例示的な動詞句オプションは、述語部分５１８と、その後に続く１つまたは複数のｅ1...n部分５１４（１．．．ｎ）、アサートする（assert；表明する）ことができる部分５２０と、その後に続く事実部分５０８、およびエイリアス部分５２２と、その後に続く表現部分５１４である。テキストの点で、これら３つの動詞句オプションは、以下によって表現されることが可能である。すなわち、それぞれ、述語ｅ1．．．ｅn、事実をアサーとすることができる、およびエイリアスｅである。整数「ｎ」は、事実５０８（１．．．ｎ）および表現５１４（１．．．ｎ）に関して様々な値をとることが可能である。
【００４９】
一般に、ＳｅｃＰＡＬステートメントは、セキュリティ主体によって行われるアサーションの形態である。セキュリティ主体は、通常、暗号鍵によって識別され、したがって、セキュリティ主体は、システム境界にまたがって認証されることが可能である。最も単純な形態において、アサーションは、主体が、ある事実が有効である（例えば、事実部分５０８を含む主張５０６によって表されるような）と信じることを言明する。また、アサーションは、他の１つまたは複数の事実が有効であり、何らかの条件セットが満たされる場合（例えば、事実部分５０８から、場合部分５１０、条件付き事実部分５０８（１．．．ｎ）を経てｃ部分５１２まで続く主張５０６によって表されるとおり）、ある事実が有効であることを言明することも可能である。また、まったく制約５１２を伴わない条件付き事実５１８（１．．．ｎ）、および／または、まったく条件付き事実５０８（１．．．ｎ）を伴わない制約５１２が存在することも可能である。
【００５０】
説明される実施形態において、事実は、主体についてのステートメントである。４つの例示的なタイプの事実ステートメントが、このセクションにおいて、この場合、説明される。第１に、ある事実が、ある「アクション動詞」で、あるリソースに対してあるアクションを実行する権利を、ある主体が有することを言明することが可能である。例示的なアクション動詞には、呼び出す、送信する、読む、リストアップする、実行する、書き込む、変更する、付加する、削除する、インストールする、所有するなどが含まれるが、以上には限定されない。リソースは、ＵＲＩ（ユニバーサル・リソース・インジケータ）、または他の任意のアプローチによって識別されることが可能である。
【００５１】
第２に、ある事実が、「有する」動詞を使用して、主体識別子と１つまたは複数の属性との間の結び付きを表現することが可能である。例示的な属性には、電子メール名、一般名、グループ名、役割タイトル、アカウント名、ＤＮＳ（ドメイン・ネーム・サーバ／サービス）名、ＩＰ（インターネット・プロトコル）アドレス、デバイス名、アプリケーション名、組織名、サービス名、アカウントＩＤ（識別／識別子）などが含まれるが、以上には限定されない。例示的な第３のタイプの事実は、２つの主体識別子が、「エイリアス」動詞を使用して、同一の主体を表すように定義されることが可能であることである。
【００５２】
「修飾子」または事実修飾子が、前述の３つの事実タイプのいずれかの一部として含められることが可能である。修飾子は、事実が有効であると考えられるとするなら、成立しなければならないとアサータ（assertor）が信じる環境パラメータ（例えば、時間、主体ロケーションなど）を、アサータが示すことを可能にする。そのようなステートメントは、これらの修飾子値に基づいて、アサータと、依拠する相手の有効性検査との間で、きれいに分離されることが可能である。
【００５３】
例示的な第４のタイプの事実は、「アサートできる（can assert）」動詞によって定義される。この「アサートできる」動詞は、信頼関係および委譲を表現するための、柔軟性のある、強力な機構を提供する。例えば、この「アサートできる」動詞は、１つの主体（Ａ）が、第２の主体（Ｂ）によってアサート（表明）される、いくつかのタイプの事実を信じる意思を言明することを可能にする。例えば、「Ｂが、事実（）をアサートできると、Ａが述べる」および「Ｂが、事実（）を述べる」というアサーションが与えられると、Ａが、事実（）を有効であると信じる、と結論付けることができ、したがって、「Ａが事実（）を述べる」と推論されることが可能である。
【００５４】
そのような信頼アサーションおよび委譲アサーションは、（ｉ）非有界であり、推移的であって、下流の委譲を許す、または（ｉｉ）有界であり、下流の委譲を除外することが可能である。修飾子は、「アサートできる」タイプの事実に適用されることが可能であるものの、これらの「アサートできる」タイプの事実に対する修飾子のサポートを省くことにより、所与のセキュリティ・スキームのセマンティクスおよび評価安全性特性が大幅に簡略化される。
【００５５】
説明される実施形態において、変数を使用して、具体的な事実が言明されることが可能であり、あるいはポリシー表現が書かれることが可能である。これらの変数は、型付きであり、無制限である（例えば、正しい型の任意の具体的な値とマッチすることを許される）ことも、制限されている（例えば、指定されたパターンに基づく具体的な値のサブセットとマッチすることを要求される）ことも可能である。
【００５６】
セキュリティ許可判定は、該当するセキュリティ・ポリシー（例えば、セキュリティ・ポリシー２２０）およびセキュリティ・トークン（例えば、１つまたは複数のセキュリティ・トークン２０４）からのアサーション（例えば、アサーション・コンテクスト）のコレクションに対する許可照会の評価アルゴリズム（例えば、許可エンジン２１８において行われることが可能な）に基づく。許可照会は、事実および／または条件を組み合わせる、極めて複雑になることが可能な論理的表現である。これらの論理的表現には、付帯的な条件および／または制約を伴う、または伴わない、例えば、事実に対するＡＮＤ論理演算、ＯＲ論理演算、および／またはＮＯＴ論理演算が含まれることが可能である。
【００５７】
許可照会のこのアプローチは、所与のアクションが許可される前に、何が知られており、有効でなければならないかを定義するための柔軟性のある機構を提供する。照会テンプレート（例えば、許可照会テーブル２２４からの）が、全体的なセキュリティ・スキームの一部分を形成し、適切な許可照会が、様々なタイプのアクセス要求、およびその他の動作／アクションに関して宣言的に言明されることを許す。
【００５８】
セキュリティ許可照会に関する例示的な実施形態  
既存のセキュリティ・ポリシー言語は、２つのアプローチのいずれかを採用する。一部のセキュリティ・ポリシー言語は、あらゆる仕方の否定の使用を常に防止する。このアプローチは、否定から生じる可能性がある、付随する不整合および不確実を減らす。しかし、このアプローチは、多くのセキュリティ・シナリオが、対処するのがはるかに困難にされ、一部のセキュリティ・シナリオは、ただ単に対処され得ないために、制限的でもある。他方のアプローチは、否定の使用にまったく制限を課さない。このアプローチは、より柔軟であるものの、入り組んだ、または非決定論的でさえあるセキュリティ・ポリシーを確立する可能性をもたらす。
【００５９】
これに対して、説明される実施形態は、複数のレベルを有するセキュリティ・スキームを生じさせる。例えば、分岐したセキュリティ・スキーム実施形態では、２つのレベルが存在する。第１のレベルは、否定の使用を禁止する。このことは、例えば、シンタックスに対する妥当性検査を使用して実行されることが可能である。第２のレベルは、否定の使用を許す。この分岐したセキュリティ・スキームは、セキュリティ・アサーションが扱いやすく、決定可能であることを確実にすることの安全性および確実性を、排他的なセキュリティ規則を扱うことの柔軟性と組み合わせる。
【００６０】
図６は、第１のレベルと、第２のレベルとを有する例示的な２つに分岐したセキュリティ・スキーム６００を示すブロック図である。図示されるとおり、第１のレベルは、アサーション・レベル６０２を含み、第２のレベルは、照会レベル６０４を含む。アサーション・レベル６０２は、複数のアサーション６０６と、シンタックス・バリデータ６１４とを含む。照会レベル６０４は、複数の部分を有する例示的な許可照会６１６を含む。これらの複数の部分の例には、アサートされる事実６０８と、論理演算子６１０および６１２とが含まれるが、以上には限定されない。
【００６１】
説明される実施形態では、アサーション・レベル６０２には、アサーション６０６が取り込まれる。アサーション６０６は、アサーション・レベルにおける任意のタイプの宣言型セキュリティ・ステートメントであることが可能である。アサーション６０６の例には、トークン・アサーションおよびポリシー・アサーションが含まれるが、以上には限定されない。（これら２つのアサーション・タイプは、図７に別々に、明示的に例示される。）否定は、セキュリティ・アサーション６０６内で許されない。シンタックス・バリデータ６１４が、各アサーション６０６を解析して、否定が存在するかどうかを検査する。所与のアサーション６０６内に否定が存在する場合、その所与のアサーション６０６は、拒否される、または不許可にされる。
【００６２】
照会レベル６０４には、例示的な許可照会６１６などの許可照会が取り込まれる。照会レベル６０６の許可照会は、ＮＯＴ演算子６１２などの否定を含むことを許される。許可照会は、任意の仕方で構造化されることが可能である。図６には特に示されていないものの、許可照会は、一般に、１つまたは複数の論理制約を含むことが可能である。
【００６３】
例示的な許可照会６１６において、照会は、ブール論理演算として構造化される。そのようなブール論理演算は、任意の数のアサートされる事実６０８、任意の数の論理演算子などを含むことが可能である。アサートされる事実、論理演算子などは、任意の仕方で組み合わされることが可能である。例示的な論理演算子には、ＡＮＤ、ＯＲ、ＮＯＴなどが含まれるが、以上には限定されない。図示されるとおり、例示的な許可照会６１６は、３つのアサートされる事実６０８と、２つのＡＮＤ演算子６１０と、１つのＮＯＴ演算子６１２とを含む。
【００６４】
アサートされる事実６０８が真であるか否かは、マッチングする有効なアサーション６０６が推定されることが可能であるか否かに依存する。このマッチング決定プロシージャが完了した後、もたらされた論理ブール演算が、評価される。例示的な許可照会６１６の事例において、ＮＯＴ演算子６１２が、ＡＮＤ演算子６１０を適用するのに先立って、右端のアサートされる事実６０８のＴＲＵＥ／ＦＡＬＳＥ決定に適用される。全体的なブール演算が、ＴＲＵＥであると評価された場合、許可判定は、肯定的である。ブール演算の全体的評価が、ＦＡＬＳＥである場合、許可判定は、否定的である。
【００６５】
アサーション６０６と許可照会（例えば、例示的な許可照会６１６）との間の例示的な相互関係が、図７〜図１０の説明において後段で提示される。ある許可照会が、１つまたは複数のアサーション６０６を含む、またはそれ以外で１つまたは複数のアサーション６０６に関連することが可能な要求に応答して、確認される。次に、この許可照会が、アサーション６０６を含む全体的なアサーション・コンテクストと併せて評価される。アサーション・コンテクストは、通常、トークン・アサーションおよびポリシー・アサーションを含む。
【００６６】
図７は、例示的な許可照会確認と、例示的な許可照会評価とを示す一般的なブロック図７００である。ブロック図７００は、図２および図３からのいくつかのセキュリティ関連の構成要素を含む。図示されるとおり、ブロック図７００は、許可コンテクスト２１２、リソース・ガード２１４、許可エンジン２１８、および許可ポリシー２２０を含む。セキュリティ・ポリシー２２０は、許可照会テーブル２２４を含む。許可エンジン２１８は、評価アルゴリズム７０８を含む。セキュリティ・ポリシー２２０は、許可照会テーブル２２４を含む。許可エンジン２１８は、評価アルゴリズム７０８を含む。
【００６７】
説明される実施形態において、許可コンテクスト２１２は、アサーション・コンテクスト７０２を含む。アサーション・コンテクスト７０２は、アサーション６０６のコレクションである。具体的には、アサーション・コンテクスト７０２は、トークン・アサーション６０６Ｔと、ポリシー・アサーション６０６Ｐとを含む。トークン・アサーション６０６Ｔは、セキュリティ・トークン（例えば、図２および図３のセキュリティ・トークン２０４）から派生する。セキュリティ・トークンは、リソース・アクセス要求の一環として、さらに／またはリソース・アクセス要求と一緒に送られることが可能である。ポリシー・アサーション６０６Ｐは、信頼、および許可ポリシー（例えば、セキュリティ・ポリシー２２０の信頼−許可ポリシー２２２モジュール（図２の））から派生する。
【００６８】
アサーション・コンテクスト７０２が、リソース・ガード２１４に転送される。要求７０４が、リソース・ガード２１４に提示される。要求７０４は、何らかのリソースにアクセスする要求である。リソース・ガード２１４は、この要求をオペレーションに変換する。このオペレーションが、許可照会テーブル２２４に与えられる。許可照会テーブル２２４は、リソース特有のオペレーションを許可照会にマップする。例示的な実施形態では、各オペレーションは、単一の許可照会に関連する。与えられたオペレーションに応答して、セキュリティ・ポリシー２２０は、関連する許可照会７０６を確認し、許可照会７０６をリソース・ガード２１４に戻す。許可照会テーブル２２４を使用して許可照会７０６を確認することは、図８を特に参照して本明細書の後段でさらに説明される。
【００６９】
このため、リソース・ガード２１４は、アサーション・コンテクスト７０２と許可照会７０６をともに含む。リソース・ガード２１４は、アサーション・コンテクスト７０２および許可照会７０６を、許可エンジン２１８の評価アルゴリズム７０８に転送する。評価アルゴリズム７０８は、アサーション・コンテクスト７０２と併せて許可照会７０６を評価することができるロジックを含む。このロジックは、ハードウェア、ソフトウェア、ファームウェア、および以上の何らかの組合せなどを使用して実装されることが可能である。
【００７０】
このため、アサーション・コンテクスト７０２は、評価アルゴリズム７０８において許可照会７０６に適用される。論理解析の後、評価アルゴリズム７０８は、許可判定７１０をもたらす。アサーション・コンテクスト７０２と併せて許可照会７０６を評価することは、図９を特に参照して本明細書の後段でさらに説明される。
【００７１】
一般に、本明細書で説明される特性を有するセキュリティ言語は、複雑なアクセス制御基準を、宣言的な仕方で書くことを比較的簡単にし、理解することを比較的簡単にする。そのようなセキュリティ言語は、入力ポリシー、および認証された要求者データに基づいて推定される有効な事実のセットを開示する任意の許可アルゴリズムに適合する。本明細書でさらに説明されるとおり、そのようなセキュリティ言語は、アサーション・コンテクストと連携した許可判定アルゴリズムと組み合わされた許可照会の概念に基づく。
【００７２】
説明される実施形態では、一般に、許可照会は、アサートされる事実のセットを制約と一緒に含む。アサートされる事実は、「Ａは、事実を述べる（Ａ  ｓａｙｓ  ｆａｃｔ）」という形態である。アサートされる事実は、合致する（マッチングする）有効なアサーションが、推定されることが可能である（例えば、アサーション・コンテクストから）という要件を表現する。そのような合致する有効なアサーションが知られている場合、アサートされる事実は、満たされ、ブール値、Ｔｒｕｅに評価され、それ以外の場合、アサートされる事実は、Ｆａｌｓｅに評価される。（一部の実施形態では、事実のアサーション者は、評価コンテクストに基づいて暗黙に知られていることが可能である。これらの事例では、アサーション者は、省略されることが可能である。）制約は、ブール値を戻す表現である。制約には、アサートされる事実において使用される変数、ならびに環境値（例えば、時間、場所など）への参照が含まれることが可能である。制約は、可変の等式、および可変の不等式を表現するのに通常、使用される。
【００７３】
各照会に少なくとも１つのアサートされる事実が存在する。複数のアサートされる事実が存在する場合、それらのアサートされる事実は、ＡＮＤ、ＯＲ、およびＮＯＴなどの論理演算子を使用して組み合わされることが可能である。オプションの制約が、アサートされる事実と論理的にＡＮＤ演算される。
【００７４】
このアプローチの結果は、より高いレベルの構造上の要件を気にすることなしに、各主体に許可されるアクセスについての肯定的なステートメントの点で、基本アクセス制御ポリシーが書かれることが可能であることである。このため、複数の主体ポリシーにおいて、各ポリシーを、各主体がリソースに対してどのような権利を潜在的に有するべきかを明言して、書くことができる。そのようなセキュリティ・ポリシーは、新たなポリシー・ステートメントの追加によって既存のいずれのアクセス権も除去されないという意味で、単調である。さらに、潜在的な矛盾または不整合を気にすることなしに、リソースのセットに対して主体がどのような権利を有するかを示す肯定的なアクセス・ポリシーを書くことができる。許可照会は、これらのアクセス制御規則を組み合わせるための、より高いレベルのセマンティクスを提供する。
【００７５】
例えば、「Ｆｏｏ」への読取りアクセスを許可するのに（ｉ）「ｆａｂｒｉｋａｍ．ｃｏｍ」電子メール・アドレスを有するユーザ、および（ｉｉ）コード・ダイジェスト値「ＡＢＣ」を有するアプリケーションを要求した場合、アクセス制御規則は、以下のように書かれることが可能である。すなわち、  
ｐがｒ｛（ｅｍａｉｌＮａｍｅ，*＠ｆａｂｒｉｋａｍ．ｃｏｍ）｝を有する場合、ｐがＦｏｏを読む、とＡは述べる（A says p read Foo if p possess r{(emailName,*@fabrikam.com)}）  
ｐがｒ｛ｄｉｇｅｓｔ，ＡＢＣ｝を有する場合、ｐがＦｏｏを読む、とＡは述べる（A says p read Foo if p possess r{digest,ABC}）  
ユーザとアプリケーションがともに認証された要求者であることを確実にするのに、例示的な許可照会は、以下のとおりである。すなわち、  
ｖ１がＦｏｏを読む、とＡは述べる  ＡＮＤ  ｖ１が、ｒ｛（ｅｍａｉｌＮａｍｅ，*）｝を有する、とＡは述べる  ＡＮＤ  ｖ２がＦｏｏを読む、とＡは述べる  ＡＮＤ  ｖ２が｛（ｄｉｊｅｓｔ，*）｝を有する、とＡは述べる（A says v1 read Foo AND A says v1 possess r{(emailName,*)}AND A says v2 read Foo AND A says v2 possess{(dijest,*)}）
【００７６】
同様に、「ｆａｂｒｉｋａｍ．ｃｏｍ」電子メール・アドレスを有する許可された２つの主体が、「Ｆｏｏ」へのアクセスを要求済みであることを要求するのに、以下のセキュリティ・ポリシーが、書かれることが可能である。すなわち、  
ｐがｒ｛（ｅｍａｉｌＮａｍｅ，*＠ｆａｂｒｉｋａｍ．ｃｏｍ）｝を有する場合、ｐがＦｏｏを読む、とＡは述べる（A says p read Foo if p possess r{(emailName,*@fabrikam.com)}）  
であり、このセキュリティ・ポリシーは、以下の許可照会と組み合わされることが可能である。すなわち、  
ｐ１がＦｏｏを読む、とＡは述べるＡＮＤ  ｐ２がＦｏｏを読む、とＡは述べるＡＮＤ（ｐ１  ！＝ｐ２）（A says p1 read Foo AND A says p2 read Foo AND(p1 !=p2)）  
前掲の許可照会において、「ｐ１」変数が、「ｐ２」変数と等しいことが可能でないことを示す部分が、制約である。
【００７７】
否定または排除は、このアプローチを使用して適切に扱われることが可能である。例えば、グループＡのメンバらがＦｏｏへの読取りアクセスを有し、グループＢのメンバらがＢａｒへの読取りアクセスを有するが、同時のアクセスは、許されないことが所与とされる。所望されるアクセスは、以下のように書かれた２つのポリシー・アサーションを有するセキュリティ・ポリシーを使用して可能にすることができる。すなわち、
ｐが、ｒ｛（ｇｒｏｕｐ，Ａ）｝を有する場合、ｐがＦｏｏを読む、とＡは述べる（A says p read Foo if p possess r{(group,A)}）
ｐが、ｒ｛（ｇｒｏｕｐ，Ｂ）｝を有する場合、ｐがＢａｒを読む、とＡは述べる（A says p read Bar if p possess r{(group,B)}）
次に、排除は、以下の許可照会を使用して執行されることが可能である。すなわち、
（ｖがＦｏｏを読む、とＡは述べる  ＯＲ  ｖがＢＡＲを読む、とＡは述べる）ＡＮＤ  ＮＯＴ（ｖがＦｏｏを読む、とＡは述べる  ＡＮＤ  ｖがＢＡＲを読む、とＡは述べる）（(A says v read Foo OR A says v read BAR)AND NOT(A says v read Foo AND A says v read BAR)）
同様の仕方で、同時に２つの役割にあること、所与のリソースに対して同時に複数のアクセス権（例えば、読取りと削除の両方）を有することなどを排除することができる。
【００７８】
図８は、リソース・アクセス要求７０４に応答する例示的な許可照会確認８００を示す、より詳細なブロック図である。図示されるとおり、許可照会確認８００は、識別されたリソース８０２、変換ファンクション（translation function）８０４、オペレーション８０６、許可照会テーブル２２４、および許可照会７０６を有する要求７０４を含む。許可照会確認８００は、要求７０４を入力として受け取ること、および関連する許可照会７０６を出力として生成することを含む。
【００７９】
説明される実施形態では、要求７０４は、識別された何らかのリソース８０２にアクセスする要求である。要求７０４は、変換ファンクション８０４を介してリソース特有のオペレーション８０６に変換される。この変換ファンクション８０４は、例えば、リソース・ガード２１４（図７の）によって実行されることが可能である。リソース特有のオペレーションの例には、例として、限定としてではなく、（ｉ）ファイルを読むこと、および／またはファイルに書き込むこと、（ｉｉ）通信ポートを介してデータを送信すること、（ｉｉｉ）プロセッサを利用すること、（ｉｖ）アプリケーションを実行することなどが含まれる。
【００８０】
一般に、オペレーション８０６は、許可照会テーブル２２４に与えられる。例えば、セキュリティ・ポリシー２２０が、オペレーション８０６を許可照会テーブル２２４に適用して、関連する許可照会７０６を取り出すことを担う。許可照会７０６が、結果としてもたらされて、リソース・ガード２１４に戻される。
【００８１】
より具体的には、許可照会テーブル２２４は、複数のフィールド８０８を含む。各フィールド８０８は、リソース特有のオペレーションを、関連する許可照会テンプレートにマップする。図示されるとおり、「ｆ」個のフィールド８０８（１）、８０８（２）、．．．８０８（ｆ）が、許可照会テーブル２２４の中に存在し、「ｆ」は、何らかの整数である。取り出された許可照会テンプレートが、リソース・ガード２１４に戻される。すると、リソース・ガード２１４は、代入（置換）プロシージャ（substitution procedure）を実行して、許可照会７０６を生成する。つまり、許可照会７０６を作成するのに、リソース・ガード２１４は、要求する実際の主体、要求される実際のリソースなどを、関連する許可照会テンプレートの所定の対応するスロットに代入する。
【００８２】
図９は、アサーション・コンテクスト７０２*を所与として例示的な許可照会評価７０８*を示す、より詳細なブロック図である。図７を参照して前段で一般的に説明したとおり、評価アルゴリズム７０８は、許可照会７０６およびアサーション・コンテクスト７０２を受け取る。図９の特定の例示的な許可評価７０８*において、ある特定の例示的な許可照会７０６*が、ある特定の例示的なアサーション・コンテクスト７０２*と併せて評価される。実際のアサーション・コンテクスト７０２、許可照会７０６、および評価アルゴリズム７０８は、これらの例とは異なる可能性がある。
【００８３】
図示されるとおり、例示的な許可照会評価７０８*は、例示的なアサーション・コンテクスト７０２*、例示的な許可照会７０６*、もたらされたブール演算９１０、および答え９１２を含む。アサーション・コンテクスト７０２*は、（ｉ）３つのトークン・アサーション６０６Ｔ−１、６０６Ｔ−２、および６０６Ｔ−３と、（ｉｉ）２つのポリシー・アサーション６０６Ｐ−１および６０６Ｐ−２とを含む。例示的な許可照会７０６*は、３つのアサートされる事実６０８−１、６０８−２、および６０８−３と、２つのＡＮＤ演算子６１０と、１つのＮＯＴ演算子６１２と、１つの制約９０２とを含む。
【００８４】
評価中、許可エンジン２１８（図７の）が、合致する有効なアサーション６０６が、許可照会７０６*のそれぞれのアサートされる事実６０８から推定されることが可能であるかどうかを決定しようと試みる。この合致（マッチング）決定プロセスは、繰り返され、再帰的であり、さらに／または１つの有効なアサーションが、有効である可能性がある別のアサーションにつながるにつれて分岐することが可能である。何らかの一定の期間の後、合致決定プロセスは、収束する。
【００８５】
図９の例示的な許可照会評価７０８*は、許可照会を評価することの概念上の基盤である一般的な理解を容易にするように、簡略化された評価アルゴリズムを示す。より詳細な、技術的に正確な説明が、図９の説明の後に後段で提示される。さらに、例示的な実施形態の比較的厳格な、論理的説明が、図１０の説明の後、本明細書の後段で提示される。
【００８６】
例示的な許可照会評価７０８*おいて、トークン・アサーション６０６Ｔ−２が有効であり、アサートされる事実６０８−１と合致する（９０４）ことが、許可エンジン２１８によって決定される。また、ポリシー・アサーション６０６Ｐ−２が有効であり、アサートされる事実６０８−２と合致する（９０６）こと、およびトークン・アサーション６０６Ｔ−３が有効であり、アサートされる事実６０８−３と合致する（９０８）ことも決定される。トークン・アサーション６０６Ｔ−１およびポリシー・アサーション６０６Ｐ−１は、ある特定のアサートされる事実６０８と明示的に合致することはないものの、合致決定プロセスにおいて使用されている。さらに、ＴＲＵＥ／ＦＡＬＳＥ決定が、制約９０２に関連して行われる。
【００８７】
合致決定プロセスの後、および／または合致決定プロセスの間、ＴＲＵＥ／ＦＡＬＳＥ置き換えプロセスが実行されて、ブール演算９１０が作成される。ある特定のアサートされる事実６０８が、合致する有効なアサーション６０６を有する場合、その特定のアサートされる事実６０８は、「ＴＲＵＥ」で置き換えられる。合致する有効なアサーション６０６を有さない場合、その特定のアサートされる事実６０８は、「ＦＡＬＳＥ」で置き換えられる。制約９０２も同様に、「ＴＲＵＥ」ステータスまたは「ＦＡＬＳＥ」ステータスで置き換えられる。許可照会７０６*に関して特に示されていないものの、制約９０２が、許可照会の残りの部分に論理的にＡＮＤ演算される。
【００８８】
例えば、許可照会評価７０８*、許可照会７０６*は、以下のようにテキストとして示されることが可能である。すなわち、アサートされる事実６０８−１、ＡＮＤ演算子６１０、アサートされる事実６０８−２、ＡＮＤ演算子６１０、ＮＯＴ演算子６１２、アサートされる事実６０８−３、および制約９０２。置き換えプロセスの後、もたらされたブール演算は、以下のようにテキストとして示されることが可能である。すなわち、ＴＲＵＥ  ＡＮＤ  ＴＲＵＥ  ＡＮＤ  ＮＯＴ  ＴＲＵＥ  ＡＮＤ  ＴＲＵＥ。以上は、論理的にＦＡＬＳＥである、ＴＲＵＥ  ＡＮＤ  ＴＲＵＥ  ＡＮＤ  ＦＡＬＳＥ  ＡＮＤ  ＴＲＵＥに短縮される。
【００８９】
したがって、ブール演算９１０に関する答え９１２は、「ＦＡＬＳＥ」である。このため、許可判定７１０は、その要求を拒否することである。他方、例えば、アサートされる事実６０８−３に関して合致する（９０８）アサーション６０６が存在しなかったとする場合、ブール演算９１０は、論理的にＴＲＵＥである、ＴＲＵＥ  ＡＮＤ  ＴＲＵＥ  ＡＮＤ  ＴＲＵＥ  ＡＮＤ  ＴＲＵＥに短縮される。この事例では、答え９１２は、「ＴＲＵＥ」であり、許可判定７１０は、その要求を許可することである。明示的に示されていない、または説明されていないものの、ブール演算９１０が、論理的にＦＡＬＳＥであるように評価される他の置換も存在する（例えば、アサートされる事実６０８−２に関して有効で、合致する（９０６）アサーション６０６が存在しないと決定された場合）。
【００９０】
許可照会を評価するためのより技術的に正確な、例示的な実施形態を以下に説明する。第１に、許可照会内部のアサートされる事実が、完全な置き換えプロセスに先立って、一斉にではなく、１つずつ評価される。第２に、許可照会内部の単一のアサートされる事実の評価が、そのアサートされる事実を真にする変数置換（variable substitutions）のセットを戻す。このため、一般に、戻される値は、事実が、実際には、所与の変数置換に関してＴＲＵＥ／ＦＡＬＳＥステータスを有するものとして表されるため、直ちにＴＲＵＥ／ＦＡＬＳＥステータスではない。
【００９１】
許可照会内部の２つのアサートされる事実の間の連結詞が、ＡＮＤである場合（図９の例において該当するとおり）、左側の事実の戻される値（すなわち、置換のセット（set of substitutions））が、右側の事実に適用される。その後、右側の事実が、必要に応じて評価される。次に、もたらされた代入セットが、代入合成によって組み合わされる。許可照会全体を評価したことの結果は、代入セットであり、この代入セットの各代入が、その許可照会を真にすることができる。
【００９２】
図１０は、許可照会を確認して、評価するための方法の例を示す流れ図１０００である。流れ図１０００は、１１（十一）のブロック１００２〜１０２２を含む。流れ図１０００のアクションは、他の環境においても、さらに様々なハードウェア／ソフトウェア／ファームウェアの組合せを使用しても実行されることが可能であるものの、図１〜図９のフィーチャ、構成要素、および態様のいくつかを使用して、本方法の実施例が示される。例えば、リソース・ガード２１４、許可照会テーブル２２４、および／または許可エンジン２１８が、別々に、または一緒になって、流れ図１０００のアクションを実施することができる。
【００９３】
説明される実施形態では、ブロック１００２で、リソースにアクセスする要求が、受け取られる。例えば、リソース８０２を識別する要求７０４が、受け取られることが可能である。ブロック１００４で、この要求が、リソースに対するオペレーションに変換される。例えば、リソース・ガード２１４が、要求７０４をリソース特有のオペレーション８０６に変換する（８０４）ことが可能である。
【００９４】
ブロック１００６で、このオペレーションが、許可照会テーブルに与えられる。例えば、リソース特有のオペレーション８０６が、許可照会テーブル２２４に与えられることが可能である。ブロック１００８で、このオペレーションに関連する許可照会が、確認される。例えば、リソース特有のオペレーション８０６を含むフィールド８０８が、探し出されることが可能である。次に、関連する許可照会が、この探し出されたフィールド８０６から取り出されることが可能である。
【００９５】
より具体的には、取り出された許可照会は、許可照会テンプレートを含むことが可能である。この関連する許可照会テンプレートは、要求者によって供給されたセキュリティ・トークンに基づいて、実際の主体、リソースなどを、許可照会テンプレートの所定の対応するスロットに代入することによって、許可照会に変換される。例示的な実施形態では、要求７０４からの実際の可変情報を知っているリソース・ガード２１４が、代入によってこの変換を実行する。
【００９６】
ブロック１０１０で、アサーション・コンテクストと許可照会が、評価アルゴリズムにおいて組み合わされる。例えば、アサーション・コンテクスト７０２および許可照会７０６が、評価アルゴリズム７０８に一緒にサブミットされることが可能である。
【００９７】
ブロック１０１２で、アサーション・コンテクストの有効なアサーションが、合致決定プロセスにおいて許可照会のアサートされる事実とマッチングされる。例えば、有効であると判明した、アサーション・コンテクスト７０２から推定可能である（すなわち、元はアサーション・コンテクスト７０２内に存在した、さらに／または、それ以外でアサーション・コンテクスト７０２から導出可能な）１つまたは複数のトークン・アサーション６０６Ｔおよび／またはポリシー・アサーション６０６Ｐが、合致決定プロセスにおいてアサートされる事実６０８とマッチングされる９０４／９０６／９０８ように試みられることが可能である。また、許可照会７０６の制約部分９０２が解析されて、制約部分９０２がＴＲＵＥであるか、ＦＡＬＳＥであるかの決定も行われる。技術的説明において前述したとおり、各アサーションは、別々に、さらに／または順次に解析されることが可能である。
【００９８】
ブロック１０１４で、合致（マッチング）決定プロセスに応答して、許可照会の中でＴＲＵＥ／ＦＡＬＳＥを置き換えることが、実行される。例えば、ブール演算９１０において、合致する有効なアサーション６０６を有すると決定されたアサートされる事実６０８が、ＴＲＵＥで置き換えられることが可能であり、合致する有効なアサーション６０６を有すると決定されなかったアサートされる事実６０８が、ＦＡＬＳＥで置き換えられることが可能である。ブロック１０１４のアクションは、ブロック１０１２のアクションの実行と完全に、または部分的に重なり合う仕方で実行されてもよいことを理解されたい。
【００９９】
ブロック１０１６で、許可照会が、論理的に評価される。例えば、ブール演算９１０が、評価アルゴリズム７０８の一環として論理的に評価されて、答えが、ＴＲＵＥであるか、ＦＡＬＳＥであるかが決定されることが可能である。ブール演算９１０の結果は、それぞれのアサートされる事実６０８および／または制約９０２をＴＲＵＥステータスまたはＦＡＬＳＥステータスで置き換えることなしに、決定可能であり得るとともに、実際に決定されることが可能であることを理解されたい。
【０１００】
ブロック１０１８で、許可照会が「ＴＲＵＥ」に論理的に評価されるかどうかが決定される。「ＴＲＵＥ」に評価される場合、ブロック１０２０において許可判定は、要求が許可されることである。反対に、許可照会が、「ＦＡＬＳＥ」に論理的に評価されると決定された場合、ブロック１０２２において許可判定は、要求が拒否されることである。「ＴＲＵＥ」ステータスを有することが可能である許可照会のアルゴリズム評価は、許可照会を「ＴＲＵＥ」にする変数のセットを戻すことが可能であることを理解されたい。
【０１０１】
また、セキュリティ許可照会は、比較的厳格な、論理的な見地から記述されることも可能である。セキュリティ許可照会の説明される論理的実施形態において、許可要求は、ローカルのアサーション、ならびにインポートされたアサーションを含むアサーション・コンテクストを照会することによって決定される。例示的な実施形態において、許可照会は、Ａは、事実を述べる（Ａ  ｓａｙｓ  ｆａｃｔ）という形態のアトミック照会のコレクションと、制約ｃとを含むことが可能である。これらのアトミック照会および制約が、否定を含む論理的連結詞によって組み合わされる。例示的な論理的連結詞には、以下が含まれる。すなわち、  
ｑ：：ｅは、事実を述べる  
｜ｑ1，ｑ2 
｜ｑ1またはｑ2 
｜（ｑ）でない  
｜ｃ  
（ｑ：：＝ｅ  ｓａｙｓ  ｆａｃｔ  
｜ｑ1，ｑ2 
｜ｑ1  ｏｒ  ｑ2 
｜ｎｏｔ（ｑ）  
｜ｃ）
もたらされる照会言語は、アトミック照会だけしか考慮されない他の論理ベースの言語より表現豊かである。例えば、責務、閾値、および拒否ポリシーの分離が、否定と制約を有するアトミック照会を構成することによって表現されることが可能である。否定は、否定を再帰的言語と結合することが、意味的曖昧さをもたらし、しばしば、より高い計算の複雑度、または決定不能性にさえつながるため、言語のアサーション・レベルにおいては許されない。否定の使用を、（これらのフィーチャをアサーション言語自体に加えるのではなく）許可照会のレベルに制限することにより、否定は、再帰から事実上、分離されて、否定に通常、関連する問題が回避される。
【０１０２】
照会のセマンティクスは、関係
【０１０３】
【数１】
2010503123.tif 000003
【０１０４】
によって定義される。以下において、ＡＣをアサーション・コンテクストとする。また、θを代入とし、εを空の代入とする。Ｄｏｍ（θ）を代入θのドメインとする。Ｘが、シンタックスの句である場合、Ｖａｒｓ（Ｘ）を、Ｘの中で現れる変数のセットとする。許可照会に関する例示的な形式的セマンティクスは、以下のとおりである。すなわち、
【０１０５】
【数２】
2010503123.tif 000004
【０１０６】
照会ｑおよび許可コンテクストＡＣを所与として、許可アルゴリズムは、
【０１０７】
【数３】
2010503123.tif 000005
【０１０８】
などの代入θのセットを戻す。照会が、グラウンドである場合、答えセットは、空である（「いいえ」を意味して、要求は、拒否される）、または空の代入εを含むシングルトンセットである（「はい」を意味して、要求は、許可される）。照会が、変数を含む場合、答えセットにおける代入は、その照会を真にする変数割り当てである。
【０１０９】
許可照会テーブルに関して、許可照会テーブルは、ローカル・セキュリティ・ポリシーの一部であることが可能であり、無条件コードとは別個に保持されることが可能である。このテーブルは、パラメータ化されたメソッド名を照会にマップすることによって、許可照会へのインターフェースを提供する。要求時に、リソース・ガードが、テーブルによってある許可照会にマップされるメソッドを呼び出し（例えば、照会を直接に発行する代わりに）、その許可照会が、次に、アサーション・コンテクストを照会するのに使用される。
【０１１０】
例えば、許可照会テーブルは、以下の例示的なマッピングを含むことが可能である。すなわち、  
ｃａｎＡｕｔｏｒｉｚｅＰａｙｍｅｎｔ（要求者，支払い）：  
Ａｄｍｉｎは、要求者が、ＢａｎｋＭａｎａｇｅｒＩＤ  ｉｄを有すると述べる，  
（Ａｄｍｉｎは、要求者が、支払いを開始したと述べる）でない  
（canAuthorizePayment(requester, payment):  
Admin says requester possesses BankManagerID id,  
not(Admin says requester has initiated payment)）  
アリスが、例えば、支払い、Ｐａｙｍｅｎｔ４７を許可しようと試みた場合、リソース・ガードは、ｃａｎＡｕｔｈｏｒｉｚｅＰａｙｍｅｎｔ（アリス，Ｐａｙｍｅｎｔ４７）（canAuthorizePayment(Alice,Payment47)）を呼び出し、これにより、以下の照会がトリガされる。すなわち、  
Ａｄｍｉｎは、アリスが、ＢａｎｋＭａｎａｇｅｒＩＤ  ｉｄを有すると述べる，  
（Ａｄｍｉｎは、アリスが、Ｐａｙｍｅｎｔ４７を開始したと述べる）でない  
（Admin says Alice possesses BankManagerID id,  
not(Admin says Alice has initiated Payment47)）  
もたらされる答えセット（例えば、要求が拒否されるべき場合、空のセット、またはｉｄに関する変数割り当て）が、リソース・ガードに戻され、すると、リソース・ガードは、そのポリシーを執行することができる。
【０１１１】
セキュリティ許可照会の形式的評価もまた、比較的厳格な論理的見地から説明されることが可能である。以下の説明は、「ｅは、事実を述べる（ｅ  ｓａｙｓ  ｆａｃｔ）」という形態の所与のステートメントが、許可コンテクストＡＣから推定可能である代入のセットを戻す別のアルゴリズムの存在を想定する。そのようなアルゴリズムは、例えば、ＡＣを、Ｄａｔａｌｏｇなどの別の論理的言語に変換することに依拠することが可能である。ファンクションＡｕｔｈＡｎｓACが、以下のように許可照会上で定義される。すなわち、
ＡｕｔｈＡｎｓAC（ｅは、事実を述べる）＝｛θ｜ｅθは、ｆａｃｔθを述べるが、ＡＣから推定可能であり、かつＤｏｍ（θ）⊆Ｖａｒｓ（ｅは、事実を述べる）｝  
ＡｕｔｈＡｎｓAC（ｑ1，ｑ2）      ＝｛θ1θ2｜θ1∈ＡｕｔｈＡｎｓAC（ｑ1）であり、かつθ2∈ＡｕｔｈＡｎｓAC（ｑ2θ1）｝  
ＡｕｔｈＡｎｓAC（ｑ1  ｏｒ  ｑ2）＝ＡｕｔｈＡｎｓAC（ｑ2）∪ＡｕｔｈＡｎｓAC（ｑ2）  
ＡｕｔｈＡｎｓAC（（ｑ）でない）  ＝｛ε｝  Ｖａｒｓ（ｑ）＝０であり、かつＡｕｔｈＡｎｓAC（ｑ）＝０である場合  
＝０        Ｖａｒｓ（ｑ）＝０であり、かつＡｕｔｈＡｎｓAC（ｑ）≠０である場合  
＝不定      それ以外の場合  
ＡｕｔｈＡｎｓAC（ｃ）            ＝｛ε｝  Ｖａｒｓ（ｃ）＝０であり、かつｃが、有効である場合  
＝０        Ｖａｒｓ（ｃ）＝０であり、かつｃが、有効でない場合  
＝不定      それ以外の場合  
（AuthAnsAC(e says fact)={θ|eθ says factθ is deducible from AC and Dom(θ)⊆Vars(e says fact)}  
AuthAnsAC(q1,q2)   =      {θ1θ2|θ1∈AuthAnsAC(q1) and θ2∈AuthAnsAC(q2θ1)}  
AuthAnsAC(q1 or q2)=      AuthAnsAC(q2)∪AuthAnsAC(q2)  
AuthAnsAC(not(q)) = {ε} if Vars(q)=0 and AuthAnsAC(q)=0  
=  0   if Vars(q)=0 and AuthAnsAC(q)≠0  
=      undefined otherwise  
AuthAnsAC(c)     = {ε}  if Vars(c)=0 and c is valid  
=      0 if Vars(c)=0 and c is not valid  
=      undefined otherwise）
【０１１２】
以下の定理は、ＡｕｔｈＡｎｓACが、安全な許可照会を評価するためのアルゴリズムであることを示す。この定理は、許可照会評価の有限性、健全性、および完全性を表し、すなわち、すべての安全なアサーション・コンテクストＡＣ、およびすべての安全な許可照会ｑに関して、  
１．ＡｕｔｈＡｎｓAC（ｑ）が、定義されて、有限であり、かつ  
【０１１３】
【数４】
2010503123.tif 000006
【０１１４】
図１〜図１０のデバイス、アクション、態様、フィーチャ、ファンクション、プロシージャ、モジュール、データ構造、プロトコル、構成要素などは、複数のブロックに分割された図において例示される。しかし、図１〜図１０が説明され、さらに／または示される順序、相互接続、相互関係、レイアウトなどは、限定として解釈されることは意図しておらず、セキュリティ許可照会のための１つまたは複数のシステム、方法、デバイス、プロシージャ、媒体、装置、ＡＰＩ、プロトコル、構成などを実装するように、任意の数のブロックが、任意の仕方で変更され、組み合わされ、再構成され、増補され、省略されることなどが可能である。
【０１１５】
システム、媒体、デバイス、方法、プロシージャ、装置、機構、スキーム、アプローチ、プロセス、構成、およびその他の実施形態が、構造上、論理上、アルゴリズム上、および機能上の特徴および／または図に特有の言葉で説明されてきたが、添付の特許請求の範囲において規定される本発明は、前述した特定の特徴または動作に必ずしも限定されないことを理解されたい。むしろ、前述した特定の特徴および動作は、特許請求の範囲を実装する例示的な形態として開示される。
【図１】
2010503123.tif 000007
【図２】
2010503123.tif 000008
【図３】
2010503123.tif 000009
【図４】
2010503123.tif 000010
【図５】
2010503123.tif 000011
【図６】
2010503123.tif 000012
【図７】
2010503123.tif 000013
【図８】
2010503123.tif 000014
【図９】
2010503123.tif 000015
【図１０】
2010503123.tif 000016
【国際調査報告】
2010503123.tif 000017
2010503123.tif 000018