Definér datatilladelser

Fabric Apps bruger @role decorator til at vedhæfte autorisationsregler direkte til dine datamodeller. Tilladelser er type-sikre, refaktorer-venlige og automatisk kompileret ind i den underliggende dataadgangskonfiguration.

Før du begynder

• Forstå forskellen mellem autentificering (hvem du er) og autorisation (hvad du kan gøre)
• Gennemgå Konfigurér autentificering for at opsætte identitetsverifikation
• Forstå datamodeller oversigt for entitetens grundlæggende principper

Indbyggede roller

Fabric Apps genkender den indbyggede rolle authenticated. Du kan også definere brugerdefinerede roller i dine politikker, når det er nødvendigt.

Dekoratøren @role

Anvend @role på klasseniveau for at kontrollere, hvilke roller der kan udføre hvilke handlinger på en enhed:

@role(roleName, actions, options?)

Parametre

Grundlæggende eksempel

Begræns autentificerede brugere 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 eksempel:

• Autentificerede brugere kan kun få adgang til Todo-elementer, der userId matcher deres JWT-krav sub .

Type-sikre politikudtryk

Callbacken policy giver indtastet adgang til både krav og entitetsfelter. TypeScript udleder entitetstypen fra den dekorerede klasse, hvilket giver dig autocompletion og refaktoreringssikkerhed:

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

Understøttede påstande

Udtryksoperatorer

Logiske operatorer

Kombiner udtryk 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 parenteseret for korrekt gruppering.

Feltniveau-tilladelser

Angiv de felter, en rolle kan få adgang til via include eller exclude i rolleindstillingerne.

Inkluder specifikke felter

Tillad title kun feltet under oprettelsesoperationer:

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

Udeluk specifikke felter

Skjul følsomme felter fra læseoperationer:

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

Handlingsspecifikke tilladelser

Anvend forskellige regler pr. handling ved hjælp af 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 konfiguration:

• Opret: Kun skaberen kan skabe, og kun title felter med en content er tilladt.
• Læs: Kun skaberen kan læse sine egne dokumenter.
• Opdatering: Kun skaberen kan opdatere, men de kan ikke ændre adminNotes.
• Slet: Kun skaberen kan slette.

Hvordan tilladelser fungerer

• Metadataindsamling: Dekoratoren @role indsamler tilladelsesmetadata, når klassen defineres.
• Skemagenerering: Når du kører db apply, læser CLI'en metadata og genererer tilladelseskonfiguration.
• Politikkompilering: TypeScript-politik-callbacks kompileres til dataadgangspolitikudtryk (for eksempel @claims.sub eq @item.userId).
• Runtime-håndhævelse: Dataadgangslaget håndhæver tilladelser på alle API-anmodninger.
• Konfliktdetektion: Flere @role dekoratorer på samme klasse aggregeres pr. rolle, med advarsler om modstridende erklæringer.

Almindelige mønstre

Ejeradgang kun

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

Fuld adgang for autentificerede brugere

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

tilsidesættelse af Administration

@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 ændre enhver ressource, men kun administratorer kan slette.

Næste trin

• Konfigurer autentificering for at opsætte identitetsudbydere
• Foresøg data med GraphQL for at teste tilladelsesbeskyttede forespørgsler
• CLI-kommandoreference til skemagenereringskommandoer