Hop til hovedindhold

Tilladelser og roller

Canopy bruger en trelagsbaseret tilladelses­model, der kombinerer rollebaseret adgangskontrol på tværs af hele applikationen med kortspecifikke interessentroller. Denne side forklarer designet, hvornår hvert lag bruges, og hvordan lagene kombineres til effektive tilladelser.

Hvorfor tre lag?​

Enterprise Architecture er i sagens natur tværfunktionel. Et givet kort — f.eks. en Application — kan være:

  • Skrivebeskyttet for de fleste brugere (læsere ser inventaret, men kan ikke redigere)
  • Redigerbart af det generelle EA-team (medlemmer kan opdatere ethvert kort)
  • Administreret af en bestemt person, der er ansvarlig for den pågældende applikation (Technical Application Owner kan redigere og godkende status, selvom vedkommende ikke har organisationsdækkende redigeringsrettigheder)
  • Fuldt kontrolleret af administratorer (der kan gøre alt)

Et fladt rollesystem håndterer de første tre tilfælde, men bryder sammen ved det fjerde: man giver enten nogen organisationsdækkende redigeringsrettigheder (for bredt) eller ingenting (for restriktivt). Interessentlaget løser dette ved at tildele kortspecifikke tilladelser til navngivne personer.

Lag 1 — Applikationsroller​

Applikationsroller tildeles brugere og gælder på tværs af hele platformen. De defineres og administreres i Administration → Brugere og roller.

Hver rolle bærer et JSON-tilladelsessæt. De indbyggede roller er:

RolleNøgleOmfang
AdminadminJokertegn {"*": true} — ubegrænset
BPM Adminbpm_adminFuld BPM + fuldt inventar, ingen admin.*
MedlemmemberFuldt inventar + BPM-redigering, ingen admin.*
LæserviewerKun læsning på tværs af alle domæner

Brugerdefinerede roller kan oprettes med enhver kombination af de tilgængelige tilladelsesnøgler, grupperet i domæner som inventory.*, reports.*, bpm.*, ppm.*, grc.*, todos.*, admin.*.

Brug applikationsroller, når du har brug for at styre, hvad en brugergruppe kan gøre på tværs af hele platformen.

Lag 2 — Interessentroller​

Interessentroller tildeles brugere på specifikke kort. Hver korttype definerer sit eget sæt af interessentrolledefinitioner (f.eks. har Application-kort "Technical Application Owner", "Business Application Owner", "Data Steward"). Disse konfigureres i Administration → Metamodel → [type] → Interessentroller.

Hver interessentrolledefinition bærer et sæt kortspecifikke tilladelser — ting som card.edit, card.approve, card.manage_relations. Når en bruger tilføjes som interessent på et kort, får de disse tilladelser på det pågældende kort alene.

Brug interessentroller, når ejerskab eller ansvarlighed er kortspecifik: ejeren af en bestemt applikation bør kunne administrere den uden at få redigeringsrettigheder til alle 500 andre applikationer.

Lag 3 — Effektive tilladelser​

Når en bruger forsøger at udføre en handling på et kort, beregner systemet deres effektive tilladelser ved at kombinere:

  1. Deres applikations­rolle­tilladelser (mappet fra platform-niveau til kortniveau-nøgler)
  2. Alle interessentrolletilladelser, de har på det specifikke kort

Resultatet er foreningen af begge sæt. En bruger, der er Læser (på platformen), men Technical Application Owner på ét kort, kan redigere det pågældende kort, fordi interessentrollen giver card.edit, selvom Læser-rollen ikke gør det.

De effektive tilladelser for den aktuelle bruger på et givet kort er tilgængelige via GET /cards/{id}/effective-permissions og styrer alle redigerings-, godkendelses- og sletningskontroller i brugergrænsefladen.

Admin-jokertegnet​

Admin-rollen bruger {"*": true} som sit tilladelsessæt. Dette evalueres som "tillad alt" — inklusive tilladelser, der ikke fandtes, da rollen blev oprettet. Det betyder, at nye moduler og nye tilladelsesnøgler automatisk er tilgængelige for administratorer uden nogen rollepåvirkning.

Ingen anden indbygget rolle bruger jokertegnet. Når du opretter brugerdefinerede roller, skal du bruge eksplicitte tilladelsesnøgler frem for jokertegn — det gør rollens omfang reviderbart og forhindrer utilsigtet over-tildeling.

Struktur for tilladelsesnøgler​

Alle tilladelsesnøgler følger et domæne.handling-mønster:

  • inventory.view — læs kort
  • inventory.edit — opdater kort
  • inventory.create — opret kort
  • admin.metamodel — administrer korttyper og relationstyper
  • admin.impersonate — midlertidigt optræde som en anden rolle (se Rolleimpersonering)
  • bpm.approve — godkend BPMN-procesflow-versioner
  • todos.view / todos.create / todos.manage — tilgå og administrer opgaver
  • risks.manage — opret og opdater risikoregisterposter

Den komplette liste over gyldige nøgler findes i backend/app/core/permissions.py, som er den eneste kilde til sandhed. Nye tilladelsesnøgler skal tilføjes der, før de kan tildeles nogen rolle.

Typiske mønstre​

Begræns et modul til et team: Opret en brugerdefineret rolle med kun tilladelserne ppm.* og inventory.view. Tildel den til projektporteføljeteamet. De kan arbejde i PPM, men kan ikke redigere hoved­inventaret.

Giv godkendelsesrettigheder uden redigeringsrettigheder: Giv en forretnings­interessent rollen "Business Application Owner" som interessentrolle på specifikke Application-kort. Konfigurer den rolle til at inkludere card.approval_status, men ikke card.edit. De kan godkende kort, som EA-teamet har udfyldt, men kan ikke ændre dataene.

Nødadgang for en administrator: Admin-jokertegnet betyder, at enhver fremtidig tilladelse — inklusive tilladelser tilføjet af udvidelser eller fremtidige versioner — automatisk tildeles. Brug Admin-rollen kun til brugere, der reelt har brug for ubegrænset adgang.

Test som en bestemt rolle: Brugere med admin.impersonate kan skifte til en hvilken som helst ikke-adminrolle fra brugermenuen (Vis som rolle…) for at verificere præcis, hvad den rolle kan se og gøre — uden at oprette en separat testkonto. Impersoneringssessionen er kun JWT-baseret og efterlader ingen spor på den underliggende konto. Se Rolleimpersonering for det fulde workflow.

Se også​