Re: Issue#61:WS-XACML:How are the contents of XACMLAuthzAssertionsrepresented in the base XACML Policies

[Anne Anderson - Sun Microsystems <Anne.Anderson@sun.com>]

Sampo, thanks for your comments.  Indeed, we need to know how outsiders 
read the WS-XACML work to make it more clear.

sampo@symlabs.com wrote:
> Sorry to jump in without necessarily having done all of my homework, but
> consider my opinion a fresh view, how would an outsider view the XACML
> work. If I have misunderstood anything, then so will have many others.
> Anne Anderson - Sun Microsystems writes:
> 
>> 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.
> 
> 
> Internal vs. external: I believe XACML is trying to specify wire protocol
> so internal vs. external debate may not be relevant? Internally everybody
> can do what they want (standards or not), but externally there is strong
> reason to be standards based. I believe focus on the standards based
> external use cases is important. If and when enterprises apply the same
> infrastructure internally, they may choose to follow standards rigorously
> or relax them (at their peril, but also at benefit of accommodating
> their specific business requirements).

The "external" policy that WS-XACML defines is policy for a Web Service, 
and this is a somewhat new use case for XACML, with new assumptions. 
Web Services interfaces, and the resources they protect, are typically 
exposed to a much wider range of clients than the interfaces used 
internal to an enterprise; Web Services interfaces may even be open to 
scruffy, dubious clients "off the street" :-).

Rich's issue is concerned with managing policies for 
internal-and-external resources.

The XACML Core does not specify wire protocol, although having an XML 
representation for policies is the basis for wire protocols: XACML 
policies might be transmitted over the wire in the form of a text XML 
document, a parsed node-set in Java, etc.  The "SAML 2.0 Profile of 
XACML 2.0" specifies portions of a wire protocol that layers on SAML 
2.0, but this is the closest we come.

So why has standardization been important for policies that were only 
exposed internal to the enterprise?

a. So that multiple applications/platforms that are internal to the 
enterprise can use the same policies.  These applications and platforms 
may come from multiple external vendors.
b. So that different organizational units within the enterprise can 
exchange, share, or combine their policies.
c. So that vendors who develop access control products can re-use a 
well-designed policy language.
d. So that vendors can develop policy tools that will work with a 
variety of internal access control products.
e. So that an enterprise is not locked-in to a single access control 
product vendor.  Their body of internal policies can be used by multiple 
vendor access control products.
f. So that research can be focused on a particular, highly-used 
language, providing more understanding of how to use it well or how to 
improve it.

With Web Services, of course, an entirely new level of interoperability 
concerns comes into play.

> 
>> ----------------------------------------------------------------------
>> 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.
> 
> 
> This option 0 "will always work", so why is it not the desired
> option, then? I presume the issues are three fold
> i.   Leakage of internal policy information to 3rd party
> ii.  Transport of the entire policy would be prohibitively expensive
> iii. Evaluation of the entire policy would be computationally expensive
> Are there other considerations?

i. Leakage is a big concern in many cases.  If an external attacker 
knows that access will be granted if the attacker can prove possession 
of certain attributes, then the attacker can concentrate on stealing 
those attributes.  The policies may also expose product information or 
organizational structure information that is sensitive.

ii and iii are also concerns: if there are huge parts of an enterprise's 
internal policy that have nothing to do with the resources that are 
exposed via a Web Services interface, why should the entire policy be 
applied to access via that Web Services interface?

The other big consideration is that, in the traditional XACML use model, 
only the service specifies policy.  The client provides a set of 
attributes, usually with no knowledge of what the policy is, and the 
service grants or denies access based on those.  This works with typical 
current static client<->service relationships: clients can be built to 
work with particular service applications.

With Web Services, clients (which may be other services) can be much 
more generic and relationships with services can be much more dynamic. 
To support this model, clients need to specify their policies, and there 
must be algorithms for comparing a client policy with a service policy. 
  Full XACML does not support client policies.

