2

もともと、「許可された権限のセットが外部属性ストアにある場合に、サブジェクトに要求された権限へのアクセスを許可することを要求するポリシーをどのように作成しますか。ポリシーで外部の権限のセットを参照できますか？」2番目の質問は肯定的に回答されているので、「方法」に焦点を当てるために質問を少し修正しています。

誰かがxacmlポリシースニペット（または疑似xacml）を提供できますか？これは、ロール属性ID（リクエストによって提供されます）が別の属性ID（外部属性ストアによって管理される）によって識別されるロールのセット内にあることを要求します。

開始点を提供するために、以下はhttp://docs.oasis-open.org/xacml/2.0/XACML-2.0-OS-ALL.zipからの例です。この場合、役割はインラインです。

<Subject>
    <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">administrator</AttributeValue>
        <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:role" 
                                DataType="http://www.w3.org/2001/XMLSchema#string"/>
    </SubjectMatch>
</Subject>
4

1 に答える 1

4

はい。ポリシーは、外部属性ストアからの属性を参照するように記述できます。

ただし、属性が実際にどこから来るかは、おそらく属性 ID の名前付けパターン以外では、通常、ポリシー自体では指定されません。XACML PDP リファレンス アーキテクチャでは、属性 ID を解決し、PDP の値を生成するのは、要求コンテキスト ハンドラーの役割です。

次のようになります。一連のポリシーに対して要求を評価しているときに、PDP は、要求に関する決定を行うために必要なポリシー ルールで attributeID を検出します。PDP は、リクエスト コンテキスト ハンドラーにその attributeID の値を「どこからでも」取得するように要求します。PDP は、それがどこから来たかは気にしません。リクエスト コンテキスト ハンドラは、リクエストで提供された属性、または LDAP、AD、SAML、単純な古いデータベースなどの任意の数の外部属性プロバイダーで属性を検索できます。要求ハンドラーは、attributeID の命名パターン (名前空間プレフィックスなど) を認識して、どこで取得するかを認識できます。

attributeID は、その内容と意味を理解できるほど具体的である必要がありますが、属性プロバイダーを別のマシンに移動したときにすべてのポリシーが壊れるほど具体的ではありません。ポリシーは構成に依存しない必要があります。

最終的に、リクエスト ハンドラがどこで属性を検索するかは、リクエスト ハンドラ/PDP サーバーの設定の問題であり、製品ベンダーによって異なります。

更新：この質問の2回目のリビジョンに答えるには

リクエストで提供された属性値と外部ソースによって提供された値のリストとの比較を実行するポリシーを作成します。

リクエストには同じ attributeID の複数の属性値が含まれる可能性があるため、属性指定子は値のリストを返すことに注意してください。属性指定子を「唯一無二」のリダクション関数でラップするか、list2 の一致について list1 のすべてのメンバーをテストする多対多の交差積一致関数を使用することで、これに対応できます。

リクエストに 1 つのロール属性のみを含めることを許可するという特定の設計要件がない限り、オプションが実際に制限されるため、「1 つだけ」の削減は避けるのが最善です。

Xacml 2.0 ポリシーは次のようになります: (構文エラーを許してください。私の Xacml 2.0 は少し錆びています)

<Policy [...] RuleCombiningAlgorithm="deny-unless-permit">
  <Rule [...]>
    <Effect>Permit</Effect>
    <Condition>
      <Apply FunctionId=”urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of”&gt;
        <SubjectAttributeDesignator
          AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:role" 
          DataType="http://www.w3.org/2001/XMLSchema#string"/>
        <SubjectAttributeDesignator
          AttributeId="list-of-acceptable-roles-from-external-provider-attribute-id"
          DataType="http://www.w3.org/2001/XMLSchema#string"/>
      </Apply>
    </Condition>
  </Rule>
</Policy>

Xacml 関数 "at-least-one-member-of" は、パラメーターとして 2 つのリストを受け取ります。最初のリストのすべての項目について、その項目が 2 番目のリストに存在するかどうかをテストします。少なくとも 1 つの一致が見つかるとすぐに true を返します。

例の属性「...example:attribute:role」は、リクエストで提供されると予想される属性です。リクエストで属性を指定する必要があることを強制する場合は、属性指定子で MustBePresent="true" を設定できます。

「list-of-acceptable-roles...」属性は、PDP コンテキスト ハンドラーが認識し、外部プロバイダーから取得する属性 ID です。コンテキスト ハンドラーが検索するプレフィックスまたはパターン、およびフェッチするプロバイダーは、PDP 構成の問題です。

理想的には、属性 id の命名パターンは、id が関連付けられている概念的なドメインまたは名前空間を示しますが、id は属性値の物理的な場所またはプロバイダーを明示的に示しません。メンテナンス コストを抑えてアプリの寿命を延ばすには、すべてのポリシーを書き直すことなく、プロバイダーの実装の詳細を変更できるようにする必要があります。

おそらく単一のプロバイダーからのみ取得されるベンダー固有の属性 ID を持つことができます。また、複数のプロバイダーによって提供される可能性があるが特定のアプリケーションに対してのみ意味を持つアプリケーション固有の属性 ID を持つことができます。また、汎用または標準化された属性を持つことができます。複数のプロバイダーから取得でき、複数のアプリケーションで使用できる ID。Oasis の標準化団体とドメイン固有のプロファイルは、標準化された属性 ID とそのセマンティクスを見つけたり、独自のアプリ固有の ID を整理する方法についてアイデアを得るのに適した出発点です。

PDP およびコンテキスト ハンドラーの実装によっては、属性のプロバイダーのリストを制約する方法として、"Issuer" フィールドを使用することもできます。Xaml の仕様では、Issuer フィールドの使用についてはあまり言及されていませんが、プロバイダーの実装の詳細からポリシーを分離するという同じ目標が引き続き保持されます。

于 2011-10-28T19:29:26.637 に答える