RE: [xacml] Open issues in delegation

[Tim Moses <tim.moses@entrust.com>]

Title: RE: [xacml] Open issues in delegation

Erik - Great analysis.  Thanks very much.  Your list makes a good agenda for today's focus group meeting and the face-to-face.

I have addressed a small number of your concerns in Draft 03.  Hopefully, everyone will be conversant with its pseudo-code description when we meet later today.

1. I agree that negative administration rights can be ignored for the time-being.

2. Administration policies for creating "deny" access policies seem a bit more useful to me.

3. PDPs have a "base policy", that is what determines how isolated access polices are combined.

4. Currently the pseudo-code only recognizes administration policies with a "permit" result.  The "combining algorithm" is built into the pseudo-code definition.

All the best.  Tim.

-----Original Message-----
From: Erik Rissanen [mailto:mirty@sics.se]
Sent: Wednesday, April 20, 2005 6:49 AM
To: xacml@lists.oasis-open.org
Subject: [xacml] Open issues in delegation

Hello,

Here are some issues with delegation that I have thought about that still need to be resolved in the current draft. Some of them might be topics at the F2F.

* Are there such things as negative administrative rights? At the access level currently XACML makes it possible to define a deny effect, which depending on the combining algorithm may ovverride a permit effect of another rule/policy. Should we in the same spirit support negative administrative rights? In other words, should it be possible to say something as "X may not create a policy for situation Z". I doubt that this is useful, but should we consider this before we lay it at rest?

* What about administrative policies for creating policies which have a deny effect at the access level? I think this is also not very useful but we may want to support in general.

* Related to this is that we need to formally define the environment in which policies from different issuers are combined. An XACML access request always starts with a single policy or policy set (correct me if I am mistaken). If we have policies from multiple sources, they need to be collected into policy sets, so their results can be combined. The processing model in the current proposal (draft 02) is really about defining a particular policy combining algorithm that uses issuer information.

Briefly, the processing model in general for XACML 3.0 should be defined something like this:

Every policy has an issuer, either explicitly by definition by the issuer element, or if the issuer element is not present, the issuer is implicitly the "PDP" (or "root") issuer.

- Rule evaluation happens like in previous versions of XACML.
- Policy evaluation happens like in previous versions XACML, except the resulting policy value is associated with the policy issuer.

- Policy set evaluation happens mostly like in previous versions of XACML, except that a policy combining algorithm MAY take the issuer of a policy result into account when combining the policy results. The result of the policy set is associated with the policy set issuer.

Within this general processing model we should define a combining algorithm called "permit-overrides-authorize-issuer" or the like. This is a policy combining algorithm that evaluates the policies at the level of the current request. Now, depending on the results, several things may happen (I haven't thought about all the possible cases yet):

- A deny result with a non "PDP" issuer is dropped.
- A permit result with a non "PDP" issuer is reevaluated as an administrative request, and the result of that recursive result replaces the result when combining the policies. The recursion happens only within the current policy set, not from the top level policy set in the PDP. (I am not 100% certain about this.)

- A PDP issued result is kept as it is.

This process, when finished, leads to a number of PDP issued results. If at least one of them is permit, the result of the policy set is a permit, otherwise a deny. (Or perhaps a not applicable. We should define a table of all possible combinations.)

This is essentially the processing model that is in the current draft, though I don't use the "pool" terminology. Another difference is that I define that the repeated requests should be evaluated only in the current policy set, not at the top level in the PDP, since the end result of the policy combining should be a result that is associated with the issuer of the current policy set only. This processing model permits nesting of policy sets with different issuers and allows for the definition of new combining algorithms in the future.

The above combining algorithm does not allow anything negative at the administrative level, but the general processing model would support combining algorithms that define different semantics, leaving it open in the future to include negative rights.

What I basically say is when a policy or a policy set is evaluated, the result is associated with the issuer of the policy or policy set. If the policy or policy set is a part of another policy set, then the combining algorithm in that policy set has to define what the significance of the issuer is. The "permit-overrides-authorize-issuer" algorithm ignores any negative results at the policy level and authorizes any positive results. Other algorithms may define different semantics.

My suggestion is that we for now ignore negative stuff at the administrative level by defining only the "permit-overrides-authorize-issuer" algorithm. Once we undestand that simpler case, we can consider more complex ones.

Now to something completely different. Some other issues that still need to be defined:

* We need to define what to do with obligations when policies are combined at different levels of administration.

* As Tim already pointed out at the last focus group meeting, we need ot define a new element in the request context which will hold the issuer/administrative subject.

There are also a couple of issues that are perhaps not quite in the scope of XACML. I am thinking about the relation to attributes.

Attributes matter for access control since we define policies in terms of them. If we are to consider administration of access control in an application, then we cannot really consider it in isolation without considering administration of attributes. I think the delegation model in the current proposal is good and is not affected by this issue, but the use of it is affected by the relation to attributes. One important such influence is the use of attributes in root policies. This in effect delegates (in a different fashion) power to those who control the attribute, in which case the PDP may want to approve all administration of that attribute. This may or may not be an issue depending on how distributed and decentralized the application is.

There is one issue with attributes that may be something for the XACML TC to consider. Should we define any temporal semantics for attributes with respect of delegation? Consider a regular access request. An access permission says that a person that satisfies the attribute constraints in the permission may access the resource. At the time of acceess, we collect the attributes of the subject and compare them with the constraints in the permission.

An adminstrative permission is a permission about the act of changing policy. When we verify the right to issue a given policy, we will compare the attributes of the issuer of the policy with the attributes in the administrative permission. Now, the question is, when we look for the attributes of the issuer, at what point in time should we do that?

At the time of the access request, or at the time when the policy was issued?

If the administrative permission is the right to issue a policy, the right was really exercised at the time the policy was issued, not when the end user requests for access. On the other hand, it may difficult to verify at what time a given policy was issued. We may want to leave this for the application to define.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  You may a link to this group and all your TCs in OASIS

at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php