RE: [xacml] [model] implementing global "deny" using 0.8 and meta-policies

Title:  RE: [xacml] [model] implementing global  deny  using 0.8 and meta-policies
I am  not suer if I agree with Anne's approach. I certainly like it better than  the alternative proposed.

I  actually thought we had previously agreed that there had to be some rules  (policy) for detemining how independantly created policies should be combined to  acheive an authorization decision.

Instead of meta-policy, which I think Ernesto fears will be take to mean
more abstract policy  or  policy about policy , perhaps something  like Policy Federation Rules would be better.

It  seems to me the key issues are:

1.  Where and how are PFR specified? Anne's approach is a distinct XML document,  which must be consistent throughout the policy federation. This seems reasonable  to me.

2.  What are the possible PFR's? I think  AND  is impractical, and  OR  is most  likely, however some kind of best-match-to-target is conceivable anthough  perhaps too expensive to implement in practice.

3. Do  all legal PFR's have to support all decision strategies? I have been thinking  about this and I think the right approach is to explictly call out the possible  decision strategies and for each legal PFR state which can or cannot be  used.

Here's  what I have so far on decision strategies.

Strategy I - Basic

Collect all applicable policies
Obtain  all required inputs
Evaluate all policies
Apply  PFR to resolve conflicting results

Strategy II - Optimized

Collect all applicable policies
Use  PFR to create equivalent combined policy
Evaluate policies incrementally, gathering inputs as needed, defer  evaluations based on inputs requirements
(this  for example allows  lazy authentication  where authentication is not done if the  result can be determined without it)

Once  the result is known, stop evaluation

Strategy III- Incremental collection

Collect  some  policies
Obtain  required inputs
Evaluate current policy set
Use  PFR to combine latest results with previous results (if any)

If  result is known, stop evaluation
If not  all policies have been collected, repeat previous steps

These  are all the possibilities I can think of. Can anyone think of others? I think  annything proposed to date works equally for I and II, but not all work for III.  However, we may find future possibilities that only work for one of  them.

To  answer Ernesto's question, our product uses  OR  for authorization decisions and
AND  for audit decisions and there have been no complaints. However we do not  have post conditions, which may change things.

As far  as the global deny, I would like to understand the requirements better. It seems  the problem Anne is trying to solve is  master policy admin can globally deny  regardless of what the policy combining rules are.  Is this the right problem to  solve? If a  OR  combining rule is used (which I happen to think is the most  common case) then any admin can implement a global deny without any special  machinery. I think the example given is a red herring to some extent, because  the right way to cut off an individual user is to change their attributes at the  Attribute Aurthority or revoke their credentials.

The  problem I see is that most evaluation engines will want to use a relatively  fixed decision strategy in order to optimize it according to the criteria that  apply in that environment. Finding it out in the middle of policy evaluation  will interfere with this goal.

Hal