[xacml] proposed amendment to Polar's resolution of PM-2-05

["Beznosov, Konstantin" <Konstantin.Beznosov@Quadrasis.com>]

Title: BATCH #2: E-mail vote to close issues...

While generally agreeing with Polar's proposal for PM-2-05 resolution, I have concern with the fact that his proposed text is vague in section 8.1  about whether a PDP must or may list attributes that are needed by the PDP to refine its decision:

------------------------------------------------------------------------------------------------------------------

The PDP MAY return an "authorization decision" of "indeterminate" with an
error code of "insufficient information", signifying that more information
needed. In this case, the "authorization decision" will list any the names
of any attributes of the subject and the resource that are needed by the
PDP to refine its "authorization decision".

-----------------------------------------------------------------------------------------------------------------

 

I suggest to amend the text of the resolution so that the above fragment will read the following:

------------------------------------------------------------------------------------------------------------------

The PDP MAY return an "authorization decision" of "indeterminate" with an
error code of "insufficient information", signifying that more information
needed. In this case, the "authorization decision" MAY list the names
of any attributes of the subject and the resource that are needed by the
PDP to refine its "authorization decision".

-----------------------------------------------------------------------------------------------------------------

 

The change makes a list of the attributes that are needed by the PDP to refine its decision optional.

 

Regards

Konstantin

-----Original Message-----
From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
Sent: Thursday, April 04, 2002 4:27 PM
To: 'xacml@lists.oasis-open.org'
Subject: [xacml] BATCH #2: E-mail vote to close issues...

Hi,

