[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Comparing ACME with WS Policy framework
[Reference: "A technical comparison of WS-Policy framework and XACML" attached to http://lists.oasis-open.org/archives/xacml/200301/msg00021.html] On 29 January, Tim Moses writes: [xacml] Comparing ACME with WS Policy framework > Colleagues - Here are some preliminary thoughts on the relationship between > the OASIS standard XACML and the proprietary WS Policy framework. I am > interested in other people's views. All the best. Tim. I finally had time to read this over. Thanks for doing this analysis, Tim! It raises some interesting ideas. First of all, I have some doubts about how easy it would be to "extend" XACML to support negotiation/resolution of two sets of requirements. XACML wasn't designed for that, but it might be an interesting research project. "Policy" means different things in different contexts. XACML supports "access control policies". There are also policies for provisioning services, policies for management and monitoring of services, etc. The requirements of the various "policy" domains are rather different, as in the present case where "access control" merely combining Boolean results of sub-policies, but WS-Policy requires actual "merging" of multiple policies. Just above the table, the comparison says "...the result of the [WS-Policy] combining-algorithm is not a Boolean, but a definitive policy statement that is devoid of options." I think the result might include options: for example, if I merge my preferences with those of my organization, I might get a more restricted list of "options" that are then merged with my correspondent's options to return a single choice. At any step, the combining-algorithm might need to return a new set of 1st choice, 2nd choice, 3rd choice, etc. The comparison suggests that XACML "Policy set" is similar to WS-Policy "policy inclusion". Can you explain further? I would have thought from the description (policy inclusions [is] a technique which allows a policy to be referenced from another policy) that "PolicyIdReference" and "PolicySetIdReference" is the XACML construct most comparable to WS-Policy "policy inclusion". The description of under "XACML Policy" mentions "algorithm to be used for combining those rules." I think a more accurate description is "algorithm to be used for combining the results of evaluating those rules." We did not want to tackle "merging" even of policies that consist of Boolean expressions. I think "merging" non-boolean statements might be even harder. Nevertheless, when I think of the specific "merge" functions described - OneOrMore, All, ExactlyOne - it seems do-able. On the other hand, if the statements are annotated with Required, Optional, Rejected, Ignored, and Observed, there are more states to handle. I agree that there seems to be no real benefit in supporting the declarative form of statement in WS-Policy. Anne Anderson -- 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] | [Elist Home]
Powered by eList eXpress LLC