Can we configure ADFS for IDP initiated SSO

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.

"MMC; Help; About AD FS Management" shows the version indeed. It show the OS version. And Starting with S2012 ADFS is one-to-one linked with the OS version. You are probably on S2012 because 6.2 is S2012.

ADFS never wanted to send SAML2 Tokens to its WS-* Relying parties. ADFS always did stick to the SAML1 Tokens. SAML2 protocol mandates SAML2 Tokens. WS-* does not mandate them, and for backward compatibility and for other interop agreements they left it at SAML1 tokens?

Any specific reason why you would want a SAML2 Token? A regular WIF app will not notice the difference.