Use a dedicated Trelica account for integrations

Information Security best practice for integrations

When you connect Trelica to another application, you typically either use an API Key, or something called OAuth2. This depends on the application you are connecting to.

Either way, you generally have to log in to a user account in the application, either as part of granting access through the OAuth2 process, or in order to create an API key to type into Trelica.

Generally these accounts need to have some level of administrative access rights.

While it's convenient to log in with an existing administrator account, we recommend creating dedicated accounts for Trelica to use to connect to other applications, particularly for key integrations such as Identity Providers.

Benefits of a dedicated account

Clarity in audit logs

Let's say you want to connect to Salesforce. If you use your personal administrator account to connect, any actions performed by Trelica will probably be recorded in the Salesforce audit log as coming from your user account. Additionally you may be using this account to integrate with other systems too, so those actions will get assigned to your user as well.

This will make proper audits difficult. You won't necessarily know which system did what, or whether it was you performing the actions.

From an audit perspective, it is preferable for each connecting system to have its own user account so that audit log entries can be clearly differentiated.

Future-proof

People change roles and sometimes leave organizations. If your integrations are connecting using a specific individual's account, then if they move roles, they may lose their administrative rights, or the account may be terminated completely if they leave your organization. At this point a new person will need to reconnect the integration. Having a dedicated Trelica account for an API connection avoids these concerns.

Principle of least privilege

One reason we use OAuth2 wherever possible is because it is based around a concept of "scopes": the application asks your permission to grant Trelica the ability to perform a specific, restricted list of actions. For example, Trelica might be allowed to view user details, but not delete users.

Some applications also do this for API keys (when you create the API key, you can specify that it is only able to perform specific actions), but often API keys grant the same level of access that the user creating them has.

If you create a dedicated user account in an application, you can often also control what rights that user account has. This means that you can ensure that an API key created through this account can only perform a limited set of actions, for example viewing users but not altering user account data.

This is a fundamental principle of information security - access is restricted to only what is needed.

This is less important with OAuth2, as Trelica only requests the access rights it needs. However some applications implement OAuth2 in a broad way, and grant general access rights. In these situations a dedicated account can help you be specific about what Trelica can do.

What Trelica needs access to

Every integration in Trelica tells you what it is going to need access to, so you can use this information to determine access rights for a dedicated account. Here are some general principles:

Things to be aware of

Google Workspace (formerly G Suite) has a specific quirk where creating dedicated roles does not provide sufficient permissions to access all users.