Re: [xacml] request's attribute assertion lifetime?

[Anne Anderson <Anne.Anderson@Sun.COM>]

On 4 March, Frank Siebenlist writes: Re: [xacml] request's attribute assertion lifetime?
 > Maybe we should make the checking of time validity a mandatory thing in the 
 > xacml engine, meaning that we optionally associate validity intervals with 
 > attribute and policy statements, and if they are present, they will always be 
 > checked with the evaluation time. So, no need to write any policy rule tests for 
 > time validity as it will be done for you automatically and always.

One reason for not putting everything into to the XACML Attribute
is that different Attribute sources will have different types of
associated information, expressed in different ways.  Not all
will be compatible with a single, normalized expression that we
could specify in the XACML Attribute itself.

For Attributes that come from SAML Assertions, I am trying to
address validity interval, etc. in the SAML Profile.  The
validity interval is to be checked against the time "associated
with the XACML Request Context" in which the SAML Attribute is to
be used.  This means that, if the Request already contains a
date/time (such as a time in the future), then the SAML Attribute
validity interval must be checked against that.  If there is no
date/time specified by the PEP, then the Context Handler uses the
date/time at the PDP.

The following text has not been approved yet by the TC, but is
the direction I think we have been moving:

2.1 Mapping a SAML Attribute Assertion to XACML Attributes

A SAML Attribute Assertion is a <saml:Assertion> instance that
contains one or more <saml:AttributeStatement> instances.  The
elements in an <xacml-context:Attribute> are populated from the
contents of a SAML Attribute Assertion as follows.

  AttributeId XML attribute
  -------------------------

  If an applicable mapping of SAML AttributeName to XACML
  AttributeId values has been defined for the SAML
  AttributeNamespace, then the result of that mapping SHALL be
  used.  Such a mapping SHOULD be defined for any SAML
  AttributeNamespace that is to serve as a source for
  <xacml-context:Attribute> values.  If no such mapping has been
  defined, then the XACML AttributeId SHALL be set to the URI
  resulting from concatenating the SAML AttributeNamespace and
  AttributeName values, using the component separator of the SAML
  AttributeNamespace URI syntax as the separator.

  DataType XML attribute
  ----------------------

  If an applicable mapping of <saml:AttributeValue> values to XACML
  DataType values has been defined, then the result of that mapping
  SHALL be used.  Otherwise, if the fully-resolved top-level
  element name in the <saml:AttributeValue> value is equivalent to
  one of the XACML standard DataType values, then the XACML
  standard DataType value SHALL be used.  For example, if the
  <saml:AttributeValue> is <xsi:string>value</xsi:string>, then the
  DataType of the <xacml-context:Attribute> SHALL be
  http://www.w3.org/2001/XMLSchema#string.  Otherwise, the value of
  the fully-resolved top-level element name in the
  <saml:AttributeValue> value SHALL be used.

  Issuer XML attribute
  --------------------

  The value of the <saml:Assertion> Issuer XML attribute SHALL be
  used.

  IssueInstant XML attribute
  --------------------------

  The value of the <saml:Assertion> IssueInstant XML attribute
  SHALL be used.

  <xacml-context:AttributeValue>
  ------------------------------

  If an applicable mapping of <saml:AttributeValue> to
  <xacml-context:AttributeValue> has been defined for the SAML
  AttributeNamespace, then the value resulting from that mapping
  SHALL be used.  Otherwise, if the fully resolved top-level
  element name of the <saml:AttributeValue> value is equivalent to
  one of the XACML standard DataType values, then the value of the
  top-level element in the <saml:AttributeValue> element SHALL be
  used.  Otherwise, the <xacml-context:AttributeValue> value SHALL
  be used.

A SAML Attribute Assertion may contain multiple
<saml:AttributeStatement> elements.  Each of these is mapped to a
single <xacml-context:Attribute> element.  The Issuer and
IssueInstant of the  <saml:Assertion> element are used as the
Issuer and IssueInstant for each <xacml-context:Attribute>
element created from that SAML Attribute Assertion.

The <xacml-context:Attribute> created from the <saml:Assertion>
MUST be placed into the <xacml-context:Resource>,
<xacml-context:Subject>, <xacml-context:Action>, or
<xacml-context:Environment> element that corresponds to the
entity that is the <saml:Subject> in the <saml:Assertion>.  For
example, unless there is an additional mapping defined, if the
<xacml-context:Attribute> is placed into an
<xacml-context:Resource> element, then the &resource;resource-id
<xacml-context:Attribute> value MUST match the value in the
<saml:NameIdentifier> element.  If the <xacml-context:Attribute>
is placed into an <xacml-context:Subject> element, then the XACML
SubjectCategory XML element MUST also be consistent with the
entity that is the Subject of the <saml:Assertion>.

The entity performing the mapping MUST ensure that the semantics
defined by SAML for the elements in the <saml:Assertion> have
been adhered to.  The mapping entity need not perform these
semantic checks itself, but it MUST ensure that the checks have
been done before any <xacml:Attribute> created from the
<saml:Assertion> is used by an XACML PDP.  These semantic checks
include, but are not limited to, the following.

Any NotBefore and NotAfter XML attributes in the
<saml:Assertion> MUST be valid with respect to the
<xacml:Request> in which the SAML-derived <xacml:Attribute> will
be used.  This means that the  NotBefore and NotAfter XML
attribute values must be consistent with the
&environment;current-time, &environment;current-date, and
&environment:current-dateTime <xacml:Attribute> values associated
with the <xacml:Request>.

The entity doing the mapping MUST ensure that the semantics
defined by SAML for any <saml:AudienceRestrictionCondition> or
<saml:DoNotCacheCondition> elements have been adhered to.

If a <ds:Signature> element occurs in the <saml:Assertion>, then
the entity performing the mapping MUST ensure that the signature
is valid and that the SAML Issuer XML attribute is consistent
with any <ds:X509IssuerName> value in the signature.  The
guidelines regarding digital signatures in Section 5 of the SAML
1.1 core specification [] MUST be adhered to.

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