Delegated and application access

Server-side Rayfin code reaches three kinds of data: entities your app owns, data that already lives in Fabric (through connectors), and other Microsoft resources (through function connections). Every one of those calls runs as one of two identities:

• Delegated — the signed-in user. Rayfin starts from the user's Microsoft Entra ID session (Fabric SSO, direct Entra token sign-in, or an embed host) and acts on that user's behalf. The source decides what that user may read and write.
• Application — the app itself. For current Fabric apps, the app identity is the owner of the Fabric app item. Every user of the app gets the same access, so the app identity — not each user — needs permission on the source.

Changed in 1.36

Rayfin 1.36 moved two surfaces to the app identity. Function connections now run only as the app identity, and rayfin connector add configures SQL connectors to run as the app identity. In 1.35, both ran as the signed-in user.

Which identity each surface uses

Your own data always runs as the caller

Entities in rayfin/data/ are protected by permission decorators. A policy callback compares the caller's claims to fields on each row, so client.data.<Entity> returns only the rows that caller may see.

The same is true inside a function. ctx.getDataClient() uses the invocation's Rayfin token, so entity policies apply to the user who invoked the function. Setting services.functions.auth.type: application does not switch your Rayfin data to the app identity.

Function connections run as the app

Since Rayfin 1.36, enabled Functions must declare application authentication:

services:
  functions:
    enabled: true
    auth:
      type: application

A deployed function that declares an audience on its RayfinContext receives a token for the app identity in ctx.Tokens. In this function, the Rayfin data query runs as the caller, and the Fabric REST call runs as the app:

import {
  AudienceType,
  UserDataFunctions,
  type RayfinContext,
} from '@microsoft/fabric-user-data-functions';

export type AppSchema = {
  Todo: { id: string; title: string };
};

const udf = new UserDataFunctions();

udf.func(
  'todoCountAndWorkspaceCount',
  async (
    ctx: RayfinContext<AppSchema, AudienceType.Fabric>,
  ): Promise<{ todos: number; workspaces: number }> => {
    // Runs as the signed-in caller: the Todo entity's policies apply.
    const todos = await ctx.getDataClient().Todo.select(['id']).execute();

    // Runs as the app identity: it must have access in Fabric.
    const response = await fetch('https://api.fabric.microsoft.com/v1/workspaces', {
      headers: { Authorization: `Bearer ${ctx.Tokens.Fabric}` },
    });
    if (!response.ok) {
      throw new Error(`Fabric API returned ${response.status}`);
    }
    const body = (await response.json()) as { value: unknown[] };

    return { todos: todos.length, workspaces: body.value.length };
  },
  [],
);

Grant the app identity the permission each resource needs — for example a workspace role for Fabric REST calls, or a data-plane role for Azure Storage — and check that the Fabric API you call supports application identities. Connections lists the five supported audiences and what to grant for each.

Signing in to the app and being allowed to invoke a function work as before; application authentication only changes which identity the function uses for external resources.

Connectors choose per connector

Each connector entry in rayfin.yml carries its own auth.type:

• delegated runs every query as the signed-in user, through an on-behalf-of token exchange. The user needs their own permission on the Fabric workspace and item, and @role() policies on generated connector entities can compare claims to the caller.
• application runs every query as the app identity. All users see the same data, so claims-based policies no longer distinguish users. It is allowed only for fabric-sqlanalytics, fabric-warehouse, and fabric-sqldatabase.

rayfin connector add writes auth.type: application for those three SQL types. To keep per-user access, change the value to delegated before you deploy — and again after you re-add the connector, because re-adding resets it. Semantic model connectors accept only delegated. See Connector authentication.

Grant access at the source

Neither identity grants access by itself. Rayfin passes the identity through, and the target resource decides:

1. For delegated calls, give each user — or a group they belong to — access to the Fabric workspace and item. A user without access gets an authorization error.
2. For application calls, give the app identity — the owner of the Fabric app item — access to the resource.
3. For your own entities, write permission decorators. No source grant is involved.

Choose a surface