[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC