OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

Validity periods in SAML Assertions

  • 1.  Validity periods in SAML Assertions

    Posted 08-05-2004 17:04
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    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]