[xacml] BATCH #2: E-mail vote to close issues...

Title: 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:]

Sent:   Thursday, April 04, 2002 12:45 PM

To:     

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: 

Sun Microsystems Laboratories

1 Network Drive,UBUR02-311     Tel: 781/442-0928

Burlington, MA 01803-0902 USA  Fax: 781/442-1692