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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

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

Subject: Re: [xacml-users] retrieving a list or query filter of resources the caller is authorized for

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> elements
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 communicating
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.

Subject=this user

and expect the <Advice> on what are Permitted and what are Denied?

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 off-the-shelf.
However, I still do not see (or expect) any XACML library
that can be used without your providing an appropriate PEP.
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 Policies.

There has been some work on a standard AzAPI, which might lower the
implementation barrier.  See Oracle's contribution to the XACML TC at
http://lists.oasis-open.org/archives/xacml/200907/msg00019.html.  This
was to have been submitted to the Liberty alliance
(http://www.projectliberty.org/) for further community development.

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 standard alone.

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

    1. // Add resource-action pairs to the request context

    2. AzResourceActionAssociation assoc =

    3. azReqCtx.createAndAddResourceActionAssociation(azResource, azAction);

    4. // its time to decide !

    5. AzResponseContext azRspCtx = azHandle.decide(azReqCtx);

    6. AzResult azRes = azRspCtx.getResult(assoc);

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 the object.

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.


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