The Web service client invokes a Web service. The WSDL for the Web service

Setting Up Your Environment for Policies 10-67 A symmetric proof key is generated on the STS side, or on the client side, or by taking inputs from both sides, as described in How the Proof Key is Determined SAML HOK Only on page 10-68. The STS puts this symmetric proof key in the SAML HOK assertion in an encrypted form that only the Web service can decrypt. Then, it signs the entire SAML assertion including the encrypted proof key and sends it to the client. When the client sends this SAML assertion to the server, it also needs to sign something with this proof key. The Web service will at first verify the STS signature of the SAML assertion, extract the proof key from the SAML assertion, and then decrypt it and verify the client’s signature. This client’s signature “proves” to the server that the client has the proof key. Because this proof key is never sent in clear text, a rogue client cannot get it by network sniffing. Even if a rogue client gets the SAML assertion by network sniffing, it cannot make use of it, because it does not have the proof key and cannot sign with it. Therefore, the rogue client cannot prove to the server that it is allowed to use the SAML assertion. ■ SAML Holder of Key Asymmetric. The asymmetric proof key works as follows. 1. The client generates a publicprivate key pair. 2. It keeps the private key and securely sends the public key to the STS along with its token username token, Kerberos, X509, and so forth. 3. The STS verifies the client’s token, and returns a SAML assertion containing the public key. The entire SAML assertion including the public key is signed by the STS and returned to the client. 4. The client then sends a SAML HOK asymmetric assertion to a Web service, and it signs something with the private key of that public-private key pair. 5. The Web service verifies the STS’s signature of the SAML assertion, then extracts the public key from the SAML assertion and uses it to verify the client’s signature. This client’s signature proves to the Web service that the SAML assertion is being used correctly, and was not stolen and replayed. Note: Unlike in the case of SAML HOK symmetric key, this public key in SAML HOK is not encrypted. This reduces the amount of configuration required on the STS side. For SAML HOK symmetric, the STS must be configured with each Web service’s certificate so that it can encrypt the symmetric key for that Web service. This is not required for SAML HOK asymmetric. Also, the same SAML HOK asymmetric token can be sent to any Web service because it is not encrypted with a particular Web service’s key.