RE: [xacml-users] retrieving a list or query filter of resources the caller is authorized for

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

> -----Original Message-----
> From: Yoichi Takayama [mailto:takayama.yoichi@gmail.com] 
> Sent: Friday, April 16, 2010 22:31
> To: Oleg Gryb
> Cc: Tyson, Paul H; Ralf Lorenz; xacml-users@lists.oasis-open.org
> Subject: Re: [xacml-users] retrieving a list or query filter 
> of resources the caller is authorized for
> 
> 
> (A)
> 
> I forgot that the Obligation element can be used when the 
> Decision is not Permit. My apologies on that.
> 
> However , my understanding is he Obligation describes what a 
> PEP should do AFTER dealing with the Decision. First, process 
> the Decision. Second, handle the Obligation.

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

The <Advice> element was added to communicate truly advisory attributes
about a decision.

> 
> 1) Regardless whether the Decision is Permit or Deny, the 
> intention of the Obligation does not seem to be for passing 
> on what Action(s) the Subject(s) may or may not do on what 
> Resource(s). The Permit or Deny is already decided, then the 
> Obligation is something else to do after that.
> 
> 2) The current XACML does not provide computer-readable 
> syntax to pass-on some Attributes or instructions about what 
> Action(s) the Subject(s) may or may not do on what 
> Resource(s) or what the Obligation should do if such 
> information is passed.

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.

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

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.

Regards,
--Paul