[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] request's attribute assertion lifetime?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]