0% found this document useful (0 votes)

351 views

Salesforce Security Implementation Guide

Salesforce.com

Uploaded by

satkabeer654

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

351 views

Salesforce Security Implementation Guide

Salesforce.com

Uploaded by

satkabeer654

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 41

Version 25.

0: Summer '12

Single Sign-On Implementation Guide

Last updated: June 2 2012

names and marks. Other marks appearing herein may be trademarks of their respective owners.

Table of Contents

Table of Contents
About Single Sign-On..........................................................................................................................2
About SAML............................................................................................................................................................................3
Working With Your Identity Provider......................................................................................................................................4
Customizing SAML Start, Error, Login, and Logout Pages........................................................................................5
Example SAML Assertions...........................................................................................................................................6
Identity Provider Values..............................................................................................................................................14

Configuring SAML Settings for Single Sign-On.................................................................................17

Viewing Single Sign-On Settings........................................................................................................19
Validating SAML Settings for Single Sign-On....................................................................................20
SAML Assertion Validation Errors........................................................................................................................................20

Reviewing the SAML Login History...................................................................................................23

About Just-in-Time Provisioning for SAML.......................................................................................25
Just-in-Time Provisioning Requirements................................................................................................................................25
Just-in-Time Provisioning Errors............................................................................................................................................27

Best Practices for Implementing Single Sign-On.................................................................................29

Enabling Single Sign-On for Portals...................................................................................................32
Understanding Delegated Authentication Single Sign-On...................................................................33
Configuring Salesforce for Delegated Authentication.............................................................................................................34

Sample Delegated Authentication Implementations............................................................................36

Frequently Asked Questions...............................................................................................................37
Index.................................................................................................................................................39

About Single Sign-On

Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

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 the following ways to use single sign-on:

Federated authentication using Security Assertion Markup Language (SAML): When federated authentication is
enabled, Salesforce does not validate a users password. Instead, Salesforce verifies an assertion in the HTTP POST request,
and allows single sign-on if the assertion is true. This is the default form of single sign-on. Federated authentication is
available in all Editions.
Delegated authentication: When delegated authentication is enabled, Salesforce does not validate a users password.
Instead, Salesforce makes a Web services call to your organization to establish authentication credentials for the user. You
must request that this feature be enabled by salesforce.com. Contact salesforce.com to enable delegated authentication
single sign-on for your organization.

When you have an external identity provider, and configure single sign-on for your Salesforce organization, Salesforce is then
acting as a service provider. You can also enable Salesforce as an identity provider, and use single sign-on to connect to a different
service provider. Only the service provider needs to configure single sign-on.
The Single Sign-On Settings page displays which version of single sign-on is available for your organization. To learn more
about the single sign-on settings, see Configuring SAML Settings for Single Sign-On on page 17. For more information
about SAML and Salesforce security, see the Security Implementation Guide.

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, the 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.

About Single Sign-On

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.com such as
records and reports. When the recipients of the email message click the links, the corresponding Salesforce.com 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.

About SAML
Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

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 occurs with your identity provider:
1. Establish a SAML identity provider and gather information about how they will connect to Salesforce. This is the provider
that will send single sign-on requests to Salesforce.
2. Provide information to your identity provider, such as the URLs for the start and logout pages.
3. Configure Salesforce using the instructions in Configuring SAML Settings for Single Sign-On. This is the only step that
takes place in Salesforce.
Your identity provider should send SAML assertions to Salesforce using the SAML Web Single Sign-on Browser POST
profile. Salesforce sends SAML responses to the Identity Provider Login URL specified in Your Name > Setup >
Security Controls > Single Sign-On Settings. Salesforce receives the assertion, verifies it against your Salesforce configuration,
and allows single sign-on if the assertion is true.
If you have problems with the SAML assertion after you configure Salesforce for SAML, use the SAML Assertion Validator
to validate the SAML assertion. You may need to obtain a SAML assertion from your identity provider.
If your users are having problems using SAML to login, you can review the SAML login history to determine why they were
not able to log in and share that information with your identity provider.

About Single Sign-On

If your identity provider supports metadata, and if you've configured SAML using version 2.0, you can click Download
Metadata to download an XML configuration file to send them, which they can then upload to automatically configure their
settings for connecting to your Salesforce organization.

Working With Your Identity Provider

Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

1. You must gather the following information from your identity provider before configuring Salesforce for SAML.

The version of SAML the identity provider uses (1.1 or 2.0)

The entity ID of the identity provider (also known as the issuer)
An authentication certificate.
Tip: Be sure to store the certificate where you can access it from your browser. This will be uploaded to
Salesforce in a later step.

The following SAML assertion parameters, as appropriate:

The SAML user ID type

The SAML user ID location
Attribute Name
Attribute URI
Name ID format
Note: Attribute Name, Attribute URI, and Name ID format are only necessary if the SAML User ID
Location is in an Attribute element, and not the name identifier element of a Subject statement.

You may also want to share more information about these values with your identity provider.
Tip: Enable Salesforce for SAML and take a screenshot of the page for your identity provider. Click Your Name
> Setup > Security Controls > Single Sign-On Settings, click Edit, then select SAML Enabled.
2. Work with your identity provider to setup the start, login, and logout pages.

About Single Sign-On

3. Share the example SAML assertions with your identity provider so they can determine the format Salesforce requires for
successful single sign-on.

Customizing SAML Start, Error, Login, and Logout Pages

Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

The start, error, login, and logout pages can be customized for single sign-on users using SAML 1.1 or 2.0. As part of your
configuration, you need to decide the following:

The logout page: the URL to direct the user to when they click the Logout link in Salesforce. The default is
http://www.salesforce.com.
If your identity provider uses SAML 1.1, the start page: the URL to direct the user to when sign-on successfully completes.
This URL can be absolute, such as https://na1.salesforce.com/001/o or it can be relative, such as /001/o. This
URL should be an endpoint that accepts SAML authentication requests.
In SAML 2.0, the start page is the page the user attempted to access before they were authenticated. The SAML 2.0 start
page must support Sp-init single sign-on.
If you are using SAML 2.0, you can also use the RelayState parameter to control where users get redirected after a
successful login.

The single sign-on start page where Salesforce sends a SAML request to start the login sequence.
We recommend that if you specify a single sign-on start page that you also specify a logout page. When you specify a
logout page, when a user clicks logout or if a users session expires, the user is redirected to that page. If you dont specify
a logout page, the user is redirected to the general Salesforce login page.

For SAML 2.0, these values can be set either during the single sign-on configuration, or by your identity provider in the login
URL or SAML assertion. The order of precedence is:
1. Session cookieif youve already logged into Salesforce and a cookie still exists, the login and logout pages specified by
the session cookie are used.
2. Values passed in from the identity provider.
3. Values from the single sign-on configuration page.
If you decide not to add these values to the single sign-on configuration, share them with your identity provider. They will
need to use these values either in the login URL or the assertion.

About Single Sign-On

You can also decide if you want users to be directed to a custom error page if theres an error during SAML login: It must be
a publicly accessible page, such as a public site Visualforce page. The URL can be absolute or relative. Use this value when
you configure SAML.

Example SAML Assertions

Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

