Re: [xacml-users] retrieving a list or query filter of resourcesthe caller is authorized for

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi Yoichi,

Some thoughts in response to your comments inline.

    Thanks,
    Rich

Yoichi Takayama wrote:

4D2560EC-5EEA-4EA5-B50A-42899BAA2AB9@gmail.com" type="cite">Hi Rich,

(A) The use of Obligations or Advice

An interesting preposition, although I don't agree with using the <Obligations> for any such purpose.

There are two components (or phases) in XACML Access Control.

(1) All factors that the PDP can determine from Target, Policies and Attributes.

(2) Additional factors only the user or the PEP can supply.

The latter uses the Obligations. Therefore, it is not fit to include any Responses about what PDP should/can determine into the <Obligations>. 

The suggestion to use <Advice> is not satisfactory, either. Because this is defined as an element that the PEP can safely ignore.

An example in the OASIS XACML 3.0 specification contains a Policy that requests the Obligation that the PEP should send an email to the patient contact before the access is to be granted. Since such an Obligation cannot be met by PDP, it is a job for the PEP.

Another example commonly used is a case, in which the end user must read and agree with the Conditions and Terms. This also cannot be performed by PDP. When the Decision comes back and the PEP gets back to the end user who triggered PDP decision, the PEP has a chance to collect the user response whether the user agrees with the condition of the use.

From my perspective, the query can be regarded as a request for a list of resources. The Obligations that the Policy returns in response may be regarded as: the PEP MUST execute these queries against the resource store in order to return the list that has been requested.

The PDP cannot, in principle, return a list of resources, because it has no direct knowledge of the resources. Furthermore, the resource store may be in a state of constant change as resources are added and removed to the repository. What the PDP has is the PolicySets governing access to the resource repository. It is able to do this because, in general, a repository has language semantics that can be used to define scopes of resources within the repository. When the XACML Request is for the list of resources, it is only the PDP that knows how to generate this list, and at the same time the PDP is unable to generate the list, and therefore, to satisfy this request, can only return the instructions to the PEP for how the PEP can generate the list.

In the model you have suggested that:the PDP determines its response from the Target, Policies, and Attributes, I think the proposed solution is in that category, as what is returned is the set of applicable expressions from the Policies as determined by the Targets. For each applicable PolicySet, if the request is for the resource, then the rule is applied to the resource-id, but if the request is for the "list" of resources, then what is returned is the rule that would have been applied to the resource-id if it had been provided. It is only the PEP or other external entity that can produce the list and it is only the PDP that can provide the command that will produce the list.

4D2560EC-5EEA-4EA5-B50A-42899BAA2AB9@gmail.com" type="cite">

(B) Theoretical considerations as to the nature of rules resulting from the Policies and how to query over them

The XACML Target, Attributes, logics (combining algorithms and conditions etc.) and Permissions may be thought of a Function:

   f (Target | Policies) -> Decision i.e. Permit or Deny

More precisely, f is,

   f (Target | Policies, a1, a2, a3, ...) -> Decision i.e. Permit or Deny

where a1, a2, a3, ... are Attribute values that are used in the Request's Target and relevant Policies. They contain subject-id, action-id, resource-id, etc. which are literal values, not variables. The id values inside the Target may be of the ANY value (or not defined).

The problem we are trying to solve is to find a kind of inverse function: (Note that we are not looking for an exact inverse function of f).

  g (Permit | Policies, subject Attributes) -> {[action-id, resource-id] , ...}

where action-id and resource-id are literals or the ANY value. It returns a set of 2-tuple elements. The ANY value will make it unnecessary for any more element with a different value for the element in the list. The subject Attributes can be a sub-set of all the subject Attributes. It may contain only the subject Attributes that appear in relevant Policies that are considered for the subject.

More precisely, g is,

  g (Permit | Policies, subject Attributes, a1, a2, a3, ... ) -> {[action-id, resource-id] , ...}

where a1, a2, a3, ... are Attribute values for Actions, Resources and Environment, which appear in all the Policies that are the matches in the context of the function, dependent on the given parameters.

Since there is no general solution for this problem (for non-specific, i.e. generalised, Policies, Actions and Resources), we can solve this only on the cases where all entities, i.e. Policies, Actions, Resources and Environment are finite.

From the given Policies and the subject (and the other Attributes) of the query context, the problem is to identify the relevant subsets and see what [action-id, resource-id] tuples are the elements of those subsets. Since Attributes are often expressed as variables in Policies, there would be situations where there may be no element in some subsets.

Assume that all [action-id, resource-id] tuples are sorted and categorised into subsets as the Policies dictate (how to do this is considered later), the question is whether finding the right subsets and the elements is equivalent to using the fixed value Prefix and a single wildcard Suffix for RegEx to search for the [action-id, resource-id] tuples.

Assumptions:

1. A Policy can be interpreted as a single RegEx for Resources

2. The RegEx consists of a fixed value Prefix (e.g. /A/B/C) and a wildcard Suffix (i.e. *).

3. Resource Handles (a mapping of the real Resources references in order to enable the RegEx search) can be searched with RegEx properly to return a set of matched Resources properly.

4. A Resource can be mapped to a Resource Handle. The mapping is maintained somewhere.

5. We are interested in the Permit outcomes only.

1'. Since a Policy may contain multiple Attributes and conditions, the RegEx must have a capability to accommodate all these that are essential to give the Permit outcome only. (We are not interested in Deny or others).

