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?

Solution 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.

Solution 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

Comments

[paullem]

Yes, the reminder in the calendar is the trick! Costs nothing!

[Michael12345]

Thank you for this - you've really nicely summarised a number of concepts here that I am still wrestling with.

[Daniel]

To add just a little bit, in ADFS this metadata is found at adfs.yourdomain.com/federationMetadata/2007-06/… If the Relying Party is using this URL to configure their stuff, then it should sync certs automatically. There's no guarantee they don't cache them forever, but ideally... IF the relying party is asking you for any other URL or for certificate files, then they are not supporting automatic update.