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

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi Ralf, Yoichi, et al,

I have been following this discussion with interest as part of the OpenAz open source effort is to provide a query capability. The intent of OpenAz is to enable XACML to be brought into enterprise environments in a seamless manner, allowing migration on an as-needed basis to enable XACML capabilities to be introduced to the enterprise.

That aside, the technique we have been looking at is focused on hierarchical resources and the use of regular expressions to address scopes of those resources. This is also consistent with the notions in the XACML Multiple and Hierarchical Profiles.

Basically, hierarchical permissions can be simply thought of as a regular expression containing a fixed prefix and a wildcard suffix, where any resource name that matches the prefix is within scope of the expression.

Generally this expression can be applied to the resource store to get a list of the concrete resources covered by the expression. Therefore if a Policy can be defined that will return the list of applicable regular expressions contained within the policy for the specific request, then this list of expressions can be applied to the resource store in order to get the full list of concrete resources covered by the query.

Therefore the trick is how to get this list of regular expressions out of the policies. The attached zip file contains a policy that provides this capability, along with sample requests and responses that were obtained by running the requests against the SunXacml PDP being used in the OpenAz project.

The trick that is used is to use a PolicySet to contain a pair of Policys. One of the pair contains the actual regular expression used for access control. The other of the pair returns an Obligation containing an AttributeAssignment that contains a copy of the regular expression. The way to get the 2nd policy of the pair invoked is to query for the specific string "/-" which is simply a string used in all the "2nd policies" and so all policies that contain this resource will match the query.

Note: none of this effort is focused on performance, and is intended at this time just to demonstrate capabilities. It is expected that optimizations will be need to enable scalability.

Note: since SunXacml is based on XACML 1.1 there are a few 1.1 artifacts floating around, but these are rather trivial, and do not impact the overall structure of things, at least in the current phase of the OpenAz project.

Comments and suggestions are welcome.

    Thanks,
    Rich


Yoichi Takayama wrote:

25B99AD7-355F-4FE4-AA07-57A55426406C@gmail.com" type="cite">

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.

Query

Subject=this user

Action=Any

Resource=Any

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. 1. // Add resource-action pairs to the request context

   2. AzResourceActionAssociation assoc =

   3. azReqCtx.createAndAddResourceActionAssociation(azResource, azAction);

   4. 
      

   5. // its time to decide !

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

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

Yoichi

SampleXacmlPolicyQueryWithReqRsp.zip