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

[Oleg Gryb <oleg_gryb@yahoo.com>]

see inline


----- Original Message ----
From: Yoichi Takayama <takayama.yoichi@gmail.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: "Tyson, Paul H" <PTyson@bellhelicopter.textron.com>; Ralf Lorenz <rol@mms-dresden.de>; xacml-users@lists.oasis-open.org
Sent: Thu, April 22, 2010 5:01:16 PM
Subject: Re: [xacml-users] XACML expressiveness (WAS: RE: [xacml-users] retrieving a list or query filter of resources the caller is authorized for)

>The idea of using "Advice" for any purpose for access control is simply wrong at this stage unless the standard >changes.
>The standard states that a "PEP can safely ignore "Advice" without any problem".
>How can you even think of using it???? Access control which is not enforceable is not an access control at all.

I was writing about necessity of having a DecisionDetails element that would allow to return details about decision that can not be described by using static values like Permit or Deny. Paul said that XACML 3.0 already had it and it's called Advice. That "PEP can safely ignore" phrase makes Advice less universal than I wanted and I would re-iterate my proposal either create a more universal and flexible field for returning non-static decision details or remove that phrase from the 3.0 draft.

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

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

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.