Security semantics of SAML SubjectConfirmation methods in Apache WSS4J/CXF

A recent blog post covered two new security advisories issued for Apache CXF in relation to SAML tokens. In particular, one advisory dealt with the enforcement of the security semantics of SAML SubjectConfirmation methods when used with the TransportBinding:

There are different security requirements associated with SAML
SubjectConfirmation methods. These security requirements are not properly enforced in Apache CXF when used with the TransportBinding, leaving endpoints that rely on SAML for authentication vulnerable to types of spoofing attacks.

In this post I will recap the security requirements that are associated with SAML SubjectConfirmation methods in the latest CXF releases:

• Holder-of-Key: If the subject confirmation method is "holder-of-key", there must be some proof-of-possession of the key associated with the subject of the assertion. CXF will enforce that either the key was used to sign some portion of the SOAP request, or alternatively the subject credential of the SAML Assertion must match a client certificate credential when TLS with client authentiction is used.
• Sender-Vouches: If the subject confirmation method is "sender-vouches", then CXF will enforce that the SAML Assertion and SOAP Body are signed by the same signature. Alternatively, it will check that TLS with client authentication is used.
• Bearer: The SAML Assertion must be signed (with an internal XML Signature) by default. This can be configured in the latest WSS4J releases.

In addition, the SamlAssertionValidator in WSS4J now enforces that at least one of the standard SubjectConfirmation methods (as listed above) is present. It is also possible to specify a given SubjectConfirmation method that is required.