2

私の質問は、XACMLコンテキストハンドラーの役割と目的に関係しています。OASIS XACML3.0の仕様を正しく理解している場合、PEPは、クライアントアプリからのリソースまたはアクセスの要求をインターセプトし、コンテキストハンドラーを使用して、PDPが処理するのに適したネイティブXACMLコンテキストオブジェクトを作成します。私の設計では、リクエストオブジェクトを作成し、xml結果を解析するメソッドを持つグローバルクラスとしてコンテキストハンドラーを使用しています。私はクラスが次のように見えることを想像しています：

public static class ContextHandler
{
    public static bool CreatePolicy(PolicyType policyName)
    {
        // Serialize PolicyType to xml document

    }

    public static PolicyType LoadPolicy(string policyName)
    {
        // 1. Load policy from db, filesystem...
        // 2. Hydrate/deserialize into XACML policy object
        // 3. Return PolicyType object
    }

    public static RequestType BuildRequest(
        Dictionary<string, string> subjects,
        Dictionary<string, string> resources,
        Dictionary<string, string> actions,
        Dictionary<string, string> environment)
    {            
        // 1. Create AttributesType collection, populate with subjects, resource...
        // 2. Populate RequestType object
        // 3. Return Request

    }
}

オブジェクトRequestType、AttributesTypeおよびその他はXACMLコンテキストの一部です。

これはコンテキストハンドラークラスの正しいアプローチですか、それともコンテキストハンドラーのポイントを完全に見逃しましたか？

どうもありがとう！

4

3 に答える 3

2

コンテキストハンドラーはPDPの一部であると思います。PEPはSOAP呼び出しをインターセプトし、パラメーター値を抽出し、それらの値を使用して標準化された要求を作成し、要求をPDPに送信します。PDPは、その要求からパラメーター値を抽出し、いくつかのPIPを照会して追加の値を検索し、要求をそのポリシーと照合して決定に到達し、PEPに返送される標準化された応答を作成します。

于 2012-07-02T11:15:45.213 に答える
2

完全なXACML2.0/ 3.0実装では、すべての承認プロセスの実際の中央ノードまたはボトルネックは、PEPでもPDPでもないコンテキストハンドラコンポーネントです。公式ドキュメントで提案されているdataf-flowは、それを明確に示しています。

したがって、最初の質問は、「簡単にするために、コンテキストハンドラコンポーネントを別のコンポーネント内に固定するための良いアプローチですか？」ということだと思います。はい。そして、「はいの場合、最適な場所はPEPまたはPDPですか？」そうですね、それはあなた自身の実際のシナリオに依存すると思います。

一般的な単純なシナリオでは、たとえばPIPが必要ない場合は、コンテキストハンドラーをPEPドメインに固定することをお勧めします。そしてこれは多くの理由で：

  • 1つだけではなく多くのPEPがある可能性があるため、PEPとPDPの間のデカップリングを実現する必要があります
  • すべてのPEPは独自の特定の承認リクエストの仕様を知っているため、ネイティブリクエストを標準のXACMLリクエストに変換することができます。
  • 特定のPEPロジック、PEP依存関係（サードパーティライブラリ）、PEPコード管理（承認要求仕様の変更、バグ修正、新しいデプロイなど）の影響を受けない中央の標準PDPを取得します。

より複雑なシナリオでは、承認リクエストに、PDPが決定を下すために必要なすべての情報が含まれていない可能性があります。この場合、PDPはこれらの情報をコンテキストハンドラーに要求する必要があり、コンテキストハンドラーはPIPコンポーネントにアクセスして、これらのuser-resources-environment値を取得できる必要があります。PIPは通常、集中型リソースにアクセスするため、通常は集中型サービスです。PDPも通常は一元化されたサービスであるため、通常、 PDPとPIPは同じドメインにあります。

このシナリオでは、コンテキストハンドラーをPDPコンポーネントに固定したくなる場合があります。ただし、そうする場合は、単純なシナリオでデカップリングと上記のすべての機能が失われるため、他の問題に対処する必要があります。さらに、XACMLの仕様に従って、標準のPDPがXACMLメッセージを介して通信できることを期待していますが、コンテキストハンドラーを直接そこに配置すると、PDPは実際にPEPの母国語を話し始めます。

于 2014-01-13T17:36:48.747 に答える
0

はい。また、コンテキストハンドラーがPDPの一部になることを願っています。PEPは、アプリケーションと一緒に使用して、要求をインターセプトし、PDPに承認の決定を求めることができます。オープンソースのXACML3.0を見つけることができます。ここから「Balana」（sun-xacmlの改善）と呼ばれる実装。これは、XACMLエンジンとしてWSO2IdentityServerによって使用されます。そのソースから、コンテキストハンドラーの実装を詳しく説明するctxクラスを見つけることができます。また、このブログは、XACML3.0の新しいことを理解するのに役立ちます。

于 2012-07-23T04:47:04.087 に答える