OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Validity periods in SAML Assertions


SAML Assertions contain a Conditions element that contains
optional "NotBefore" and "NotOnOrAfter" xml attributes.  If
"NotBefore" is omitted, then the Assertion is valid at all times
up to the "NotOnOrAfter" time.  If "NotOnOrAfter" is omitted,
then the Assertion is valid at all times after the "NotBefore"
time.  If both are omitted, then the Assertion is valid at any
time.  If both are present, NotBefore MUST be earlier than
NotOnOrAfter.

We discussed the use and creation of appropriate validity periods
in SAML Assertions used with XACML in our TC meeting today.

As a first shot, we decided that the validity period the PDP puts
into an XACMLAuthzDecision Assertion MUST be the intersection of
the validity periods of the various SAML Assertions used in
obtaining the decision: i.e. the validity periods of all SAML
Attribute and XACMLPolicy Assertions that were used by the PDP in
its evaluation.

[Note: I say the "PDP" does certain things with respect to
validity periods.  Actually, of course, it is not the "PDP" that
will make judgments about which SAML Assertions to use or about
what validity period to put into a Response, but either a Context
Handler or a SAML protocol handler outside even the Context
Handler.]

We also discussed mismatches between the "current-dateTime"
Attribute value in an XACML Request Context and the validity
periods of SAML Assertions used in the PDP evaluation.  By
default, the "current-dateTime" is the time at the PDP when the
evaluation is done, but XACML also supports letting a PEP provide
a specific "current-dateTime" that might be in the future or in
the past for purposes of analysis and testing, such as "what if"
Requests.

We decided that the validity period in the XACMLAuthzDecision
Assertion need not be consistent with the current-dateTime of the
Request.

What we did not explicitly discuss is which validity periods in
SAML Assertions are acceptable for the PDP to use during an
evaluation.  What if the Request contains a future "what-if"
time, and a SAML Assertion would be valid at that time, but is
not valid at the current time?  Would the PDP ever use Assertions
that are not valid at its current time?

PROPOSAL: the PDP SHALL use only Assertions that are valid at the
PDP's evaluation time, regardless of the Request's
"current-dateTime" value.  The PDP SHALL use the intersection of
the validity periods of all SAML Assertions used during the
evaluation as the validity period in its Response Assertion.  The
PDP SHALL NOT use the "current-dateTime" in the Request Context
to determine which SAML Assertions to use.

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]