I'm new to all this security features, and recently I was asked to look into ADFS 2.0. I found ADFS uses the following types of X.509 certificates to communicate with Relying Party (RP):
Help me out please to figure out which one is really important and needed in a real-life production scenario where all 3 parts are involved: user, service provider (our company), IdP(ADFS) (on customer's server).
1) What I found regarding first certificate in MS help: "This is the same certificate that a federation server uses as the SSL certificate in Internet Information Services (IIS)" I'm not sure it's true coz I was able to replace them separately not affecting each other so they definitely might function in parallel. So no idea what this certificate is needed for.
2) Second one is for signing up issued tokens so that RP is able to make sure the token is really issued by trusted ADFS, not intercepted, right?
3) Third one is probably for reverse purposes: ADFS makes sure the message is really from trusted RP.
4) Encryption certificate for specific RP helps encrypt whole message (token), so that even if you got https public key and intercept a message from ADFS, you can not read it not having other public key which supposed to be only know to RP, correct?
Correct me if I'm wrong please.
All this certificates are optional and Micorosoft says nothing about importance of which, the only mention I cound in WIF SDK help saying it's better to use token encryption certificate in real life. The thing is we have HTTPS protocol being established for ADFS-RP communication (IIS is set up to use https on both sides). Is not it enough for secure communication? I wonder: do we really need 2), 3) and even 4)?
In a real life scenario, you have at least two:
1.) SSL certificate - just common sense nowadays, and recommended by the SAML 2.0 SSO profile. This could be the same certificate as IIS that's front-ending ADFS.
2.) Token signing / verification (not "decrypting") certificate - required to conform to SAML 2.0 profiles that use "front channel bindings" (HTTP Redirect/POST). If you're the Identity Provider (IdP) then you'll have the private signing key - if not, just the certificate (w public verification key). Indeed this is to verify that the assertions have been issued by a trusted party, and not tampered with. It is absolutely critical for federation otherwise anyone can forge their way into your environment (as the SP (RP)).
An encryption certificate would indeed be used to encrypt portions of your SAML messages - which is common if you're trying to hide information that may be passed via a user's browser (like sensitive attributes within a SAML Assertion's Attribute Statement).