A while back I posted configuration notes for SAML 1.1 Integration with Salesforce.com. The integration was performed with a trial edition of Salesforce CRM. Since that time Salesforce have added support for SAML 2.0 as a single sign-on protocol. This article will highlight the configuration requirements for SAML 2.0.

If you haven’t already done so, please read my earlier posting on the SAML 1.1 Integration with Salesforce.com as most of the configuration is identical and explanations won’t be repeated in detail in this posting.

Technical Summary

For those familiar with TFIM and SAML 2.0, here are my technical summary observations from the integration:

• The SSO is still performed with SAML Browser-POST profile using only IDP-initiated SSO. I was not able to find any way to trigger SP-initiated SSO for Salesforce CRM. It appears from reading the very detailed Salesforce Documentation that some Salesforce product offerings do support SP-initiated SSO, however I don’t believe the trial edition of Salesforce CRM is one of them.
• All of the same user mapping options are identical between the SAML 1.1 and SAML 2.0 offerings.
• Some extra TFIM configuration is required to set the DefaultNameIdFormat attribute for the federation or partner to urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Configuration Details

TFIM SAML 2.0 Identity Provider Configuration

Use the TFIM console to create a SAML 2.0 Identity Provider federation using all of the default federation options, including the default ip_saml20.xsl mapping rule. We will override the mapping rule at the partner level later anyway. After configuration of the federation you can optionally disable artifact profiles as only the browser-post profile is used for this integration. For the example given here, the federation name I chose was saml20idp.

If you are using WebSEAL as your point-of-contact, don’t forget to run the tfimcfg utility to set the TAM access control lists and WebSEAL configuration required for the federation to work.

There is no need to export the SAML 2.0 metadata for the TFIM IDP federation from the console as this is not used for configuration at salesforce.com

Salesforce.com SAML 2.0 Service Provider Configuration

After establishing my free trail Salesforce CRM account (via www.salesforce.com) and logging in, click to the Setup link (click on any image to view it in actual size):

On the left navigation frame, navigate to Administration Setup -> Security Controls -> Single Sign-On Settings:

Enable SAML via the checkbox, then enter your SAML settings:

After saving the configuration, download the SAML 2.0 metadata that is required to create a partner in TFIM from the link shown:

Adding Salesforce as a SAML 2.0 Partner to the TFIM Identity Provider Federation

You can use the standard partner wizard in the TFIM console to create the partner configuration using the metadata provided by Salesforce. All the default federation options can be used, although I recommend this mapping rule for your Salesforce partner: ip_saml_20_salesforce.xsl. After the partner is created, reload the TFIM configurations using the console.

Your work for the SAML 2.0 partner is not quite down however, as we need to set the DefaultNameIdFormat property for the partner as salesforce.com by default uses the “unspecified” nameid format, and we are going to perform IDP-initiated SSO. The TFIM command line interface is required for this step. Login to wsadmin on the WebSphere running the TFIM Management Service (typically the dmgr node in a cluster):

To verify the name of your federation and partner, list all partners (my examples use a FIM Domain called idp):

wsadmin>$AdminTask manageItfimPartner {-fimDomainName idp -operation list}
{Partner Role=sp, Partner Name=https://saml.salesforce.com, Federation=saml20idp, Status=Enabled}

Now create a response file for you partner:

wsadmin>$AdminTask manageItfimPartner {-fimDomainName idp -operation createResponseFile 
  -fileId /tmp/x.x -federationName saml20idp -partnerName https://saml.salesforce.com}
FBTADM001I Command completed successfully

Now edit the response file and update the DefautlNameIdFormat property. This examples shows the TFIM 6.2.1 response file format, however the property also exists in TFIM 6.2.0. Note that we are configuring the DNameIdFormat to urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. This simply means to use the userid as the NameIdentifier in the SAML Subject:

  <void method="put">
   <string>DefaultNameIdFormat</string>
   <object class="java.util.ArrayList">
    <void method="add">
     <string>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</string>
    </void>
   </object>
  </void>

Now update the partner configuration with the modified response file:

wsadmin>$AdminTask manageItfimPartner {-fimDomainName idp -operation modify 
  -fileId /tmp/x.x -federationName saml20idp -partnerName https://saml.salesforce.com}
FBTADM001I Command completed successfully

Finally reload the TFIM configurations

wsadmin>$AdminTask reloadItfimRuntime {-fimDomainName idp}

Testing and Debugging Considerations

For triggering IDP-initiated SSO, I use a URL similar to this:

https://www.myidp.ibm.com/FIM/sps/saml20idp/saml20/logininitial?RequestBinding=HTTPPost&PartnerId=https://saml.salesforce.com

Debugging was exactly the same as discussed in the SAML 1.1 integration. For issues on the Identity Provider, check the TFIM WebSphere logs. For issues at Salesforce.com, check the user authentication history under Setup->Administration Setup->Manage Users->Login History.

The Salesforce documentation for SAML federated single sign-on also contains some good debugging tips and best practices for your integration.

Conclusion

The TFIM SAML 2.0 integration with Salesforce CRM (at least with the trial I used) was quite straight forward with only one advanced piece of configuration requried for setting the DefaultNameIdFormat. Given a choice I would still use the SAML 1.1 configuration as it’s simpler, unless I was using a Salesforce.com offering that supported SP-initiated single sign-on. In that case I would probably use SAML 2.0 just for user convenience so that when a user bookmarked a salesforce.com page they would be automatically redirected to my IDP for authentication.

From a quick perusal of the Salesforce.com documentation there are a lot of other SAML 2.0 capabilities discussed which appear to be for offerings beyond those exposed in the trial edition of Salesforce CRM that I had access to. In any case it appears the integration with TFIM is straight forward and I would not expect any insurmountable interoperability issues.