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

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:

  

  
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.

  

  

  

  
    

      

      
        

          

          // Add resource-action pairs to the
request context

        

        

          

          AzResourceActionAssociation assoc = 
          

        

        

          

          azReqCtx.createAndAddResourceActionAssociation(azResource,
azAction);  

        

        

          

           
          

        

        

          

          // its time to decide !

        

        

          

          AzResponseContext azRspCtx =
azHandle.decide(azReqCtx);

        

        

          

          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