locked
ADFS Token Encryption/ Decryption Certificate - A great Confusion RRS feed

  • Question

  • I am hoping that some may clarify once and for all. in ADFS, We understand SSL/service communication and Token Signing Certificate fine and how they are used.

    But we cant understand how the Token Encryption/Decryption Cert is used? in our ADFS 3.0 there few relying party trusts. We provide token signing cert to all of them when  auto-rollover generate new tokens every year. One of the relying party trust partner asking for token encryption / decryption certificate also in addition to token signing cert. Do we have to provide Encryption/decryption cert also? is there a KB that explains exactly how the encryption/decryption cert is used?

    I have gone through https://blogs.technet.microsoft.com/askpfeplat/2015/01/26/adfs-deep-dive-certificate-planning/

    according to this article, since we are not consuming tokens so we should not be providing encryption/ decryption certs. But why that relying party trust requires token encryption/decryption cert?

    I also saw http://stackoverflow.com/questions/11727526/adfs-difference-between-token-decrypting-certificate-and-relying-party-signatur 

    But still not clear.

    Thanks a lot

     



    • Edited by Birla Wednesday, January 4, 2017 2:59 AM
    Wednesday, January 4, 2017 1:11 AM

Answers

  • Well it is as the stackoverflow-thread says, token encryption/decryption is used when you want to/need to encrypt the information in the SAML-token. 

    So for example, the signing certificate is used to sign the SAML-token, all data within the token is readable in clear-text but when the SP receives the token it knows it has not been modified on the way and is from intended source.

    Encryption on the other hand is used to encrypt the information in the SAML-token itself, so the assertions within the token is not readable until its decrypted. 

    You can fairly easy verify the encryption on your own to get a better understanding of how it works.
    Just do a SAML-trace in Firefox against a Relying Party with an encryption certificate and check the SAML-token, you will see that the saml:p response to the SP will be encrypted. So the Attributes and Values is encrypted and not readable.

    And then you do the same against a Relying Party without an encryption certificate and check the SAML token. Now you will see all Attibutes and Values in the saml:p response is readable in cleartext.


    • Edited by Jorrk Wednesday, January 4, 2017 12:29 PM
    • Marked as answer by Birla Friday, January 6, 2017 12:26 AM
    Wednesday, January 4, 2017 12:27 PM
  • Hi Birla,

    If you are doing any RP initiated authentication, then the RP will send an AuthN request with the user redirect. There may be a security policy that requires that the AuthN request is encrypted in transit, this might occur if there was some special information in the AuthN request that you or the RP consider confidential.

    The only way to encrypt the AuthN request (or any other information sent from the RP to your IDP using SAML) is to provide them with your encryption certificate.

    In case you were wondering, there is no risk providing the public key of your encryption certificate. In all versions of ADFS it is automatically published publicly on your federation metadata. In fact, if you provide them the federation metadata URL they should be able to download the metadata and extract your certificates. If they setup an automated process there is no need for them to ask for your certs at all - that is what federation metadata is for.

    Good Luck!

    Shane

    • Marked as answer by Birla Friday, January 6, 2017 12:26 AM
    Wednesday, January 4, 2017 9:58 PM

All replies

  • Well it is as the stackoverflow-thread says, token encryption/decryption is used when you want to/need to encrypt the information in the SAML-token. 

    So for example, the signing certificate is used to sign the SAML-token, all data within the token is readable in clear-text but when the SP receives the token it knows it has not been modified on the way and is from intended source.

    Encryption on the other hand is used to encrypt the information in the SAML-token itself, so the assertions within the token is not readable until its decrypted. 

    You can fairly easy verify the encryption on your own to get a better understanding of how it works.
    Just do a SAML-trace in Firefox against a Relying Party with an encryption certificate and check the SAML-token, you will see that the saml:p response to the SP will be encrypted. So the Attributes and Values is encrypted and not readable.

    And then you do the same against a Relying Party without an encryption certificate and check the SAML token. Now you will see all Attibutes and Values in the saml:p response is readable in cleartext.


    • Edited by Jorrk Wednesday, January 4, 2017 12:29 PM
    • Marked as answer by Birla Friday, January 6, 2017 12:26 AM
    Wednesday, January 4, 2017 12:27 PM
  • Hi Birla,

    If you are doing any RP initiated authentication, then the RP will send an AuthN request with the user redirect. There may be a security policy that requires that the AuthN request is encrypted in transit, this might occur if there was some special information in the AuthN request that you or the RP consider confidential.

    The only way to encrypt the AuthN request (or any other information sent from the RP to your IDP using SAML) is to provide them with your encryption certificate.

    In case you were wondering, there is no risk providing the public key of your encryption certificate. In all versions of ADFS it is automatically published publicly on your federation metadata. In fact, if you provide them the federation metadata URL they should be able to download the metadata and extract your certificates. If they setup an automated process there is no need for them to ask for your certs at all - that is what federation metadata is for.

    Good Luck!

    Shane

    • Marked as answer by Birla Friday, January 6, 2017 12:26 AM
    Wednesday, January 4, 2017 9:58 PM