Salesforce.com: Salesforce Winter '09 Single Sign-On Implementation Guide Copyright 2000-2008 salesforce.com, inc. All rights reserved. Salesforce.com and the no software logo are registered trademarks, and AppExchange, Success On Demand, and The Business Web are trademarks of salesforce.com, inc. All other trademarks mentioned in this document are the properties of their respective owners.
Table of Contents Table of Contents About Single Sign-On...3 Enabling Delegated Authentication Single Sign-On...4 Configuring SAML Settings for Single Sign-On...6 Best Practices for Implementing Single Sign-On...11 Sample Delegated Authentication Implementations...13 Frequently Asked Questions...13 Index...15 i
Table of Contents ii
About Single Sign-On About Single Sign-On Available in: All Editions User Permissions Needed To view the settings: To edit the settings: "View Setup and Configuration" "Customize Application" AND "Modify All Data" Single sign-on is a process that allows network users to access all authorized network resources without having to log in separately to each resource. Single sign-on allows you to validate usernames and passwords against your corporate user database or other client application rather than having separate user passwords managed by Salesforce. Salesforce offers two ways to use single sign-on: Delegated authentication: you must request that this feature be enabled by salesforce.com. Contact salesforce.com to enable delegated authentication single sign-on for your organization. Federated authentication using Security Assertion Markup Language (SAML): available in all Editions. Benefits of Single Sign-On Implementing single sign-on can offer the following advantages to your organization: Reduced Administrative Costs: With single sign-on, users only need to memorize a single password to access both network resources or external applications and Salesforce. When accessing Salesforce from inside the corporate network, users are logged in seamlessly, without being prompted to enter a username or password. When accessing Salesforce from outside the corporate network, users' corporate network login works to log them in. With fewer passwords to manage, system administrators receive fewer requests to reset forgotten passwords. Leverage Existing Investment: Many companies use a central LDAP database to manage user identities. By delegating Salesforce authentication to this system, when a user is removed from the LDAP system, they can no longer access Salesforce. Consequently, users who leave the company automatically lose access to company data after their departure. Time Savings: On average, a user takes five to 20 seconds to log in to an online application; longer if they mistype their username or password and are prompted to reenter them. With single sign-on in place, the need to manually log in to Salesforce is avoided. These saved seconds add up to increased productivity. Increased User Adoption: Due to the convenience of not having to log in, users are more likely to use Salesforce on a regular basis. For example, users can send email messages that contain links to information in Salesforce such as records and reports. When the recipients of the email message click the links, the corresponding Salesforce page opens automatically. Increased Security: Any password policies that you have established for your corporate network will also be in effect for Salesforce. In addition, sending an authentication credential that is only valid for a single use can increase security for users who have access to sensitive data. 3
Enabling Delegated Authentication Single Sign-On Enabling Delegated Authentication Single Sign-On Available in: All Editions User Permissions Needed To view the settings: To edit the settings: "View Setup and Configuration" "Customize Application" AND "Modify All Data" Understanding Delegated Authentication in Salesforce Salesforce uses the following process for authenticating users via delegated authentication single sign-on: 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 Is Single Sign-On Enabled user permission, then Salesforce does not validate the username and password. Instead, a Web services call is made to the user s organization, asking it to validate the username and password. 3. The Web services call passes the username, password, and sourceip to your Web service. (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 is invalid. Configuring Salesforce for Delegated Authentication To enable delegated authentication single sign-on for your organization: 1. Contact salesforce.com to enable delegated authentication single sign-on for your organization. 2. Build your single sign-on Web service: a. In Salesforce, download the Web Services Description Language (WSDL) file, AuthenticationService.wsdl, by clicking Setup Develop API Download Delegated Authentication WSDL. The WSDL describes the delegated authentication single sign-on service and can be used to automatically generate a server-side stub to which you can add your specific implementation. For example, in the WSDL2Java tool from Apache Axis, you can use the --server-side switch. In the wsdl.exe tool from.net, you can use the /server switch. For a sample request and response, see Sample SOAP Message for Delegated Authentication on page 5. b. Add a link to your corporate intranet or other internally-accessible site that takes the authenticated user s credentials and passes them through an HTTP POST to the Salesforce login page. Because Salesforce does not use the password field other than to pass it back to you, you do not need to send a password in this field. Instead, you could pass another authentication token, such as a Kerberos Ticket so that your actual corporate passwords are not passed to or from Salesforce. You can configure the Salesforce delegated authentication authority to allow only tokens or to accept either tokens or passwords. If the authority only accepts tokens, a Salesforce user cannot log in to Salesforce directly, because they cannot 4
Enabling Delegated Authentication Single Sign-On create a valid token. However, many companies choose to allow both tokens and passwords. In this environment, a user could still log in to Salesforce through the login page. When the salesforce.com server passes these credentials back to you in the Authenticate message, verify them, and the user will gain access to the application. 3. In Salesforce, specify your organization s single sign-on gateway URL by clicking Setup Security Controls Single Sign-On Settings Edit. Enter the URL in the Delegated Gateway URL text box. For security reasons, Salesforce restricts the outbound ports you may specify to one of the following: 80: This port only accepts HTTP connections. 443: This port only accepts HTTPS connections. 7000-10000 (inclusive): These ports accept HTTP or HTTPS connections. 4. Modify your user profiles to enable the Is Single Sign-On Enabled user permission. In Salesforce, click Setup Manage Users Profiles to add or edit profiles. Important: If single sign-on is enabled for your organization, API and desktop client users cannot log in to Salesforce unless their IP address is included on your organization's list of trusted IP addresses or on their profile, if their profile has IP address restrictions set. Futhermore, the single sign-on authority usually handles login lockout policies for users with the "Is Single Sign-On Enabled " permission. However, if the security token is enabled for your organization, then your organization's login lockout settings determine the number of times a user can attempt to log in with an invalid security token before being locked out of Salesforce. For more information, see "Setting Login Restrictions" in the Salesforce online help. For information on how to view login errors, see "Viewing Single Sign-On Login Errors" in the Salesforce online help. Sample SOAP Message for Delegated Authentication As part of the delegated authentication single sign-on process, a salesforce.com server makes a SOAP 1.1 request to authenticate the user who is passing in the credentials. Here is an example of this type of request. Your single sign-on Web service needs to accept this request, process it, and return a true or false response. Sample Request <?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>sampleuser@sample.org</username> <password>mypassword99</password> <sourceip>1.2.3.4</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>false</Authenticated> </AuthenticateResponse> </soapenv:body> </soapenv:envelope> 5
Configuring SAML Settings for Single Sign-On Configuring SAML Settings for Single Sign-On Available in: All Editions User Permissions Needed To view the settings: To edit the settings: "View Setup and Configuration" "Customize Application" AND "Modify All Data" Your organization must have SAML enabled in order to view the SAML Settings on the Single Sign-On settings page. For more information, contact your salesforce.com representative. Understanding SAML in Salesforce Security Assertion Markup Language (SAML) is an XML-based standard that allows you to communicate authentication decisions between one service and another. It underlies many Web single sign-on solutions. Salesforce supports SAML for single sign-on into Salesforce from a corporate portal or identity provider. Much of the work to set up single sign-on using SAML takes place outside of Salesforce: 1. Obtain a certificate from a third party identity provider (IDP) for your client application. This is the application that will send single sign-on requests to Salesforce, the service provider. 2. Configure Salesforce using the instructions in Configuring Salesforce for SAML on page 7. This is the only step that takes place in Salesforce. 3. Send the SAML assertion from your client application to Salesforce with an HTTP POST request, to the Recipient URL specified in Setup Security Controls Single Sign-On Settings. This field is populated after your configuration is complete. Salesforce receives the assertion, verifies it against your Salesforce configuration, and allows single sign-on if the assertion is true. See Customizing SAML Start, Login, and Logout Pages on page 6 for details on customizing the start and logout pages. Customizing SAML Start, Login, and Logout Pages The landing, login, and logout pages can be customized for single sign-on users using SAML 1.1. The SAML specification defines a TARGET field that may be included in the HTTP POST that sends a SAML assertion. By passing a URL in this field, the SAML identity provider can control what page the user sees after successfully logging in with SAML. Note: This URL must be in the salesforce.com domain, either in an absolute, (https://na1.salesforce.com/005), or relative, (/005), format. In some cases, it is useful for the identity provider to pass additional information to Salesforce, such as the URLs for the appropriate login and logout pages for a particular user. Salesforce embeds this additional information in the TARGET field in a URL format. This URL accepts URL-encoded parameters and propagates the information as necessary. The URL is as follows: https://saml.salesforce.com/? Salesforce supports the following parameters on this URL: 6
Configuring SAML Settings for Single Sign-On ssostartpage is the page to which the user should be redirected when trying to log in with SAML. The user is directed to this page when requesting a protected resource in Salesforce, without an active session. The ssostartpage should be the SAML identity provider's login page. starturl is the URL where you want the user to be directed when sign-on completes successfully. This URL can be absolute, such as https://na1.salesforce.com/001/o or it can be relative, such as /001/o. logouturl is the URL where you want the user to be directed when they click the Logout link in Salesforce. The default is http://www.salesforce.com. Note: The parameter values are encoded. This allows the URLs, passed as values that include their own parameters, to be handled correctly. The following sample URL includes properly-encoded parameters. It passes customized start and logout pages embedded as parameter values in the query string. https://saml.salesforce.com/?ssostartpage=%2f001%2fo&logouturl=http%3a%2f%2fwww.salesforcecustomer.com Configuring Salesforce for SAML To configure SAML settings for single sign-on from your corporate identity provider to Salesforce: 1. Obtain a certificate from your identity provider and store it where you can access it from Salesforce. 2. In Salesforce, navigate to Setup Security Controls Single Sign-On Settings, and click Edit. 3. Customize the SAML settings: Field SAML Enabled SAML Version Issuer Identity Provider Certificate Current Certificate SAML User ID Type Description Select this checkbox to enable SAML for your organization. Deselect it to disable SAML. Specify the version of SAML your identity provider uses. Salesforce currently supports version 1.1. A limited release of version 2.0 is available. Contact salesforce.com for more information. Specify the identity provider who issued your identity provider (IDP) certificate. This value is usually the URL of the identity provider service, or the entity ID of the identity provider. SAML assertions sent to Salesforce must use this value in the Issuer attribute of SAML assertions. Use the Browse button to locate and upload a new identity provider certificate issued by your identity provider. Once successfully uploaded, the certificate is listed as the Current Certificate. Information about the current identity provider certificate, including the expiration date. Specify which element in a SAML assertion contains the string that identifies a Salesforce user: Assertion contains User's Salesforce username Select this option if the assertion identifies a Salesforce user with his or her Salesforce username. Use this option if you keep Salesforce usernames in the external system. Assertion contains the federated ID from the User object Select this option if the assertion identifies a Salesforce user with the value of the FederationIdentifier field on his or her User record. Use this option if you want to map Salesforce users with an external value instead of the Salesforce username. 7
Configuring SAML Settings for Single Sign-On Field SAML User ID Location Description Specify where in the assertion a user should be identified: User ID is in the NameIdentifier element of the Subject statement The Salesforce Username or FederationIdentifier is located in the <Subject> statement of the assertion. User ID is in an Attribute element The Salesforce Username or FederationIdentifier is specified in an <AttributeValue>, located in the <Attribute> of the assertion. Attribute Name Attribute URI Recipient URL If "User ID is in an Attribute element" is selected, enter the value of the AttributeName that is specified in <Attribute> that contains the User ID. If "User ID is in an Attribute element" is selected: SAML 1.1: Enter the value of the AttributeNamespace that is specified in <Attribute>. SAML 2.0: Do not enter any value in this field. The URL to which you post assertions. This field displays the correct value after you save your SAML configuration. If you select the Username User ID type and the <Subject> User ID location, this URL will be of the form https://login.salesforce.com or for Sandbox, https://test.salesforce.com. For all other selections, you will see similar URLs appended with additional encrypted material. 4. Click Save. 5. To request single sign-on, your client application sends a POST message containing SAML assertions to the Salesforce login page. Each assertion is verified, and if successful, single sign-on is allowed. Validity Requirements To protect the security of single sign-on users and applications, Salesforce imposes the following validity requirements on assertions: Attribute If your configuration is set to User ID is in an Attribute element, your assertion must contain an <AttributeStatement>. Audience If you include an <Audience> value, it must be https://saml.salesforce.com. Omit the <Audience> element if your application allows; it is not required. Authentication Statement You must include an <AuthenticationStatement> in the assertion. Issuer The issuer specified in an assertion must match the issuer specified in Salesforce. Recipient The recipient specified in an assertion must match the recipient specified in the Salesforce configuration. Signature A valid signature must be included in the assertion. 8
Configuring SAML Settings for Single Sign-On Login History Time limits The validity period specified in an assertion is honored. In addition, an assertion's timestamp must be less than five minutes old, plus or minus three minutes, regardless of the assertion's validity period setting. This allows for differences between machines. If the <NotBefore> or <NotOnOrAfter> constraints are defined in the assertion, these constraints are also enforced. Uniqueness Every assertion must be assigned a unique identifier. Salesforce prevents all replays by rejecting assertions with a repeated identifier. When a user logs in to Salesforce from another application using single sign-on, SAML assertions are sent to the Salesforce login page. The assertions are checked against assertions in the identity provider certificate specified in Setup Security Controls Single Sign-On Settings. If a user fails to log in, a message is written to the login history log that indicates why the login failed: Sample Assertions Issuer Mismatched The issuer specified in an assertion does not match the issuer specified in your Salesforce configuration. Recipient Mismatched The recipient specified in an assertion does not match the recipient specified in your Salesforce configuration. Signature Invalid The signature in an assertion cannot be validated by the certificate in your Salesforce configuration. Assertion Expired An assertion's timestamp is more than five minutes old. For more information about assertion time limits, see Validity Requirements on page 8. Assertion Invalid An assertion is not valid. For example, the <Subject> element of an assertion might be missing. Configuration Error/Perm Disabled Something is wrong with the SAML configuration in Salesforce. For example, the uploaded certificate might be corrupted, or the organization preference might have been turned off. Check your configuration in Setup Security Controls Single Sign-On Settings. Subject Confirmation Error The <Subject> specified in the assertion does not match the SAML configuration in Salesforce. Replay Detected The same assertion ID was used more than once. Assertion IDs must be unique within an organization. For more information, see Validity Requirements on page 8. Audience Invalid The value specified in <Audience> must be https://saml.salesforce.com Sample assertions are included below for SAML 1.1 and SAML 2.0. SAML User ID type is the Salesforce username, and SAML User ID location is the <NameIdentifier> element in the <Subject> element SAML 1.1: <Subject> <NameIdentifier>user101@salesforce.com</NameIdentifier> </Subject> 9
Configuring SAML Settings for Single Sign-On SAML 2.0: <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">user101@salesforce.com</saml:NameID> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdata NotOnOrAfter="2008-06-26T02:44:24.173Z" Recipient="http://localhost:9000"/> </saml:subjectconfirmation> </saml:subject> SAML User ID type issalesforce username, and SAML User ID location is the <Attribute> element SAML 1.1: <AttributeStatement> <Subject> <NameIdentifier>this value doesn't matter</nameidentifier> <SubjectConfirmation> <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</ConfirmationMethod> </SubjectConfirmation> </Subject> <Attribute AttributeName="MySfdcName" AttributeNamespace="MySfdcURI"> <AttributeValue>user101@salesforce.com</AttributeValue> </Attribute> </AttributeStatement> SAML 2.0: <saml:attributestatement> <saml:attribute FriendlyName="fooAttrib" Name="SFDC_USERNAME" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml:attributevalue xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:type="xs:string"> user101@salesforce.com </saml:attributevalue> </saml:attribute> </saml:attributestatement> SAML User ID type is the Salesforce User object's FederationIdentifier field, and SAML User ID location is the <NameIdentifier> element in the <Subject> element SAML 1.1: <saml:attributestatement> <saml:subject> <saml:nameidentifier Format="urn:oasis:names:tc:SAML:1.0:assertion" NameQualifier="www.saml_assertions.com"> MyName </saml:nameidentifier> SAML 2.0: <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">MyName</saml:NameID> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> 10
Best Practices for Implementing Single Sign-On <saml:subjectconfirmationdata NotOnOrAfter="2008-06-26T02:48:25.730Z" Recipient="http://localhost:9000/"/> </saml:subjectconfirmation> </saml:subject> Note: The name identifier can be any arbitrary string, including email addresses or numeric ID strings. SAML User ID type is thesalesforce User object's FederationIdentifier field, and SAML User ID location is the <Attribute> element SAML 1.1: <AttributeStatement> <Subject> <NameIdentifier>who cares</nameidentifier> <SubjectConfirmation> <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</ConfirmationMethod> </SubjectConfirmation> </Subject> <Attribute AttributeName="MyName" AttributeNamespace="MyURI"> <AttributeValue>user101</AttributeValue> </Attribute> </AttributeStatement> SAML 2.0: <saml:attributestatement> <saml:attribute FriendlyName="fooAttrib" Name="SFDC_ATTR" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml:attributevalue xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:type="xs:string"> user101 </saml:attributevalue> </saml:attribute> </saml:attributestatement> Best Practices for Implementing Single Sign-On Available in: All Editions User Permissions Needed To view the settings: To edit the settings: "View Setup and Configuration" "Customize Application" AND "Modify All Data" Salesforce offers two ways to use single sign-on: 11
Best Practices for Implementing Single Sign-On Delegated authentication: you must request that this feature be enabled by salesforce.com. Contact salesforce.com to enable delegated authentication single sign-on for your organization. Federated authentication using Security Assertion Markup Language (SAML): available in all Editions. Delegated Authentication Best Practices Consider the following best practices when implementing delegated authentication single sign-on for your organization. Your organization s implementation of the Web service must be accessible by salesforce.com servers. This means you must deploy the Web service on a server in your DMZ. Remember to use your server s external DNS name when entering the Delegated Gateway URL in the Delegated authentication section at Setup Security Controls Single Sign-On Settings in Salesforce. If salesforce.com and your system cannot connect, or the request takes longer than 10 seconds to process, the login attempt fails. An error is reported to the user indicating that his or her corporate authentication service is down. Namespaces, element names, and capitalization must be exact in SOAP requests. Wherever possible, generate your server stub from the WSDL to ensure accuracy. For security reasons, you should make your Web service available by SSL only. You must use an SSL certificate from a trusted provider, such as Verisign or Thawte. For a full list of trusted providers, contact salesforce.com. The IP address that originated the login request is sourceip. 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. For more information, see "Restricting Login IP Ranges on Profiles" in the Salesforce online help. You may need 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. We recommend that you do not enable single sign-on for the system administrator s profile. If your system administrators are single sign-on users and your single sign-on server has an outage, they 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 developer.force.com. Make sure to test your implementation with Salesforce clients such as Connect for Outlook, Connect for Office, and Connect Offline. For more information, see the developer.force.com. Federated Authentication using SAML Best Practices Consider the following best practices when implementing federated single sign-on with SAML for your organization. Obtain the Recipient URL value from the configuration page and put it in the corresponding configuration parameter of your Identity Provider. If your identity provider requires you to set the Service Provider's Audience URL, set it to https://saml.salesforce.com. Salesforce allows a maximum of five minutes for clock skew with your IDP server, make sure your server's clock is up-to-date. If you are unable to login with SAML assertion, always check the login history and note the error message. You may need 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. Before allowing users to login with SAML assertion, enable the SAML organization preference and provide all the necessary configurations. We recommend that you use a Sandbox or Developer Edition account when testing a SAML single sign-on solution. To sign up for a free Developer Edition account, go to developer.force.com. All sandbox copies are made with federated authentication with SAML disabled. Any configuration information is preserved, except the value for Recipient URL changes to http://tapp0.salesforce.com. The Recipient URL is updated 12
Sample Delegated Authentication Implementations to match your sandbox URL, for example http://cs1.salesforce.com, after you re-enable SAML. To enable SAML in the sandbox copy, click Setup Security Controls Single Sign-On Settings; then click Edit, and select SAML Enabled. Sample Delegated Authentication Implementations Samples are available by downloading the sample code for.net from the developer.force.com. 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. Frequently Asked Questions How do I enable single sign-on? Salesforce offers two ways to use single sign-on: Delegated authentication: you must request that this feature be enabled by salesforce.com. Contact salesforce.com to enable delegated authentication single sign-on for your organization. Federated authentication using Security Assertion Markup Language (SAML): available in all Editions. Where in Salesforce do I configure single sign-on? For delegated authentication single sign-on: The WSDL is available by clicking Setup Develop API Download Delegated Authentication WSDL. You can specify your organization s single sign-on gateway URL by clicking Setup Security Controls Single Sign-On Settings Edit. 13
Frequently Asked Questions Click Setup Manage Users Profiles to enable the Is Single Sign-On Enabled user permission for the profiles of your single sign-on users. For federated authentication using SAML: Click Setup Security Controls Single Sign-On Settings Edit. 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. Can I configure a start page and logout page that are specific to my company? Yes. For delegated authentication, the ssostartpage and logouturl fields can be submitted in a GET or POST request. The configuration is different for federated authentication (SAML) where you add a TARGET field in the HTTP POST request that sends a SAML assertion. The value of the TARGET field has a URL format described below: https://saml.salesforce.com/?ssostartpage=/001/o&logouturl=http://www.salesforcecustomer.com The portion of the URL before the query string (question mark) must be set to https://saml.salesforce.com/, and the customized start and logout pages are embedded as parameter values in the query string. The parameters are explained below: ssostartpage is the URL where you want the user to be directed when sign-on completes successfully. This URL can be absolute, such as https://na1.salesforce.com/001/o or it can be relative, such as /001/o. logouturl is the URL where you want the user to be directed when they click the Logout link in Salesforce. The default is http://www.salesforce.com. Refer to the sample delegated authentication implementations for details. Does Salesforce delegated authentication support SAML tokens? Yes, SAML tokens can be used with the sample delegated authentication implementations using the listener validating the token. Can delegated authentication single sign-on work with Connect Offline? Yes, delegated authentication can work with Connect Offline if it is set up to work with both tokens and passwords. In this case, users should use their network password to access Connect Offline. 14
Index Index D Delegated authentication sample implementations 13 single sign-on 4 S Single sign-on best practices 11 delegated authentication 4, 13 FAQ 13 overview 3 SAML 6 sample SOAP message 5 SAML single sign-on 6 15