Single Sign-On – Things to ponder

Consider the following when implementing Single Sign-On: 


  • Your organization’s implementation of the Web Service must be accessible by salesforce.com servers. Typically this means that you must deploy the Web Service on a server in your DMZ. Remember to use your server’s external DNS name when entering the Single Sign-On Gateway URL on the Company Information page within Salesforce.


  • If the Salesforce.com server cannot connect to your server, or the request takes longer than 4 seconds to process, the login attempt will fail. An error will be reported to the user indicating that his or her corporate authentication service is down.
Mobile Dynamics CRM Filed Services - AhaApps
  • Namespaces and element names are case sensitive in SOAP messages. Wherever possible, generate your server stub from the WSDL to ensure accuracy.


  • For security reasons, you should make your service available by SSL only. You must use an SSL certificate from a trusted provider, such as Verisign or Thawte.


  • sourceIp is the IP address that originated the login request. Use this information to restrict access based on the user’s location. Note that the Salesforce feature that validates login IP ranges continues to be in effect for Single Sign-On users.


  • You need a way to map your organization’s internal usernames and Salesforce usernames. If your organization does not follow a standard mapping, you may be able to extend your user database schema (for example, Active Directory) to include the Salesforce username as an attribute of a user account. Your authentication service can then use this attribute to map back to a user account. Alternatively, you can use a database to store the mapping of Salesforce username to your directory’s username


  • Do not enable Single Sign-On for the system administrator’s profile. If your system administrators were Single Sign-On users and your Single Sign-On server had an outage, they would have no way to log in to Salesforce. System administrators should always be able to log in to Salesforce so they can disable Single Sign-On in the event of a problem.


  • We recommend that you use a Developer Edition account when developing a Single Sign-On solution before implementing it in your organization. To sign up for a free Developer Edition account, go to register or login.


  • Make sure to test your implementation with Salesforce clients such as Outlook Edition, Office Edition, and Offline Edition.