Idp-Initiated SSO to SalesForce.com and AD FS 2.0 in 5 minutes

This post is to demonstrate how you can configure cloud-based applications for federated authentication using AD FS 2.0 RC. Basically, any service provider supporting SAML authentication via IdP-initiated SSO or SP-initiated SSO profiles. In Beta 2, Joe and I had to extend this functionality through code but AD FS 2.0 RC eliminates the need for this making it a strictly out-of-box solution.

To get this working, the only thing you’ll need is a workable ADFS 2.0 installation and rights within SalesForce.com to configure SSO. My 5 minute timeframe only factors in the actual configuration work.

SalesForce.com enables SSO at the user level by Profiles. You can create an SSO-enabled profile and test user for your test case. AD requires a valid user which will contain valid assertions (claims) which will map to profile information in SalesForce.com.

To enable SAML SSO in Salesforce.com, do the following steps:

1. Enable Federated single sign-on using SAML.
2. Specify the issuer name. For example, https://idp.identityjunkie.com/adfs/services/trust
3. Upload token signing certificate.
4. Specify the Username ID Type = Username and Location which will be within the NameIdentifier element of the SAML token.

Salesforce.com provides a SAML Assertion Validation tool you can run against their configurations. This can be extracted from ADFS using Fiddler.

On the ADFS side, create a Relying Party Trust.

1. There is no exchange of federated metadata, so you’d select Enter data about the relying party manually.
2. Assign a Display Name.
3. Select AD FS 2.0 profile
4. Specify an optional encryption certificate. This is used to encrypt the claims being sent to the RP. For this case, none was used.
5. You only need to enable support for the SAML 2.0 Web SSO protocol. WS-Federation is not used here. Enter the URL provided by Salesforce.com as the SAML 2.0 SSO Service URL.
6. Add the relying party trust identifier. This is https://saml.salesforce.com.
7. Define your Issuance Authorization Rules.
8. Configure the Claim Rules. Here you would map your issuance transform rules to Send LDAP Attributes as Claims. For example, E-Mail-Addresses > Name ID.

That’s it. As the user, the experience is to initiate the sign-on process at the IdP which is your ADFS server:

https://sts.identityjunkie.com/adfs/ls/IdpInitiatedSignOn.aspx

You can bypass the entire site selection process by using the loginToRp=federation.urn. For example: https://sts.identityjunkie.com/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=https://saml.salesforce.com

This will provide the user with an “auto-login” experience.