WS-XACML defines a subset of full XACML for which it is possible to 
automatically compare two policies and compute a new policy; it is 
possible to tell exactly which sets of Attribute values will be accepted 
by the new policy, and thus it is possible to know if the two policies 
are incompatible.  The new policy will accept all those Requests that 
would have been accepted by BOTH of the original policies, and no more.

> 
>> -----------------------------------------------------------------------
>> 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 
> 
> 
> Why is this? Just some referential integrity constraint of IDs between
> request and response? Is this constraint explicitly stated?

Assume we are dealing with Permit Rules.  Unless it is redundant, the 
Rule that had no flagged constraints will be satisfied by certain 
requests that will satisfy no other Rule.  If there is no Requirements 
element corresponding to that Rule, the XACMLAuthzAssertion may reject 
Requests that satisfy only that Rule.

All of this information should eventually be described in an Assertion 
Design Guidelines document.  We are still just defining and 
understanding the necessary functionality at this stage, however.

> 
>> 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.
> 
> 
> This last paragraph seems scary. Are you saying that some obfuscated
> error in specifying the policy could lead to a situation where
> "pass-through" rule gets created or assumed and we have effectively
> a default of "accept all that is not forbidden". This is scary when
> compared to the conservative principle of "all that is not expressly
> allowed is forbiddent".
> I think the XACML spec should be constructed such that is its difficult
> or contrieved to accidentally or out of ignorance to create default
> allow policies.

Yes.  I am saying that.  If you are extracting parts of your full policy 
to expose externally, then you either have to know exactly what you are 
doing, or else you have to then apply the full policy when Requests 
actually arrive.  Policies have to be designed very carefully, and 
policy analysis tools are important.  A lot of research is going into 
this area.

Policy analysis with WS-XACML is much easier than with full XACML; for 
example, it is easy to spot an empty Requirements element and say 
"Whoa!!!  Something is probably wrong,"  but you could have created an 
effectively empty Rule in full XACML without it being quite as obvious. 
  It is easy to analyze the set of WS-XACML Requirements elements 
because each is a simple, self-contained policy in itself, made up of 
atomic constraints.

> 
>> -----------------------------------------------------------------------
>> 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.
> 
> 
> Perhaps this is the 90% case? Or we should encourage the deployers as
> a "best practise" to employ this mode as much as possible.

Yes, I think an eventual Assertion Design Guidelines specification would 
recommend this where possible.  But I can think of lots of situations 
where this would not be sufficient.  It is impossible to quantify this 
without a known population of users.

> 
>> 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.
> 
> 
> This latter conceptually always assumes full evaluation of the internal
> policy at run time. The prefiltering stage is merely an optimization
> that may be very valuable as a denial of service blocker, but should
> at any rate be always automatically maintained.
> Thus: a vendor tool should work on internal policies and contain
> automated fuctionality to extract the simple rules (3a) and the
> prefilter for 3b as well as be prepared to fully evaluate whatever
> passes the prefilter.

Yes, such a vendor tool would be nice, but there are no known algorithms 
for doing this automated extraction on unfettered full XACML policies. 
Erik Rissanen's proposal to "Tag parts of a common policy to be specific 
for the public or private policies." helps localize the decisions about 
what can be extracted, but requires constraints on Rule design - it 
can't be applied after the fact.  Guidelines for expressing XACML Rules 
such that they are more amenable to analysis and re-factoring will 
probably be a useful outcome of our work on using XACML with Web Services.

This is a complex subject, and questions such as yours are valuable. 
Once we develop good explanations for what we are doing in response to 
such questions, these explanations can be incorporated into either the 
WS-XACML specification itself, FAQs, or associated policy and Assertion 
design guidelines documents.

Regards,
Anne

> Cheers,
>  --Sampo
> 
>> 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
> 
>  
> 
> 
> __________________________________________________________________
> Sym  | Sampo Kellomaki  ______| Identity Architect, Federated SSO
> ____ | +351-918.731.007 ______| Liberty ID-WSF DirectoryScript
> labs | skype: sampo.kellomaki | LDAP SOAP PlainDoc Crypto C Perl
> 

-- 
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