ADFS 2.0 / PingFederate Encryption

AD FS 2.0 Encryption Strength


In AD FS 2.0, encryption of outbound assertions is turned on by default. Assertion encryption occurs for any relying party/service provider for which AS FS 2.0 possesses an encryption certificate.

When it performs encryption, AD FS 2.0 uses 256-bit Advanced Encryption Standard (AES) keys, or AES-256. In contrast, by default PingFederate supports a weaker algorithm (AES-128). Failing to reconcile these conflicting defaults can result in failed SSO attempts.Alternatives for addressing this issue include the following:

• Disabling encryption in AD FS 2.0. To disable encryption, on the AD FS 2.0 computer, click Start, click Administrative Tools, and then click Windows PowerShell Modules. Then, at the Windows PowerShell command prompt, type the following:

other

Copy

set-ADFSRelyingPartyTrust –TargetName “Ping Example” –EncryptClaims $False

• Upgrade PingFederate’s encryption capability. Because of import control restrictions, the standard Java Runtime Environment (JRE) distribution supports strong but not unlimited encryption. For this reason, the strongest cipher suites are commented out of the two configuration files com.pingidentity.crypto.SunJCEManager.xml and com.pingidentity.crypto.LunaJCEManager.xml, which are located in the folder /server/default/data/config-store. To use the strongest encryption, remove the comments from the AES 256 cipher suites, and then download and install the appropriate version of Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from the Java SE Downloads (http://go.microsoft.com/fwlink/?LinkId=206383).

ADFS 2.0 WS-Federation

Just heard from a MS support engineer yesterday,
ADFS 2.0 does not support WS-federation as Idp-Initiated SSO. It has to be SP-Initiated SSO. However it supports SAML 2.0 in both modes.

ADFS - SAML 2.0 for Idp Initiated SSO

Scenario: My first experience setting up an ADFS environment to enable federation between ADFS and PingFederate. This is strictly Idp Initiated SSO scenario, where ADFS is the Idp.

Steps:
1. Send federation xml to relying party / SP (PingFederate user). This should include SSL certificate information and chain certificate information.
2. Receive xml from relying party
3. Extract certificate information from xml and save as .cert file. (This is done by extracting text content from relying party xml between the tags,
)
4. Store .cert file in AD or local server Trusted Root certificate store
5. Create a relying party connection in ADFS by uploading relying party xml from step 2.
6. Edit and setup claim rules, for e.g. map employee ID from AD (i.e. LDAP) to Name ID claim type.
7. Load certificate from relying party into relying party encryption configuration in ADFS.

*These steps should ideally be enough to setup the federation. The client needs to have his application point to Idp ADFS. The Url would look something like this,

https://adfs-server-hostheader/adfs/ls/idpinitiatedsignon.aspx?LoginToRP=RPIdentityName
where RPIdentityName is the name of the Relying Party Identifier name.

Troubleshooting tips:
1. Many a time security is an issue. Hence we need to run some powershell scripts to disable encryption.
e.g. Set-ADFSRelyingPartyTrust

2. Use Fiddler to track SAML traffic, http://msinnovations.wordpress.com/2011/05/24/using-fiddler-to-trace-a-saml-idp-request-from-adfs-2-0/

Critical Issue:

Reference http://technet.microsoft.com/en-us/library/adfs2-federation-with-ping-identity-ping-federate(WS.10).aspx

"AD FS 2.0 does not support the declaration of a Target or RelayState parameter when it acts as the IdP during IdP-initiated SSO. Therefore, successful use of the third link (IdP-initiated SSO)—which does not state the target application explicitly—requires the SP to use the Default URL feature in PingFederate (which is already configured in this lab). The setting is available on the Main Menu under My SP Configuration\Application Integration Settings\Default URLs."

In our situation, the relying party had PingFederate and had a dummy url as its default url which was causing issues during federation.

Solution: (Read right to the end) ADFS and RelayState issues
http://social.msdn.microsoft.com/Forums/en/Geneva/thread/91812934-e620-44c7-b4ef-8383083dc3c4

http://syrstad.blogspot.com/2011/02/adfs-saml-and-relaystate.html
 
http://mydailytechlog.blogspot.com/2011/09/adfs-idp-initiated-sso-relaystate.html


Update (9/23/2011):

None of the above code options worked for us since our RelyingParty is PingFederate.

This final solution which should work in this scenario is to a SP-Initiated SSO as mentioned in this link,
http://social.msdn.microsoft.com/Forums/ar-SA/Geneva/thread/dbd703a1-d6ce-4376-ac49-9d7e1809c9f3 
and confimed by MSFT here,
http://social.msdn.microsoft.com/Forums/en/Geneva/thread/91812934-e620-44c7-b4ef-8383083dc3c4