In one of my recent posts, we discussed what type of user we should use in our Mule app to access Salesforce: a Named User or an Integration User. Click here to read What User Should We Use for the Salesforce Connector
In a nutshell, we should use a Named User when the consumer of our mule app is an identifiable end user and when the requests made by the connector should be in the security context of that user (the app calling Salesforce should have the same level of access as the consumer of the app). When that’s not the case, and the access to Salesforce is more of the type of machine-to-machine we should use an Integration User.
Integration users are normally users with higher levels of permissions in Salesforce, The more generic, or the broader the audience that will be using the mule app, the larger amount of information in Salesforce will be required for the integration user to have access to. So, we need to be careful with this type of users. Here are some tips for using integration users in our mule apps:
Protect the credentials
Since the integration user is not directly associated to only one user, the credentials of an integration user many times are shared by a whole development team, with all the consequences (written in post-its, spreadsheets, sent by email...).So, first and foremost, make sure you create strong passwords and you rotate them frequently. Next, make sure these credentials are stored securely and limit the number of people with access to them.
For a mule app, avoid using other authentication options and use the OAuth 2.0 JWT bearer flow. This flow does not require the password, it requires a certificate in the app which adds an extra layer of protection. This way you don’t have to provide the password to your devs.
All credentials should be secured in transit by using HTTPS for all communication
Protect access with those credentials
Even if the integration user credentials are compromised, we still have some mechanisms that we can put into practice to avoid any attacker with these credentials that could create some damage to our systems.- First, make sure that authentication/authorization for our mule apps is using a Connected App in Salesforce. The Salesforce Connected Apps give us more control. For example:
- IP restrictions - When we use an Integration User we normally use it from an external system or, in our mule world, from specific APIs. This means we can probably limit the origin of the API calls to the IPs or IP ranges of these systems/applications. You can restrict the list of authorized IP addresses on the Salesforce Connected App.
- Restrict Access to APIs - We can use the API Access Control feature in a connected app to restrict all users from accessing the Salesforce API. This way, API calls can only be made through our connected apps.
- API Only Integrations Profile - The Salesforce Integration user license supports this best practice by offering a profile that restricts assigned users to API-only access, ideal for system-to-system integration users. The Minimum Access - API Only Integrations profile enables and also restricts assigned users to operate via API. More info here
- Enforce SSL/TLS mutual authentication - This will add an extra layer of security because it will require a client certificate. Knowing the Integration User credentials won’t be enough if we enforce mTLS.
Minimize the damage
Don’t use only one Integration User for all your mule apps. We should define an Integration User for each system, API/group of APIs, use case, domain... Have a look at this previous post where we provide more insights on the topic.And once we’ve got our Integration Users, follow always the Principle of Least Privilege (PoLP). Limit the access of each Integration User to the specific subset of data/functionality needed in Salesforce. This way if credentials are compromised, only that subset will be compromised.
Lastly, NEVER grant System Administrator permissions to an Integration User (don’t make me explain that please...)