Skip to main content

Astrato Enterprise Onboarding – Internal & Customer-Facing Analytics

This guide explains the recommended enterprise setup for securely delivering internal authoring and external embedded analytics from a single Astrato tenant.

Piers Batchelor avatar
Written by Piers Batchelor
Updated today

Two access patterns

1) Internal users (authors & admins)

Used for:

  • Creating and editing workbooks

  • Managing semantic models

  • Administration

Authentication

  • SSO via your Identity Provider (Azure AD, Okta, Ping, Keycloak, etc.)

  • Each user has their own Astrato identity and role

Identity federation (Snowflake example):
​https://help.astrato.io/en/articles/8930244-identity-federation-in-snowflake-using-external-oauth

User provisioning with SCIM (Azure Entra example):
​https://help.astrato.io/en/articles/8582420-enabling-multi-domain-scim-active-directory-for-astrato-with-azure-entra-example

Why

  • Governance and auditability

  • Clear role separation

  • Full platform access

2) Customer-facing analytics (embedded)

Used for:

  • Portals and products

  • Multi-tenant external users

  • Scalable OEM delivery

Authentication

Flow

  1. User logs into your application

  2. Your backend requests a web-ticket for that user

  3. The browser exchanges the ticket for an Astrato session

  4. The workbook loads inside an iframe

Session lifecycle

  • Web-ticket: ~60 seconds (one-time exchange)

  • Astrato session: ~1 hour (auto-renewed)

  • Switching tenant/org → mint a new ticket

This model isolates users without creating Astrato accounts for each one.

Fallback login page (unbranded OEM experience)

For customer-facing analytics you can provide a dedicated, unbranded Astrato login page.

This is useful when:

  • a user’s embedded session expires

  • a direct login is required before the web-ticket flow starts

  • you want to avoid exposing the standard Astrato UI

Users should access the following URL:

https://app.astrato.io/auth-login/sign-in?hideInfo=true

Row-level security and tenant isolation

Recommended: session-bound parameter

  • Pass org_id (or equivalent) in the web-ticket

  • Bound to the session and enforced server-side

  • Client-side tampering is ignored

Result

  • Every query is filtered to the correct tenant

  • Works with a single service account

  • Preserves existing RLS strategy

Alternative: database passthrough RLS

Handled in the data warehouse:

  • Requires users and roles in the warehouse

  • Reusable across multiple tools

  • Typically a later phase for writeback and advanced governance

Passthrough authentication documentation:
​https://help.astrato.io/en/articles/6360082-passthrough-authentication-snowflake

Data source authentication options

Snowflake external OAuth / identity federation:
​https://help.astrato.io/en/articles/8930244-identity-federation-in-snowflake-using-external-oauth

Google BigQuery OAuth / JWT:
​https://help.astrato.io/en/articles/6557470-connecting-to-google-bigquery-oauth-jwt

These approaches allow Astrato to:

  • Reuse existing identity and access policies

  • Enforce warehouse-level security

  • Avoid static credentials

Content access control

Control what users can see via web-ticket claims:

  • Pass groups or roles in the ticket

  • Map them to workbook collections and feature access

Guidance

  • Only create groups when content differs

  • Avoid one group per tenant unless required

Embedding model

Embedding and sharing documentation:
​https://help.astrato.io/en/articles/6117486-embedding-and-sharing-interactive-analytics

Publishing

  1. Build and publish a workbook once

  2. Use its stable embed link in your application

Updates to content do not require new embed URLs.

Domain allow‑listing (CSP)

Your host application domain must be added to the embed allow‑list.

Only approved parent frames can load Astrato content.

What you can embed

  • Entire workbook

  • Single sheet

  • Grouped objects

  • Individual visual

Context and interaction with the host application

URL parameters

  • Pre-filter content

  • Pass runtime context

postMessage API

  • Sync filters between application and dashboard

  • Trigger actions (reload, navigation, close full-screen)

Branding options

  • Theming inside Astrato

  • Full-screen embedded mode

  • Custom domain via reverse proxy (optional)

Implementation phases

Phase 1 – Proof of concept

  • Web-ticket authentication working

  • Tenant parameter enforced

  • Basic embed

Phase 2 – Governance setup

  • Groups and collections

  • Domain allow‑list

  • Role mapping

Phase 3 – Production rollout

  • Automated ticket minting

  • Branded experience (optional)

  • Operational monitoring

Operational checklist

Authentication

  • IdP configured for internal users

  • SCIM provisioning configured (optional but recommended)

  • Web-ticket endpoint in your backend

Security

  • Service account created

  • Tenant parameter enforced server-side

  • Embed domains allow‑listed

Data source

  • OAuth / External OAuth configured where supported

  • Warehouse roles aligned to Astrato access model

Content

  • Collection structure defined

  • Group mapping agreed

Embedding

  • Stable embed links used

  • Session renewal handled

When to use which model

Use case

Model

Internal analytics

SSO per user

Customer portal / product analytics

Web-ticket embedding

Warehouse-enforced RLS across tools

External OAuth / passthrough

Future writeback / advanced governance

Database passthrough RLS

Related documentation

Related Articles
Enabling multi-domain SCIM (Active Directory) for Astrato, with Azure Entra example
Create a custom Astrato Login page for your portal
Did this answer your question?