This e-mail vote is to officially close the following batch of issues.  The proposed resolutions are included.  (As Anne has noted, there are two resolutions given for PM-2-05 but one appears to be favoured.  Silence on this issue, therefore, indicates an acceptance of Polar's proposed resolution.)  If you have any objections to the resolutions on any of these issues, please make them known to the list by responding to this e-mail.  A new resolution (or an amendment to the current resolution) must be included in your posting.

This e-mail vote closes at the end of the day on Thursday, April 11, 2002.  If no objections are posted by that time, the current batch of resolutions will pass and the issues will be closed.

Carlisle.

----------
From:   Anne Anderson[SMTP:Anne.Anderson@Sun.com]
Sent:   Thursday, April 04, 2002 12:45 PM
To:     Carlisle.Adams@Entrust.com
Cc:     Anne Anderson
Subject:        Issues ready for e-mail vote

MI-1-03, PM-2-05, PM-2-06, PM-8-05, PM-3-04

The final text for the proposed resolutions follows.  Note that
there are two proposed resolutions for PM-2-05, although I think
mine got unofficially voted down.

-Anne
================================================================
MI-1-03: Definition and purpose of Target (Anne)

Proposed Resolution: a <target> element consists of three
predicates over elements in a SAML access decision request: one
over Subject, one over Resource, and one over Action.  Any of
these predicates may be universal in that they may result in
"true" for "anySubject", "anyResource", or "anyAction".

the <target> element in a <rule>, <policyStatement>, or
<policyCombinationStatement> has two purposes.  First, it allows
<rule>s, <policyStatement>s, and <policyCombinationStatement>s to
be indexed based on their applicable subject, resource, and/or
action.  Second, it allows a PDP to quickly and efficiently
reduce the set of <rule>s, <policyStatement>s, and
<policyCombinationStatement>s that must be evaluated in response
to a given access decision request.

These intended purposes place three restrictions on what can be
included in a <target>.  First, the predicates in a <target> must
be very efficient to evaluate.  Second, each predicate in a
<target> must refer to only one of <subject>, <resource>, and
<action> (for indexing purposes).  Third, each predicate in a
<target> must refer only to attributes that will always be
present in a SAML access decision request, since a <target> must
not return a result of "indeterminate".

In a <rule>, the <target> element is logically part of the
<condition> element.  Were indexing and efficiency not a concern,
the tests in the <target> could be incorporated into the
<condition>.  The <target> element serves as the "first pass"
test for whether the rule applies:

    if (<target> == true) {
        if (<condition> == true) {
            return <effect>;
        }
    }
    return <not applicable>;
===========================================================
PM-2-05: Ensuring Completeness (Anne and Polar)

Anne Proposed Resolution: A PDP must have a single base policy,
which may be either a <policyStatement> or a
<policyCombinationStatement>.  The combiner algorithm in this
base policy, together with the tree of associated <policySet> and
<ruleSet> declarations, specifies the complete set of rules that
the PDP will use in evaluating an access decision request.

Polar's Proposed Resolution: This resolution is against the
Version 12 document:

I would suggest that we add a Normative section for Operational Semantics.
I suggest that we put it between Section 8 and Section 9 (of course
altering the numbering of 9 to 10, etc). We may add more normative parts
for other operational parts of the model. However, I think the only one we
have to really worry about is the PDP, which is the XACML policy language
evaluator.

However, given the enormous flexibility of our model, I don't think we can
actually state specify by XACML language alone, what happens behind the
PDP, a.k.a retrieving policies, attributes, (lazy evaluation) etc. It
appears that our PDP can be an interconnected collection of PRPs, PIPs,
and even other PDPs recursively. I think it best just to state the
compliance rules for a PDP for our viable language elements.

The basic crux of the argument is that the when faced with evaluating a
XACML policy or policy set it will do so in accordance to the semantics
that we lay out in this document. (I've kept the terminology somewhat
non-saml specific (i.e. "authorization decision request"), and apply that
conformance to the SAML profile section.

Here it goes:




8.0 Operational Model (Normative)

8.1 Policy Decision Point (PDP)

Given a valid XACML "policy statement" or a "policy set statement", a
compliant XACML PDP MUST evaluate that statement in accordance to the
semantics specified in Sections 5, 6, and 7 when applied to an
"authorization decision request". The PDP MUST return a "authorization
decision", with one value of "permit", "deny", or "indeterminate".  The
PDP MAY return an "authorization decision" of "indeterminate" with an
error code of "insufficient information", signifying that more information
needed. In this case, the "authorization decision" will list any the names
of any attributes of the subject and the resource that are needed by the
PDP to refine its "authorization decision".

Decision Convergence

A client of a PDP MAY resubmit a refined authorization decision request in
response to an "authorization decision" of "indeterminate" with an error
code of "insufficient information" by adding attribute values for the
attribute names that are listed in the response.

When the PDP returns an "authorization decision" of "indeterminate" with
and error code of "insufficient information", a PDP MUST NOT list the
names of any attribute of the subject or the resource of the "authorization
decision request" of which values were already supplied in the
"authorization decision request". Note, this requirement forces the PDP to
eventually return an "authorization decision" of "permit", "deny", or
"indeterminate"  with some other reason, in response to successively
refined "authorization decision requests".

9. Profiles (Normative, but not mandatory to implement)

9.2 SAML Profile

A compliant SAML based PDP MUST reply to an SAML Authorization Decision
Request with a SAML Authorization Decision in accordance with operational
semantics of the PDP stated in Section 8.1.
================================================================
PM-2-06: Encapsulation of XACML policy (Anne)

Proposed Resolution: The XACML syntax will not contain its own
security features.  An XACML rule has no XACML-specified
encapsulation.  An XACML policyStatement or
policyCombinationStatement MAY be encapsulated in a SAML
assertion.
=================================================================
PM-8-05: How to return obligation via SAML (Michiharu)

Proposed Resolution: Here is an authorization decision syntax
that returns obligation(s). SAML AuthorizationDecisionStatement
is extended to include xacml:obligations element by type
extension. "samle" namespace prefix is used to indicate SAML
extension for the decision assertion with obligation. Note that
the following example just shows the overview for simplicity.

<saml:Assertion>
  <saml:AuthorizationDecisionStatement Resource="aaa" Decision="Permit"
xsi:type="samle:AuthorizationDecisionStatementWithObligations">
  <saml:Subject>
   <saml:NameIdentifier SecurityDomain="aaa" Name="Alice"/>
  </saml:Subject>
  <saml:Actions Namespace="http://www.oasis-open.org/xmlactions">
   <saml:Action>Read</saml:Action>
  </saml:Actions>
  <xacml:obligations>
   <xacml:obligation obligationId="myId">
     ...
   </xacml:obligation>
  </xacml:obligations>
  </saml:AuthorizationDecisionStatement>
</saml:Assertion>




The following "samle" schema fragment defines an authorization
decision with obligations.

<complexType name="AuthorizationDecisionStatementWithObligations">
  <complexContent>
    <extension base="saml:AuthorizationDecisionStatementType">
      <sequence>
        <element ref="xacml:obligations"/>
      </sequence>
    </extension>
  </complexContent>
</complexType>
===============================================================
PM-3-04: Pseudo Code for Combiner Algorithms (Ernesto)

Proposed Resolution: Java syntax should be used to describe any
mandatory-to-implement combiner algorithms.
================================================================

--
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692