- Basic Authentication
- OAuth 2.0
- OAuth JWT
- OAuth Username and Password
- OAuth SAML
In all of the options for authentication, we always need to provide a Username. That’s because, in Salesforce, every single interaction with the platform happens in the context of a user. For our mule apps that means all the calls made by our Salesforce connector need to be associated with a user in Salesforce.
Now the question is, what user should we use? and what permissions should this user have?
Now the question is, what user should we use? and what permissions should this user have?
In this post we’ll review the different options we’ve got and what are the best practices for choosing or creating the best user for our mule apps interacting with Salesforce.
Different ways to access Salesforce
There are different ways to interact with the Salesforce Platform. Most of the time, it is human beings accessing Salesforce via the user interface. But that’s not the only way we can interact with Salesforce.There are other ways to interact with Salesforce. For example:
- Using the Salesforce APIs
- Automated processes running within Salesforce (such as flows or batch jobs)
- Public access (via a guest user)
Types of users in Salesforce
Since we have different ways to access the platform, Salesforce provides different types of users.- Named Users: These are our end users accessing Salesforce via the web browser. These users will need to log in with their own credentials. They should never share these credentials and each authenticated user in Salesforce should always represent the actual person accessing the user interface.
- Integration User: An integration user in Salesforce is a special type of user account used specifically for integrating external systems and applications with Salesforce. In this machine-to-machine communication, we don’t have an identifiable ultimate end user. This account is used to facilitate automated data exchanges between Salesforce and other systems. This type of user does not represent an end user, it represents an external system, an application or an automated process.
- Guest User: A guest user in Salesforce is a user associated with a Salesforce Community or Experience Cloud site who can access the site without logging in. This type of user is primarily used to allow anonymous access to certain parts of a Salesforce site, such as public knowledge articles, contact forms, or other public-facing content and services
What type of user is recommended for our Mule Apps?
As we mentioned above, when we access Salesforce via the API (for example using the connector in the Mule app), all of the calls made from the app must be done as an authenticated user. This authenticated user can be a named user, an integration user of a guest user.For our Mule apps, we should only use a named user or an integration user. Choosing between the two will depend on our use case. Let's see them in detail.
Named Users
We use named users when we want to impersonate a known end user. The Salesforce connector will make the API calls as it was the named user directly making them. This is the preferred approach when we know who the end user is using the mule app and we want to make the requests on their behalf.Example - A banking mobile app.
In this case, the end user will sign in to the mobile app using their credentials and the mobile app will be making API requests to our mule app. In this case, we should use the named user credentials for the API requests. That will give us:- Traceability - we’ll be able to track all activity performed by the end user in a better way. If we used a generic integration user, all the API calls made by the app when the end user interacts with the mobile app will be tracked as an integration user and not as the end user.
- Breach identification - If an end user's credentials are compromised it would be much easier to identify all the operations performed by that user in the app than if they were performed by a generic/integration user.
- Principle of least privilege - When a user interacts with Salesforce data he/she should only have access to the subset of data he’s allowed to access based on their user permissions/profile. When using the mobile app the user should have access to the same subset of data in Salesforce. We can do that easily with a named account for the Mule app. But if we use an integration user, this user would have access to all records and objects, which is probably more than what the user should see. Also, if the integration user credentials are compromised the impact would be higher.
Integration Users
When we don’t have an identifiable ultimate end user, for example when our mule app would be exchanging data between salesforce and another system of records, we should use an integration user. Normally integration users have a higher level of permissions than standard named users, because in this kind of scenario, the integration user should have access to all records.For example, if we are synchronizing records between Salesforce and a database we don’t have a clear end user. We should not use a named user for this, it’s better if we have an integration user and all of the operations done during that synchronization process are tracked and mapped to that user.
However, this does not mean we should have only one Integration User for all integrations and programmatic accesses to Salesforce. As a matter of fact, the recommendation is to have multiple integration users.
How many Integration Users should we create for our mule apps?
There’s no magic number for this. In Salesforce, the recommendation is to create an Integration User per integration. This, translated to our Mule world does not necessarily mean having an Integration User per Mule app accessing Salesforce. I’ve seen some people recommending creating one integration user per Mule app. I do not agree with that approach. That would only make sense if our mule app is accessing Salesforce for only one use case.But our goal in Mule, for example when we create a system API to access Salesforce, is to reuse that same app for as many use cases as we possibly can.
We should define different Integration Users and map each Integration User to a group of mule apps or to a group of use cases within the same mule apps. Some examples:
- Example 1: Let’s say we’ve got only one system API for Salesforce that is used by different use cases. For example, this API can be used by our eCommerce site to get information about our accounts and catalog and at the same time, it can be used by our Support team to synchronize the cases in Salesforce with Jira or ServiceNow. In this case, we should have 2-3 Integration Users to identify the different types of access.
- Example 2: Let’s say that instead of having a unique system API to access to Salesforce we created a few system APIs to access different clouds (Sales, Cloud, Marketing...) or different subsets of records in Salesforce (Accounts, Cases, Campaigns...). In this case, instead of having the same Integration User for all these APIs, we could have (at least) one Integration User per API. And, again, if these apps are highly reusable and we’ve got different use cases within each app we could also consider having more than one Integration User per app.
- Traceability - With one integration user per API/group we can track which system is accessing Salesforce via the mule app. It will be useful to see which calls are made for our eCommerce site, our mobiel app, Jira or ServiceNow.
- Minimize breach impact - having more than one integration user limits the impact of having the credentials compromised.
- Principle of Least Privilege - if we can create some categories or domains for different subsets of data in the platform that will give us more control and the ability to fine-tune access rights. For example: should our mobile app have the same visibility as our partners' site? probably not, as the audiences are different.
Lastly, we also need to pay attention to the volume of calls - if this volume is high we might need to have a few integration users in order not to be throttled on the number of API calls.