Federated Authentication using SAML

Federated authentication uses SAML, an industry standard for secure integrations. Investing in SAML with Salesforce.com can be leveraged with other products or services. If you use SAML, you don't have to expose an internal server to the Internet: the secure integration is done using the browser. In addition, Salesforce.com never handles any passwords used by your organization.

When an HTTP request arrives at Salesforce, if there is no valid session ID supplied (or the request is for a login page), Salesforce first examines the requested domain. If the requested domain is a My Domain (i.e. of the form https://mycompany.my.salesforce.com/), then we look up the associated org and check whether SAML (or, from Winter '13, an Authentication Provider) is configured for single sign-on.

If SAML is configured, then the browser is redirected to the relevant identity provider (IdP), the user is authenticated there, and the browser POSTs a signed SAML assertion (XML document) back to Salesforce asserting the user's identity. We can then create a session, set the relevant cookie and redirect the browser to the originally requested page.

Note that SAML can be implemented in an 'IdP-initiated' configuration, in which case, the user requests some page at the IdP, in response to which it generates the assertion and POSTs it 'unsolicited' to Salesforce. This process also sets a persistent cookie, so subsequent login requests are redirected via the IdP.

For troubleshooting, it is possible to force the use of the Salesforce login page rather than SAML by specifying the login query parameter - very handy in case of a misconfiguration!

If SAML is not configured, or the request was to a non-My Domain URL, then a login page is shown. We examine the user agent header to serve an appropriately formatted login page for the device, although this can be overridden via the display query parameter:

• page Full-page authorization screen (default).
• popup Compact dialog optimized for modern web browser popup windows.
• touch Mobile-optimized dialog designed for modern smartphones, such as Android and iPhone.

For example, try https://login.salesforce.com/?display=touch on a desktop browser.

If the request was to a Trialforce branded domain (i.e. mycompany.cloudforce.com), then the login page is branded appropriately, otherwise the standard Salesforce login page is shown.

Now, when the user submits the login page with their credentials, Salesforce looks up the user from the username. If Delegated Authentication (DA) is configured for this org and user, we send the supplied password to the configured DA endpoint for verification, otherwise we verify the password against the hash we have on record for that user. Either way, if the password is successfully verified, we create a session, issue the cookie, and redirect the user to the requested page.

Detailed flow of SSO with SAML: