I have had several enquiries about how to configure federated single sign-on integration between Tivoli Federated Identity Manager and salesforce.com. Saleforce.com offer cloud applications for all manner of sales and CRM capabilities, and the typical use case is that an enterprise has already authenticated their employees (application users) via a company portal/website, and then want them to be able to single-click login to outsourced applications such as those hosted by salesforce.com. Earlier this year I documented a similar integration for Google Apps.
The saleforce.com SSO capability is very simple and easy to use. The underlying technology is SAML 1.1, using browser-post profile. Configuration is required at both the identity provider (in this case Tivoli Federated Identity Manager), and the service provider (i.e. a salesforce.com subscription). I was able to test this integration using a 30-day trial license, and completed the entire integration in 20 minutes. The remainder of this entry dives straight into the configuration tasks and options.
Configuration at Tivoli Federated Identity Manager (Identity Provider)
Federation Configuration
Using the Tivoli Federated Identity Manager management console, create a SAML 1.1 identity provider federation. You MUST select a signing key for the signing of SAML browser-POST messages, and the public key will need to be shared with salesforce.com (so be sure to have that ready as a PEM-encoded certificate file). All the typical SAML federation settings can be left at the default values, with the exception of the identity mapping rule.
The identity mapping rule is responsible for determining the SAML Subject (ie. the username) and certain other attributes of the SAML assertion. In the integration with salesforce.com you must determine how identities will be mapped between your local website user accounts, and salesforce.com user accounts. In the simplest case they are the same, and the SAML subject that you send from the identity provider will be the exact same username as the salesforce.com username. If this is NOT the case, identity mapping can either be done at the identity provider (with custom logic in the TFIM mapping rule), or in the case of salesforce.com, at the service provider where you can store a Federation ID for each salesforce.com user account. This is a nice feature, but can become a management headache for large numbers of users. If starting fresh I would recommend keeping them the same.
The other requirement on the identity mapping rule in TFIM for salesforce.com is to set the correct value for the Audience value in the AudienceRestrictionCondition. In my testing this value needed to be: https://saml.salesforce.com. The mapping rule ip_saml_11_salesforce.xsl can be used for this purpose in your federation.
Partner Configuration
When creating the federation partner in TFIM for salesforce.com, here are the key parameter values to use:
| Parameter |
Suggested/Default Value |
Notes |
| Provider ID |
https://login.salesforce.com |
This value should match the protocol, hostname and port (if non-standard) of “Recipient URL” that you get when you configure SSO in the salesforce.com administration panel. |
| Assertion Consumer Service URL |
https://login.salesforce.com |
This value should exactly match the entire “Recipient URL” that you get when you configure SSO in the salesforce.com administration panel. |
| Partner uses HTTP POST profile for Single Sign-On |
Checked |
This checkbox should be selected as salesforce.com does use the browser-post profile. |
| Validate Signatures on Artifact Requests |
Unchecked |
Unchecked and not-needed because salesforce.com does not use browser-artifact profile. |
| Sign SAML Assertions |
Unchecked |
Not required as the entire SAML Response is signed for browser-post profile. |
This completes the configuration for TFIM. If you are using TAM/WebSEAL as your point-of-contact, don’t forget to run the tfimcfg utility to establish the correct TAM ACL policy.
Configuration at salesforce.com (Service Provider)
Login to your salesforce.com account as a system administrator, then click on Setup (right at the top). Navigate to Administration Setup->Security Controls->Single Sign-On Settings. Enter configuration settings as follows:
| Parameter |
Suggested/Default Value |
Notes |
| SAML Enabled |
Checked |
This must be enabled to allow SAML authentication. |
| Identity Provider Certificate |
Signer cert from TFIM identity provider |
This should be an uploaded PEM-encoded certificate file containing the public key matching the signing certificate at the TFIM identity provider. |
| SAML User ID Type |
Assertion contains User’s Salesforce username |
There are two choices, and this is the selection you would use when the identities on your identity provider website match the usernames in your salesforce.com account. If the names do not match, then you would select Assertion contains the Federation ID from the User object and you would need to enter a Federation ID for each user in the Manage Users menu. |
| SAML User ID Location |
User ID is in the NameIdentifier element of the Subject statement |
Again there are two choices, and this is the most logical. The other choice would be for advanced user mapping scenarios and allows the value to be read from an nominated Attribute in the AttributeStatement of the SAML assertion. |
| Issuer |
The Protocol ID value from your TFIM federation |
This value must match the Issuer in the SAML assertion, which comes from the Provider ID value defined in the identity provider SAML federation settings in TFIM. |
Testing and Debugging the Configuration
To launch a single sign-on, use the TFIM intersite transfer service URL. This be part of your TFIM federation configuration, but will look something like:
https://yourwebsite.com/FIM/sps/saml11idp/saml11/login?TARGET=https://login.salesforce.com
You can always check the value of your intersite transfer service URL in the federation properties for your federation in the TFIM console.
If you have any errors on the identity provider side, check the WebSphere Application Server SystemOut.log for details.
If you have any errors on the salesforce.com side, the best place to check is in the administration console under Administration Setup->Manage Users->Login History
Conclusion
Integration with salesforce.com is simple, easy to setup and manage, and it works. Authentication can be done via either SAML federated single sign-on or local username/password concurrently (unlike GoogleApps which is all-or-nothing when using federation). Prior planning is required to decide how to manage user identity mapping.