...
Name | Type | Default | Description | |||||
|---|---|---|---|---|---|---|---|---|
checkValidity | boolean | true | When true, the enclosed | |||||
checkRecipient | boolean | true | When true, and the URL to which the assertion was submitted is available, the <SubjectConfirmationData> element's Recipient attribute is checked against that value. If no attribute is present, this setting has no effect. | |||||
checkCorrelation | boolean | true | When true, and the identifier of a request to which the assertion was submitted as a response is available, the In the Shibboleth SP, the request ID is not in fact ever available, so this setting doesn't have any effect either way. | missingFatal | boolean | true | When 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 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. |
| boolean | false | Enables the checkCorrelation option and adds rejection of any message with an empty InResponseTo attribute |
Example
| Code Block | ||
|---|---|---|
| ||
<TBD/> |