Versions Compared

Old Version 2

changes.mady.by.user Rod Widdowson

Saved on

compared with

New Version Current

changes.mady.by.user Rod Widdowson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Identified by type="Bearer", this rule allows a SAML 2.0 assertion with the "bearer" subject confirmation method to be accepted when possible. Normally not used explicitly, this rule is applied automatically to any policy running inside an AssertionConsumerService that implements SAML 2.0 profiles that make use of this confirmation type.

Attributes

Name

Type

Default

Description

checkValidity 

checkValidity 

boolean

true

When true, the

enclosed <SubjectConfirmationData> element

enclosed <SubjectConfirmationData> element must include

a NotOnOrAfter attribute

a NotOnOrAfter attribute, and both it and the

optional NotBefore attribute

optional NotBefore attribute are checked for validity.

checkRecipient 

checkRecipient 

boolean

true

When true, and the URL to which the assertion was submitted is available,

the <SubjectConfirmationData> element's Recipient attribute

the <SubjectConfirmationData> element's Recipient attribute is checked against that value. If no attribute is present, this setting has no effect.

checkCorrelation 

checkCorrelation     

boolean

trueWhen true, and the identifier of a request to which the assertion was submitted as a response is available, the <SubjectConfirmationData> element's InResponseTo attribute is checked against that value. If no attribute is present, this setting has no effect.missingFatal booleantrueWhen true, the absence of an acceptable <SubjectConfirmation> element is treated as a fatal error. Otherwise, the rule signals nothing was found but does not fail. Can be set to allow for stacking of rules based on multiple confirmation methods.

false

Enables request/response correlation checking based on use of a cookie to track request IDs, subsequently recovered to compare to the InResponseTo attribute in the <SubjectConfirmationData> element.

This setting previous defaulted to "true" but had no effect because there was no supporting request tracking implementation. This is now implemented, but the default has been reversed for compatibility with existing behavior.

blockUnsolicited 3.1

boolean

false

Enables the checkCorrelation option and adds rejection of any message with an empty InResponseTo attribute

Example

Code Block
languagexml
<TBD<PolicyRule type="Bearer" blockUnsolicited="true" />