Credential Manager
- Danny Hannah
- Arunima Kurup Prasad
Platform URL | https://[enterprise]/v2/enterprise/credential-manager?page%251=1&itemsPerPage%251=10 |
|---|---|
Epic | https://convertr.atlassian.net/browse/CON-4535 https://convertr.atlassian.net/browse/CON-6116 https://convertr.atlassian.net/browse/CON-5716 https://convertr.atlassian.net/browse/DAS-1025 https://convertr.atlassian.net/browse/CON-4475 |
API Endpoints | Load All Credential Details
Add credentials for ConnectedApp type Retrieve all connectedApp types
Edit Credentials for ConnectedApp type
Add credentials for Processr Job type Retrieve all processr jobs requiring credentials
Edit Credentials for Processr Job type
Delete Credentials (ConnectedApp and Processr Job types)
|
Document status | FOR REVIEW |
Document owner | @Danny Hannah @Adam Carter |
Technical writers | @Arunima Kurup Prasad @Danny Hannah |
Related Content | Processr Jobs |
Feature Overview
The Credential Manager is a feature which will allow users to manage all their credentials for Connected Apps and Processr Jobs from a central place by abstracting client secrets required for API access in Processr Jobs and Connected Apps.
The Credential Manager is available in the Enterprise section, which is only accessible to Admin and Super Admin users.
From this interface you can Add, Edit and Delete credentials for ConnectedApp types and Processr jobs.
Name | Required | Notes |
|---|---|---|
Name |
| A label for the entry. |
Type |
|
|
Entity |
| Related entity to the type |
When adding a Processr Job type to the Credential Manager, the entity will show a list of supported processr jobs to associate the credentials to, as shown below.
When adding a ConnectedApp type to the Credential Manager, the entity will show a list of ConnectedApps to associate the credentials to, as shown below.
Once the ConnectedApp is selected, the user must enter the corresponding values for Client ID, Client Secret and API URL.
Name | Required | Notes |
Client ID |
| API client Id for third party system |
Client Secret |
| API Client Secret for third party system |
API URL | Connection URL |
These credentials will then be stored behind the scenes using the AWS Credential Manager, and in the Convertr system we will store the ID related to the record in AWS SM, never storing the client secret in Convertr.
When editing an entry for the Credential Manager, the same fields will be available as adding, however the Client Secret is not pre-populated with the previous value - this is intentional as we do not want to surface the secret to other admin users, therefore you will need to re-enter the secret if you want to update anything on the entry, or enter a new client secret.
Using Saved Credentials
Now you have created entries into your Credential Manager, you can reference them in your Processr Jobs. Navigate to a campaign and then to the Processr > Integrations tab. Add one of the support jobs which you have added credentials for earlier.
You will now notice a “credential_source” option in the config. For supported jobs you will now have two options here, by default it will offer the Credential Manager, however you can change to “Manual” which will allow for you to configure the client_id and client_secret as previous.
When Credential Manager is selected from the source, you will now see a list of manager_credentials that are linked to this Processr Job. Choose the relevant one and save the config. The integration should work as if you had manually configured the client_id and client_secret.
Objectives
The objectives are to:
Centralise credentials which are reused across campaigns, in order to update and rotate them in a single place rather than manually in each campaign
Add a permissions barrier to stop lower level users such as Creative Managers or Agency users who often set up campaigns, to not see sensitive client credentials to client systems
Ensure credentials are stored securely outside of Convertr incase of security compromise
Summary
Functionality | User Story | |
|---|---|---|
| 1 | Credentials stored securely | Convertr uses AWS Secret Manager which uses AES256 encryption so that Credentials are securely stored using strong encryption. |
| 2 | Ability to store credentials globally and reuse them on both Connected Apps and Processr Jobs | As an Admin user, all my integration and connected app credentials are stored centrally, allowing for them to be reused on multiple configurations so that I can rotate and change the credentials for multiple campaigns in a single location. |
| 3 | Only Admin & Super Admin users able to change the credentials | As an Admin user, I expect to own the authorisation layer whilst allowing lesser users to continue to handle campaign setup but not have access to the secrets which act as the keys to my third party systems. To handle this, Credential Manager lives in the Enterprise Section of the system which is only accessible to Admin and Super Admin users. For Agency and Creative Managers who do the campaign setup, the users will only be able to choose from a dropdown of credential options, and not see the credentials themselves. |
| 4 | All integrations and connected apps are configurable with the Credential Manager | As a user, I expect that all connected apps and processr jobs would work in a standardised way. |
| 5 | Editing does not surface the secret | For security reasons we never show the client secret. As a user, if I edit a Credential Manager entry the client secret will be empty and will need to be re-entered in order for the record to be updated. |
Open Questions
Question | Answer | Date Answered |
|---|---|---|
Should we allow for other users types to have optional access to the Credential Manager if we force it upon all enterprises? We wouldn’t want users to be granted Admin rights in order to just to benefit from the CM. Perhaps adding in a grant type for certain core features should exist on a User level. I.e. Agency user + Credential Manager grant. |
| |
Should we mandate use of Credential Manager? |
|
|
Should we rotate encryption keys within AWS? |
|
|
User Permissions
Only Admin and Super Admin users have access to the Enterprise section of the platform.