OASIS eXtensible Access Control Markup Language (XACML) TC

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:

   

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

Anne Anderson - Sun Microsystems wrote:
> 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.

Anne, here is another one:

OPTION 4: Tag parts of a common policy to be specific for the public or
private policies.

For instance:



A few lines of xslt could then extract the public respective private
policies from the common file, without the need to manually keep the
common parts in sync.

Regards,
Erik