[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Proposed XACML 1.1 Solution for Item F1:Properties for newcombining algorithms
> Since any PDP that understands one of these new
> combining algorithms that requires parameters will need to be a
> custom PDP, why not let this be a custom extension?
In your definition, is any PDP that uses custom function(s) a custom PDP?
Is any PDP that uses custom data type(s) a custom PDP? If so, I agree that
any PDP that understands one of these new combining algorithms is a custom
PDP.
My observation is that the current XACML schema allows implementers to
define new functions with arbitrary arguments while it is not in the case
of new combining algorithms. As Simon suggested in the call yesterday, I
think we need a placeholder for a list of attributes for the custom
combining algorithm.
The following is a use case that you might be interested.
- Use case: Privacy protection policy
As you may aware, privacy protection policy has a policy structure similar
to the access control policy (it sometimes requires purpose attribute but I
ignore it here). Suppose that each customer specifies a privacy protection
policy for their profile data stored in the merchant server as a XACML
policy (including one or more rules) and a site administrator specifies a
policy to combine the customers' policies (as a policy set). The site
administrator also specifies privacy protection policies that guarantees
the appropriate operation in the company. When the customer writes their
policy, they may specify that their policy never be overridden by the site
policy if exists. It is a strong customer policy. When the customer has no
strong preference on his/her policy, it becomes a weak customer policy and
may be overridden by the site policy. This enables the customer's
preference (if exists) takes precedence over the site policy.
If this is the case, we need to have the place to store "strong" or "weak"
preference parameter of the customer policy. The site administrator uses a
custom policy combining algorithm that checks the significance of
customer's policy which generates the decision based on the conflict
resolution scheme such as strong policies overrules any weak policies. The
terms of strong and weak might be different according to the domain, for
example "final" might be used in other domain, or integer values might be
used instead.
The following example shows a simple policy. The policy "PS1" and "P-Site"
are site policies and the policy, respectively. "P1" and "P2" are
customer's policy, Alice and Bob, respectively.
(The following shows just a rough structure, not the precise one.)
<PolicySet PolicyCombiningAlgoId="StrongWeakAlgo" PolicyId="PS1">
<Target>...
<PolicyIdReference>SitePolicy</>
<PolicyIdReference>Policy1</>
<PolicyIdReference>Policy2</>
</>
<Policy RuleCombiningAlgoId="PermitOverrides" PolicyId="P-Site">
<Property>type:significance, value:weak</>
<Target>...
<Rule Effect="Permit">...
...
</>
<Policy RuleCombiningAlgoId="PermitOverrides" PolicyId="P1">
<Property>type:significance, value:strong</>
<Target>...
<Rule Effect="Deny">...
...
</>
<Policy RuleCombiningAlgoId="PermitOverrides" PolicyId="P2">
<Property>type:significance, value:weak</>
<Target>...
<Rule Effect="Permit">...
...
</>
A custom algorithm "StrongWeakAlgo" reads each policy, refers to the rule
significance argument such as "strong" and "weak", and follows the conflict
resolution described above. If SitePolicy and Policy1 are applicable
policies against a certain access request, then the Alice's policy
overrules the site policy. If SitePolicy and Policy2 are applicable
policies, then some conflict resolution criteria is applied (e.g.
deny-overrides).
At a first glance, the "StrongWeakAlgo" seems solvable by using ordered
versions of permit-overrides and deny-overrides combining algorithms but
actually not. It is because that the conflict resolution is based on the
policy significance parameter specified by each customer, not on the order
of the PolicyIdReference specified in the "PS1". Using <Property> element
and the custom algorithm, the above problem is easily resolved. Note that
<Property> element is needed even if we standardized the custom algorithm.
For the algorithm, StrongWeakAlgo policy combining algorithm can be stated
as:
"In the entire set of policy in the policy set, any policy which has
"strong" property overrides any policy which has "weak"property. If the set
of policy has only "strong" policy and they conflicts, then "Indeterminate"
SHALL be returned. If the set of policy has only "weak" policy and they
conflicts, then deny policy overrides permit policy."
I have no strong opinion on whether or not this algorithm should be
standardized because this kind of algorithms often differs from company to
company.
Michiharu Kudo
Anne Anderson
<Anne.Anderson@Su To: Michiharu Kudoh/Japan/IBM@IBMJP
n.com> cc: XACML TC <xacml@lists.oasis-open.org>
Subject: Re: [xacml] Proposed XACML 1.1 Solution for Item F1:Properties for new combining
2003/05/08 21:34 algorithms
Please respond to
Anne.Anderson
I still think this proposal adds a dangerous "catch-all" element
to XACML. Since any PDP that understands one of these new
combining algorithms that requires parameters will need to be a
custom PDP, why not let this be a custom extension? Why do we
need to standardize it?
Before we standardize an element like this, I think we need a
strong use case based on actual customer demand. The use case
would need to require that we would standardize one or more
combining algorithms that require this element at the same time.
As we worked on standardizing such an algorithm, we could better
consider whether this <Property> element is really the best
solution, or if there is something more controllable that would
suffice.
Anne
--
Anne H. Anderson Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]