In the previous article we discussed authentication settings that are required when some of the modeling elements in Questetra send HTTP requests to external services. This article explains the scope of authentication sharing and the various options that are available when creating HTTP authorization settings.
We explained how to configure authorization settings here.
As of V15.1, there are four types of authorization settings:
- OAuth2
- OAuth2 Client Credentials
- Token Fixed Value
- Basic Authentication
Each of these types can have shared settings created for use over multiple apps.
Available Scopes for Shared Authorization Settings
There are three scopes for authorization settings:
- Workflow app specific settings
- Settings shared by all workflow apps
- Settings associated with the users
When using Settings associated with the users, an App Administrator can use the settings associated with their profile to obtain tokens for each external service. These settings can then be referred to by other App Administrators who are using built-in auto-steps to connect to the respective external service, provided that the user who originally obtained the token is also an App Administrator of the App which is referring to their user-associated settings.
“Types” refers the method of authentication used when connecting with external services.
Workflow app specific settings
This setting can be used for:
- Throwing Message Intermediate Event (HTTP)
- Script Tasks
- Some Add-on Auto steps
- Built-in Auto steps that connect with external cloud services
It can be created/edited from:
- The ▼App Menu
- Throwing Message Intermediate Event (HTTP)
- Some Add-on Auto steps
- [Set up Settings] in the properties screen of:
- Throwing Message Intermediate Event (HTTP)
- Some Add-on Auto steps
- Built-in Auto steps that connect with external cloud services
These are authorization settings for which the scope is restricted to only the app currently being edited. Settings can apply to multiple steps within the app, but not other apps that use the same auto step.
It is possible for App Administrators to edit these kinds of setting, even if they were not the one who created it.
Settings shared by all workflow apps
This setting can be used for:
- Throwing Message Intermediate Event (HTTP)
- Script Tasks
- Some Add-on Auto steps
- Built-in Auto steps that connect with external cloud services
It can be created/edited from:
- The ▼App Menu
- Throwing Message Intermediate Event (HTTP)
- Some Add-on Auto steps
- [Set up Settings] in the properties screen of:
- Throwing Message Intermediate Event (HTTP)
- Some Add-on Auto steps
- Built-in Auto steps that connect with external cloud services
These are settings that can be used across multiple apps, but they are only applicable to a particular service/API. For example, it is possible to configure settings that provide authorization for all Box auto steps on a platform, which can be used for any app which includes an auto step that connects to Box. However, in order to connect to a service such as, for example, Slack, it is necessary to configure another setting for that service.
As with Workflow app specific settings, System Administrators may edit these kinds of setting, even if they were not the one who created it.
Settings associated with the users
This setting is only valid for:
- Built-in Auto steps that connect with external cloud services
- Steps which use an OAuth2 authentication type
This can be created from an app where the user is an App Administrator. When the App Modeler is in edit mode, you can access the HTTP Authorization settings by opening the properties window of a relevant auto-step and clicking on the “Set up Setting” button. The app editor’s name will be listed in the User column, and you can obtain a token from the linked service by clicking [Get Token] next to your own user name on the HTTP Authentication Settings screen.
Once the user has obtained a token for their profile, their user-associated authorization setting will become visible across all apps that use the specified auto-step for which the token was obtained where the user is also an App Administrator. Prior to obtaining a token the setting will only be visible to the user themselves, and will not function as authorization. Other App Administrators may also use the User-specific setting associated with another user, provided that the user who created the setting also remains as an App Administrator on the app utilising the authorization setting.
This setting can be used for multiple different services, and it is necessary to obtain a token for each service to which the user’s setting connects. In this way it is possible to use just one setting for all built-in auto steps, provided that the relevant token has been obtained.
Requirements for Shared Settings
Same Authorization Type
In order for an authorization setting to be usable by multiple apps, it is necessary for the auto-steps used to require the same authorization type.
For example, shared settings that are configured for OAuth2 will not be available for use by an auto-step that requires Basic Authentication. The method of authorization used will depend on the auto-step; some require OAuth2 to be used, while others can use any of the methods listed above.
This means that for modeling elements that are used multiple times across different apps on your workflow platform, it will only be necessary to create one shared authorization setting for all auto-steps of the same type, rather than configuring authorization for that element in each app. This will reduce the time required for building new apps, as app administrators can use existing authorization settings instead of having to set them up themselves each time an auto-step that requires HTTP authorization is used.
Services with Multiple APIs
Please note that certain services have APIs that are specific to that service. So for example, while [Gmail: Get Email Message] and [Google BigQuery: Insert New Data] both connect to Google services, they connect to different APIs. Therefore, it is not possible to use a shared setting configured for the Google BigQuery API as authorization for the Gmail API.
Pingback: Understanding HTTP Authorization Settings – Questetra Support