Authentication
User ModelCopied!
Before creating authentications to call connectors with, it is necessary to create the users that will own these authentications.
Each of these users can own multiple authentications.
Tray does not have strict limits on the creation of users.
A one-to-one mapping between your system’s users and Tray users is the recommended approach.
Tray features are designed assuming this is the case.
The following table shows how all aspects of user management are dealt with:
| Feature | How it works | Notes | API used |
|---|---|---|---|
| User creation | via Embedded API | should be the users in your company that are part of the system being integrated with Tray | Create User API |
| Auth ownership | a user can own multiple authentications | otherwise solutions with more than one authentication will not be able to be executed | Create User Auth - but normally created via auth-only dialog (see below) |
| Permission model | based on workspaces | can have an impact on embedded solutions that use workspace objects such as authentications or connectors | n/a |
| Auth management | systems can read or delete all a user's auths with a single API call | could be triggered after a user is removed from the system | Get User Auths and Delete User Auth |
The simplest way to integrate Tray users would be to add a field to the entities that represent the concept of a user in the system’s model.
It could also be modelled as an “add on” feature without changing the system’s domain by:
adding the mapping as a new concept that would link a local user with a tray user
these user mappings can then be created as part of the creation of the authentication:
if the user mapping doesn’t exist create it
otherwise reuse the one that already exists
Of course these are just suggestions that may or may not apply depending on your internal user model
Collecting authenticationsCopied!
PrerequisitesCopied!
- Obtain a master tokenCopied!
To use the authentication and call connector APIs you will need to obtain a master token.
Details of how to create a master token can be found here
- Obtain serviceId and serviceEnvironmentIdCopied!
Services are the systems that you are connecting to in your integration solution. Example: an integration between Salesforce to Slack involves two services: Salesforce and Slack.
You would need serviceId and serviceEnvironmentId to draft the auth collection URL shown in step 2 below. These are unique for every service. Here are two ways you can find them:
Copy the serviceId and serviceEnvironmentId, as they would be required to prepare the auth collection URL in Step 2 below.
Step 1 - create a user and user tokenCopied!
Step 2 - collect authenticationsCopied!
Once the auth flow is completed a message will be sent to the window that opened the pop-up containing a UUID
This UUID is the authId and will be used when the connector call is made so that Tray can access the users credentials:
