Plan deployment

While getting ready to roll out your Mosaic integration, determine how you are going to handle communication with Mosaic. Depending on your security guidelines and requirements, decide on the deployment setup to use.

Third-party integration

In a basic implementation, a user's device calls your app APIs (e.g., 'app.acme.com') while communicating directly with Mosaic (https://api.transmitsecurity.io/) 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 Mosaic flows.

First-party integration

In production environments, the best practice is to try to avoid redirecting to external services, such as Mosaic, for privacy, usability, and security reasons. Unlike third-party integration, first-party integrations imply that all communication occurs within your domain. From the user's perspective, the app never leaves its domain, but under the hood it remains fully integrated with Mosaic through APIs and SDK calls.

• Option 1: CName mapping
• Option 2: CName proxying
• Option 3: Path proxying

CName mapping

In this first-party integration, Mosaic traffic is passed through the dedicated subdomain. For Mosaic to operate properly, create a CNAME record at the DNS level that points to Mosaic.

In the diagram below, 'app.acme.com' is your main subdomain, 'mosaic.acme.com' is a CNAME record that points to Mosaic ('api.transmitsecurity.io'). Whenever a user's device needs to send data to Mosaic, DNS lookup resolves the 'mosaic.acme.com' CNAME to Mosaic.

Consider:

• Benefits : The implementation is fairly simple. It requires providing the TLS certificate to Mosaic and changing the DNS record on your side.
• Caveats : You have to take care of TLS certificates, including generating new certificates and replacing expired certificates. Alternatively, you can leverage ACME challenge and DCV delegation to automate certificate renewals.

CName proxying

This first-party integration suggests to proxy traffic to Mosaic through a dedicated subdomain. For Mosaic to operate properly, forward Mosaic client-side SDK calls and API calls through this subdomain as a proxy.

In the diagram below, 'app.acme.com' is your main subdomain and 'mosaic.acme.com' is a subdomain managed by your product and proxied to Mosaic ('api.transmitsecurity.io').

Consider:

• Benefits : Ability to control your app subdomains and forward traffic via a load balancer, CDN, reverse proxy, etc.
• Caveats : CNAME proxying can introduce additional charges for cloud computing services.

Path proxying

This first-party integration suggests you forward Mosaic client-side SDK and API calls through a path-based proxy. This includes creating a URI path within your domain and configuring the load balancer, CDN, reverse proxy, application layer, etc., to work as a proxy.

In the diagram below, 'app.acme.com' is your main subdomain, 'app.acme.com/mosaic' is a URI path managed by your product and proxied to Mosaic.

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, CDN, reverse proxy, etc.
• Caveats : You have to handle data before routing it to Mosaic.