Plan deployment

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

  • Make sure the app has access to Mosaic 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 .
How it works

To issue recommendations on whether a device is trusted or malicious, Mosaic Detection and Response services rely on the client-side SDK for collecting security data. By default, the telemetry data is sent to Mosaic servers directly—such calls can be blocked by privacy and ad-block tools. As a workaround, consider routing requests through your domain.

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 Mosaic 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 Mosaic for privacy and security reasons. Unlike third-party integration, first-party integrations imply that all communication occurs within your domain.

Delegated subdomain

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

Consider:

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

Subdomain with proxying

This first-party integration suggests you forward traffic to Mosaic through a dedicated subdomain (e.g., 'risk.acme.com'). Mosaic doesn't need to be in charge of this subdomain. For Mosaic 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 Mosaic 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 Mosaic.

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.