Salesforce External Client App (ECA) Authentication – Clarification on Test Connection and Account Aggregation

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hi Everyone,

I have enabled ECA authentication and completed all the required configuration steps:

  • Configured the host_name and corresponding value.
  • Successfully completed the Authorize process.
  • Verified in the Salesforce application logs that the authorization event was successful.

However, after performing a Test Connection, I noticed that the Salesforce logs show a Basic Authentication event instead of an ECA-based authentication event. Since ECA authentication is enabled and authorization has been completed successfully, I expected the authentication flow to use ECA.

My concern is that Test Connection and Account Aggregation operations still appear to be using the legacy/basic authentication mechanism rather than ECA.

Could you please clarify the following:

  1. Are Test Connection and Account Aggregation currently supported through ECA authentication?
  2. Do these operations continue to use the older authentication mechanism by design?
  3. Is any additional configuration required to ensure that all connector operations use ECA authentication?
2

@Ashutosh_Pandey can you tell the steps you did to change to ECA?

3

I enabled the External Client App (ECA) toggle and configured the required client settings:

  1. Turned on Enable External Client App (ECA).
  2. Under Client Configuration, added the key-value pair:
    • Key: host_name
    • Value: <Token URL host> (for example, login.salesforce.com or test.salesforce.com)
  3. Clicked Save to persist the configuration.
  4. Selected Authorize and completed the authorization successfully.
4

Your understanding looks correct to me. Once ECA is enabled, authorized and saved, Test Connection and aggregation should be going through the ECA path. The migration steps also say to run Test Connection after ECA configuration, then a test aggregation to confirm accounts and entitlements are returned. So I would not assume Basic is expected by design here.

I would check if the source is still falling back to legacy settings. The backward compatibility toggle is available during the 90-day migration window, and if that is still on, the connector would use the old auth method for operations even though the ECA authorize step itself worked fine. Also confirm old Basic/OAuth values are not still being picked from the source config, and that host_name is set only to login.salesforce.com or test.salesforce.com.

If Salesforce still shows Basic after verifying all of that, I would refer to the ECA product announcement and reach out to Angel_Tawade or your SailPoint PM/CSM for migration support. Per the announcement, ECA is the supported path for connector validation and operations going forward, so they should be able to confirm why it is still logging as Basic in your tenant.

5

Thanks for the insight.
I am seeing a similar behavior in our testing. To validate this further, I created a new Salesforce source in Sandbox, enabled ECA from the beginning, and configured it strictly according to the SailPoint documentation. However, when running Test Connection, the connector returned the following error:
We have detected an error from the managed system.

Error Received:

[salesforce-saas]: [ConnectorError] ‘Username’ is required (requestId: 0f17ed0a52e542da8dfe2bb0dbb76f47) (requestId: 0f17ed0a52e542da8dfe2bb0dbb76f47)

Based on my understanding, once ECA is enabled and authorized, the connector should rely on the ECA authentication flow and should not require a username in the traditional source configuration. The fact that the connector is still prompting for a username raises the question of whether some legacy authentication validation is still being performed during Test Connection.

6

The toggle to turn on ECA is either not obvious or it’s not activated for all environments?

7

Based on the ECA announcement, the expected ECA setup is basically enable ECA, add host_name, complete Authorize, save, then run Test Connection. I do not see username mentioned as a required field in that ECA flow.

So this error does look like either Test Connection is still hitting some legacy validation path, or the connector still expects the Salesforce service account username internally but that requirement is not clear in the ECA documentation.

8

Hi @Ashutosh_Pandey , from where i can get the values that i can add at key and value fields after install the package on salesforse.

9

Hi @ahmed119
key will be - host_name
value will be - domain.salesforce.com

Thanks & regards,
Tulasi

10

Thanks @Tulasi ..

its directed me to salesforce authentication page

11

Hi @Tulasi nothing i enter for the host_name works. I am receiving error" {{host_name}}’s server IP address could not be found" . I am entering the logon url for my salesforce instance. Can you advise the exact format of the host name, please

12

Hi @jane246
If https://xyz.my.salesforce.com/services/oauth2/token is your Token URL
then value will be xyz.my.salesforce.com
Hope this work’s

Thanks & Regards,
Tulasi

13

Thanks @Tulasi This is what I am entering and I am still receiving that error message. Which is strange since i already have a working connection using the legacy OAuth. Trying to create a new connection now using only ECA, and can’t get it to work. I will keep trying

14

you may have basic or oauth already configured has some values populated. clear those and try again.

15

It adds a whole other section on the navigation page of the source - it now gets Base Configuration, Connection Settings, ECA Authentication

16

We literally had to use the word “host_name” - I did not understand that at all.

17

Same here. I figured it out eventually, but I don’t think the documentation explains it clearly enough.