Gegevensmachtigingen definiëren

Fabric Apps gebruikt de @role decorator om autorisatieregels rechtstreeks aan uw gegevensmodellen toe te voegen. Machtigingen zijn typeveilig, geschikt voor refactoring en worden automatisch omgezet naar de onderliggende configuratie voor gegevenstoegang.

Voordat u begint

• Inzicht krijgen in het verschil tussen verificatie (wie u bent) en autorisatie (wat u kunt doen)
• Bekijk Authenticatie configureren om identiteitsverificatie in te stellen
• Begrijp Overzicht van gegevensmodellen voor de basisprincipes van entiteiten

Ingebouwde rollen

Fabric Apps herkent de ingebouwde rol authenticated. U kunt ook aangepaste rollen in uw beleid definiëren wanneer dat nodig is.

De @role decorator

Toepassen @role op klasseniveau om te bepalen welke rollen welke acties op een entiteit kunnen uitvoeren:

@role(roleName, actions, options?)

Parameters

Basisvoorbeeld

Geverifieerde gebruikers beperken tot hun eigen gegevens:

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

In dit voorbeeld:

• Geauthenticeerde gebruikers hebben alleen toegang tot Todo-items waarvoor userId overeenkomt met hun JWT-claim sub.

Typeveilige beleidsuitdrukkingen

De policy callback biedt getypte toegang tot zowel claims als entiteitsvelden. TypeScript leidt het entiteitstype af uit de gedecoreerde klasse, waardoor u automatische aanvulling en veilige refactoring krijgt:

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

Ondersteunde claims

Operatoren voor expressies

Logische operatoren

Expressies combineren met .and() en .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))
})

Aan beide kanten worden automatisch haakjes geplaatst voor een correcte groepering.

Machtigingen op veldniveau

Geef de velden op die een rol kan openen met behulp van include of exclude in de rolopties.

Specifieke velden opnemen

Sta het title veld alleen toe tijdens het maken van bewerkingen:

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

Specifieke velden uitsluiten

Gevoelige velden verbergen voor leesbewerkingen:

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

Actiespecifieke machtigingen

Verschillende regels per actie toepassen met behulp van meerdere @role decorators:

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

Deze configuratie:

• Maken: Alleen de maker kan maken en alleen title en content velden zijn toegestaan.
• Lezen: Alleen de maker kan zijn of haar eigen documenten lezen.
• Update: Alleen de maker kan bijwerken, maar kan deze niet wijzigen adminNotes.
• Verwijderen: Alleen de maker kan verwijderen.

Hoe machtigingen werken

• Verzameling metagegevens: de @role decorator verzamelt metagegevens van machtigingen wanneer de klasse is gedefinieerd.
• Schemageneratie: Wanneer u uitvoert db apply, leest de CLI metagegevens en genereert de configuratie van machtigingen.
• Beleidscompilatie: Callbacks van TypeScript-beleid worden gecompileerd in beleidsexpressies voor gegevenstoegang (bijvoorbeeld @claims.sub eq @item.userId).
• Afdwingen tijdens runtime: De gegevenstoegangslaag dwingt toegangsrechten af bij elke API-aanvraag.
• Conflictdetectie: meerdere @role decorators in dezelfde klasse worden samengevoegd per rol, met waarschuwingen voor conflicterende declaraties.

Algemene patronen

Alleen toegang voor eigenaren

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

Volledige toegang voor geverifieerde gebruikers

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

Overschrijven door beheerder

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

Beheerders kunnen elke resource wijzigen, maar alleen beheerders kunnen verwijderen.

Volgende stappen 

• Verificatie configureren voor het instellen van id-providers
• Gegevens opvragen met GraphQL om query's te testen die met machtigingen zijn beveiligd
• CLI-opdrachtreferentie voor opdrachten voor het genereren van schema's