locked
ADFS installation and Token Signning Certficate

    Question

  • I am trying to set up ADFS 2.0 for WebSSO. Some forums suggest that NOT install the role for ADFS role that is included in Windows 2008 R2 as it is not the current version of ADFS but download ADFS install along with ADFS 2.0 rollup 1. Does anyone know if the latest ADFS is included in W2k8R2+SP1 ? Also some people recommend to use third-party Token Signing Certificate. We understand we should use third-party SSL certificate. But for Token Signing Certificate,  can we use internal CA to generate it? Thanks in advance.


    This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    Wednesday, April 11, 2012 12:35 PM

Answers

  • KungfuPanda2,

    Here are my notes from the last time I researched this:

    1. The certificate's key length should be at least 2048 bits.
    2. Validity period should be as long as possible (given cost), up to 5 years
    3. The signing algorithm should be either SHA-1 or SHA-256. If you need to support ADFS 1.x legacy federation, Windows 2000, Windows XP SP2, or Windows Server 2003, use SHA-1. Otherwise, for best security, use SHA-256. You may need to call your publically-trusted certificate issuer to validate the signing algorithm.
    4. Ensure that the private key is exportable
    5. Subject name does not matter… but something like adfstoken.yourdomainname.com would be a common implementation.
    6. Key usage does not matter.

    The key points being #5 and #6 - ADFS does not care what you name the certificate or what kind of certificate is being used (i.e. code signing, server authentication, client authentication, etc.). My advice would be to generate a certificate however you'd normally feel comfortable doing so. For example, many of my clients use IIS to generate the certificate signing request (CSR), then submit the CSR to the commercial CA. Once you've loaded the certificate into the computer store, it should be available for AD FS to use.

    • Marked as answer by KungfuPanda2 Wednesday, April 11, 2012 6:58 PM
    Wednesday, April 11, 2012 5:03 PM

All replies

  • KungfuPanda2,

    -ADFS 2.0 is not included in Windows Server 2008 R2 SP1. Use the downloaded version.

    -I would encourage you to use a commercial (third-party) CA for the token signing certificate. External organizations that need to validate your token signing certificate will need to be able to access the CRL Distribution Point (CDP) of the CA that issued it. Most of my customers with an internal CA do not have the CDP architected such that it is accessible from the Internet (or, the ones that do have it accessible have not made it highly-available). However, a commercial CA would inherently have Internet access to the CDP and high-availability.

    Hope that helps,
    -Frank

    • Proposed as answer by Frank Lesniak Wednesday, April 11, 2012 3:50 PM
    Wednesday, April 11, 2012 3:50 PM
  • Thanks Frank. Do you know how to get a token-signing certificate from third-party CA? What type of cert request we need to submit ? I searched on the web but couldn't find any information related.


    This posting is provided AS-IS with no warranties/guarantees and confers no rights.


    Wednesday, April 11, 2012 4:56 PM
  • KungfuPanda2,

    Here are my notes from the last time I researched this:

    1. The certificate's key length should be at least 2048 bits.
    2. Validity period should be as long as possible (given cost), up to 5 years
    3. The signing algorithm should be either SHA-1 or SHA-256. If you need to support ADFS 1.x legacy federation, Windows 2000, Windows XP SP2, or Windows Server 2003, use SHA-1. Otherwise, for best security, use SHA-256. You may need to call your publically-trusted certificate issuer to validate the signing algorithm.
    4. Ensure that the private key is exportable
    5. Subject name does not matter… but something like adfstoken.yourdomainname.com would be a common implementation.
    6. Key usage does not matter.

    The key points being #5 and #6 - ADFS does not care what you name the certificate or what kind of certificate is being used (i.e. code signing, server authentication, client authentication, etc.). My advice would be to generate a certificate however you'd normally feel comfortable doing so. For example, many of my clients use IIS to generate the certificate signing request (CSR), then submit the CSR to the commercial CA. Once you've loaded the certificate into the computer store, it should be available for AD FS to use.

    • Marked as answer by KungfuPanda2 Wednesday, April 11, 2012 6:58 PM
    Wednesday, April 11, 2012 5:03 PM
  • Thanks Frank for your reply. It is very helpful.


    This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    Wednesday, April 11, 2012 6:58 PM
  • My advice is to use the self-signed, self-generated Certificate (by ADFS 2), automatic roll-over is *great*. Using one issued by an external CA does not make it more secure......

    Paul Lemmers

    Wednesday, April 11, 2012 7:30 PM
  • Paul,

    I disagree. Self-signed certificates are in many ways equivalent to "no security" because it's not possible to do any sort of validation of the certificate or that it was issued by a legitimate party. Additionally, you have no recourse if the certificate is compromised (i.e. you cannot revoke the certificate if it is compromised).

    An internal CA improves this situation somewhat: if the partner organization trusts your internal CA (unlikely), then the certificate itself can be validated. More precisely, it is possible to validate that the CA issued the certificate and that impersonation is not occurring. If the internal CA has its CRL Distribution Point (CDP) published to the Internet and made highly-available (unlikely), it is also possible to validate that the certificate has not been compromised since the time that it has been issued.

    In contrast, using a commercial CA allows validation of the certificate (impersonation is not occurring), and that the certificate has not been revoked. This is because the partner organization will trust the CA and be able to validate the signature of the certificate. Additionally, you are guaranteed that the CDP is published to the Internet and made highly-available.

    I think I paid $75 for a three year certificate from GoDaddy. So to me this is a no-brainer.

    Thanks,
    Frank

    Wednesday, April 11, 2012 7:49 PM
  • Sometimes there are (more or less silly, company and/or government) policies regarding the signing cert. In that case don't waste time on reading this. Just do what the (possibly silly) policy says and send them the bill.

    But: SAML metadata was designed to be able to work without the need for (external/internal) CA's, PKIX etc.... You *could* use them if you want to (for some special reason).

    The metadata mechanism has it own (potentially quicker) revocation mechanism. Implementations/People should check metadata regularly, don't do manual configuration or file configuration. Use online Metadata.
    If the signing certificate is compromised, then put a new cert in the metadata. Whether the cert is self signed or not, you need an out of band public key exchange. Initially and whenever rolling over after a compromise. The assurances of external CA's are really limited... And trusting the CA and not the key-pair is possible (see InCommon metadata). But trusting a CA in the technically incorrect way is used (which I have seen all too often), it opens the trust or even other applications to CA insertion attacks.
    If it is revocation that you want, then do analyse in detail who will intiate and actually revoke/replace the certificate. Are those the persons and organizations that your trust requires? What is the response time?


    Paul Lemmers


    • Edited by paullem Thursday, April 12, 2012 9:10 AM
    Thursday, April 12, 2012 9:08 AM