Avklaring: Granulering av Rettigheter for Recipient av Correspondence

[RagnarFatland-Avanade]

Granulering av rettigheter for Recipient:

I Altinn 2 var det i praksis 4 forskjellige rettigheter som styrte Receipient sine aksjoner:

• Read
• Write
• ArchiveRead
• ArchiveDelete.

Mens vi har per nå i Altinn-Correspondence:

• "ActionType:Read", som dekker alle aksjonene som ble granulert av disse 4 for Recipient.
• "ActionType:Write" bruker vi for å dekke alle aksjoner som Sender har.

Dette satte vi i utgangspunktet basert på hva som var brukt i Broker.

Jeg har satt opp en mapping mot hvilke konkrete aksjoner det dekket her: Autorisasjonsoversikt - Arbeidsdokument WIP.xlsx

Jeg tok uttrekk av alle autorisasjonsreglene for A2 Correspondence og gjorde en analyse av bruken: Autorisasjonsoversikt - Arbeidsdokument WIP.xlsx Ark "Rettighetsbruk"

Oppsummert:

1. 63% av alle roller har alle rettighetene.
2. 28% Read, Write og ArchiveRead
3. 6% Read og ArchiveRead
4. 3% ymse annet

Altinn 2 Read og Write

I praksis er det forsvinnende få som skiller mellom Altinn 2 Read og Write når de gir tilganger til rollene. Min og @Ceredron sin mening er at det ikke er nødvendig å innføre mer granulering med mindre TE kan argumentere for et reelt behov på å skille mellom disse operasjonene. Dette spørsmålet bør derfor tas spesifikt med TE gjennom den planlagte dialogen der.

• Det kan for eksempel finnes argumenter for at "Confirm" og "Delete" bør ha separat tilgangsnivå enn resten av operasjonene dersom man kan regne dette som mer sensitivt.

Altinn 2 ArchiveRead og ArchiveDelete

Det er en åpen diskusjon om "Arkiverings"-konseptet skal pensjoneres i #337 og dersom arkivering fjernes vil det i så fall gjøre tilsvarende granulering på disse rettighetene overflødige. Dersom konseptet skal beholdes, så bør også beslutningen inkludere om det er et behov for å skille denne rettigheten fra resten av "Read".

[RagnarFatland-Avanade]

@leogasnier ønsker innspill/diskusjon på dette slik at vi kan lande riktig sted.

[leogasnier]

Ulempen med å bruke write for "Confirm" og "Delete" og read for resten? Lettere å sette feil tilgang/glemme "write" slik at brukere ikke får slettet? - kan korrigeres i RR

Litt bekymret for tilnærming med å "røyke ut behovet" da det gjerne ikke uttales før seint i prossessen, så den vil uansett kunne gi "omkamper". Kunne en tilnærming vært å implementert som jeg foreslår over (likhetstrekk fra A2 men forenklet en god del)?

For arkiv-spesifikke rettigheter støtter jeg at de bør utgå. Arkiv er ikke noe annet enn en mappe, og trenger som sådan ingen spes tilgangregler.

[RagnarFatland-Avanade]

Jeg oppdaterte teksten litt mer for å gi mer klarhet.

Ulempen med å bruke write for "Confirm" og "Delete" og read for resten? I ny løsning er ActionType:Write brukt for Sender, slik at det er mulig for andre enn ServiceOwner/ResourceOwner å være avsender, og ActionType:Read brukt for alle rettighetene som tilhører en Recipient. Litt "arv" fra slik vi gjorde det for Broker altså.

Dersom vi skal dele opp i mer granulert for Recipient så må vi innføre ny Action Type "ReadAdvanced" eller noe tilsvarende.? Et annet alternativ ville vært å skru mer om på det:

• Innføre en "Send" ActionType som erstatter bruken vi har av "write" i dagens Correspondence.
• "Read" mister Delete og Confirm
• "Write" blir omdefinert til gå gi adgang til "Delete", "Confirm"

Litt usync med Broker blir det uansett.

Litt bekymret for tilnærming med å "røyke ut behovet" da det gjerne ikke uttales før seint i prossessen, så den vil uansett kunne gi "omkamper". Kunne en tilnærming vært å implementert som jeg foreslår over (likhetstrekk fra A2 men forenklet en god del)?

Enig med at vi ikke bør fiske for mye, men i dette konkrete tilfellet så vil en endring av hva en ActionType gjør og/eller innføring av en ny ActionType medføre behov for å endre eksisterende policies. Så derfor viktig å få landet.

For arkiv-spesifikke rettigheter støtter jeg at de bør utgå. Arkiv er ikke noe annet enn en mappe, og trenger som sådan ingen spes tilgangregler.

Enig.