[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
Dear Michiharu, We still do not think XACML needs Properties. The requirements of the provided use-case can be satisfied using existing combining algorithms plus an ordered version of an existing combining algorithm. Our comments are in-line. Anne Anderson and Seth Proctor On 9 May, Michiharu Kudoh writes: Re: [xacml] Proposed XACML 1.1 Solution for Item F1:Properties for new combining 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. Yes, that is Anne's definition. A "custom" XACML PDP is one that contains functionality not specified in the XACML 1.0 standard. XACML has defined standard ways to define extensions to XACML 1.0, but not standard ways to implement extended functionality. "Custom" means that one can't buy a vanilla XACML PDP from some vendor that will handle new combining algorithms, and policies that specify a new combining algorithm can not be evaluated by a vanilla XACML PDP. We still don't see any advantage to standardizing a "Properties" element. Policies that use Properties MUST be evaluated by a PDP that has special code added to implement the special combining algorithm that uses the Properties. Since new, algorithm-specific code has to be added to implement a new combining algorithm, why not add new code at the same time to parse policies that contain a custom extension to define some sort of CombiningAlgorithmParameters element? [more comments follow below] > 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." This use-case requirement can be met by using the proposed "ordered-deny-overrides" along with the existing "only-one-applicable" combining algorithms, as follows. <PolicySet PolicyCombiningAlgId="ordered-deny-overrides" PolicyId="PS1"> <Target>... <PolicySetIdReference>Customer1PolicyStrong</> <PolicyIdReference>Customer2PolicyWeak</> <PolicyIdReference>SitePolicy</> </> <PolicySet PolicyCombiningAlgId="only-one-applicable" PolicySetId="Customer1PolicyStrong"> <Target>Customer1</> <PolicyIdReference>Customer1Policy</> <PolicyIdReference>SitePolicy</> </> <Policy RuleCombiningAlgoId="PermitOverrides" PolicyId="SitePolicy"> <Target>Any</> <Rule Effect="Permit">... ... </> <Policy RuleCombiningAlgoId="PermitOverrides" PolicyId="Customer1Policy"> <Target>Customer1</> <Rule Effect="Deny">... ... </> <Policy RuleCombiningAlgoId="PermitOverrides" PolicyId="Customer2PolicyWeak"> <Target>Customer2</> <Rule Effect="Permit">... ... </> "Properties" has one capability that this solution does not provide: it allows an individual policy writer to override other policies in the system without having to understand the system as a whole. But a general override mechanism is very insecure: a low-level policy writer does not know which other policies it is appropriate to override. It allows a policy writer with limited knowledge to override another policy improperly because an individual policy writer does not have a view of the entire policy hierarchy. One final point: although we think combining algorithm properties should not be added to XACML 1.1, if they are added, we think they should be simpler than the proposed Properties element. We suggest using an xml attribute instead, even though it is not so flexible. [no more comments follow] > > 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 > > > > > > -- 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]