Single Sign-on for Saleforce.com applications

1. Ming Yuan
March 2013

2. Two Approaches
 Delegated Authentication
 SFDC doesn’t validate passwords
 SFDC uses an external web service to validate credentials
 SSO scope is limited to SFDC
 Federated Authentication
 SFDC doesn’t validate passwords
 SFDC receives a SAML assertion from an HTTP POST request
 SFDC SSO can be part of enterprise SSO scope

3. Delegated Authentication
<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:Body>
<AuthenticateResponse
xmlns="urn:authentication.soap.sforce.com">
<Authenticated>true</Authenticated>
</AuthenticateResponse>
</soapenv:Body>
1 2
3
4
5
67

4. Federated Authentication
 Identity provider (Idp)
 the authority system that provides the user information
 Service provider (SP)
 the system (SFDC) that trusts the identity provider's user information, and uses
the data to provide access to the service or application
 Security Assertion Markup Language (SAML)
 a secure, XML-based solution for exchanging user security information between
an identity provider (Zurichna) and a service provider (SFDC)
 Two use cases
 Service Provider Initiated Login
 Identity Provider Initiated Login

5. Service Provider Initiated Login
zurich.my.salesforce.com
Zurich
SSO
Page
SAML Response
SAML Request

6. Identity Provider Initiated Login
Zurich
SSO
Page
SAML Response

7. SFDC Settings
a URL that uniquely identifies our SAML identity provider
Check to enable just-in-time security
The URL where SFDC sends a SAML request to start the login
sequence
HTTP POST binding sends SAML messages using base64-encoded HTML forms.
HTTP Redirect binding sends base64-encoded and URL-encoded SAML messages
within URL parameters.
Select MyDomain name

8. SAML-based Federated
Authentication
 Platform neutrality - abstracts the security framework
away from particular vendor implementations and
architectures
 Loosely coupled - SAML does not require user
credentials to be maintained and synchronized
between directories
 Flexibility - it is metadata-driven, allowing identity
providers to determine agreements and configurations
for multiple service providers