OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [xacml] WS-Policy and XACML comparison

Colleagues - The persuasiveness of Anne's argument is inescapable.  I
propose the following use-cases as a starting point.  All the best.  Tim.

1.a.  Provider decision - Service provider decides whether a request is
conformant with the applicable part of its policy.
1.b.  Consumer decision - Service consumer decides whether a response is
conformant with the applicable part of its policy.
2.a.  Construct request - Service consumer forms a request that is
simultaneously conformant with the applicable part of its own and the
service provider's policy, or returns a fault.
2.b.  Construct response - Service provider forms a response that is
simultaneously conformant with the applicable part of its own and the
service consumer's policy, or returns a fault.
3.  Forward decision - Subsequent process-step decides whether a request is
conformant with its own and the information owner's policy.

-----Original Message-----
From: Anne Anderson [mailto:Anne.Anderson@Sun.com]
Sent: Tuesday, February 25, 2003 3:54 PM
To: Maryann Hondo
Subject: Re: [xacml] WS-Policy and XACML comparison

On 20 February, Maryann Hondo writes: [xacml] WS-Policy and XACML comparison
 > Here are some thoughts about the positioning of WS-Policy and XACML for
 > your consideration.
 > Comments welcome.

I'll have to admit, my thinking on this has evolved considerably
since my first tentative response [3b] to Tim's initial proposal
[3].  The more I have studied WS-Policy requirements, the more I
think XACML is the best candidate for meeting them.  I've tried
to explain why below.

In this response, I first make an important general point about
XACML as a policy language versus XACML as an access control
decision evaluator.  I then respond to particular points in
"Positioning XACML Relative to WS-Security Standards" [1].
Finally I describe XACML's particular suitability for handling
WS-Policy requirements.  Readers should feel free to read the
sections that interest them, as I think they are relatively

In this response, "WS-Policy" refers the set of requirements for
Web services policy [6], and "Web Services Policy Framework"
refers to one specific proposal [4] for meeting those


It is very important to distinguish the XACML Policy and
PolicySet schemas (the "XACML Policy Language") from the models
for evaluating these schemas.

Currently, one model has been defined in the XACML 1.0
Specification -- the access control model.  In this model, an
entity called a Policy Decision Point (PDP) is defined, along
with a syntax for requesting an access control decision,
returning a decision of "Permit", "Deny", "NotApplicable", or
"Indeterminate".  The XACML 1.0 Specification provides very
explicit semantics for how the PDP evaluates policies against
such requests in order to return an access control decision.
Another entity called a Policy Enforcement Point (PEP) must know
how to use the information in the returned decision to control

The same XACML Policy Language, however, can be used in a
different model -- the policy negotiation model.  In this model,
an entity I call a Policy Negotiation Point (PNP) is defined.  No
new syntax is required for making policy negotiation requests,
since the inputs to the PNP can be one XACML policy from the
service requester and another XACML policy from the service
provider.  The XACML 1.0 Specification must be extended to define
the semantics for how a PNP evaluates two such policies, and what
the format for the response will be.  One possibility is that the
PNP will return a new XACML policy that is acceptable to both
parties (or else returns "policies incompatible").  Another
entity that I call a Request Formation Point (RFP) would then use
this returned policy to extract information needed to compose a
service request.

The XACML TC has not yet defined semantics for this second model,
but the semantics are closely related to those for the access
control model.  Tim Moses [3,6] has suggested the general flavor
of such semantics.  Most elements of the evaluation, including
the bulk of the processing support required, are identical for
the access control decision and for the policy negotiation

Since a service provider's PDP will evaluate any incoming request
against its XACML policy to see if the request is acceptable
(using the access control model), it is obvious that the XACML
policy already contains most of the information required to
formulate an acceptable request.  The remaining information --
that used to package the request (encryption, transport, etc.) --
can be expressed in the same way; it will just be evaluated and
consumed by different entities (PNP and RFP).


This section responds to particular points made in "Positioning
XACML Relative to WS-Security Standards".

