Adfs: Difference between token decrypting certificate and relying party signature verification certificate

Question

I am trying to set up a Relying Party (SP) with ADFS. ADFS recognizes and responds for requests without signature. But ADFS fails to verify a signed AuthRequest. I have a certificate imported into relying party's 'Signature verification certificates' section but this certificate does not seem to be used in signature verification of requests from the relying party.

Rather it seems to use a 'token-decrypting' certificate. I do not understand the purpose of this certificate. Can someone please explain me the difference between these two certificates and how to replace a 'token-decrypting' certificate with another self-signed certificate (in DER or pem format)? Thanks

Fyi: sample AuthnRequest sent to ADFS

<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://adfs-sj1.sjlab.local/adfs/ls/" ID="_422d0bb72b1120db737695464793dedf4ea8ddd2" IssueInstant="2012-07-30T21:52:47.501Z" Version="2.0">
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">spid</saml2:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
            <ds:Reference URI="#_422d0bb72b1120db737695464793dedf4ea8ddd2">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <ds:DigestValue>S5b7PCF8WscoOX++EcpyjQNW4q0=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>g1PXYERi48Q/vGXNBPwZlteyihQmt3eo9+MIQlBdC8MqTsm8GdvE1Nq4osszEyprAK5Q6Uv5QV/UgctUWGV2hUxLc5bpXVwpaYaoywH0XPXArROR1EyGVz2g5YAjgGxpU0YbxJIk+2A1DblE0alYSK/88oHHcmpwp6dmgwmvfXcRA83DnVCeIZoKSPuNTqSLb6UKk+QxUABieuAb1ecsQmJsEjUXcrPq+RPL1+goNhC4/vbPatuK90ZyZe5CljwAtWXmqoBzWexxgWdzs4E9zIc/aQi/HFioGz0EnPiipgBjHRlV+Gv0iFV1dS++a24+F7H2NG6aZSGipcyj2kJMDg==</ds:SignatureValue>
    </ds:Signature>
</saml2p:AuthnRequest>

Solution 1

Good article: AD FS 2.0: How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates.

The Service Communications certificate is essentially the IIS SSL certificate and serves the same purpose.

The Token-Decrypting certificate is for communication with other claims providers. They encrypt the token with this certificate's public key and ADFS decrypts with the private key.

The Token-Signing certificate is used to sign the token sent to the RP to prove that it indeed came from ADFS.

Plus when you select the encrypt option when using FedUtil, you use another certificate on the RP side to encrypt the token. In this case, it is double encrypted - SSL plus RP certificate.

Your question is somewhat confusing. ADFS always signs the RP token. It's not optional. Could you please clarify?

Solution 2

• Service Communications — This SSL cert is used to encrypt all client connectivity to the AD FS server.

• Token-Signing — This x.509 cert is used to sign the token sent to the relaying party to prove that it indeed came from AD FS.

• Token-Decrypting — This x.509 cert used to encrypt the payload of a SAML token before its encrypted again at the SSL transport layer. It is rarely used.

Hope this answers your original question

Comments

[Rag]

Thanks for your answer. I was assuming ADFS was the Claims Provider and it generates secure tokens (Saml Assertion) back to the relying party. But you seem to mention someoneelse other than ADFS to be Claims Provider. Do you say ActiveDirectory as Claims Provider and ADFS as STS (Secure Token Service) which generates secure token out of the claims of ActiveDirectory?

[Rag]

Also the problem I had was, the relying party sends a signed AuthnRequest with SHA1. But from event logs, I found that it was expecting the message signature to have SHA256. I was not able to figure out of the components in the architecture and I ended up replacing the 'token-decrypting-certificate' with a relying party certificate. This could be wrong and ADFS went on to complain about a different problem.