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