2'. In the example given, each level inside the PATH expression seems to correspond to a condition and its value that the RegEx can examine. E.g. A Resource may be in a condition /A/B/C, while another one in /a/B/c. It indicate that the predicates used are the same but the predicate values are different.

2''. The Suffix represents each Resources within that privilege subset.

2'''. The necessary Attributes values are expressed as 2'.

3' & 4'. The Resource Handle represents all subsets exist plus a specific Resource Id for an individual Resource.

5'. Since a Policy may contain multiple Permit outcomes, the RegEx must have a capability to accommodate all Permit occurs into one RegEx syntax, e.g. must use logical OR.

6. It is expecting a list of Resources but this should be amended to get a list of [action-id, resource-id] tuples in our case.

Proof

If we can demonstrate that any of the XACML Policy syntax capabilities cannot be done with RegEx, that is an anti-Proof to deny the conjecture.

It, however, seems it can done in case of a single Policy. It also seems possible to express the Policy-combining algorithms, e.g. Permit-overrides, Deny-overrides, Ordered-Permit-overrides, First-applicable, and so on.

Direct Proof may be given to demonstrate whether all XACML syntax may be expressed in RegEx. That can be done but I will skip such an effort.

I am not sure I agree with the problem statement here. It appears to be saying that in order to provide a response to a query, that response must return a function that is the exact inverse of whatever constructs could conceivably put into a Policy.
To me, that is an academic problem, as opposed to a real world problem. If an enterprise places constraints on the manner in which Policys are allowed to be specified, then I think it is reasonable to be able to produce responses that are within the scope of those constraints.
For example, my suggestion was to define the query for hierarchical resources. For a single hierarchy, the solution is fairly simple if access is only allowed to permitted resources - just return the list of regexps, and the pep can execute the queries and return the collected list.
If the situation involves more complex rules, such as mixing permits and denies, then the returned lists will have to specify whether they are permits or denies, and a combining algorithm, such as permit-overrides or deny-overrides, which then puts responsibility on the PEP to understand how to execute the individual regexps and combine the results.
I have not analyzed this more complex use case, but it seems to me to be manageable for a set of well defined hierarchies, where the rules are all defined in terms of a syntax used for those hierarchies.
Also, I think one must consider that at some point, making the policies too complex actually reduces the effectiveness of the system because it becomes very difficult to understand the rationale for decisions that are made by the system, which represents a loss of control by management over the organization.

4D2560EC-5EEA-4EA5-B50A-42899BAA2AB9@gmail.com" type="cite">

(C) Modifications/comments

The Resource Handle mapping for RegEx is not a part of XACML. Although it can be done by the PIP to return such a vlue as an Attribute and use it in the Policies, it is better if one can write Policies without using Handles.

By any rate, how to construct Handles encompassing all Predicates may not be trivial (depending on the number of Policies).

This type of query should be done not as an XACML Query but outside its scope. How the [action-id, resource-id] listing is done should be a blackbox.

One other thought is that the query could conceivably be done in 2 phases:

1. based on the returned regexps, the PEP can obtain a potential list of concrete resources.
2. the PEP can then, one at a time, submit the entries from the potential list to the PDP which can apply the more complex predicate to the individual resource, and based on the returns the PEP will remove specific items from the list to be returned to the caller.

4D2560EC-5EEA-4EA5-B50A-42899BAA2AB9@gmail.com" type="cite">

The Handle values may have to be dynamically revised when new Policies or predicates are dynamically added.

Yoichi

On 19/04/2010, at 2:30 PM, Rich.Levinson wrote:

Hi Ralf, Yoichi, et al,

I have been following this discussion with interest as part of the OpenAz open source effort is to provide a query capability. The intent of OpenAz is to enable XACML to be brought into enterprise environments in a seamless manner, allowing migration on an as-needed basis to enable XACML capabilities to be introduced to the enterprise.

That aside, the technique we have been looking at is focused on hierarchical resources and the use of regular expressions to address scopes of those resources. This is also consistent with the notions in the XACML Multiple and Hierarchical Profiles.

Basically, hierarchical permissions can be simply thought of as a regular expression containing a fixed prefix and a wildcard suffix, where any resource name that matches the prefix is within scope of the expression.

Generally this expression can be applied to the resource store to get a list of the concrete resources covered by the expression. Therefore if a Policy can be defined that will return the list of applicable regular expressions contained within the policy for the specific request, then this list of expressions can be applied to the resource store in order to get the full list of concrete resources covered by the query.

Therefore the trick is how to get this list of regular expressions out of the policies. The attached zip file contains a policy that provides this capability, along with sample requests and responses that were obtained by running the requests against the SunXacml PDP being used in the OpenAz project.

The trick that is used is to use a PolicySet to contain a pair of Policys. One of the pair contains the actual regular expression used for access control. The other of the pair returns an Obligation containing an AttributeAssignment that contains a copy of the regular expression. The way to get the 2nd policy of the pair invoked is to query for the specific string "/-" which is simply a string used in all the "2nd policies" and so all policies that contain this resource will match the query.

Note: none of this effort is focused on performance, and is intended at this time just to demonstrate capabilities. It is expected that optimizations will be need to enable scalability.

Note: since SunXacml is based on XACML 1.1 there are a few 1.1 artifacts floating around, but these are rather trivial, and do not impact the overall structure of things, at least in the current phase of the OpenAz project.

Comments and suggestions are welcome.

    Thanks,
    Rich