Delegated Authentication

Module 5 of 5 in the chapter The Mirror Image: Social Sign-On and Delegated Authentication, chapter 10 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: What can you do when the passwords live in an old system that can’t speak SAML or OpenID Connect?

The legacy store

This was a bigger deal years ago, before single sign-on was everywhere. Picture a company with an old system, a proprietary database, and inside it, all its users’ usernames and passwords. Thousands of them. And the company says: we want Salesforce to be part of our single sign-on, using these.

What’s the first idea someone has? Copy them. Export the usernames and passwords, create the same users in Salesforce with the same passwords. Done.

Never, ever, ever copy usernames and passwords out of a system. That’s security 101. You shouldn’t even be able to, because they should be hashed and protected. And think it through: when someone changes their password in the old system, what happens in Salesforce? You’d have to copy it again. And again. It becomes a nightmare.

So what do you do?

The better answer first: teach it SAML

I had a client with exactly this: a legacy system with all their credentials, and it couldn’t speak SAML. But they controlled its code. So I asked: if this system is going to become the identity provider, what does it need to receive? A SAML request. And what does it need to send back? A signed SAML response.

So I walked their team through it. Receive a SAML request at a new endpoint. Send out a SAML response. Sign the assertion. That’s chapter 6, from the other side. We set it up, and it worked great: the old login screen became the identity provider.

If the system that holds the passwords can be changed, that’s the answer. Make it a real identity provider, with SAML or OpenID Connect, and everything in chapters 6 and 10 works with it.

But what if it can’t be changed? What if it’s something you can’t customize, and it still has all those users and passwords?

True or false

That’s what Salesforce built delegated authentication for. Salesforce trusts an external service to check the password. In Salesforce’s words, “one system relies on another system to validate user credentials”, for example a Lightweight Directory Access Protocol (LDAP) server (S7).

Click to enlarge

1. Priya types her username and password on Salesforce’s own login page. Not a redirect: she stays at Salesforce.
2. Salesforce checks the user. If she has the Is Single Sign-On Enabled permission, Salesforce calls your web service, a SOAP call, and passes “the username, password, and source IP” (S7).
3. Your service checks the password against the store it wraps, and answers.

And what does it answer? True or false. What does true mean? She’s authenticated, let her in. What does false mean? It isn’t her: bad password, bad anything. That’s all you get, no other feedback (S7).

And the password itself: “Salesforce immediately disposes of the password without storing, logging, or viewing it” (S7).

Notice how different this is from everything else in this chapter. With single sign-on, she signs in at the identity provider and Salesforce never sees her password. With delegated authentication, she types it into Salesforce, and Salesforce passes it along. Both let people use one set of credentials, but with delegated authentication “users must log in to each app separately” (S7).

Setting it up

Delegated authentication is available from Professional Edition up, and you need Customize Application and Modify All Data (S8). The steps (S8):

1. Turn it on for the org, in Single Sign-On Settings. If you don’t see the setting, your org may need Salesforce to turn it on first; ask Salesforce Support.
2. Build your web service. From Setup, API, download the Delegated Authentication WSDL, and generate a server stub from it. “Namespaces, element names, and capitalization must be exact in SOAP requests”, so generate it rather than write it by hand (S9).
3. Enter the Delegated Gateway URL in Single Sign-On Settings: your service’s address.
4. Give the permission, Is Single Sign-On Enabled, to the users who should log in this way (S8).

Your service has to be reachable by Salesforce, so it sits in your DMZ, over TLS, with a certificate from a trusted provider (S9). I’d raise it further: allow only Salesforce’s addresses, and use two-way TLS, where Salesforce and your service each have a certificate to prove who they are, the mutual TLS from chapter 3. Then your service knows it’s only getting requests from Salesforce. And your users’ Salesforce usernames have to map to the ones in your store (S9).

One more option, and it’s a good one. You don’t have to pass the real password at all. Salesforce suggests a link on your intranet that passes “another authentication token instead, such as a Kerberos ticket” (S8). Then the corporate password never travels to Salesforce.

What you give up

Once a user has Is Single Sign-On Enabled, Salesforce no longer manages their password, so neither do any of Salesforce’s password policies (S7). That has some consequences.

• No password reset. “Password reset is disabled… Users who try to reset their passwords in Salesforce are directed to their Salesforce admin” (S9).
• Lockouts are your service’s job, usually (S8).
• The API and desktop clients can log in with it too (S8).
• It doesn’t meet the MFA requirement. In Salesforce’s words: “Delegated Authentication does not satisfy the MFA requirement” (S10). Single sign-on does, when it’s SAML or OpenID Connect with MFA at the identity provider (S10).
• When something goes wrong, the Delegated Authentication Error History in Setup shows the 21 most recent login errors (S9).

Don’t lock yourself out

Here’s the big one. Don’t do this for all your profiles. If your service goes down, everyone on delegated authentication is locked out. That whole group, shut down.

So always keep users who don’t use it, starting with your admins. Salesforce’s own example does exactly that: standard users log in through the LDAP server, system administrators with their Salesforce password (S7). Somebody has to be able to get in and fix it.

How rarely

In all my years, I’ve done this at two clients. Most companies’ passwords now live in an identity provider that speaks SAML or OpenID Connect. So: old technology, still in there. Only use it when you absolutely have to.

Keep it in your pocket, though. It’s the break-glass option, the one you reach for in an emergency. It’s old school: the way things were done before single sign-on was everywhere. And it could be on the test.

Test knowledge. In my experience, know how delegated authentication works: Salesforce’s login page collects the password, calls your SOAP web service, and gets back true or false; the permission is Is Single Sign-On Enabled; and Salesforce doesn’t store the password.

What’s next

That’s the chapter. The practice puts modules 2 and 3 to work: one lab org signing in through the other. Then chapter 11: acting as someone, the impersonation flows.

What an architect decides here

• Whether the store can be taught SAML or OpenID Connect first. That’s the better answer.
• Who gets Is Single Sign-On Enabled, and who never does: the admins.
• How the service is protected: in the DMZ, TLS, two-way TLS, Salesforce’s addresses only.
• Whether to pass a token instead of the password.
• How MFA is met for users who log in this way.

Explore

• Delegated Authentication (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
• Configure Salesforce for Delegated Authentication (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
• FAQs for Delegated Authentication (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)