Definiera databehörigheter

Fabric Apps använder @role dekoratör för att ansluta auktoriseringsregler direkt till dina datamodeller. Behörigheter är typsäkra, refaktorvänliga och kompileras automatiskt till den underliggande dataåtkomstkonfigurationen.

Innan du börjar

• Förstå skillnaden mellan autentisering (vem du är) och auktorisering (vad du kan göra)
• Granska Konfigurera autentisering för att konfigurera identitetsverifiering
• Förstå översikten över datamodeller för entitetsgrunder

Inbyggda roller

Fabric Apps identifierar den inbyggda rollen authenticated. Du kan också definiera anpassade roller i dina principer när det behövs.

Dekoratören @role

Använd @role på klassnivå för att styra vilka roller som kan utföra vilka åtgärder på en entitet:

@role(roleName, actions, options?)

Parameters

Grundläggande exempel

Begränsa autentiserade användare till sina egna data:

import { entity, role, uuid, text } from '@microsoft/rayfin-core';

@entity()
@role('authenticated', ['create', 'read', 'update', 'delete'], {
  policy: (claims, item) => claims.sub.eq(item.userId),
})
export class Todo {
  @uuid() id!: string;
  @text() title!: string;
  @text({ optional: true }) description?: string;
  @text() userId!: string;
}

I det här exemplet:

• Autentiserade användare kan endast komma åt Todo-objekt där userId matchar deras JWT-anspråk sub .

Typsäkra principuttryck

Återanropet policy ger skriven åtkomst till både anspråk och entitetsfält. TypeScript härleder entitetstypen från den dekorerade klassen, vilket ger dig automatisk komplettering och refaktorsäkerhet:

policy: (claims, item) => claims.sub.eq(item.userId)

Anspråk som stöds

Uttrycksoperatorer

Logiska operatorer

Kombinera uttryck med .and() och .or():

// User must own the item AND item must be active
@role('authenticated', 'read', {
  policy: (claims, item) =>
    claims.sub.eq(item.userId).and(item.isActive.eq(true))
})

// User is admin OR user owns the item
@role('authenticated', ['update', 'delete'], {
  policy: (claims, item) =>
    claims.role.eq('admin').or(claims.sub.eq(item.ownerId))
})

Båda sidor parenteseras automatiskt för korrekt gruppering.

Behörigheter på fältnivå

Ange de fält som en roll kan komma åt med hjälp av include eller exclude i rollalternativen.

Inkludera specifika fält

Tillåt endast fältet title under skapandeåtgärder:

@entity()
@role('authenticated', 'create', {
  policy: (claims, item) => claims.sub.eq(item.createdBy),
  include: ['title'],
})
export class Document {
  @uuid() id!: string;
  @text() title!: string;
  @text({ optional: true }) content?: string;
  @text() createdBy!: string;
}

Exkludera specifika fält

Dölj känsliga fält från läsåtgärder:

@entity()
@role('authenticated', 'read', {
  exclude: ['lastLogin', 'passwordHash'],
})
export class User {
  @uuid() id!: string;
  @text() email!: string;
  @date({ optional: true }) lastLogin?: Date;
  @text() passwordHash!: string;
}

Åtgärdsspecifika behörigheter

Tillämpa olika regler per åtgärd med flera @role dekoratörer:

@entity()
@role('authenticated', 'create', {
  policy: (claims, item) => claims.sub.eq(item.createdBy),
  include: ['title', 'content'],
})
@role('authenticated', 'read', {
  policy: (claims, item) => claims.sub.eq(item.createdBy),
})
@role('authenticated', 'update', {
  policy: (claims, item) => claims.sub.eq(item.createdBy),
  exclude: ['adminNotes'],
})
@role('authenticated', 'delete', {
  policy: (claims, item) => claims.sub.eq(item.createdBy),
})
export class SecureDocument {
  @uuid() id!: string;
  @text() title!: string;
  @text({ optional: true }) content?: string;
  @text({ optional: true }) adminNotes?: string;
  @text() createdBy!: string;
}

Den här konfigurationen:

• Skapa: Endast skaparen kan skapa och endast titlecontent fält tillåts.
• Läs: Endast skaparen kan läsa sina egna dokument.
• Uppdatering: Endast skaparen kan uppdatera, men de kan inte ändra adminNotes.
• Ta bort: Endast skaparen kan ta bort.

Så här fungerar behörigheter

• Metadatainsamling: Dekoratören @role samlar in behörighetsmetadata när klassen har definierats.
• Schemagenerering: När du kör db applyläser CLI metadata och genererar behörighetskonfiguration.
• Principkompilering: TypeScript-principåteranrop kompileras till principuttryck för dataåtkomst (till exempel @claims.sub eq @item.userId).
• Körningsframtvingande: Dataåtkomstlagret tillämpar behörigheter för varje API-begäran.
• Konfliktidentifiering: Flera @role dekoratörer i samma klass aggregeras per roll, med varningar för motstridiga deklarationer.

Vanliga mönster

Åtkomst endast till ägare

@entity()
@role('authenticated', '*', {
  policy: (claims, item) => claims.sub.eq(item.ownerId)
})
export class PrivateNote {
  @uuid() id!: string;
  @text() ownerId!: string;
  @text() content!: string;
}

Fullständig åtkomst för autentiserade användare

@entity()
@role('authenticated', '*')
export class BlogPost {
  @uuid() id!: string;
  @text() title!: string;
  @text() content!: string;
}

Administratörsåsidosättning

@entity()
@role('authenticated', ['create', 'read', 'update'], {
  policy: (claims, item) =>
    claims.role.eq('admin').or(claims.sub.eq(item.ownerId))
})
@role('authenticated', 'delete', {
  policy: (claims, _item) => claims.role.eq('admin')
})
export class ManagedResource {
  @uuid() id!: string;
  @text() ownerId!: string;
  @text() name!: string;
}

Administratörer kan ändra valfri resurs, men endast administratörer kan ta bort.

Nästa steg

• Konfigurera autentisering för att konfigurera identitetsprovidrar
• Fråga data med GraphQL för att testa frågor som skyddas av behörigheter
• CLI-kommandoreferens för schemagenereringskommandon