Share the example SAML assertions with your identity provider so they can determine the format of the information Salesforce
requires for successful single-sign on.
In addition to the general single sign-on examples for both SAML 1.1 and SAML 2.0, use the following samples for the
specific feature:

assertions for portals

assertions for Sites
SOAP message for delegated authentication
assertion for just-in-time provisioning

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>

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>

About Single Sign-On

SAML User ID type is the Salesforce 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:
<AttributeStatement>
<saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0:assertion"
NameQualifier="www.saml_assertions.com">
MyName
</saml:NameIdentifier>
</saml:Subject>
</AttributeStatement>

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">
<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.

About Single Sign-On

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>

SAML User ID type is the Salesforce username, and SAML User ID location is the <NameIdentifier> element
in the <Subject> element
The following is a complete SAML response, for SAML 2.0:
<samlp:Response ID="_257f9d9e9fa14962c0803903a6ccad931245264310738"
IssueInstant="2009-06-17T18:45:10.738Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://www.salesforce.com</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion ID="_3c39bc0fe7b13769cab2f6f45eba801b1245264310738"
IssueInstant="2009-06-17T18:45:10.738Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://www.salesforce.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
saml01@salesforce.com</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2009-06-17T18:50:10.738Z"
Recipient="https://login.www.salesforce.com"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2009-06-17T18:45:10.738Z"
NotOnOrAfter="2009-06-17T18:50:10.738Z">

About Single Sign-On

<saml:AudienceRestriction>
<saml:Audience>https://saml.salesforce.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2009-06-17T18:45:10.738Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="portal_id">
<saml:AttributeValue xsi:type="xs:anyType">060D00000000SHZ
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="organization_id">
<saml:AttributeValue xsi:type="xs:anyType">00DD0000000F7L5
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="ssostartpage"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">
http://www.salesforce.com/security/saml/saml20-gen.jsp
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="logouturl"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">
http://www.salesforce.com/security/del_auth/SsoLogoutPage.html
</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>

Sample SAML Assertions for Portals

The following shows the portal_id and organization_id attributes in a SAML assertion statement:
<saml:AttributeStatement>
<saml:Attribute Name="portal_id">
<saml:AttributeValue xsi:type="xs:anyType">060D00000000SHZ</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="organization_id">
<saml:AttributeValue xsi:type="xs:anyType">00DD0000000F7P5</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>

About Single Sign-On

The following is a complete SAML assertion statement that can be used for single sign-on for portals. The organization is
using federated sign-on, which is included in an attribute, not in the subject.
<samlp:Response ID="_f97faa927f54ab2c1fef230eee27cba21245264205456"
IssueInstant="2009-06-17T18:43:25.456Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://www.salesforce.com</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion ID="_f690da2480a8df7fcc1cbee5dc67dbbb1245264205456"
IssueInstant="2009-06-17T18:43:25.456Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://www.salesforce.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">null
</saml:NameID>

<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2009-06-17T18:48:25.456Z"
Recipient="https://www.salesforce.com/?saml=02HKiPoin4f49GRMsOdFmhTgi
_0nR7BBAflopdnD3gtixujECWpxr9klAw"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2009-06-17T18:43:25.456Z"
NotOnOrAfter="2009-06-17T18:48:25.456Z">
<saml:AudienceRestriction>
<saml:Audience>https://saml.salesforce.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2009-06-17T18:43:25.456Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute FriendlyName="Friendly Name" Name="federationId"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:string">saml_portal_user_federation_id
</saml:AttributeValue>
<saml:AttributeValue xsi:type="xs:string">SomeOtherValue
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="portal_id">
<saml:AttributeValue xsi:type="xs:anyType">060D00000000SHZ
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="organization_id">
<saml:AttributeValue xsi:type="xs:anyType">00DD0000000F7Z5
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="ssostartpage"

About Single Sign-On

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">
http://www.salesforce.com/qa/security/saml/saml20-gen.jsp
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="logouturl"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">
http://www.salesforce.com/qa/security/del_auth/SsoLogoutPage.html
</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>

Sample SAML Assertion for Sites

The following shows the portal_id, organization_id, and siteurl attributes in a SAML assertion statement:
<saml:AttributeStatement>
<saml:Attribute Name="portal_id">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:anyType">060900000004cDk
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="organization_id">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:anyType">00D900000008bX0
</saml:AttributeValue></saml:Attribute>
<saml:Attribute Name="siteurl">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:anyType">https://ap1.force.com/mySuffix</saml:AttributeValue>
</saml:Attribute>

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>

About Single Sign-On

Sample Response Message

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<AuthenticateResult
xmlns="urn:authentication.soap.sforce.com">
<Authenticated>false</Authenticated>
</AuthenticateResult>
</soapenv:Body>
</soapenv:Envelope>

Sample SAML Assertion for Just-In-Time Provisioning

The following is a sample SAML assertion for just in time provisioning.
<saml:Attribute Name="User.Username"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">testuser@123.org
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.Phone"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">415-123-1234
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.FirstName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">Testuser
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.LanguageLocaleKey"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">en_US
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.CompanyName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">Salesforce.com
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.Alias"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">tlee2
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.CommunityNickname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">tlee2
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.UserRoleId"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">000000000000000
</saml:AttributeValue>
</saml:Attribute>

About Single Sign-On

<saml:Attribute Name="User.Title"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">Mr.
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.LocaleSidKey"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">en_CA
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.Email"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">testuser@salesforce.com
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name=" User.FederationIdentifier"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">tlee2
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.TimeZoneSidKey"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">America/Los_Angeles
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.LastName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">Lee
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.ProfileId"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">00ex0000001pBNL
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.IsActive"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">1
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="User.EmailEncodingKey"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">UTF-8
</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>

About Single Sign-On

Identity Provider Values

Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

Before you can configure Salesforce for SAML, you must receive information from your identity provider. This information
must be used on the single sign-on page.
The following information might be useful for your identity provider.
Field

Description

SAML Version

The version of SAML your identity provider uses. Salesforce currently supports version 1.1
and 2.0. The SAML specifications for the various versions are linked below:
SAML 1.1
SAML 2.0

Issuer

The Entity IDa URL that uniquely identifies your SAML identity provider. SAML
assertions sent to Salesforce must match this value exactly in the <saml:Issuer> attribute
of SAML assertions.

Entity ID

The issuer in SAML requests generated by Salesforce, and is also the expected audience of
any inbound SAML Responses. If you dont have domains deployed, this value is always
https://saml.salesforce.com. If you have domains deployed, Salesforce recommends
that you use your custom domain name. You can find the value on the Single Sign-On Settings
page. Click Your Name > Setup > Security Controls > Single Sign-On Settings.

Identity Provider
Certificate

The authentication certificate issued by your identity provider.

Identity Provider
Login URL

For SAML 2.0 only: The URL where Salesforce sends a SAML request to start the login
sequence.
If you have domains deployed and a value specified for this field, login requests are usually
sent to the address specified by this field. However, if you need to bypass this value (for
example, your identity provider is down) add the login parameter to the query string for the
login page. For example: http://mydomain.my.salesforce.com?login

Identity Provider
Logout URL

For SAML 2.0 only: The URL to direct the user to when they click the Logout link in
Salesforce. The default is http://www.salesforce.com.

About Single Sign-On

Field

Description

Salesforce Login URL

The URL associated with login for the Web single sign-on flow. See SAML Assertion Flow
in the online help.

OAuth 2.0 Token

Endpoint

For SAML 2.0 only: The ACS URL used with enabling Salesforce as an identity provider
in the Web single sign-on OAuth assertion flow. See SAML Assertion Flow in the online
help.

Custom Error URL

The URL of the page users should be directed to if there's an error during SAML login. It
must be a publicly accessible page, such as a public site Visualforce page. The URL can be
absolute or relative.

SAML User ID Type

The element in a SAML assertion that contains the string that identifies a Salesforce user.
Values are:
Assertion contains Users Salesforce username

Use this option if your identity provider passes the Salesforce username in SAML
assertions.
Assertion contains the Federation ID from the User object

Use this option if your identity provider passes an external user identifier, for example
an employee ID, in the SAML assertion to identify the user.
SAML User ID Location The location in the assertion where a user should be identified. Values are:
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

If User ID is in an Attribute element is selected, this contains the value of the

AttributeName that is specified in <Attribute> that contains the User ID.

Attribute URI

If SAML 1.1 is the specified SAML version and User ID is in an Attribute

element is selected, this contains the value of the AttributeNamespace that is specified
in <Attribute>.

Name ID Format

If SAML 2.0 is the specified SAML version and User ID is in an Attribute

element is selected, this contains the value for the nameid-format. Possible values include
unspecified, emailAddress or persistent. All legal values can be found in the Name
Identifier Format Identifiers section of the Assertions and Protocols SAML 2.0 specification.

Start, Login and Logout URL Values

In addition to the information used during the single sign-on, your identity provider can also set the start, login, and logout
pages. You can also specify these pages yourself when you configure single sign-on.
The following information might be useful to your identity provider if they are setting these pages.

The SAML specification supports an HTML form that is used to pass the SAML assertion via HTTPS POST.

About Single Sign-On

For SAML 1.1, the SAML identity provider can embed name-value pairs in the TARGET field to pass this additional
information to Salesforce prepended with a specially formatted URL that contains URL-encoded parameters.
The URL for SAML 1.1 to include in the TARGET field is as follows: https://saml.salesforce.com/?
For SAML 2.0, instead of using the TARGET field, the identity providers uses the <AttributeStatement> in the SAML
assertion to specify the additional information.
Salesforce supports the following parameters:
Note: For SAML 1.1 these parameters must be URL-encoded. This allows the URLs, passed as values that include
their own parameters, to be handled correctly. For SAML 2.0, these parameters are part of the
<AttributeStatement>.
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. This parameter is
only used in SAML 1.1. In SAML 2.0, the start URL is the page the user attempted to access before they were
authenticated.
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.

The following sample TARGET field is for SAML 1.1, and includes properly-encoded parameters. It passes a customized start
page, as well as start and logout URLs embedded as parameter values in the query string.
https://saml.salesforce.com/?ssoStartPage=https%3A%2F
%2Fwww.customer.org%2Flogin%2F&startURL=%2F001%2Fo&logoutURL=http%3A%2F%2Fwww.salesforce.com

The following is an example of an <AttributeStatement> for SAML 2.0 that contains both ssoStartPage and
logoutURL:
<saml:AttributeStatement>
<saml:Attribute Name="ssoStartPage"
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:anyType">
http://www.customer.org
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="logoutURL"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
https://www.salesforce.com
</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>

Configuring SAML Settings for Single Sign-On

Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

From this page, you can configure your organization to use single sign-on. You can also set up just-in-time provisioning. Work
with your identity provider to properly configure these settings. For more information about single sign-on, see About Single
Sign-On. For more information about just-in-time provisioning, see About Just-In-Time Provisioning.

Configuring Single Sign-on

To configure SAML settings for single sign-on from your corporate identity provider to Salesforce:
1.
2.
3.
4.
5.
6.
7.

Gather information from your identity provider.

Provide information to your identity provider.
In Salesforce, navigate to Your Name > Setup > Security Controls > Single Sign-On Settings, and click Edit.
Select SAML Enabled. You must enable SAML to view the SAML single sign-on settings.
Specify the SAML version used by your identity provider.
Enter the Issuer. This is often referred to as the entity ID for the identity provider.
For the Identity Provider Certificate, use the Browse button to locate and upload the authentication certificate
issued by your identity provider.
8. For SAML 2.0, if your identity provider has specific login or logout pages, specify them in Identity Provider Login URL
and Identity Provider Logout URL, respectively.
9. For the Custom Error URL, specify the URL of the page users should be directed to if there's an error during SAML
login. It must be a publicly accessible page, such as a public site Visualforce page. The URL can be absolute or relative.
10. If you are enabling just-in-time provisioning for security, check User Provisioning Enabled.
Note:

Just-in-time provisioning requires a Federation ID in the user type. In SAML User ID Type, select Assertion
contains the Federation ID from the User object.
If your identity provider previously used the Salesforce username, communicate to them that they must use the
Federation ID.

