SSO to Salesforce.com

James, my partner in crime had recently asked about features in federation products. I want to leave out the comparison part to analysts and customers since it’s very much depend on the end use case.

However (getting a bit specific), I was recently in a conversation on ‘why should the customer use PingFederate instead of a home grown solution to do SSO to Salesforce.com’ (SSO to Salesforce.com was the big focus for PingFederate’s latest release in September). Here are some of the reasons I came up with:

  • Multiple access methods for Salesforce.com
    • SP-Initiated SSO via Direct Logon: The user navigates directly to Salesforce.com, enters a corporate email address and password, and is authenticated via the PingFederate Authentication Service.
    • IdP-Initiated SSO: The user logs on to an Identity Provider (IdP) application integrated with PingFederate. By clicking a specific URL that goes through PingFederate, the user can SSO to salesforce.com. The admin can choose to deploy this use case using either Delegated Authentication or SAML.
    • SP-Initiated SSO via “Deep Linking”: The user clicks a link in an email to a Web page inside salesforce.com, which sees that this user has performed SSO previously and redirects the user to the IdP for authentication. After logging on, the user is redirected back to salesforce.com—to the “deep link”, rather than the default home page.
    • SP-Initiated Single Logout (SLO): The user is logged on to salesforce.com and wants to log out of both salesforce.com and the IdP application. Upon clicking the logout link, the user is also logged out of the IdP application.
  • Outlook Access via the Rich Client Proxy Service: The user is using the Microsoft Outlook plug-in that Salesforce develops and maintains. The plug-in stores the user’s corporate email and password, which are used to authenticate to the corporate LDAP directory via a Rich Client Proxy service. The user’s salesforce.com data synchronizes with Outlook; thus, by using PingFederate, the corporate credentials are not transmitted outside the firewall.
  • Works with existing infrastructure: PingFederate provides out-of-the-box integration with a number of authentication and enterprise identity systems including Integrated Windows Authentication (IWA), LDAP authentication, CA Siteminder, Oracle Access manager, BEA Weblogic etc. You can find the up-to-date list of supported systems here.
  • Automated account provisioning: Administrators create a group or filter to contain all Salesforce.com users in the existing corporate directory. As changes are made to user accounts in the corporate directory, PingFederate automatically replicates each change to Salesforce.com via the Salesforce.com provisioning API.
  • Proven architecture: Over 30 customers are using PingFederate for SSO to Salesforce.com including Cox Media, Rearden Commerce, Cognos, LandAmerica and many others.
  • Rapid Deployment: PingFederate can be setup for SSO to Salesforce in a matter of days. The latest release of PingFederate bundles a quick-connection template for Salesforce.com that automatically configures many of the settings required for Salesforce SSO as well as provisioning in the PingFederate administrative console.
  • Standard/Independent server to manage SSO: Adding another SSO partner (internal or external) is as simple as adding a connection within PingFederate console. Other than Salesforce.com Delegated Authentication Protocol, PingFederate supports SAML 1.0, 1.1, 2.0 and WS-Federation.

Expect a call from our sales team, James :-) .

Leave a Reply

Image | WordPress Themes