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.
I need some clarification on SAML token based system. Does syncope core has any endpoints for authorization with SAML tokens??
Please ask any Syncope related questions to the Syncope user list.ReplyDelete
This comment has been removed by the author.ReplyDelete