Re: [xacml-users] XACML expressiveness (WAS: RE: [xacml-users] retrieving a list or query filter of resources the caller is authorized for)

[Yoichi Takayama <takayama.yoichi@gmail.com>]

On 24/04/2010, at 3:37 AM, Oleg Gryb wrote:

>> You can miss-use it to implement any capability but it is not a standard-based system and it can't be used >mix-and-match with different PEP and PDP vendors. Interoperability is the purpose of a standard.
> 
> Interoperability doesn't exist as soon as you move from describing your authz rules in PDP's Policies to writing code in PEP/PIP and this exactly what you proposed in the message to Rich: instead of trying to utilize PDP and its formal language, you try to do authorization job ("get a list of resources for a subject") in proprietary code in PEP and PIP. I don't see how it's better from interop point of view.


I never suggested PEP/PIP to violate what XACML standard defines and interoperability, despite what you suggest that I did.

Native application requests which prod the PEP to trigger XACML to return Decisions and how the PEP actually enforce the Decisions are never within the XACML domain. This has been always a custom code, differ from system to system. The XACML itself has no ability to enforce the access control. It is only to tell the system (the PEP) what the rules are. Then the system is actually responsible to comply with it.

How the PEP does it is (naturally) undefined in the spec. If the system is well designed to give a plugability for a rule engine, the XACML module sub-module can be replaced with another plugin that uses a different rule engine, e.g which may use a rule table in a database.

The PEP issues XACML Query to the Context Handler. That is a defined interface, with <Request> and <Response> messages

(Please note that I got my previous email somewhat wrong as though the Context Handler were able to obtain a list of Resources. This was totally wrong and my apologies. I hadn't thought that it did, but, to be careful, I re-read the spec and actually managed to get it wrong this time, due to what Paul said about the Context Handler.)

Although the XACML messages between them are clearly defined in the spec, the API between the PEP and the Context Handler is undefined in the spec.

(In fact the APIs are different between different implementations of XACML Libraries, e.g. Oracle and Sun XACMl Libraries have different Java syntaxes for the API between the PEP and the Context Handler)

If the <Query> contains a list of Actions and/or Resources, it is a role of the Context Handler to convert it to multiple <Request>s within the root <Query>. It gets back a single <Response> with multiple Decision, which is returned to the PEP.

Therefore, it is a job of the PEP to get the list(s) of Action and/or Resources and construct the first XACML <Request>, and also deal with the multiple Decisions within the <Response>.


> 
>> Miss-use or proprietary interpretation/implementation is of course OK for system or mechanism that are internal use >only, but you should not claim that that is XACML compliant. It is only an XACML-like system (or partially compliant).
> 
> The problem is that when you start writing authz code in PIP/PEP it's even worse, becuase you're actually moving away from XACML space to a gray area that is not formally defined by any specification. All XACML's "goodness" that Paul and I were writing about goes away if you use this approach, let alone interop. Terms like "compliant" or "not compliant" become absolutely irrelevant in this case: they are simply not applicable.

You are getting it somewhat wrong. XACML compliance applies to: 

1. that the access control rule engine uses XACML Policy-based rules and the Attributes, together with its suggested architecture (modules and data-flows),

2. that the system guarantees that it can enforce whatever the XACML <Response> tells it to do. No exceptions. All Permit and Denied and Obligation are complied.

Different from all-in-one access control mechanism, XACML never has a power to enforce access control. It is a rule engine which only makes decisions. It relies on the system, which uses the XACML rule engine, to enforce the access control. Access control is (and has ever been) in the domain of the system.

In tradition systems, a rule engine and the enforcing mechanism made up a single access control unit. In terms of XACML, however, the rule engine may reside at a central location in the network, and the compliant systems may be distributed all over in the organisation. Therefore, it needed the decoupling of those two distinctive but related modules.

> It leaves us with two major choices:
> 
> 1. We make PDP and policies more robust and closer to a programming language
> 2. We continue writing authz code in PIP/PDP each time when have more or less complex use case
> 
> I would like to ask Ralf who's initiated this discussion, if he has a suitable solution for his use case and what it is if he has. I think, the answer would be indicative of how productive our discussion was.

1. may be needed
2. is not necessary, as PEP is to be customised but not PDP. Also, as I said, PIP needs a kind of customisation always, in order to be able to handle new Attributes. However, this can be done with the plugin design pattern. In that case, the body of the PIP code never changes (also the interface and/or APIs between other modules and the PIP never change) but a new plugin is simply added to it when a new Attribute is designed. Also, it is possible to architect some other type of PIP which allows dynamic addition of new Attributes without adding plugin module (code), e.g. by adding an Attribute Descriptor which is an instruction of how to get the value.

Yoichi