Originally, I asked “How do you write a policy that requires a subject be granted access to a requested permission, where the set of allowed permissions is in an external attribute store. Can you reference an external set of permissions in a policy?” The second question has been answered in the affirmative, so I’m revising the question a bit to focus on the “how”.
Can someone provide a xacml policy snippet (or even pseudo-xacml) that requires a role attribute id (will be provided by the request) to be within a set of roles which are identified by another attribute id (managed by external attribute store).
For the sake of providing a starting point, the following is an example from http://docs.oasis-open.org/xacml/2.0/XACML-2.0-OS-ALL.zip. In this case, the role is inline.
<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>
Yes, policies can be written to reference attributes that come from an external attribute store.
However, where the attributes actually come from is usually not specified in the policy itself, other than perhaps by a naming pattern in the attribute ID. In the XACML PDP reference architecture, it’s the responsibility of the request context handler to resolve attribute IDs and produce values for the PDP.
It goes something like this: While evaluating a request against a set of policies, the PDP encounters an attributeID in a policy rule that it needs to form a decision about the request. The PDP asks the request context handler to get the value of that attributeID “from whereever” – the PDP doesn’t care where it comes from. The request context handler may look for the attribute in the attributes provided with the request, or in any number of external attribute providers, such as LDAP or AD or SAML or plain old databases. The request handler might recognize naming patterns (like, namespace prefixes) in the attributeID to know where to obtain it.
You want your attributeIDs to be specific enough to know what they are and what they mean, but not so specific that all of your policies break when you move your attribute provider to a different machine. Policies should be configuration independent.
Ultimately, where the request handler looks for attributes is a matter of configuration of the request handler / PDP server, and will vary by product vendor.
Update: To answer the 2nd revision to this question
You would write your policy to perform a comparison between the attribute value(s) provided in the request and a list of values provided by an external source.
Keep in mind that an attribute designator returns a list of values, since the request could contain multiple attribute values for the same attributeID. You can accommodate that by either by wrapping the attribute designator in a “one-and-only” reduction function, or by using a many-to-many cross product match function that will test every member of list1 for a match in list2.
Unless you have a specific design requirement that the request is only allowed to contain one role attribute, it’s best to avoid the “one-and-only” reduction since it really limits your options.
Your Xacml 2.0 policy could look something like this: (forgive syntax errors, my Xacml 2.0 is a little rusty)
The Xacml function “at-least-one-member-of” takes two lists as parameters. For every item in the first list, it tests to see if that item exists in the second list. It returns true as soon as it finds at least one match.
The attribute “…example:attribute:role” from your example is the attribute you’re expecting to be provided in the request. If you want to enforce that the attribute must be provided in the request, you can set MustBePresent=”true” in the attribute designator.
The “list-of-acceptable-roles…” attribute is an attribute id that your PDP context handler recognizes and retrieves from some external provider. What prefix or pattern the context handler looks for and which provider it fetches from is a matter of PDP configuration.
Ideally, the naming pattern on the attribute id indicates a conceptual domain or namespace the id is associated with, but the id does not explicitly indicate the physical location or provider of the attribute value(s). For longer app lifetime with lower maintenance costs, you want to be able to change your provider implementation details without having to rewrite all of your policies.
You can have vendor-specific attribute ids that will probably only come from a single provider, you can have application-specific attribute ids that could be supplied by multiple providers but only make sense for a particular application, and you can have generic or standardized attribute ids that could come from multiple providers and be used in multiple applications. The Oasis standards body and domain-specific profiles are a good starting point for finding standardized attribute ids and their semantics or getting ideas on how to organize your own app specific ids.
Depending on your PDP and context handler implementation, it may also possible to use the “Issuer” field as a way to constrain the list of providers for an attribute. The Xacml spec doesn’t say much about use of the Issuer field, but the same goals of decoupling policy from provider implementation details still holds.