Plan deployment

While getting ready to roll out your application that leverages Transmit Detection and Response services, consider the following pre-deployment steps:

• Make sure the app has access to Transmit services by allowlisting the following hosts in your firewall: *.riskid.security , *.transmitsecurity.io .
• Determine what domain should be configured in the web application. Depending on your security guidelines and deployment type, decide on the integration to use. It is recommended to choose third-party integration for test and POC deployments and first-party integration for production deployments .

Test and POC deployments

In a basic implementation that is recommended for testing and POC deployments, a user's device calls your app APIs (e.g., 'app.acme.com') while communicating directly with Transmit Detection and Response services SDK (https://api.transmitsecurity.io/risk-collect) at the same time. Such implementation is called third-party integration because the user's device interacts with other services outside your domain.

Consider:

• Benefits : The implementation is simple since it does not require any changes to your DNS or domain, configuring certificates and network.
• Caveats : Take into account that third-party DNS lookups are often evaluated and blocked by privacy and ad-block tools and which can interfere with the risk detection and response flows.

Production deployments

In production environments, you would typically try to refrain from sharing data with external services such as Transmit for privacy and security reasons. Unlike third-party integration, first-party integrations imply that all communication occurs within your domain.

• Option 1: Delegated subdomain
• Option 2: Subdomain with proxying
• Option 3: URI path with proxying

Delegated subdomain

For Transmit to access the data, set up a dedicated subdomain (e.g., 'risk.acme.com') and delegate its management to Transmit. The subdomain will be served by Transmit's name servers. In the diagram below, 'app.acme.com' is your domain, 'risk.acme.com' is a subdomain managed by Transmit.

Consider:

• Benefits : The implementation is fairly simple as it only requires assigning a subdomain to Transmit and providing the TLS certificate. There is no need to update CNAME records or redirect traffic to Transmit.
• Caveats : You must issue the TLS certificate for Transmit.

Subdomain with proxying

This first-party integration suggests you forward traffic to Transmit through a dedicated subdomain (e.g., 'risk.acme.com'). Transmit doesn't need to be in charge of this subdomain. For Transmit to access the data and identify the device, forward Detection and Response SDK calls through this subdomain as a proxy. From the frontend perspective, the data isn't shared with external services while Transmit can still access it and create recommendations based on the device fingerprint. In the diagram below, 'app.acme.com' is your domain and 'risk.acme.com' is a proxy subdomain managed by your product.

Consider:

• Benefits : Ability to control your app domain and forward traffic via a load balancer.
• Caveats : You have to handle data before routing it to Transmit.

URI path with proxying

This first-party integration suggests you forward Detection and Response SDK calls through a path-based proxy meaning you have to create a URI path (e.g., 'app.acme.com/risk') within your domain and configure the load balancer to work as a proxy. In the diagram below, 'app.acme.com' is your domain, 'app.acme.com/risk' is a proxy URI path managed by your product.

Consider:

• Benefits : The most seamless integration. Enables you to leverage an existing DNS record and data routing. The only changes being made are affecting a load balancer or CDN.
• Caveats : You have to inspect the path and handle it in the network.