With this scenario, the STS and the consumer negotiate a symmetric key. This is used for an endorsing signature for messages between the consumer and the provider. The consumer uses this endorsing signature to prove that it is in possession of the key that the STS signed.
This symetric key is not used to encrypt messages between the consumer and the provider.
The figure shows the steps that take place with this scenario:
The service user of the consumer authenticates himself or herself with the Security Token Service (STS), for example, with a Kerberos token. The STS exchanges this for a security token (SAML token). The consumer can contribute material to the creation of the short-lived key.
The STS generates a short-lived symmetric key, which it encrypts with the public key of the provider. The STS inserts this key, together with the security token, into the SAML assertion, and signs the SAML assertion with a signature key.
The STS issues the SAML assertion as an SAML token and sends it, together with its key material for generating the short-lived symmetric key, to the consumer.
The consumer generates the short-lived symmetric key from its material and the key material from the STS.
The consumer signs the SAML token and the message text with the generated short-lived symmetric key and sends the user's request to the provider.
Since the consumer only signs the message and does not encrypt it, the communication route between the consumer and the provider must be secured using other methods, such as using the Secure Sockets Layer protocol (SSL protocol), or with a symmetric trust relationship based on the exchange of X.509 certificates.
The provider checks the STS signature in the SAML token and uses its private key to decrypt the short-lived symmetric key contained in the SAML token.
The provider verifies the signature of the consumer (that is, the Holder-of-Key) with the decrypted short-lived symmetric key. In this way, the STS confirms that the Holder-of-Key is the subject (the user) in the assertion. The provider allows the user whose ID is contained in the SAML token to access the resources.