Secret Chest aims to be the most developer-friendly secret manager on the market. We provide access to our data objects in a variety of ways to help bake Secret Chest into apps, the most intricate devops workflows, stream our events to your favorite SEIM, and access any of our data on the fly. This includes an API-first mentality, full swagger documentation, postman collections, and of course, full webhook support. Because we do not consider webhooks secure, we do not use them for the payload of a secret (but we're happy to be convinced if you find a way to do so securely). We do make them available for the metadata about secrets, though.
Each tenant can have a number of webhooks. These are displayed in the main Webhooks screen, as follows.
Click the Add An Endpoint button to create a new webhook entry. The webhooks modal then shows a URL field and a number of events. The URL field accepts URLs as follows:
https://domain.tld/endpoint: used for a standard unauthenticated stream of events. Each is posted as a new json document.
https://domain.tld/endpoint1, https://domain.tld/endpoint2: used to stream events for a given type to two different URIs.
https://domain.tld/endpoint1:8088: used to define a path
Note: Other special characters or patterns will not pass form validation (although if you need any, please let us know).
Next, select boxes for each event that should be sent to that endpoint. This allows administrators to have a different URL (and if needed, token) for each endpoint. Use "Select all" for everything.
An example of a workflow would be to have a webhook listener just for IdP communications. The below shows a custom endpoint and just those two options.
Another example would be to just see sharing information, as follows. Notice that to remove any, simply click the x beside each that shouldn't be there.
Finally, let's go through what each of the supported webhooks does:
Select all: Enables all the webhooks to go to the single URL. This is going to be a lot of data, according to the size of a given tenant, so get ready for a firehose of information.
IdP settings updated: Sends json about what the Identity Provider (IdP) settings were configured to be. This should be rare, as once admins have an IdP setup, they rarely change it unless required to do so.
SCIM Updated: Each time the SCIM process runs, if a user is created or pruned, will include that information to the endpoint.
Secret Shared Began: Triggered when a user goes to a secret and initiates a standard share or group share. Includes the standard time information as well as who (or whom) the shared object was sent to and the sender.
Secret Share Completed: Triggered when a user accepts a share. Includes the standard time information as well as who the shared object was sent to and the sender.
Multi-User Secret Shared: Triggered when a user goes to a secret and initiates a multi-peer share. Includes the standard time information as well as who the shared object was sent to and the sender.
Multi-User Secret Shared Completed: Triggered when a user accepts a multi-peer share. Includes the standard time information as well as who (or which users if there are more than 1) the shared object was sent to and the original sender.
Secret Used: Triggered every time a secret is desharded. Includes the GUID of each device used and the shard map.
Secret Deleted: Triggered each time a secret is deleted. The json includes the GUID of each device used and the shard map.
User Created: Triggered each time a user is created. The json includes the user metadata.
User Deleted Triggered each time a user is removed from a tenant. The json includes the user metadata.
Group Created: Triggered each time a group is created. The json includes the group metadata, including members.
Group Deleted: Triggered each time a group is removed. The json includes the group metadata, including members.
Secret Created: Triggered each time a secret is created. The json includes the metadata from the shard map.
Get And Delete Temporarily Stored Secret: Tracks each time a secret is available in clear text (e.g. when it's used to autofill a form or provide a passkey to a web form).
Archive Backend Message: Allows tracking the backend Secret Chest queuing service by seeing when messages to objects are cleared.
Post Backend Message: Allows tracking the backend Secret Chest queuing service by exposing when messages to objects are substantiated.
Reject Pending Shared Secret: Triggered when a user chooses not to accept a shard that has been shared to them, whether via a multi-peer share or a standard share.
Accept Pending Shared Secret: Triggered when a user chooses to accept a shard that has been shared to them, whether via a multi-peer share or a standard share.
Pending Shared Secret: Triggered when a user chooses to share a shard but the request hasn't been fully processed.
Post Meta Data Of Personal Device: Triggered when a new device is added to Secret Chest. Includes the available metadata of a device (e.g. device type, OS, GUID, serial, if bluetooth is available, if APNs is enabled, if entitlements are present, etc).
Delete Installation Map: Triggered when a shard map is created from the backend, and a share has been processed.
Post Installation Map: Triggered when a shard map is removed from the backend, post-processing.
User Shards(POST): Triggered when shards are posted to the queue.
User Shards(DELETE): Triggered when shards are removed from the queue.
Test each webhook out and reach out to support should there be something desired or any information in the json that isn't there.