Single Sign-On is a process that allows network users to access all authorized network resources without having to separately log in to each resource. Single Sign-On also enables your organization to integrate with an external identity management system or perform web-based single sign-on to Force.com. Single Sign-On enables multiple types of authentication integration, but the most common are:
As of Summer 08 Salesforce.com provides SAML 1.1 Browser Post support in addition to the methods below! Here's a great writeup on SAML support: http://wiki.developerforce.com/index.php/Single_Sign-On_with_SAML_on_Force.com
Single Sign-On produces benefits in three main areas - reduction in administrative costs, increased ease of use and better implementation of security schemes.
The high-level process for authenticating users via Single Sign-On is as follows:
1. When a user tries to log in—either online or using the API—Salesforce validates the username and checks the user’s profile settings.
2. If the user’s profile has the "Uses Single Sign-on" user permission, then Salesforce does not authenticate the username with the password. Instead, a Web Services call is made to the user’s single sign-on service, asking it to validate the username and password.
3. The Web Services call passes the username, password, and sourceIp to a Web Service defined for your organization. (sourceIp is the IP address that originated the login request). You must create and deploy an implementation of the Web Service that can be accessed by Salesforce.com servers.
4. Your implementation of the Web Service validates the passed information and returns either "true" or "false."
5. If the response is "true," then the login process continues, a new session is generated, and the user proceeds to the application. If "false" is returned, then the user is informed that his or her username and password combination was invalid.
1. Contact Salesforce.com to turn on Single Sign-On for your organization.
2. Build your SSO Web Service:
3. In Salesforce, specify your organization’s Single Sign-On Gateway URL by clicking Setup | Security Controls | Single Sign-On settings.
4. Modify your user profiles to contain the "Uses Single Sign-On" user permission. In Salesforce, click Setup | Manage Users | Profiles to add or edit profiles. It is recommended you create a new user with a new profile to test single sign on. Do not test with the administrator account.
As part of the Single Sign-On process, a Salesforce.com server makes a SOAP 1.1 request to authenticate the user who is passing in the credentials. Below is an example of this type of request. Your Single Sign-On service needs to accept this request, process it, and return a "true" or "false" response.
<?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <Authenticate xmlns="urn:authentication.soap.sforce.com"> <username>[email protected]</username> <password>myPassword99</password> <sourceIp>22.214.171.124</sourceIp> </Authenticate> </soapenv:Body> </soapenv:Envelope>
Sample Response Message
<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <AuthenticateResponse xmlns="urn:authentication.soap.sforce.com"> <Authenticated>true</Authenticated> </AuthenticateResponse> </soapenv:Body> </soapenv:Envelope>
In the previous sections of this discussion, you have learned how to enable Salesforce to support Single Sign-On capabilities. The actual implementation of Single Sign-On is transparent to users, but involves a number of steps behind the scenes.
When you configure Salesforce for Single Sign-On, you are allowing a delegated authentication authority. When a user first logs onto their network environment, they are initially authenticated by this authority. When the user attempts to log on to subsequent protected applications, instead of passing a user name and password to the application, the user requests a token from a token generator. (On Windows, this token request can use the NTLM protocol.) The received token is passed to the application, which verifies that the token properly identifies the user, and then allows the user access to the application.
Salesforce can use this method, since the password field is simply used to exchange information with the client, rather than specifying a particular data type. This flexibility means that Salesforce can accept a token, which is then used with the delegated authentication authority to verify the user. If the verification succeeds, the user is logged on to Salesforce. If the verification fails, the user receives an error. The process flow for Salesforce Single Sign-On is shown in the figure below.
Typically, this Single Sign-On process is initiated by means of a link on a corporate intranet page. The link requests the token, passes it to the Salesforce login page, and accepts the result of the login attempt from Salesforce.
You can configure the Salesforce delegated authentication authority to only allow tokens, or to accept either tokens or passwords. If the authority only accepts tokens, a Salesforce user cannot log onto Salesforce directly, since they cannot create a valid token. However, many companies choose to allow both tokens and passwords. In this environment, a user could still log onto Salesforce through the login page, or use a link to implement Single Sign-On for the user.
Consider the following best practices when implementing Single Sign-On:
Samples are available by downloading the sample code for .NET. The samples are written in C# and authenticate users against Active Directory. The first sample is a simple implementation of delegated authentication. The second is a more complex sample that demonstrates a Single Sign-On solution in conjunction with an authentication token. Both samples use Microsoft .NET v1.1 and were deployed using IIS6 on a Windows 2003 server. Use the included makefile to build the samples.
Sample 1 This is implemented in simple.asmx.cs. This file declares a new class, SimpleAdAuth, that is a Web Service with one method: Authenticate. There are a number of attributes declared on the method. These control the formatting of the expected request and the generated response, and set up the service to match the message definition in the WSDL. The implementation uses the passed credentials to try to connect to Active Directory via the LDAP provider. If it connects successfully, the credentials are good; otherwise the credentials are not valid.
Sample 2 This is a more complex example that generates and verifies an authentication token rather than a password. The bulk of the implementation is in the sso.asmx.cs file, which defines a class SingleSignOn that can generate an authentication token and implements the authentication service to later verify that token. The generated token consists of a token number, expiry timestamp, and username. All the data is then encrypted and signed. The verification process verifies the signature, decrypts the token, checks that it has not expired, and checks that the token number has not been previously used. (The token number and expiration timestamp are used to prevent replay attacks.) The file gotosfdc.aspx is an ASPX page designed to be deployed and/or linked to from an intranet site. This forces the user’s authentication, generates a new authentication token for the user, and finally POSTs that token to the Salesforce login page along with a username that is mapped from the local NT username. The Salesforce login process sends the authentication token back to the service, which verifies the token and lets the user into Salesforce. intranet.aspx is a simple page that links to gotosfdc.aspx so you can see this in action.
How do I enable Single Sign-On?
Where in Salesforce do I configure Single Sign-On?
How are passwords reset when Single Sign-On has been implemented?
Password reset is disabled for Single Sign-On users because Salesforce no longer manages their passwords. Users who try to reset their passwords in Salesforce will be directed to their Salesforce administrator.
Where can I view Single Sign-On login errors?
Administrators with the "Modify All Data" permission can view the twenty-one most recent Single Sign-On login errors for your organization by clicking Setup | Manage Users | Single Sign-On Error History. For each failed login, you can view the user's username, login time, and the error.
Does Single Sign-On work outside my corporate firewall?
Yes, Single Sign-On can work outside your corporate firewall. When users are outside the corporate firewall, they can use their network passwords to log in to Salesforce. Alternately, you can require that users must first be connected to your corporate network in order to log in, or you could build a custom login page that required multi-factor authentication if users are outside the corporate firewall.
Can I configure a start page and logout page that are specific to my company?
Yes - please refer to the sample implementations for details on ssoStartPage and logoutUrl.
Does Salesforce support SAML tokens?
SAML tokens can be used with this solution described in this document, with the delegated authentication listener validating the token. Salesforce.com also release native SAML support with the Summer 08 release.
Can Single Sign-On work with Offline Edition?
Single Sign-On can work with Offline Edition if Single Sign On is set up to work with both tokens and passwords. In the offline use case, end users should use their network password to access offline edition.