On 19/04/2010, at 4:53 AM, Tyson, Paul H wrote:
In XACML 3.0, the expected behavior was made truly obligatory:
"PEPs that conform to v3.0 of XACML are required to deny access unless
they understand and can discharge all of the <Obligations>
associated with the applicable policy." (Section 2.12).
I think that it has been always the way, that the system that
accepts XACML control had to oblige the <Obligations> in such a
way as detailed in the standard.
3.0 adds the <Advice> element, which can be used for
name-value pairs in the XACML response. The policy-writer and the PEP
implementor must agree on what these name-value pairs mean.
Each <Advice> is also a part of a <Decision>, and it
does not apply to the case in which Oleg/Ralf wants "a list of all
Permissions" for the user.
and expect the <Advice> on what are Permitted and what are
It should return Indeterminate really, because there are
combinations of Actions and Resources which are Permissible and Denied.
Then, there is only one Advice with a list of Name/Value pairs.
That is hardly enough to express multiple triplets (i.e. Decision,
Action and Resource) or to express more complex conditions that would
apply to those triplets. It is not simply a combination of Action and
Resource that will determine the outcome.
My point was that the current multi-quetion Query can achieve
what they want, although Oleg desires if one can ask XACML to give "a
list of all Permissions for the user". That is not possible where the
Permissions are written as Policies and involving dynamic Policies and
dynamic Attributes, without using some kind of lists and multiple
questions (implicit or XACML Queries).
PDP, PIP, PAP, and the Policy Store can be
However, I still do not see (or expect) any
that can be used without your providing an
This is because a PEP is normally very
tightly tied with what
your system does, i.e. what Actions and
Resources are dealt
with. Since these can't be generalised in a
standard, it is
left out as implementation-dependant. I
think that this is
quite acceptable at this time.
XACML users should ask their software vendors to supply built-in PEPs,
or at least to include PEP functions in their customization kits. Since
most large enterprises have many applications that handle their
intellectual property and business processes, it is not acceptable for
each application to handle access control in its own proprietary way.
I am talking about the standard. Not the vendor products. The standard
does not define PEP, except for the query syntax between PEP and PDP
and how the Attributes would be obtained magically by the PIP and
Policies by PAP. The actual programming interface (API) between PEP and
PDP is not defined, since it is programming language- and
implementation dependent (i.e. the syntax of a statement or the name of
a function that sends the XACML Query XML statements to PDP).
What you are saying is in line with my statement. XACML PEP
should be provided by vendors of the system if that system uses XACML
This is an implementation of how one may communicate with PDP.
How one may construct a Query, send it to a PDP and how to access the
Response is totally an implementation matter with the current XACML
If there is a need for having interoperability between different
PDP suppliers and software vendors (their products contain PEP), having
API standard(s) would be a must.
However, the Oracle contribution proposes an API that has these
// Add resource-action pairs to the
AzResourceActionAssociation assoc =
// its time to decide !
AzResponseContext azRspCtx =
AzResult azRes =
a. It exposes and contains too much proprietary details as to
how the PEP is formulating the Query. How the PEP may be formulating
the Query should be encapsulated into another module, which produces
XACML Request as an XML or an XML-representative object. How this is
done is totally application dependent and it should not be any part of
the proposal for a standard API.
b. The AzQueryContext should be sent separately from the XACML
Query itself. XACML does not define such an object as AzRequestContext.
The XACML Query Context is the <Query> object itself. In case the
PDP resides on a different server (A) than the PEP server (B), this
should include some kind of information about calling back from server
B to server A. Because the PDP/PIP will probably need to use it as a
part of a call-back for Attributes that only server A can resolve.
c. Accessing the Response for this Query should not be using
such a thing as the Resource-Action association as a "key" to obtain
d. The AzHandle is a service, not a PDP. So, it should be more
appropriate to "sendQuery()" than "decide()".
e. Since a different implementation of the PEP-PDP may not use a
service paradigm, it is not appropriate to pride an API that is limited
to use a service.
f. This hides the actual communication API between this system
and the PDP, and the need to clarify the need for that API or
interface. A PDP may have interface to external world with Web Service
Profile, Java RMI Profile, Java direct method call, etc.
This is not at all what I expect to see in a standard.