Security and permissions

This page explains the security model behind Icon Map for Fabric — how identity, permissions, and data storage work. It's written for anyone carrying out a security review.

Looking for the step-by-step admin setup (tenant settings, admin consent, service-principal grants)? See the Onboarding & Setup section.

The guiding principle is that Icon Map works on your data, in your tenant: it reads your data in place, acts under the identity of the signed-in user, and stores anything it writes in your own OneLake.

Identity model

Authoring and reading a map (inside Fabric). The Icon Map editor and viewer run inside the Fabric experience and act as the signed-in user using their Microsoft Entra identity. Reads of OneLake files (such as tile and imagery files) use a short-lived, user-delegated SAS obtained on the user's behalf — so a user only ever sees data they are already permitted to access. Power BI semantic model sources are queried through the model, which enforces the model's measures, relationships, and row-level security.

Because Icon Map inherits Fabric permissions, no separate access system is introduced for normal authoring and viewing — your existing workspace roles and OneLake permissions govern who can see what.

Permissions for authoring

To build maps, a user needs:

  • Access to the workspace containing the Icon Map item (Contributor or higher to create and edit items; Viewer to open in reading view).
  • Read access to the data they connect to — the Lakehouse, Warehouse/SQL, semantic model, Eventhouse/KQL database, or file — under their own identity.
  • For an Organizational Catalog, OneLake permissions on the catalog's repository folder, which govern who can use its layers.

No elevated or service credentials are required for a user to author or read a map. So that authoring works without repeated consent prompts, an administrator grants tenant-wide admin consent to the Icon Map app — this pre-approves the delegated permissions but grants no standalone access to your data.

Embedding outside Fabric: two modes

A map can be shown outside Fabric in two ways, and their security models differ.

User-owns-data (embedding in your own application). Every viewer signs in with their own Microsoft Entra identity and the map reads the item, its OneLake files and its live queries as that viewer. There is no publish step, no copy of your data and no service principal at all. Because the reads are the viewer's own, your native Fabric and Power BI row-level security applies per viewer automatically, and a viewer can never see anything their Fabric permissions do not already allow. Use this for internal portals and line-of-business applications. See Embedding for your organization.

Published maps. For audiences with no Fabric access at all, an author publishes a map and the public embedded viewer serves it. This is the mode described in the rest of this section.

Publishing and the viewer identity

Publishing a map for viewing outside Fabric is the one case where a non-user identity is involved: the public embedded viewer reads the frozen, published files from your OneLake using a dedicated, read-only embed service principal. It is a separate Microsoft Entra application from the workload, authenticates with a certificate held in Azure Key Vault, and requests no API permissions. Its only access is a read-only OneLake data-access role on the Lakehouse that holds your published maps — granted automatically at publish, under the author's own identity, never workspace Contributor. Enterprises can supply their own service principal for this read instead. The setup is covered in Set up publishing. Key security properties:

  • A publish grants no more than its author has. At publish time the service verifies, under the author's own identity, that the author can reach every data source, file and item the map references, and refuses the publish otherwise. Publishing therefore cannot be used to expose data the author could not already open.
  • Tamper-evident published maps. Published instructions are cryptographically signed and the signature is verified on every read; a published map altered after publishing is refused rather than served.
  • Snapshot vs live. A snapshot publish freezes data at publish time; a live publish runs the map's pinned queries on each load, with server-validated parameters and a daily query budget (default 500 fresh queries/day, 50,000 rows/query) you can lower.
  • Row-level security for viewers. Within published maps, per-viewer RLS is available only with signed embed tokens, where token claims map to declared, server-validated filter parameters. Anonymous published links cannot apply per-viewer RLS — publish only data you're content to share with everyone who has the link. If you need your existing Fabric RLS to apply per viewer, use the user-owns-data mode above instead, where it applies natively because each viewer reads as themselves.
  • Allowed origins. Token-gated embeds must declare which sites may host them (wildcard subdomains supported), enforced in the browser via Content-Security-Policy; embed tokens last at most four hours.
  • No credentials to viewers. Keys for keyed map services are removed from published content at publish time, kept in your OneLake, and attached server-side when tiles are relayed; and the browser-facing form of a map omits query text, table/file names, column lists and connection details.
  • Revocation. Any published link can be revoked at any time from Publish management; revocation takes effect within 30 seconds.
  • Organization-wide off switch. Embedded publishing can be disabled for your tenant, or for individual workspaces: the Publish action is removed from the editor and the embed service refuses to serve the affected maps, including ones published before the change.
  • Read-only, scoped identity. The embed service principal has no write access to your workspace — only a read-only data-access role on the publishing Lakehouse. Large raster tilesets are read in place from their own Lakehouse (so they stay live), covered by the same read-only role.
  • What's stored where. Published files live in your OneLake, in a Lakehouse (IconMap Published) in your workspace, under Files/_published/<publish-id>/ (a signed manifest.json of styling/config with no secrets or connection strings, a data.json snapshot, and assets). Icon Map does not copy or cache your map data on its own servers.

Source credentials

For sources that need credentials (for example, an authenticated WMS service or a GTFS feed), the saved credentials are stored in the map item's own OneLake folder, protected by workspace roles, and attached server-side when the source is fetched — they are not stored in the layer's configuration.

Write-back permissions

Write-back — letting viewers add or edit the data behind a map — writes to files in your OneLake (the map's annotations store, or a layer's GeoJSON/CSV file) as the signed-in user. It is gated on the user's Fabric Write permission on the item, so it's available to users with write access even when they're in reading view. In this preview, anonymous published/embedded viewers cannot write back.

Next steps