[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:
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.
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 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).
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.
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.
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.