Web Services Policy Framework [4] "is a language, which can be
used to describe properties and capabilities of many different
types of resources, including, Web services and Web service
endpoints...  This language is used for communicating such
information as security requirements, supported features,
preferred ways of invoking the service, etc."

  XACML does the same.  It describes the properties and
  capabilities as questions about the resource to be accessed.
  XACML can be used for web services and web service endpoints.
  As Tim Moses' worked out example [2] illustrates, XACML is
  perfectly capable of communicating information about security
  requirements, supported features, preferred ways of invoking
  the service, etc.

"There are no assumptions on how the descriptions are associated
with a target resource."

  XACML does not have such assumptions.  It does have very
  expressive language that allows policies to be
  associated with particular requesters, services, or types of
  access, but it does not require that such associations be
  made.  A policy writer can say that a given policy applies to
  "AnySubject", "AnyResource", or "AnyAction".

  The ability in XACML to express associations is one of its real
  strengths.  It allows the policy writer to say, for example,
  that password authentication is supported when a request comes
  from inside the firewall, but that token-card authentication is
  required when a request comes from outside the firewall.

"This language [Web Services Policy Framework [4]] is not
intended to be interpreted (in the sense of programming language
execution) but to be processed as data from which useful
information can be extracted.

  An XACML policy is "data from which useful information can be
  processed".  XACML has already defined one way of interpreting
  that data in order to make an access control decision.  There
  are other ways to interpret the data, such as for negotiating
  mutually acceptable request characteristics.

  Given that the data is the same, and just the questions to be
  asked are different, it does not make sense to create that data
  in two different forms.  That only introduces the certainty of
  incompatibilities and the overhead of maintaining two systems.

"XACML is an access control rule language"

  We originally designed it that way, but if you think about it,
  a description of the rules for accessing a resource must
  contain the information about how that resource can be
  accessed.  Using XACML to answer the second question is very
  natural.  The example by Tim Moses [2] illustrates this.

"The target of an access control rule is assumed to be
represented as a triple of subject, resource, and action."

  Right.  We allow the policy writer to specify that particular
  capabilities, security requirements, ways of invoking the
  service, etc. depend on characteristics of who is making the
  request, characteristics of the resource being requested, and
  characteristics of the type of access requested.  We also
  support "AnySubject", "AnyResource", "AnyAction".

  By supporting the concept of "target", XACML makes it possible
  to index large databases of policy information efficiently.

"Its principal usage is to be consumed by an XACML rule
evaluation engine at an access control decision point...  the
body of the description is always a formula returning a boolean

  Only the one use model spelled out in the XACML 1.0
  specification.  As I've described above, the model where XACML
  is used to provide information about capabilities, preferences,
  etc. is just as natural.


  I think Tim Moses has provided proof by example [2] that it is
  possible "to express generic properties of web services" using
  XACML.  That addresses the remaining points.


Not only is it possible to express "generic properties of web
services" using XACML, there are particular reasons for using
XACML for this purpose.  I was initially somewhat sceptical, but
as I have come to know more about WS-Policy and its requirements,
I am now convinced that XACML is the best candidate for

1. Given that most of the information describing what a service
   supports will be expressed in XACML anyway (to support the
   access control decision), it is both redundant and insecure to
   require that the same information be described a second time
   using another language.

   Systems must support XACML PDPs to determine authorization.
   "Privacy" is another form of authorization -- determining
   whether the information-owner and custodian have given their
   permission for a specified "use" of the information [5].  This
   covers two important application domains already addressed by
   XACML.  It makes sense to adapt XACML to the others, such as
   reliable messaging and transactions.  How this can be done is
   described in [2] and [3].

2. XACML is already a standard, has been implemented by several
   companies, and is available in open source.

3. XACML was developed with broad representation over a long
   period of time.  In the course of its development, it was
   tested against numerous real-world models and sets of

