Subject Confirmation Methods 
The following subject confirmation methods exist:
Sender-vouches
Holder-of-key
Authentication with SAML sender-vouches
With SAML sender-vouches, the user identity is forwarded between two systems, for example, between a portal and a backend system.
Subject confirmation method sender-vouches
In the first step, the user authenticates himself or herself with the portal, and in the second step, the portal calls the backend system, to specify user data in a SAML assertion. SInce there is a trust relationship between the WS consumer on the portal and the WS provider, the WS provider can use the SAML assertion for authentication.
SAML sender-vouches requires a direct trust relationship between a Web service consumer and a Web service provider system. The consumer system confirms a subject (a user) in a SAML assertion (the sender-vouches) and secures this data with an XML signature that applies to the SOAP text, the SOAP header, and the SAML assertion.
Sender-vouches is suitable for system-to-system communication. Sender-vouches is not suitable for forwarding identities from a desktop application, such as a Microsoft Office application, to a backend system, for the following reasons:
A trust relationship must be set up between each WS consumer and the backend system.
Each WS consumer must use its own key to sign the assertions.
Authentication with SAML holder-of-key
If you require a central location for the issuing of the SAML token, that is, if the WS consumer is embedded in a desktop application, use SAML holder-of-key (SAML HoK).
Subject confirmation method holder-of-key
The WS consumer first calls a central location, the Security Token Service (STS). The STS issues a token, forwards the token to the WS consumer and sends it as an authentication token to the WS provider.
The SAML HoK token is similar to an ID card. An ID card has the following properties:
It contains a handwritten signature that identifies the owner.
It is issued from a trusted location.
It contains information about the subject.
In the XML world, this corresponds to the following properties of the HoK token:
It contains a signature key.
This key binds the assertion to the message in that the XML text and XML header are signed.
The SAML assertion itself contains an XML signature that identifies the issuing location.
In a similar way to the SAML sender-vouches assertion, the token contains information about the user identity.
With Web services, SAML tokens are issued by a Security Token Service. The STS is a specific Web service that is defined by the WS Trust specification. The STS issues security tokens, exchanges them, and validates them. The STS can normally accept many token types and therefore serves the following purposes:
Acts as a broker for different token types
If a WS consumer authenticates itself with the STS using a Kerberos token, it receives a SAML token. In this way, the STS is an integration component between IT silos.
Centralizes trust relationships and authentication with a star-shaped trust relationship
The WS provider and WS consumer system both trust a central STS. Therefore, no direct trust relationship between the consumer and the provider is required. Instead, the consumer authenticates itself with the STS; and the STS issues a token that the provider trusts.