App Development Best Practices

When developing custom BigID Applications, following best practices ensures that your app is secure, scalable, and behaves correctly across both BigID Cloud (multi-tenant) and On-Premise environments.

Avoid Duplicating Settings

If a configuration setting or preference already exists within the core BigID platform, do not recreate a redundant option within your custom application’s UI.

Instead, your application should utilize the BigID API to seamlessly retrieve the existing configuration. This guarantees a single source of truth for administrators and prevents conflicting states between the platform and your app.

Utilize Native TPA Storage

Do not stand up your own database or establish direct external database connections for your application state unless absolutely necessary.

BigID provides native TPA (Third Party App) Storage specifically designed for custom applications. Relying on TPA storage ensures that:

• Your application natively inherits BigID’s secure, multi-tenant isolation out of the box.
• Your application will function identically whether deployed in a BigID Cloud environment or within an On-Premise customer installation.
• You avoid the overhead of managing, scaling, and securing an external database connection.

You can interact with TPA storage directly through the BigID API using your App’s token credentials.

Secure Endpoint Validation

Because your custom application is an independent web service receiving POST requests from the BigID core, it is critical that your application validates that these requests are legitimately originating from BigID.

• Always parse and validate the X-Signed-Token header sent with action executions.
• Always fetch the public key from the BigID api/v1/tpa/public-key endpoint to cryptographically verify the signature payload.
• Ensure the exp (expiration) field within the signature payload is checked to prevent replay attacks using expired tokens.

Build for Asynchronous Execution

When designing your app’s actions, assume that tasks might take a significant amount of time to process, especially when dealing with large datasets or complex remediation workflows.

• Design actions to run asynchronously whenever possible. Avoid blocking the initial HTTP request with long-running operations.
• Instead, your /execute endpoint should immediately acknowledge the request and return an IN_PROGRESS status response.
• Once your application completes the background processing, utilize the updateResultCallback URL provided in the initial execution payload to send the final SUCCESS or ERROR status back to BigID.

Stateless Design

Your BigID Application should be designed as a stateless microservice.

• Avoid storing session state or long-running execution context directly in memory on your application server.
• If your app crashes or scales horizontally across multiple instances, it should be able to pick up work or serve UI components without relying on local server state.
• Rely on the payload parameters sent by BigID on each request, and use TPA Storage for any necessary persistent configuration.