Definer datatillatelser

Fabric Apps bruker @role decorator for å knytte autorisasjonsregler direkte til datamodellene dine. Tillatelser er type-sikre, refaktorer-vennlige, og automatisk kompilert inn i den underliggende datatilgangskonfigurasjonen.

Før du starter

Innebygde roller

Fabric Apps gjenkjenner den innebygde rollen authenticated. Du kan også definere tilpassede roller i policyene dine når det trengs.

Role Beskrivelse Brukstilfelle
authenticated Krever en gyldig brukerøkt med Fabric-autentisering Brukerspesifikke data, beskyttede ressurser

Dekoratøren @role

Bruk @role på klassenivå for å kontrollere hvilke roller som kan utføre hvilke handlinger på en enhet:

@role(roleName, actions, options?)

Parametre

Parameteren Type: Beskrivelse
roleName string Rollenavnet, som for eksempel 'authenticated' en egendefinert applikasjonsrolle
actions string \| string[] Enkelthandling eller array: 'create', 'read', 'update', , 'delete', eller '*' for alle
options object Valgfritt objekt med check, include, og exclude egenskaper

Grunnleggende eksempel

Begrens autentiserte brukere til deres egne 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 dette eksemplet:

  • Autentiserte brukere kan kun få tilgang til oppgaver som userId samsvarer med deres JWT-krav sub .

Type-sikre policyuttrykk

Callbacken policy gir skrevet tilgang til både krav og enhetsfelt. TypeScript utleder entitetstypen fra den dekorerte klassen, og gir deg autokomplettering og refaktorer-sikkerhet:

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

Støttede påstander

Krav Beskrivelse Eksempelverdi
claims.sub Emneidentifikator (bruker-ID) 00000000-0000-0000-0000-000000000001
claims.email Brukerens e-postadresse user@contoso.com
claims.role Brukerrolle (hvis levert av identitetsleverandøren) admin

Uttrykksoperatorer

Operatør Eksempel Beskrivelse
.eq() claims.sub.eq(item.userId) Likhetssjekk

Logiske operatorer

Kombiner uttrykk med .and() og .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))
})

Begge sider er automatisk parentesert for korrekt gruppering.

Feltnivå-tillatelser

Spesifiser hvilke felt en rolle kan få tilgang til ved å bruke include eller exclude i rollealternativene.

Inkluder spesifikke felt

Tillat title feltet kun under opprettelsesoperasjoner:

@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;
}

Ekskluder spesifikke felt

Skjul sensitive felt fra leseoperasjoner:

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

Note

Feltmatriser skrives til enhetens faktiske eiendomsnavn. Omdøping av et felt gir en kompileringstidsfeil i hver include eller exclude liste som refererer til det.

Handlingsspesifikke tillatelser

Bruk ulike regler per handling ved å bruke flere @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;
}

Denne konfigurasjonen:

  • Opprett: Kun skaperen kan lage, og kun title felt content og er tillatt.
  • Les: Bare skaperen kan lese sine egne dokumenter.
  • Oppdatering: Bare skaperen kan oppdatere, men de kan ikke endre adminNotesdet.
  • Slett: Kun skaperen kan slette.

Hvordan tillatelser fungerer

  • Metadatainnsamling: Dekoratøren @role samler inn tillatelsesmetadata når klassen defineres.
  • Skjemagenerering: Når du kjører db apply, leser CLI-en metadata og genererer tillatelseskonfigurasjon.
  • Policykompilering: TypeScript-policy-callbacks kompileres til data-tilgangspolicyuttrykk (for eksempel, @claims.sub eq @item.userId).
  • Kjøretidshåndheving: Data-aksesslaget håndhever tillatelser på hver API-forespørsel.
  • Konfliktdeteksjon: Flere @role dekoratører på samme klasse aggregeres per rolle, med advarsler for motstridende erklæringer.

Vanlige mønstre

Kun for eiere

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

Full tilgang for autentiserte brukere

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

Admin overstyre

@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;
}

Administratorer kan endre hvilken som helst ressurs, men bare administratorer kan slette.

Neste trinn

  • Last updated on