4. XACML has a rich set of data types for attributes and a rich
   set of built-in functions for manipulating the attribute data.
   This contributes to out-of-the-box multi-vendor

   The absence of such common data-types and functions in "Web
   Services Policy Framework" [4] will lead to duplication and
   inconsistency in the various application domains.  The
   resulting costs, in development and management, are
   unacceptable and represent a genuine security risk.

5. XACML's expression syntax allowed for very precise
   descriptions of services and capabilities: under condition A,
   service/feature B is supported; under condition C, feature D
   is required; etc.  XACML's policy syntax also allows general
   policies to be written that apply to multiple services.

6. Expression of policies requires good GUIs.  I think XACML is
   better designed for GUIs than the alternatives, including Web
   Services Policy Framework [4].  Why? XACML is not extended via
   new XML schemas, but instead is extensible via IDs.  These new
   IDs do not affect the semantics or structure of the language,
   and thus do not affect the user interface other than by being
   new values that can be plugged in to the existing language
   structure.  For example, an organization can define a new
   function, new combining algorithm, new data type, or new
   attribute type merely by providing an identifier for it.  The
   evaluator (PDP or PNP) must be provided with plug-in code for
   handling a new datatype, function, or algorithm, but such
   plug-ins do not affect the GUI used to compose the policies.
   In fact, new attribute types require no plug-ins at all, and
   that is the most common "extension" required for XACML.
7. A PNP can be used to merge multiple policies on the requester
   or provider side.  The provider, for example, may use some
   policies that are provider-specific, and some general policies
   defined by the provider's enterprise.  The requester may
   likewise use some policies that are requester-specific, but
   other general policies defined by the requester's enterprise.

   The XACML TC has done a great deal of work to support the
   capability of referencing policies from multiple sources, all
   of which may apply to the same resource or service.

8. The way in which XACML defines combining algorithms is
   flexible in a way that meets real-world requirements.  I came
   into XACML convinced that Boolean or N-of types of combining
   algorithms were sufficient.  After learning of the various
   kinds of combinations that customers want to do
   (e.g. customer's idea of a "best fit"), I had to change my

9. Because of the way XACML defines its extensions (see #6),
   any XACML policy that does not define new data types or
   functions can be interpreted by any standard interpreter,
   whether that interpreter is a PDP or a PNP.  This is very
   important for interoperability.  A language that MUST be
   extended via XML schema extensions just to be usable is not
   interoperable out of the box.

[1] "Positioning XACML Relative to WS-Security Standards", by
    Maryann Hondo.  Submitted to the xacml@lists.oasis-open.org
    mailing list on 20 Feb 2003 as an attachment to message

[2] "Crypto-security policy in XACML", by Tim Moses.  Submitted
    to the xacml@lists.oasis-open.org mailing list on 19 Feb 2003
   as message
   Correction: The inner "and" should span only the first
   "anyURI-equal" and the "integer-greater-than" elements.  The
   following should be placed after the first
   "integer-greater-than" element ...

   <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> 

[3] "Comparing ACME with WS Policy framework", by Tim Moses.
    Submitted to the xacml@lists.oasis-open.org mailing list on
    29 Jan 2003 as an attachment to message
    with followup in messages
    a) http://lists.oasis-open.org/archives/xacml/200301/msg00022.html,
    b) http://lists.oasis-open.org/archives/xacml/200302/msg00010.html,
    c) http://lists.oasis-open.org/archives/xacml/200302/msg00023.html

[4] "Web Services Policy Framework", by IBM, Microsoft, BEA and
    SAP, dated Dec 2002.  Available at

[5] See slides by Michael Willett of the International Security,
    Trust and Privacy Alliance (ISTPA) attached to message
    See also the ISTPA Privacy Framework document attached to

[6] "Requirements for policy-management in distributed systems",
    slides presented by Tim Moses to the Policy Workshop at Sun
    Microsystems, 21 Feb 2003.  Attached to this e-mail.

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

<Requirements for policy-management in distributed systems, by
Tim Moses>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC