Skip to content

Azure Synapse Analytics Access Pattern

Audience: System Administrators

Content Summary: This page describes the Dynamic Azure Synapse Analytics access pattern, through which Immuta applies policies directly in Azure Synapse Analytics.

For a tutorial on configuring Azure Synapse Analytics see the App Settings page.

Overview

The Dynamic Azure Synapse Analytics access pattern allows Immuta to apply policies directly in Azure Synapse Analytics dedicated SQL pools without the need for users to go through the Immuta Query Engine. Users can work within their existing Synapse Studio and have per-user policies dynamically applied at query time.

Data Flow

  1. An Immuta Application Administrator configures the Synapse integration, registering their initial Synapse Dedicated SQL pool with Immuta.
  2. Immuta creates Immuta schemas inside the configured Synapse Dedicated SQL pool.
  3. A Data Owner registers Synapse tables in Immuta as data sources. A Data Owner, Data Governor, or Administrator creates or changes a policy or user in Immuta.
  4. Data source metadata, tags, user metadata, and policy definitions are stored in Immuta's Metadata Database.
  5. The Immuta Web Service calls a stored procedure that modifies the user entitlements or policies and updates data source view definitions as necessary.
  6. A Synapse user who is subscribed to the data source in Immuta queries the corresponding data source view in Synapse and sees policy-enforced data.

Synapse Integration

View Generation

Data sources are represented by views; because they are under one schema instead of a database, their view name will be a combination of their schema and table name, separated by an underscore.

Example: With a configuration that uses IMMUTA as the native schema in the database dedicated_pool, the view name for the data source dedicated_pool.tpc.case would be dedicated_pool.IMMUTA.tpc_case.

You can see the view information from the data source health check.

Azure Synapse Analytics View

Syncing and Policy Enforcement

This access pattern leverages webhooks to keep the views up-to-date with the corresponding Immuta data sources. When a data source or policy is created, updated, or disabled, a webhook will be called that will create, modify, or delete the dynamic view. Note that only standard views are available because Azure Synapse Analytics dedicated SQL pools do not support secure views.

The immuta_system.user_profile view uses the constraint UPPER(immuta__userid) = UPPER(SYSTEM_USER) to ensure only the profile of the current user is returned.

Configuring

The native integration will create views from the tables contained within the database specified upon configuration. Then, the user can configure the schema name where all the Immuta generated views will reside. Immuta will also create the schemas immuta_system, immuta_functions, and immuta_procedures to contain the tables, views, UDFs, and stored procedures that support the native integration.

Since Azure Synapse Analytics dedicated SQL pools do not support array or hash objects, certain user access information is stored as delimited strings; those delimiters can be modified to ensure they do not conflict with possible characters in strings.

For a full tutorial on configuring Azure Synapse Analytics see the App Settings page.

Multiple Azure Synapse Analytics Instances

A user can configure multiple native Azure Synapse Analytics integrations, which give users direct access to views in a Dedicated SQL Pool in Synapse Studio.

Limitations

  • Immuta does not support the following masking types in this native access pattern because of limitations with dedicated SQL pools. Any column assigned one of these masking types will be masked to NULL:

    • Reversible masking
    • Format Preserving Masking
    • Regex
  • The delimiters configured when enabling the native integration cannot be changed once they are set. To change the delimiters, the native integration has to be disabled and re-enabled.

  • If the generated view name is more than 128 characters, then the view name is shortened to 128 characters. This could cause collisions between view names if the shortened version is the same for two different data sources.

  • For proper updates, the dedicated SQL pools have to be running when changes are made to users or data sources in Immuta.