Configuration Guides › Policy Server Configuration Guide › Authentication Schemes › WS‑Security Authentication › Choose a WS‑Security Token Type › SAML Assertion Token › Token Subject and Issuer Confirmation and Validation

Token Subject and Issuer Confirmation and Validation

The WS‑Security authentication scheme can use multiple aspects of an incoming SOAP document to validate the subject and issuer of a SAML token:

• The web service consumer represented as the subject of the assertion can be validated against an associated user database.
• The assertion issuer can be validated against a corresponding certificate or public key in the Smkeydatabase.
• The integrity of the message content can be verified using the signature of the issuer, the subject, or both.

The exact manner in which the authentication scheme assertion subject and issuer are validated depends on the subject confirmation method that you specify. SOA Security Manager supports both methods defined in the Web Services Security SAML Token Binding specification.

Holder-of-Key Subject Confirmation Method

The holder-of-key method confirms that the subject of the SAML token and the sender of the request containing that token have the same identity, mandating the following:

• The SAML token must contain the public key/certificate of the subject and be signed by the token issuer.
• The request sender must sign the SOAP envelope with its private key and the signature reference must point to a matching public key/certificate in the SAML token.

SAML tokens with the holder-of-key subject confirmation method are reusable. That is, when returned to the web service consumer (as in the multistep authentication method), a holder-of-key SAML token can subsequently be associated with other SOAP documents—not just with the document sent to the authentication service. This allows the web service consumer to send one request to the authentication service and then associate the returned token with multiple documents and send them directly to target web services.

Sender-Vouches Subject Confirmation Method

The sender-vouches method confirms that the subject of the SAML token was authenticated by the trusted token issuer, which vouches that the identity of the token’s subject is the web service consumer making the request. The token issuer then binds the assertion and the message body together by signing them with its private key.

Note: The sender-vouches token is valid only in association with the SOAP document to which it is bound by the authentication service—it cannot be reused with other documents.

The identity of the token issuer can be validated during authentication by doing the following:

• Verifying the issuer’s digital signature, which can cover the assertion (holder-of-key) or the assertion and message content (sender-vouches), and then validating that the issuer’s certificate is one of the trusted issuer public keys/certificates stored in the Smkeydatabase.
• (Sender-vouches only) Using an SSL link (established using the SSL client cert option) between the issuer of the token and the downstream web service that consumes it. In this case, the assertion and contents do not necessarily need to be signed.

The main distinction between these validation mechanisms is that the digital signature mechanism requires signed elements within the message being processed. When using the SSL case, you can improve security by configuring SOA Security Manager to obtain the token issuer’s client certificate from the link and use it to validate against the Smkeydatabase.

The following table provides a complete summary of the security features and associated validation methods available for messages using the different subject and issuer confirmation methods.

Note: Sender-vouches with SSL-based issuer confirmation is weaker than sender-vouches with signature-based issuer validation. With signature-based issuer validation, each message is protected by the holder of the issuer private key, whereas in the SSL case only the channel is protected by the holder of the issuer private key. This means if an intruder gets access to the channel, anything sent on that channel is considered valid; whereas, in the general case the intruder would have to actually get access to the issuer private key itself to sign individual messages.