These are notes on Delegated Authentication that I am making while studying for my Identity and Access Management Architect certification.
Delegated Authentication enables users to log into many applications with one set of credentials. In many respects it is similar to Single Sign On (SSO). One system relies on another system to validate the user’s credentials. The external authenticating system manages the credentials by wrapping them in a web service. Salesforce calls the external authentication method in the web service that controls user passwords and associated policies. Salesforce does not control the passwords at all. Also, My Domain is not required for Delegated Authentication.
The external authentication system is generally an LDAP (Lightweight Directory Access Protocol – see https://ldap.com). The web service it provides must be SOAP-based (Simple Object Access Protocol) and available by TLS (Transport Layer Security). It must also have a certificate from a trusted provider. Salesforce holds a list of these, but two mentioned fairly frequently are Verisign or Thawte.
The web service must also be accessible by Salesforce servers. For example, if the web service is part of an on-premise system, to ensure Salesforce can communicate with it, the web service must be deployed on a server in the DMZ (demilitarized zone aka a perimeter network protecting an organisation’s internal local area network (LAN) from untrusted traffic).
Mapping has to be carried out to map the usernames on the web service to Salesforce Usernames. As SOAP requests must be exact, namespaces, names, and lower/upper case must be correct and so where possible generate server stubs from the WSDL file to ensure accuracy.
When a user logs in to Salesforce either through the User Interface or via API, if the Single Sign-On Enabled user permission is enabled, instead of Salesforce validating the username and checking the user’s permissions and access settings, Salesforce calls to the Single Sign-on SOAP-based web service to validate the username and password. Salesforce does not keep the password that has been entered, but passes the password, the username, and source IP to the SSO Web Service implementation through a web service call.
The SSO Web Service validates the passed information and returns True or False. True allows the login process to continue and the user to access Salesforce. False returns an error to the user that says the username and password combination is invalid.
One key thing to note with delegated authentication is that password reset is disabled for delegated authentication. Anyone who tries to reset their password will be directed to the Salesforce admin. They in turn (providing they have the modify all data permission) can view the most recent login errors in Delegated Authentication Error History. Examples of errors that can be returned are username and password combination is invalid or when the request to the web service takes too long or a certificate has expired that “Your company’s authentication service is down”.
Note: Although the Delegated Authentication must be carried out with a SOAP message. It is possible to use an intermediary application that uses REST that passes the Username, and a SAML assertion or authentication token or password to Salesforce who after checking the is single sign-on enabled permission passes a SOAP request to the external authentication service. This is used to provide an extra layer of security.