Share via

AD FS 2.0: ID4149: "The Saml2SecurityToken is rejected because the SAML2:Assertion specifies a OneTimeUse condition."

  • Article

Symptoms

  • Token acceptance from a third party Claims Provider (CP) fails
  • The following exception is thrown by AD FS 2.0:

*ID4149: The Saml2SecurityToken is rejected because the SAML2:Assertion specifies a OneTimeUse condition. Enforcement of the OneTimeUse condition is not supported by default. To customize the enforcement of Saml2Conditions, extend Saml2SecurityTokenHandler and override ValidateConditions.
**
This request failed

Cause

This is by design.

Explanation:

OneTimeUse is defined in SAML 2.0 Core, section 2.5.1 and 2.5.1.5:

2.5.1 Element <Conditions>

<OneTimeUse> [Optional]

Specifies that the assertion SHOULD be used immediately and MUST NOT be* retained for future
**
use*. Although the schema permits multiple occurrences, there MUST be at most one instance of

this element.

2.5.1.5 Element <OneTimeUse>

In general, relying parties may choose to retain assertions, or the information they contain in some other

form, for reuse. The <OneTimeUse> condition element allows an authority to indicate that the information

in the assertion is likely to change very soon and fresh information should be obtained for each use. An

example would be an assertion containing an <AuthzDecisionStatement> which was the result of a

policy which specified access control which was a function of the time of day.

If system clocks in a distributed environment could be precisely synchronized, then this requirement could

be met by careful use of the validity interval. However, since some clock skew between systems will

always be present and will be combined with possible transmission delays, there is no convenient way for

the issuer to appropriately limit the lifetime of an assertion without running a substantial risk that it will

already have expired before it arrives.

The <OneTimeUse> element indicates that the assertion SHOULD be used immediately by the relying

party and MUST NOT be retained for future use. Relying parties are always free to request a fresh

assertion for every use. However, implementations that choose to retain assertions for future use MUST
**
observe the <OneTimeUse> element*. This condition is independent from the NotBefore and

NotOnOrAfter condition information.

To support the single use constraint, a relying party should maintain a cache of the assertions it has
**
processed containing such a condition. Whenever an assertion with this condition is processed, the cache

should be checked to ensure that the same assertion has not been previously received and processed by

the relying party.
**

A SAML authority MUST NOT include more than one <OneTimeUse> element within a <Conditions>

element of an assertion.

For the purposes of determining the validity of the <Conditions> element, the <OneTimeUse> is

considered to always be valid. That is, this condition does not affect validity but is a condition on use.

The ID4149 exception is thrown by Windows Identity Foundation (WIF), which affects security token acceptance in AD FS 2.0. The exception shows that WIF can consume OneTimeUse tokens if the Saml2SecurityTokenHandler is extended. While this is true for WIF, it is not possible to extend the security token handlers of AD FS 2.0.

AD FS 2.0, when using the WebSSO profile of SAML 2.0, does not accept or need to make use of OneTimeUse tokens because:

        -AD FS 2.0, as Service Provider (SP), does not ever cache security tokens from a CP

                -see bolded text from SAML 2.0 Core above regarding caching of tokens

        -AD FS 2.0, when in Standalone or SQL Farm configuration, has the ability to detect and stop replay attacks using built-in TokenReplayDetection

                -see SAML/WS-Federation token replay detection here: http://technet.microsoft.com/en-us/library/ee913581(WS.10).aspx

This means that AD FS 2.0 is not capable of reusing a security token because it is not cached, and if a user attempts to replay a token to AD FS 2.0, the replay is detected, token acceptance fails, and an exception is thrown.

The exception behavior is by design since AD FS 2.0 does not cache CP tokens and mitigates token replay. AD FS 2.0 is designed to refuse tokens which specify OneTimeUse.

 

Resolution

Disable OneTimeUse at the CP STS