ADFS and relying party token-signing certificates

Question

I haven't quite gotten the grasp of relying party token-signing certificate's functionality with ADFS 2.0 / 3.0. Once the automatic self-signed certificate roll-over occurs (by default), there are scenarios where you have to manually deliver the new token-signing certificate to (usually) an external SSO application provider in order for them to place the new certificate on their end so the SSO will keep functioning.

However, this can happen automatically. The best I've found it explained here:

AD FS and self-signed Token-Signing certificates | Kloud Blog

[ADFS] ... can automatically renew self-signed certificates before expiry, and if a relying party trust is configured for automatic federation metadata updates, automatically provide the new public key to the relying party. This automation makes for a resilient, low maintenance federation service in that a key certificate used by the service does not require periodic attention.

The question is; how do I know if a relying party trust is configured for automatic federation metadata updates? Is this plain and simply this setting in the trust (thanks Google image search):

If so, how can I ensure that the update has been successful (besides possibly the 'last checked on' date) and the relying party has automatically gotten the new certificate or its public key?

Answer 1

There are several certificates in a SAML2 and WS-federation trusts. I will ignore here the TLS certificate of the https url of the servers (ADFS calls it the communication certificate).

Each party can have a signing certificate. The messages that the party sends are signed with the private key of that certificate. SAML2 parties often sign both requests and responses. WS-Federation passive does not sign the request (so a passive RP doesn’t have one). The signing certificate is published in the metadata. During roll-over there can be two (old and new).

Each party can have an Encryption certificate. When a request or response is sent to a party with an encryption certificate then the public key of that certificate can be used to encrypt the encryption key. Making the message unreadable for everyone except the target. The encryption certificate is published in the metadata. Most of the time only one encryption certificate is published in the metadata. But old certificates are accepted for some time to make the roll-over seamless.

The automatic roll-over of ADFS is cool. I suggest you leave it that way or replace it with a self-signed cert with a validity of 10 years. ADFS will follow the metadata published by its partners if ADFS has a url for their metadata.

Relying parties in WS-Fed land, read the Microsoft .NET (also called WIF) applications. It depends on the application. Applications can publish their metadata, which is nice for the ADFS admin, because they do not have to type a lot, less out of band mis-communication etc. Win-win for everyone. So every application should publish its metadata. Better for everybody. But for passive WS-Fed relying parties there would not be a signing cert. There could be an encryption cert. .NET has classes to read and generate the metadata “per-request” in System.IdentityModel.Metadata. There are several samples of it on the Internet. One example of them is in the Thinktecture IdentityServer.

Relying parties can read the ADFS metadata. There was always a scheduled task available. It did read the ADFS metadata and then updated the web.config file of the application. I never used it because it had the side effect of a pool recycle (even if there was no change) and it did clobber the directory with old versions of web.config. If you have trouble coding a reader or writer then contact me off-line. It can be done for any app (also for SharePoint). It is a matter of costs, doing it manually (once per year) or writing code to do it automatically.

Answer 2

While replying parties consume your AD FS service, you cannot control how the replying party applications work. You need to work with them to reduce service down time.

http://www.maplelanetechnologies.com/Blog/Post/6/ADFS-3-0--Token-Signing-Certificate-Renewal-and-Service-Downtime

Answer 3

this can happen automatically.

It's more than that, it DOES happen automatically! Your certificates are automatically renewed every X days, X being the value of the property "CertificateRolloverInterval" (or maybe "CertificateDuration", I have a doubt; run Get-ADFSProperties to retrieve them).

how do I know if a relying party trust is configured for automatic federation metadata updates?

You cannot know... This is not controlled by your ADFS server. It is the other party that decides whether they check your metadata regularly or not. Well, obviously if you change your certificates, and your SSO breaks, then you know that the other party is not verifying your ADFS...

Your print screen shows the opposite, i.e. it shows that YOU are checking the other party's metadata. If you send this print screen to your partner, they know that they can change their certificates "safely".

Finale note: from my experience, the only application that has this "auto-update" functionality built-in is ADFS itself. Even Sharepoint and Dynamics CRM do not have it. So I find it pretty useless.

So to conclude, my suggestion is to disable the "AutoCertificateRollover" property of ADFS, and manage your certificates yourself. The advantage is that you use the certificate you want, with an expiration date that you choose (for TEST environment, set the expiration date 50 years later, very useful). And write in your calendar a big reminder to update your trusts when your certificate is about to expire!