11. For the SAML User ID Type, SAML User ID Location, and other values as appropriate, specify the value provided
by your identity provider.
12. If your Salesforce organization has domains deployed, specify whether you want to use the base domain
(https://saml.salesforce.com) or the custom domain for the Entity ID. You must share this information with
your identity provider.

Configuring SAML Settings for Single Sign-On

Tip: Generally, use the custom domain as the entity ID. If you already have single sign-on configured before
deploying a domain, the base domain is the entity ID. If you are providing Salesforce to Salesforce services, you
must specify the custom domain.
13. Click Save.
If your identity provider supports metadata, and if you've configured SAML using version 2.0, you can click Download
Metadata to download an XML configuration file to send them, which they can then upload to automatically configure their
settings for connecting to your Salesforce organization.
After you have configured and saved your SAML settings, test them by trying to access the identity provider's application.
Your identity provider directs the user's browser to POST a form containing SAML assertions to the Salesforce login page.
Each assertion is verified, and if successful, single sign-on is allowed.
If you have difficulty signing on using single sign-on after you have configured and saved your SAML settings, use the SAML
Assertion Validator. You may have to obtain a SAML assertion from your identity provider first.
If your users are having problems using SAML to login, you can review the SAML login history to determine why they were
not able to log in and share that information with your identity provider.
If you are using SAML version 2.0, after you've finished configuring SAML, the OAuth 2.0 Token Endpoint field is populated.
Use this with the Web single sign-on authentication flow in the online help for OAuth 2.0.

Viewing Single Sign-On Settings

Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

After you have configured your Salesforce organization to use SAML, you can view the single sign-on settings. Click Your
Name > Setup > Security Controls > Single Sign-on Settings.
This page lists the details of your SAML configuration. Most of these fields are the same as the fields on the page where you
configured SAML. The following fields contain information automatically generated by completing the configuration. The
available fields depend on your configuration.
Field

Description

Salesforce Login URL

For SAML 2.0 only. If you select Assertion contains User's salesforce.com username for
SAML User ID Type and User ID is in the NameIdentifier element of the Subject
statement for SAML User ID Location, this URL is the URL associated with login for
the Web single sign-on OAuth assertion flow. See SAML Assertion Flow in the online
help

Salesforce Logout URL For SAML 2.0. Displays the Salesforce logout URL that the user is directed to after he or
she logs off. This URL is only used if no value is specified for Identity Provider Logout
URL.
OAuth 2.0 Token
Endpoint

For SAML 2.0 only: The ACS URL used with enabling Salesforce as an identity provider
in the Web single sign-on OAuth assertion flow. See SAML Assertion Flow in the online
help.

From this page you can do any of the following:

Click Edit to change the existing SAML configuration.

Click SAML Assertion Validator to validate the SAML settings for your organization using a SAML assertion provided
by your identity provider.
If your identity provider supports metadata, and if you've configured SAML using version 2.0, you can click Download
Metadata to download an XML configuration file to send them, which they can then upload to automatically configure
their settings for connecting to your Salesforce organization.

Validating SAML Settings for Single Sign-On

Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

If your users have difficulty logging into Salesforce after you configure Salesforce for single sign-on, use the SAML Assertion
Validator and the login history to validate the SAML assertions sent by your identity provider.
1. Obtain a SAML assertion from your identity provider. The assertion can be either in plain XML format or a base64
encoded.
If a user tries to log in to Salesforce and fails, the invalid SAML assertion is used to automatically populate the SAML
Assertion Validator if possible.
2. Click Your Name > Setup > Security Controls > Single Sign-On Settings, then click SAML Assertion Validator.
3. Enter the SAML assertion into the text box, and click Validate.
4. Share the results of the validation errors with your identity provider.

SAML Assertion Validation Errors

Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

Salesforce imposes the following validity requirements on assertions:

Validating SAML Settings for Single Sign-On

Authentication Statement
The identity provider must include an <AuthenticationStatement> in the assertion.
Conditions Statement
If the assertion contains a <Conditions> statement, it must contain a valid timestamp.
Timestamps
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. The NotBefore and NotOnOrAfter constraints must also be defined and valid.
Attribute
If your Salesforce configuration is set to User ID is in an Attribute element, the assertion from the identity
provider must contain an <AttributeStatement>.
If you are using SAML 1.1, both <AttributeName> and <AttributeNamespace> are required as part of the
<AttributeStatement>.
If you are using SAML 2.0, only <AttributeName> is required.
Format
The Format attribute of an <Issuer> statement must be set to
"urn:oasis:names:tc:SAML:2.0:nameid-format:entity" or not set at all.

For example:
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://www.salesforce.com</saml:Issuer>

The following example is also valid:

<saml:Issuer >https://www.salesforce.com</saml:Issuer>

Issuer
The issuer specified in an assertion must match the issuer specified in Salesforce.
Subject
The subject of the assertion must be resolved to be either the Salesforce username or the Federation ID of the user.
Audience
The <Audience> value is required and must match the Entity ID from the single sign-on configuration. The default
value is https://saml.salesforce.com.
Recipient
The recipient specified in an assertion must match either the Salesforce login URL specified in the Salesforce configuration
or the OAuth 2.0 token endpoint. This is a required portion of the assertion and is always verified.
Signature
A valid signature must be included in the assertion. The signature must be created using the private key associated with
the certificate that was provided in the SAML configuration.

Validating SAML Settings for Single Sign-On

Recipient
Verifies that the recipient and organization ID received in the assertion matches the expected recipient and organization
ID, as specified in the single sign-on configuration. This is an optional portion of the assertion and is only verified if its
present. For example:
Recipient that we found in the assertion: http://aalbert-salesforce.com:8081/
?saml=02HKiPoin4zeKLPYxfj3twkPsNSJF3fxsH0Jnq4vVeQr3xNkIWmZC_IVk3
Recipient that we expected based on the Single Sign-On Settings page:
http://asmith.salesforce.com:8081/
?saml=EK03Almz90Cik_ig0L97.0BRme6mT4o6nzi0t_JROL6HLbdR1WVP5aQO5w
Organization Id that we expected: 00Dx0000000BQlI
Organization Id that we found based on your assertion: 00D000000000062

Site URL Attribute

Verifies if a valid Sites URL is provided. Values are:

Not Provided
Checked
Site URL is invalid
HTTPS is required for Site URL
The specified Site is inactive or has exceeded its page limit

Reviewing the SAML Login History

Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

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 authentication certificate specified in Your Name > 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. In addition, the SAML Assertion Validator may be automatically populated with the invalid assertion.
To view the login history, click Your Name > Setup > Users > Login History. After viewing the login history, you may want
to share the information with your identity provider.
The following are the possible failures:
Assertion Expired
An assertion's timestamp is more than five minutes old.
Note: Salesforce does make an allowance of three minutes for clock skew. This means, in practice, that an
assertion can be as much as eight minutes passed the timestamp time, or three minutes before it. This amount
of time may be less if the assertion's validity period is less than five minutes.
Assertion Invalid
An assertion is not valid. For example, the <Subject> element of an assertion might be missing.
Audience Invalid
The value specified in <Audience> must be https://saml.salesforce.com.
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 Your Name > Setup > Security
Controls > Single Sign-On Settings, get a sample SAML assertion from your identity provider, and click SAML
Assertion Validator.
Issuer Mismatched
The issuer or entity ID specified in an assertion does not match the issuer specified in your Salesforce configuration.

Reviewing the SAML Login History

Recipient Mismatched
The recipient specified in an assertion does not match the recipient specified in your Salesforce configuration.
Replay Detected
The same assertion ID was used more than once. Assertion IDs must be unique within an organization.
Signature Invalid
The signature in an assertion cannot be validated by the certificate in your Salesforce configuration.
Subject Confirmation Error
The <Subject> specified in the assertion does not match the SAML configuration in Salesforce.

About Just-in-Time Provisioning for SAML

Available in: All Editions

With Just-in-Time provisioning, you can use a SAML assertion to create regular and portal users on the fly the first time they
try to log in. This eliminates the need to create user accounts in advance. For example, if you recently added an employee to
your organization, you don't need to manually create the user in Salesforce. When they log in with single sign-on, their account
is automatically created for them, eliminating the time and effort with on-boarding the account. Just-in-Time provisioning
works with your SAML identity provider to pass the correct user information to Salesforce in a SAML 2.0 assertion. You can
both create and modify accounts this way. Because Just-in-Time provisioning uses SAML to communicate, your organization
must have SAML-based single sign-on enabled.

Benefits of Just-in-Time Provisioning

Implementing Just-in-Time provisioning can offer the following advantages to your organization.

Reduced Administrative Costs: Provisioning over SAML allows customers to create accounts on-demand, as part of the
single sign-on process. This greatly simplifies the integration work required in scenarios where users need to be dynamically
provisioned, by combining the provisioning and single sign-on processes into a single message.
Increased User Adoption: Users only need to memorize a single password to access both their main site and Salesforce.
Users are more likely to use your Salesforce application on a regular basis.
Increased Security: Any password policies that you have established for your corporate network are also 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.

Just-in-Time Provisioning Requirements

Just-in-Time provisioning requires the creation of a SAML assertion. Consider the following when creating your SAML
assertion.

Provision Version is supported as an optional attribute. If it isn't specified, the default is 1.0. For example:
<saml:Attribute Name="ProvisionVersion" NameFormat=
"urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">1.0</saml:AttributeValue>
</saml:Attribute>

ProfileIDs change per organization, even for standard profiles. To make it easier to find the profile name, Salesforce allows
you to do a profile name lookup by passing the ProfileName into the ProfileId field.

Field Requirements for the SAML Assertion

To correctly identify which object to create in Salesforce, you must use the User. prefix for all fields passed in the SAML
assertion. In this example, the User. prefix has been added to the Username field name.
<saml:Attribute
Name="User.Username"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

About Just-in-Time Provisioning for SAML

<saml:AttributeValue xsi:type="xs:anyType">testuser@123.org</saml:AttributeValue>
</saml:Attribute>

The following standard fields are supported.

Fields

Required

Comments

AboutMe

If not present, a default is derived from FirstName and LastName.

Alias
CallCenter
City

If not present, a default is derived from the UserName.

CommunityNickname
CompanyName
Country

Derived from organization settings.

DefaultCurrencyIsoCode
DelegatedApproverId
Department
Division
Email

Y
If not present, a default is derived from the organization settings.

EmailEncodingKey
EmployeeNumber
Extension
Fax
FederationIdentifier (insert

If present, it must match the SAML subject, or the SAML subject is

taken instead. Can't be updated with SAML.

only)
FirstName
ForecastEnabled
IsActive
LastName

LanguageLocaleKey

If not present, a default is derived from the organization settings.

LocaleSidKey
Manager
MobilePhone
Phone
ProfileId

ReceivesAdminInfoEmails
ReceivesInfoEmails

About Just-in-Time Provisioning for SAML

Fields

Required

Comments

State
Street

If not present, a default is derived from the organization settings.

TimeZoneSidKey
Title
Username (insert only)

UserRoleId

Can't update using SAML.

Defaults to no role if blank.

Zip

Other field requirements:

Only text type custom fields are supported.
Only the insert and update functions are supported for custom fields.
When using the API for user creation, you can pass the new username into the User.Username field. You can also specify
the User.FederationIdentifier if it is present. However, the Username and FederationIdentifier fields
can't be updated with API.

Just-in-Time Provisioning Errors

This table shows the error codes for Just-in-Time provisioning for SAML. Errors are returned in the URL parameter, for
example:
http://login.salesforce.com/identity/jit/saml-error.jsp?
ErrorCode=5&ErrorDescription=Unable+to+create+user&ErrorDetails=
INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST+TimeZoneSidKey

Note:
Salesforce redirects the user to a custom error URL if one is specified in your SAML configuration. For more information
on setting a custom error URL, see Configuring SAML Settings for Single Sign-On. on page 17

Error Messages
Code

Description

Error Details

Missing Federation Identifier

MISSING_FEDERATION_ID

Mis-matched Federation Identifier

MISMATCH_FEDERATION_ID

Invalid organization ID

INVALID_ORG_ID

Unable to acquire lock

USER_CREATION_FAILED_ON_UROG

Unable to create user

USER_CREATION_API_ERROR

Unable to establish admin context

ADMIN_CONTEXT_NOT_ESTABLISHED

Unrecognized custom field

UNRECOGNIZED_CUSTOM_FIELD

About Just-in-Time Provisioning for SAML

Code

Description

Error Details

Unrecognized standard field

UNRECOGNIZED_STANDARD_FIELD

License limit exceeded

LICENSE_LIMIT_EXCEEDED

Federation ID and username do not match MISMATCH_FEDERATION_ID_AND_USERNAME_ATTRS

Unsupported provision API version

UNSUPPORTED_VERSION

Username change isn't allowed

USER_NAME_CHANGE_NOT_ALLOWED

Custom field type isn't supported

UNSUPPORTED_CUSTOM_FIELD_TYPE

Unable to map an unique profile ID for the PROFILE_NAME_LOOKUP_ERROR

given profile name

Unable to map an unique role ID for the

given role name

ROLE_NAME_LOOKUP_ERROR

Invalid account

INVALID_ACCOUNT_ID

Missing account name

MISSING_ACCOUNT_NAME

Missing account number

MISSING_ACCOUNT_NUMBER

Unable to create account

ACCOUNT_CREATION_API_ERROR

Invalid contact

INVALID_CONTACT

Missing contact email

MISSING_CONTACT_EMAIL

Missing contact last name

MISSING_CONTACT_LAST_NAME

Unable to create contact

CONTACT_CREATION_API_ERROR

Multiple matching contacts found

MULTIPLE_CONTACTS_FOUND

Multiple matching accounts found

MULTIPLE_ACCOUNTS_FOUND

Invalid account owner

INVALID_ACCOUNT_OWNER

Invalid portal profile

INVALID_PORTAL_PROFILE

Account change is not allowed

ACCOUNT_CHANGE_NOT_ALLOWED

Unable to update account

ACCOUNT_UPDATE_FAILED

Unable to update contact

CONTACT_UPDATE_FAILED

Invalid standard account field value

INVALID_STANDARD_ACCOUNT_FIELD_VALUE

Contact change not allowed

CONTACT_CHANGE_NOT_ALLOWED

Invalid portal role

INVALID_PORTAL_ROLE

Best Practices for Implementing Single Sign-On

Federated Authentication is available in: All Editions
Delegated Authentication is available in: Professional, Enterprise, Unlimited, Developer and Database.com Editions
Customer Portals and partner portals are not available in Database.com

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

Salesforce offers the following ways to use single sign-on:

In addition, you can also configure SAML for use with portals as well as for Sites.

Delegated Authentication Best Practices

Consider the following best practices when implementing delegated authentication single sign-on for your organization.

Your organizations 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 servers external DNS name when entering the
Delegated Gateway URL in the Delegated authentication section at Your Name > 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 users
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 Setting Login Restrictions in the online help.
You may need to map your organizations 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

Best Practices for Implementing Single Sign-On

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 system administrators. 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 or a sandbox 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.com clients such as Salesforce for Outlook, Connect for Office,
and Connect Offline. For more information, see Single Sign-On for Salesforce clients.

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.
Your identity provider must allow you to set the Service Providers Audience URL, and it must be set to
https://saml.salesforce.com.
Salesforce allows a maximum of three minutes for clock skew with your IDP server; make sure your servers clock is
up-to-date.
If you are unable to log in with SAML assertion, always check the login history and note the error message.
You need to map your organizations internal usernames and Salesforce usernames. You have two choices to do this: add
a unique identifier to the FederationIdentifier field of each Salesforce user, or extend your user database schema
(for example, Active Directory) to include the Salesforce username as an attribute of a user account. Choose the corresponding
option for the SAML User ID Type field and configure your authentication service to send the identifier in SAML
assertions.
Before allowing users to log in with SAML assertions, enable the SAML organization preference and provide all the
necessary configurations.
We recommend that you use Developer Edition account or a sandbox 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
to match your sandbox URL, for example http://cs1.salesforce.com, after you re-enable SAML. To enable SAML
in the sandbox copy, click Your Name > Setup > Security Controls > Single Sign-On Settings; then click Edit, and
select SAML Enabled.
Your identity provider must allow you to set the service providers audience URL. The value must match the Entity ID
value in the single sign-on configuration. The default value is https://saml.salesforce.com.

Single Sign-On for Portals Best Practices

Only SAML version 2.0 can be used with portals.

Only Customer Portals and partner portals are supported.
Service provider initiated login is not supported.
Both the portal_id and organization_id attributes are required for single sign-on for portals. If only one is specified,
the user receives an error.
If both the portal_id and organization_id attributes are populated in the SAML assertion, the user is directed to
that portal login. If neither is populated, the user is directed to the regular SAML Salesforce login.
More than one portal can be used with a single organization.

Single Sign-On for Sites Best Practices

Only SAML version 2.0 can be used with Sites.

Best Practices for Implementing Single Sign-On

Only Customer Portals and partner portals are supported.

Service provider initiated login is not supported.
The portal_id, organization_id and siteUrl attributes are required for single sign-on for Sites. If only one is
specified, the user receives an error.
If all three of the portal_id, organization_id and siteUrl attributes are populated in the SAML assertion, the
user is directed to that Sites login. If the siteUrl isnt populated and the other two are, the user is directed to that portal
login.
More than one portal can be used with a single organization.

Enabling Single Sign-On for Portals

Customer Portal is available in: Enterprise, Unlimited, and Developer Editions
Partner Portal is available in: Enterprise and Unlimited Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

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.
You can set up Customer Portals and partner portals to use SAML single sign-on, so that a customer only has to login once.
Note: Single sign-on with portals is only supported for SAML 2.0.

To enable single sign-on for portals:

1. In addition to the SAML sign-on information that must be gathered and shared with your identity provider, you must
supply your information provider with the Organization ID and the Portal ID. In the SAML assertion that is sent from
your identity provider, the portal_id and organization_id must be added as attributes.
Note: You can leave these attributes blank to differentiate between portal and platform users. For example, when
blank, the user is a regular platform user and when populated, the user is a portal user.
a. Click Your Name > Setup > Company Profile > Company Information and copy the ID located in the Salesforce
Organization ID.
b. For Customer Portals, click Your Name > Setup > Customize > Customer Portal > Settings, click the name of the
Customer Portal, and copy the ID located in the Portal ID.
c. For partner portals, click Your Name > Setup > Customize > Partners > Settings, click the name of the partner portal,
and copy the ID located in the salesforce.com Portal ID.

Understanding Delegated Authentication Single Sign-On

Available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

Salesforce uses the following process for authenticating users using delegated authentication single sign-on:
1. When a user tries to log ineither online or using the APISalesforce validates the username and checks the users
permissions and access settings.
2. If the user 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 users organization, asking it to validate the username and password.
Note: Salesforce doesnt store, log, or view the password in any way. It is disposed of immediately once the process
is complete.
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.
Note:

System administrators should have single sign-on disabled. If your system administrators were single sign-on users
and your single sign-on server had an outage, the administrators would have no way to log in to Salesforce. System
administrators should always be able to log in to Salesforce so that they can disable single sign-on in the event of
a problem. All users, except those with the System Administrator profile, have delegated authentication enabled
by default in Professional Edition.
There may be a momentary delay before a new user can log in after using delegated authentication due to the time
required for the new user account to become available in the organization.

Understanding Delegated Authentication Single Sign-On

Configuring Salesforce for Delegated Authentication

Available in: Professional, Enterprise, Unlimited, Developer, and Database.com Editions

User Permissions Needed

To view the settings:

View Setup and Configuration

To edit the settings:

Customize Application
AND
Modify All Data

To enable delegated authentication single sign-on (SSO) 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 Your Name > 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 11.
b. Add a link to your corporate intranet or other internally-accessible site that takes the authenticated users 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
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 organizations single sign-on gateway URL by clicking Your Name > 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.
102466535 (inclusive): These ports accept HTTP or HTTPS connections.

4. Optionally, check the Force Delegated Authentication Callout box.

Understanding Delegated Authentication Single Sign-On

Note: When this box is unchecked, a call is not made to the SSO endpoint if the login attempt first fails because
of login restrictions within the Salesforce organization. If you must record every login attempt, then check this box
to force a callout to the SSO endpoint regardless of login restriction failures.
5. Enable the Is Single Sign-On Enabled permission. For more information, see Overview of User Permissions and Access
in the online help.
Important: If single sign-on is enabled for your organization, API and desktop client users can't log into 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 online help. For information on how to view login errors, see Viewing Single Sign-On Login Errors in the
online help.

Sample Delegated Authentication Implementations

Samples are available by downloading the sample code for .NET from the Developer Force.
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 users
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 the following ways to use single sign-on:

Federated authentication using Security Assertion Markup Language (SAML): When federated authentication
is enabled, Salesforce does not validate a users password. Instead, Salesforce verifies an assertion in the HTTP POST
request, and allows single sign-on if the assertion is true. This is the default form of single sign-on. Federated
authentication is available in all Editions.
Delegated authentication: When delegated authentication is enabled, Salesforce does not validate a users password.
Instead, Salesforce makes a Web services call to your organization to establish authentication credentials for the user.
You must request that this feature be enabled by salesforce.com. Contact salesforce.com to enable delegated
authentication single sign-on for your organization.

Where in Salesforce do I configure single sign-on?

For delegated authentication single sign-on:

The WSDL is available by clicking Your Name > Setup > Develop > API > Download Delegated Authentication
WSDL.
You can specify your organizations single sign-on gateway URL by clicking Your Name > Setup > Security Controls
> Single Sign-On Settings > Edit.
To enable the Is Single Sign-On Enabled user permission for your single sign-on users, click Your Name > Setup
> Manage Users > Permission Sets, or if permission sets arent available, Your Name > Setup > Manage Users >
Profiles.

For federated authentication using SAML:

Click Your Name > 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 who use delegated authentication 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?
For delegated authentication, administrators with the Modify All Data permission can view the twenty-one most
recent single sign-on login errors for your organization by clicking Your Name > Setup > Manage Users > Delegated
Authentication Error History. For each failed login, you can view the user's username, login time, and the error. For
federated authentication, administrators can view login errors by clicking Your Name > Setup > Manage Users > Login
History.
Where can I find entries about login history for a failed SAML login attempt?
When Salesforce cannot find the user in your assertion or cannot associate the provided user ID with a user in Salesforce,
an entry is inserted in the login history at Your Name > Setup > Manage Users > Login History.

Frequently Asked Questions

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 validate the SAML response sent by my identity provider?
Yes. After you have configured single sign-on, you can access the SAML Validation page by clicking the SAML
Validation button at Your Name > Setup > Security Controls > Single Sign-On Settings. If a user tries to log in to
Salesforce and fails, the invalid SAML assertion is used to automatically populate the SAML Assertion Validator if
possible. On the SAML Validation page, if the SAML assertion is not automatically populated, you can enter either an
XML or base64encoded SAML response that you've received from your service provider. Salesforce validates the
response against the values provided during single sign-on setup, and provides detailed information about the response.
Can I configure a start page and logout page that are specific to my company?
Yes.
The start, error, login, and logout pages can be customized for single sign-on users using SAML 1.1 or 2.0. As part of
your configuration, you need to decide the following:

The logout page: the URL to direct the user to when they click the Logout link in Salesforce. The default is
http://www.salesforce.com.
If your identity provider uses SAML 1.1, the start page: the URL to direct the user to when sign-on successfully
completes. This URL can be absolute, such as https://na1.salesforce.com/001/o or it can be relative, such
as /001/o. This URL should be an endpoint that accepts SAML authentication requests.
In SAML 2.0, the start page is the page the user attempted to access before they were authenticated. The SAML
2.0 start page must support Sp-init single sign-on.
If you are using SAML 2.0, you can also use the RelayState parameter to control where users get redirected after
a successful login.

The single sign-on start page where Salesforce sends a SAML request to start the login sequence.
We recommend that if you specify a single sign-on start page that you also specify a logout page. When you specify
a logout page, when a user clicks logout or if a users session expires, the user is redirected to that page. If you dont
specify a logout page, the user is redirected to the general Salesforce login page.

See Customizing SAML Start, Error, Login, and Logout Pages on page 5.
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.

Index

Index
D

Delegated authentication
configuring single sign-on 34
sample implementations 36
single sign-on 33

SAML
about 3
custom error page 5
example assertions 6
Just-in-Time provisioning 25
Just-in-Time provisioning errors 27
Just-in-Time provisioning requirements 25
login history 23
login page 5
logout page 5
prerequisites 4
single sign-on 17
start page 5
validating single sign-on 20
validation errors 20
viewing single sign-on 19
Security
Just-in-Time provisioning 25
Just-in-Time provisioning requirements 25
portals single sign-on 32
single sign-on
identity provider values 14
Single sign-on
best practices 29
configuring delegated authentication 34
debugging 20
delegated authentication 33, 36
example SAML assertions 6
FAQ 37
login history 23
overview 2
portals 32
prerequisites 4
SAML 17
SAML validation 20
viewing 19

E
Error page
customizing in SAML 5

I
Identity provider
values 14

J
Just-in-time provisioning
example SAML assertions 6
Just-in-Time provisioning
requirements 25
Just-in-Time provisioning errors 27

L
Logging in
SAML start page 5
Logging out
SAML 5

P
Portals
single sign-on 32

Veeva Systems Recruiting Exercise: Introduction and Instructions
0% (1)
Veeva Systems Recruiting Exercise: Introduction and Instructions
2 pages
Salesforce Admin Preparation
No ratings yet
Salesforce Admin Preparation
15 pages
NFPA54 Pressure Test
No ratings yet
NFPA54 Pressure Test
2 pages
Pe - 1969-05
100% (8)
Pe - 1969-05
100 pages
Implementing PRM Portal
No ratings yet
Implementing PRM Portal
82 pages
Marketing Cloud Administrator Study Guide
100% (1)
Marketing Cloud Administrator Study Guide
9 pages
A. Salesforce Fundamentals 1. Can Two Users Have The Same Profile? Can Two Profiles Be Assigned To The Same User?
No ratings yet
A. Salesforce Fundamentals 1. Can Two Users Have The Same Profile? Can Two Profiles Be Assigned To The Same User?
34 pages
S DocsCookBook 13W
100% (2)
S DocsCookBook 13W
32 pages
Salesforce Single Sign On
No ratings yet
Salesforce Single Sign On
22 pages
SFDC Basics
No ratings yet
SFDC Basics
77 pages
Cheatsheet: Setting Name Description Location
No ratings yet
Cheatsheet: Setting Name Description Location
4 pages
Salesforce CRM Admin Cookbook
From Everand
Salesforce CRM Admin Cookbook
Paul Goodey
4/5 (1)
Salesforce.com Customization Handbook
From Everand
Salesforce.com Customization Handbook
Rakesh Gupta
3/5 (2)
JunoAPI SEARCH v1.3.1
No ratings yet
JunoAPI SEARCH v1.3.1
36 pages
T & H P A: Understanding Person Accounts
No ratings yet
T & H P A: Understanding Person Accounts
2 pages
Salesforce Security Notes For Certification
No ratings yet
Salesforce Security Notes For Certification
7 pages
Sales Outlook Integration Impl Guide
No ratings yet
Sales Outlook Integration Impl Guide
16 pages
Salesforce - Volvo Customer Success Story
No ratings yet
Salesforce - Volvo Customer Success Story
3 pages
Admin-4-Security and Access-15% - SFDC Notes
No ratings yet
Admin-4-Security and Access-15% - SFDC Notes
1 page
Salesforce Useful Formula Fields
No ratings yet
Salesforce Useful Formula Fields
39 pages
Salesforce Security Impl Guide
No ratings yet
Salesforce Security Impl Guide
356 pages
Salesforce Exam Notes
100% (1)
Salesforce Exam Notes
4 pages
Interview Questions - Salesforce Marketing Cloud
No ratings yet
Interview Questions - Salesforce Marketing Cloud
30 pages
Salesforce Shield PDF
No ratings yet
Salesforce Shield PDF
8 pages
SG Certified Marketing Cloud Email Specialist
No ratings yet
SG Certified Marketing Cloud Email Specialist
13 pages
Facebook Salesforce Integration
No ratings yet
Facebook Salesforce Integration
12 pages
Admin-6-Sales and Marketing Applications-9% - SFDC Notes
No ratings yet
Admin-6-Sales and Marketing Applications-9% - SFDC Notes
1 page
Salesforce Course Outline
No ratings yet
Salesforce Course Outline
3 pages
Salesforce Workflow Cheatsheet
No ratings yet
Salesforce Workflow Cheatsheet
4 pages
Pardot Fields
No ratings yet
Pardot Fields
4 pages
SF Experience Cloud
No ratings yet
SF Experience Cloud
941 pages
Salesforce Virtual Internship Admin Track HandBook Final Cohort 2
100% (1)
Salesforce Virtual Internship Admin Track HandBook Final Cohort 2
11 pages
Salesforce Formulas Cheatsheet
No ratings yet
Salesforce Formulas Cheatsheet
6 pages
Salesforce Technology
100% (1)
Salesforce Technology
72 pages
How Salesforce - Com Uses The Service Cloud and Salesforce Chatter
100% (1)
How Salesforce - Com Uses The Service Cloud and Salesforce Chatter
4 pages
SFCC v1
No ratings yet
SFCC v1
14 pages
Salesforce Marketing Cloud Session
50% (2)
Salesforce Marketing Cloud Session
3 pages
How Salesforce - Com Uses Salesforce Chatter
0% (1)
How Salesforce - Com Uses Salesforce Chatter
3 pages
Adm 201
No ratings yet
Adm 201
13 pages
Salesforce Winter24 Release Notes
No ratings yet
Salesforce Winter24 Release Notes
706 pages
Pardot Engagement
No ratings yet
Pardot Engagement
17 pages
Microsoft Dynamics CRM 2011: Dashboards Cookbook
From Everand
Microsoft Dynamics CRM 2011: Dashboards Cookbook
Mark AuCoin
No ratings yet
Aministrator Certification Prep Module 3
100% (1)
Aministrator Certification Prep Module 3
29 pages
What Is Salesforce Sales Cloud?
No ratings yet
What Is Salesforce Sales Cloud?
6 pages
How Salesforce - Com Uses Salesforce CRM in Marketing
No ratings yet
How Salesforce - Com Uses Salesforce CRM in Marketing
3 pages
Salesforce CPQ
No ratings yet
Salesforce CPQ
463 pages
Salesforce Query Search Optimization Developer Cheatsheet
No ratings yet
Salesforce Query Search Optimization Developer Cheatsheet
2 pages
Salesforce Reporting and Dashboards
From Everand
Salesforce Reporting and Dashboards
Johan Yu
4/5 (1)
Salesforce Marketing Cloud Connect Essentials
No ratings yet
Salesforce Marketing Cloud Connect Essentials
1 page
OKTA S Training
No ratings yet
OKTA S Training
10 pages
MC Consultant Cert Deep Dive
No ratings yet
MC Consultant Cert Deep Dive
18 pages
sa
No ratings yet
sa
27 pages
Salesforce - The Trailblazer's Guide To Field Service Ebook
No ratings yet
Salesforce - The Trailblazer's Guide To Field Service Ebook
19 pages
Getting Started WIth SalesForce Part II
50% (2)
Getting Started WIth SalesForce Part II
15 pages
Salesforce Admin
No ratings yet
Salesforce Admin
4 pages
Salesforce Admin Guide
No ratings yet
Salesforce Admin Guide
2 pages
Irep Installation
100% (1)
Irep Installation
49 pages
ADM211-Examen 1
100% (1)
ADM211-Examen 1
12 pages
Salesforce Partners Home Page Components Configuration Guide
No ratings yet
Salesforce Partners Home Page Components Configuration Guide
13 pages
Administrator Practice Test Results
No ratings yet
Administrator Practice Test Results
13 pages
Top 100 Salesforce Admin 201 Questions and Answers
No ratings yet
Top 100 Salesforce Admin 201 Questions and Answers
25 pages
DEV-450.exam.37q: Website: VCE To PDF Converter: Facebook: Twitter
No ratings yet
DEV-450.exam.37q: Website: VCE To PDF Converter: Facebook: Twitter
18 pages
Salesforce Useful Validation Formulas
0% (1)
Salesforce Useful Validation Formulas
35 pages
Install Package Info - SFDC
No ratings yet
Install Package Info - SFDC
10 pages
Df10 Fin-Analyst Session
No ratings yet
Df10 Fin-Analyst Session
61 pages
Visualforce in Practice
No ratings yet
Visualforce in Practice
224 pages
FY15 Cloud Alliance Partner Program Guide 1
No ratings yet
FY15 Cloud Alliance Partner Program Guide 1
19 pages
Salesforce Apex Language Reference PDF
No ratings yet
Salesforce Apex Language Reference PDF
639 pages
CA Converted Thresholds 22jul2013
No ratings yet
CA Converted Thresholds 22jul2013
1 page
Stem Opt - 2016-04828
No ratings yet
Stem Opt - 2016-04828
300 pages
Tax Treaty Table 3
No ratings yet
Tax Treaty Table 3
3 pages
Salesforce Report Summary Functions Cheatsheet
No ratings yet
Salesforce Report Summary Functions Cheatsheet
2 pages
Advanced Testing & Debugging: Getting The Most From The Developer Console
No ratings yet
Advanced Testing & Debugging: Getting The Most From The Developer Console
23 pages
"R T E U A ": B O T I Instrumentation AND Control Engineering
No ratings yet
"R T E U A ": B O T I Instrumentation AND Control Engineering
7 pages
TDS Rust-X Vci 10
No ratings yet
TDS Rust-X Vci 10
4 pages
Knoppix Cheat Codes
No ratings yet
Knoppix Cheat Codes
4 pages
Case Final3
No ratings yet
Case Final3
60 pages
Lecture #1 Design of Reinforced Concrete Structures
100% (6)
Lecture #1 Design of Reinforced Concrete Structures
25 pages
Genuine Eaton® Air System Parts, Kits and Assemblies For Top Shift Performance
No ratings yet
Genuine Eaton® Air System Parts, Kits and Assemblies For Top Shift Performance
4 pages
Bandwidth Document Examples
No ratings yet
Bandwidth Document Examples
6 pages
Oriental Yeast India Pvt. Ltd. OPYE Project: Design Calculation For Treated Molasses Tank (11-B-05)
No ratings yet
Oriental Yeast India Pvt. Ltd. OPYE Project: Design Calculation For Treated Molasses Tank (11-B-05)
2 pages
MO Paper
No ratings yet
MO Paper
2 pages
Fart
100% (1)
Fart
2 pages
Catalog Mud Pump 25864
100% (1)
Catalog Mud Pump 25864
24 pages
Road Drainage Manual Chapter 9 Culvert Design
100% (1)
Road Drainage Manual Chapter 9 Culvert Design
51 pages
Recommended Weld Reference Materials PDF
No ratings yet
Recommended Weld Reference Materials PDF
2 pages
City of Brockton, Ma Police Log April 9, 2019
No ratings yet
City of Brockton, Ma Police Log April 9, 2019
21 pages
CO2 Tune
No ratings yet
CO2 Tune
5 pages
Sahitya Kala Parishad: District Cultural Center - Bodella - Vikaspuri
No ratings yet
Sahitya Kala Parishad: District Cultural Center - Bodella - Vikaspuri
28 pages
Frequently Asked Electrical Engineering Interview Questions
0% (1)
Frequently Asked Electrical Engineering Interview Questions
2 pages
Roland V-Drums Catalog
No ratings yet
Roland V-Drums Catalog
23 pages
Aerodynamic Analysis Models For Vertical-Axis Wind Turbines
No ratings yet
Aerodynamic Analysis Models For Vertical-Axis Wind Turbines
8 pages
Sic Mosfet
No ratings yet
Sic Mosfet
6 pages
Newsletter 1
No ratings yet
Newsletter 1
7 pages
Composite Elevated Water Storage Tank Specifications
No ratings yet
Composite Elevated Water Storage Tank Specifications
9 pages
Better Safe Than Sorry!: Lead Battery Know-How and Accident Prevention
No ratings yet
Better Safe Than Sorry!: Lead Battery Know-How and Accident Prevention
0 pages
WpDataTables Documentation
No ratings yet
WpDataTables Documentation
164 pages
Beneview T5/T6/T8: Patient Monitor
No ratings yet
Beneview T5/T6/T8: Patient Monitor
2 pages
Pan in America - 6th Sem
100% (3)
Pan in America - 6th Sem
2 pages
Serial & Parallel Robot Manipulators - Kucuk
No ratings yet
Serial & Parallel Robot Manipulators - Kucuk
468 pages
Real-Time Rendering 4th Edition Tomas Akenine-MöLler instant download
100% (3)
Real-Time Rendering 4th Edition Tomas Akenine-MöLler instant download
61 pages