Re: [xacml] PEP Conformance

[Polar Humenn <polar@syr.edu>]

On Tue, 8 Oct 2002, bill parducci wrote:

> i think we are veering off of the topic, but...
>
> if you look at "Conformance Program Specification for the OASIS Security Assertion Markup Language (SAML)"
> Document identifier: draft-sstc-conform-spec-12
> Location: http://www.oasis-open.org/committees/security/docs
> Publication date: 22 March 2002
> Maturity Level: Committee Working Draft
>
>
> you will see in the conformance objectives:
>
> /*
> The objectives of the SAML Conformance Clause are to:
> 1. [...]
> 2. Promote interoperability in the exchange of authentication and authorization information
> */
>
> which has no meaning if the *application* of this information is not
> consistent.

True, which means how the application interprets the result. I fully
agree, that *if* the application is functioning as a PEP, and asks a PDP
for access decision based on the request parameters, the application
should interpret the PDP's result as such.

All I'm saying is that if you want the PEP to deny access based on some
non-understandable obligations, make the PDP do it, and you have some
notion of conformance on the PDP. You cannot control the application.

As far as multiple PEP-PDP relationships, I don't think you can say
anything to make it work in a consistent manner, so why really bother.

> i believe that this position is embodied in the following
> conformance test case:
>
> /* 4.1.6 Test Case 1-6: SOAP Protocol Binding:
> Implementation-Under-Test Consumes Valid Authorization Decision
> Assertion, Requested in Valid Query Description: This test case
> receives an authorization decision query created by an
> implementation-under-test using the AuthorizationRequest protocol in
> the SOAP binding. It confirms that the received query is valid for all
> required functionality. It returns an authorization decision assertion
> to the implemenation-uder-test and confirms that the assertion is
> consumed.
> Pass/Fail Criteria: AuthorizationQuery contains all required
> elements in the right format and sequence; authorization decision
> response and assertion are consumed.
> Requirements Reference: R-AUTHZDECISION, and R-MULTIDOMAIN
> Specification Reference: SAML Core, sections 2.4.4 and 3
>             SAML Bind, section 3.1
> Implementation notes: The implementation-under-test executes the
> authorization decision assertion consumer role. Test program and
> implementation-under-test must agree how to validate that assertion
> was consumed. */
>
> which states that authorization query consumption must be validated
> (i.e 'consumed' the same way).

Consumed yes, in a SOAP sense. It got a valid response from a valid
request.  But as the test says, there is a previous agreement between the
TP and the IUT such that the result is expected for the request.

It says nothing about what the TP does in regard to receiving the
AuthzQueryResponse, other than "validating" a response that is considered
valid by Test specification.

> i posit that this will be performed in much the same way attribute
> conformance was achieved this summer: multiple vendors will send azn
> queries back and forth while protecting a controlled asset;
> conformance is declared when the *results* match across systems.

True, but the "result" is emitted by a PDP implementing a SOAP binding.
Making sure they return the same results for the same configuration, same
inputs (XACML policy being considered an input). It says nothing, and
rightfully so, how an application should behave that uses such a SOAP
request/response.

> in other words this:
>
> /*
> The Application may or may not give you access, sometimes you won't even
> see it. I being an application, may get a Deny response from a PDP, but
> decide to give you access any way, but maybe to a false object. But in any
> case, you cannot bind me to deny access in a consistent manner.
> */
>
> will *not* conform.

This is my application choice. My application is to deny you access to the
real resource, yet give you access to a false, or an alternate resource
instead, with no discernible way for you to figure out that you have been
denied.

You're going to wave your XACML Red flag at me for non-conformance? If the
specification is going to tell me how to run my business, the
specification will be ignored, at least in that regard.

-Polar