[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue#61:WS-XACML:How are the contents of XACMLAuthzAssertionsrepresented in the base XACML Policies
At the Face-to-Face, I said I would re-state on the list some options about how to keep an enterprise's internal authorization policy consistent with its XACMLAuthzAssertion Web Services policy. Here they are. ---------------------------------------------------------------------- OPTION 0: Insert the entire enterprise policy in its full XACML Policy or PolicySet form into the XACMLAuthzAssertion Requirements element This will always work. I think Rich is interested in the cases where the enterprise does not want to expose its entire policy, or where the enterprise wants to be able to use the automatic policy intersection functionality that the other forms of an XACMLAuthzAssertion offer. ----------------------------------------------------------------------- OPTION 1: Flag specific constraints in the internal policy, extract them into the XACMLAuthzAssertion This is what Rich would like, if I'm not mistaken: a way to flag specific policy variable constraints that are in the enterprise's internal authorization Policy or PolicySet as ones that need to be extracted for inclusion in a Web Service's XACMLAuthzAssertion. While it would be easy to implement such a flag, it would be very difficult to use the flag in ways that preserve the integrity of the enterprise policies. The tool that controlled the setting of such flags would have to be more intelligent than all the XACML analysis research so far has been :-) Extremely simple example: <Policy RuleCombiningAlg="permit-overrides"> <Rule Effect="Permit"> <Apply FunctionId="and"> role == "manager" resource == "salary-table" <Apply FunctionId="or"> dept == "Engineering" dept == "Sales" </Apply> </Apply> </Rule> <Rule Effect="Permit"> <Apply FunctionId="Permit"> role == "engineer" resource == "project-schedule" </Apply> </Rule> </Policy> To automatically extract individual flagged constraints from this very simple policy, the policy extraction tool would have to know that a separate XACMLAuthzAssertion Requirements element MUST be created for each Rule even it no constraints in that Rule are flagged. If any constraint in an inner "or" function is flagged, then the extraction tool must also create a separate Requirements element for each constraint inside the "or" function, even if not all of the constraints are flagged. Remember that this is a VERY simple policy, and the complexity of analysis quickly becomes unmanageable for XACML policies in general. If not all constraints are flagged, then the enterprise will need to evaluate each request against the enterprise's full internal policy at run-time, and deny those that fail to meet the full set of internal constraints. Typically, the policy extraction tool will quickly end up creating at least one empty Requirements element because no constraints are flagged in a Rule, or because at least one constraint is not flagged in an "or" function. In that case, all further analysis and extraction becomes irrelevant: the XACMLAuthzAssertion has become a "pass-through" permitting every Request. ----------------------------------------------------------------------- OPTION 2: Write internal policies in a constrained form that is easy to convert to XACMLAuthzAssertion Requirements If the enterprise is willing to limit its entire set of policies that might be used as part of XACMLAuthzAssertions to a very constrained form, then a tool could easily convert the policies to XACMLAuthzAssertions. For example, this would work if the enterprise used only a single Policy whose individual Rules use only the "and" Boolean function and the comparison functions (no arithmetic, no string conversions, etc.). Then individual constraints could be flagged and a tool could easily convert each Rule into a separate XACMLAuthzAssertion Requirements element, including only the flagged constraints. Again, if not all constraints are flagged, then the enterprise will need to evaluate each request against the enterprise's full internal policy at run-time, and deny those that fail to meet the full set of internal constraints. Once again, unless every Rule has at least one constraint flagged, the policy extraction tool will have to create an empty Requirements element, and once again, all further analysis and extraction becomes irrelevant: the XACMLAuthzAssertion has become a "pass-through" permitting every Request. --------------------------------------------------------------------- OPTION 3: Create and maintain the XACMLAuthzAssertion Requirements independently from internal enterprise policies This is the option that will make the best use of authorization assertions in Web Services, in my opinion. 3a. For Web Services that have simple authorization policies, express the entire policy using an XACMLAuthzAssertion and evaluate all requests and client policies against that. In this case there is no separate internal policy, so no need to deal with inconsistency. 3b. For Web Services that have complex authorization policies, use the XACMLAuthzAssertion Requirements to filter out a useful fraction of unauthorized requests, then evaluate the requests that pass the assertion against the full internal policy at run-time. This is not an automatic process. Policy Administrators need to understand the overall enterprise policies well enough to know certain sets of constraints that are ALWAYS pre-conditions for access to the controlled Web Service. Regards, 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]