Utkast til designdiskusjon: forvaltning av delegeringstak for applikasjoner (BRU-TIL-DEL-001/002)

[krhoybraten-sikt]

Utkast til krav for forvaltning av delegeringstak for applikasjoner. Alt står @could @draft — dette er lagt fram for designdiskusjon, ikke for godkjenning. Ett valg er likevel tatt på forhånd og presentert som gitt: hvem som kan endre et tak. Se «Besluttet» under.

Bakgrunn

En Feide-applikasjon kan opptre på to måter. Den kan handle som seg selv, med tilganger tildelt applikasjonen — det er tilgangslisten BRU-APP-API-003 beskriver. Og den kan handle på vegne av en innlogget bruker. Et delegeringstak gjelder bare det siste: det er den øvre grensen for hvor mye av en brukers egen myndighet applikasjonen får bære.

Taket gir applikasjonen ingenting alene. Håndhevelsen er et snitt — en bruker får gjennom en applikasjon bare det hun selv har OG taket bærer, per organisasjon og tilgang, i ett miljø. Snittet har to egenskaper som er hele grunnen til at kravene finnes:

• Det er stille. En tilgang taket ikke bærer forsvinner uten feilmelding. Symptomet er at flaten svarer tomt, ikke at noe avvises.
• Det treffer bare brukere gjennom en applikasjon. Den samme brukeren har tilgangen andre steder, så feilen ser ut som et problem med applikasjonen eller med grafen.

Erfaring har vist at dette er den vanligste årsaken til at en ny tilgang «ikke virker»: tilgangen ble innført i katalogen, men ikke lagt inn i taket til applikasjonen den skulle brukes gjennom. Regelen — taket må følge tilgangskatalogen — står nå på tabellen selv, men et sted å håndheve den finnes ikke.

Datamodellen er i produksjon, med miljødimensjon, ikke-overlappende gyldighetsperioder og sporing av aktør for både innlegging og avslutning. Det som ikke finnes er forvaltningen: ingen mutasjon, ingen synkronisering, ingen flate. Radene legges inn manuelt av databaseforvaltningen, mens taket i praksis er driftsdata som endres uavhengig av deployer.

En avgrensning som er lett å overse: fremmednøkkelen peker på Feide-applikasjon, ikke på subjekt generelt. Bare applikasjoner brukere logger inn i har et delegeringstak. Maskinbrukere og Maskinporten-klienter opptrer alltid som seg selv, og for dem finnes taket ikke som begrep — derfor skal visningen ikke dukke opp der i det hele tatt, heller ikke som en tom liste.

Hva som er lagt til

Ny kapabilitet krav/07 Brukeradministrasjon og tilgangsstyring/11 Tilgangsstyring/03 Delegeringstak/:

Fil	Innhold
se_delegeringstak.feature (BRU-TIL-DEL-001)	Taket som egen liste (ikke applikasjonens egne tilganger), organisasjonsskopet lesing, synlighet av effektiv formidlingsevne — inkludert invarianten at et tomt eller avskåret snitt skal være en forklart tilstand — og sporbar historikk
endre_delegeringstak.feature (BRU-TIL-DEL-002)	Gating på applikasjonsadministrator hos Sikt, endring per (tilgang, organisasjon, miljø), idempotens, tilbaketrekking ved å avslutte perioden, og regelen om at taket må følge tilgangskatalogen
forvalte_delegeringstak.design.md	Designnotat: modellen som finnes, de tre alternativene, UI-mønster, tilstander, designpoengene og de åpne spørsmålene

Besluttet: hvem kan endre et tak

Endring av et delegeringstak krever applikasjonsadministrator hos Sikt. Features er skrevet under den forutsetningen, og alternativ (a) i notatet er presentert med denne gatingen som utgangspunkt, ikke som et åpent spørsmål.

Begrunnelsen er hvem endringen treffer. Et takinnslag navngir organisasjonen applikasjonen får opptre innenfor — ikke organisasjonen som eier applikasjonen. En utvidelse gir altså en applikasjon, ofte eid av en annen part, lov til å handle i en organisasjons navn. Resten av applikasjonsforvaltningen er skopet slik at en administrator forvalter det som hører til sine egne organisasjoner; her ville det samme skopet gjort utvidelsen til et valg for eieren av applikasjonen eller for den berørte organisasjonen, og ingen av de to er riktig part alene.

Lesing forblir bredere. Organisasjonen som har lånt ut myndighet skal kunne se det, uten å kunne endre det. Modellen har allerede en egen leseregel med organisasjonsskop ved siden av skriveregelen, så beslutningen krever at skriveregelen strammes — ikke at lesingen gjøres om. Verdt å merke seg, fordi den motsatte antakelsen ville fjernet lesesynet til organisasjonene i samme grep.

Konsekvensen for kravene er at de to features har ulike aktører: BRU-TIL-DEL-001 er skrevet fra organisasjonens side, BRU-TIL-DEL-002 fra Sikts.

De tre alternativene

(a) Forvaltningsflate — valgt retning. Taket får en eier i løsningen: API for å lese og endre, og senere en flate. Lesing organisasjonsskopet, endring gatet hos Sikt, endringer temporale, sporbare og idempotente. Det er den eneste av de tre som gir regelen et sted å bo, og den gir lesehalvdelen gratis: når taket er lesbart gjennom løsningen kan flaten forklare et avskåret snitt i stedet for å vise en tom liste. Kostnaden er at taket får en skriveflate — derfor den strammere gatingen, og derfor må tilbaketrekking være like lett som utvidelse.

(b) Migrerings- og driftseid, status quo formalisert. Taket endres bare gjennom reviewet migrering, og regelen håndheves som prosess. Argumentet for: hver utvidelse får en review, ingen skriveflate å misbruke, nullkostnad å beholde. Grunnen til at den ikke velges: migreringer kjører ved deploy, mens taket er driftsdata — en organisasjon som senere skal dekkes får ikke radene av seg selv, og en ny tilgang får ikke radene av seg selv. Erfaringen med feilklassen er nettopp fra dette regimet: prosesskravet ble ikke oppfylt fordi ingenting minnet noen på det. Alternativet er dessuten ikke gratis på lesesiden — uten en flate kan ingen organisasjon se hva den har lånt ut, og support kan ikke forklare et tomt svar uten databasetilgang.

(c) Modellendring: taket enumererer bare de fingranede tilgangene. Taket slutter å nevne sammensatte tilganger; ekspansjonen skjer utelukkende på brukersiden av snittet. Det er det eneste alternativet som gjør feilklassen strukturelt umulig for den store gruppen tilganger. Grunnen til at den ikke velges nå: det er en semantikkendring i selve håndhevelsen, ikke en ny flate. Snittet nuller i dag også de sammensatte kodene, og en visning som spør «hvilke tilganger har jeg her» leser nettopp dem — så endringen berører mer enn autorisasjonen. Ikke forkastet: det er det naturlige neste steget hvis forvaltningsflaten viser at takradene for sammensatte tilganger aldri bærer noen egen beslutning.

(a) og (c) utelukker ikke hverandre — (a) reduserer smerten ved å utsette (c).

Designpoengene som bærer kravene

Leseskopet følger den berørte organisasjonen, ikke eieren. Det er lett å lese taket som en egenskap ved applikasjonen, og dermed som noe eierorganisasjonen forvalter. Modellen sier noe annet: hver rad navngir organisasjonen applikasjonen får opptre innenfor. En administrator ved et lærested kan derfor se hvilke applikasjoner som kan opptre på vegne av lærestedets brukere, også når applikasjonen tilhører en annen part. Den uvante halvdelen: eieren av en applikasjon ser bare de organisasjonene hun selv administrerer, og altså ikke nødvendigvis hele taket til sin egen applikasjon. Bør bekreftes i review.

Grensen er ikke absolutt, og visningen må ikke love at den er det. Tilganger som gjelder alle legges til etter snittet — taket begrenser brukerens egne tilganger, ikke alt applikasjonen kan vise. Og deaktivering av applikasjonen undertrykker hele resultatet uavhengig av taket, uten at brukerens egne tilganger berøres.

Temporal historikk er et løfte vi kan holde. Et tak trekkes tilbake ved å lukke perioden, ikke ved å slette raden, og perioder for samme kombinasjon kan ikke overlappe. Kravene kan derfor love «når fikk applikasjonen lov til dette, og av hvem», «hva kunne applikasjonen formidle på et gitt tidspunkt», og at gjeninnføring gir en ny periode ved siden av den gamle. For et tak er dette mer enn bekvemmelighet: «hadde denne applikasjonen lov til å gjøre det da» er et sikkerhetsspørsmål, og svaret skal ikke avhenge av at ingen har ryddet.

Effektiv formidlingsevne er den visningen som ikke finnes i dag. Den skal svare: hvilke av brukerens tilganger kommer gjennom denne applikasjonen, og hvilke stopper i taket? Uten den er et hull i taket usynlig helt til noen feilsøker i databasen.

Plassering og nummerering

Kapabilitetsmappen er lagt under 11 Tilgangsstyring, som søsken til 01 Tilganger, med samme begrunnelse som i #546: applikasjoner er iterasjonsnavngitt, og et udatert @could @draft-krav hører ikke inn i en planlagt iterasjon. Et delegeringstak er samtidig mer enn applikasjonsforvaltning — det er en regel om hvordan brukertilganger håndheves.

To ting det er verdt å ta stilling til:

• Mappenummeret. 02 er tatt av Utkast til designdiskusjon: forvaltning av organisasjonssamlinger (BRU-TIL-SAM-001/002) #546 (organisasjonssamlinger), som fortsatt er åpen. Denne PR-en er derfor 03 Delegeringstak, og lager et hull hvis Utkast til designdiskusjon: forvaltning av organisasjonssamlinger (BRU-TIL-SAM-001/002) #546 ikke merges. Trivielt å renummerere om det er ønskelig — si fra hvilken rekkefølge som foretrekkes.
• ID-prefikset. Utledet av mappenavnene blir det BRU-TIL-DEL, samme mønster som BRU-TIL-SAM i Utkast til designdiskusjon: forvaltning av organisasjonssamlinger (BRU-TIL-SAM-001/002) #546. Nabofilene i sub-domenet har det eldre prefikset TIL-TIL-TIL. Jeg har fulgt konvensjonen slik den er skrevet, ikke naboene. Hvis kravene heller skal under applikasjoner, er neste ledige nummer i den serien BRU-APP-API-011.

Åpne spørsmål jeg har latt stå

• Automatikk for løsningens egen administrasjonsflate. Skal taket for Sikts egen flate følge tilgangskatalogen automatisk, slik at en ny administrasjonstilgang virker med én gang, eller forvaltes manuelt som alle andre tak? Automatikk fjerner den vanligste feilklassen for den applikasjonen den treffer oftest, men gjør taket til noe som utvides uten en beslutning per gang — og det er nettopp beslutningen per gang som er sikkerhetsverdien i (a). Scenarioet er merket @openquestion.
• GUI-omfang. Bare lesevisning på detaljsiden i første omgang, med endring gjennom API-et, eller lese- og endringsflate samtidig? Lesevisningen er den som løser feilsøkingsproblemet; endringsflaten er den som fjerner det manuelle innslaget.
• Hvor hører visningen av effektiv formidlingsevne — på applikasjonen, i «mine tilganger», eller begge? Spørsmålet er hvem som oppdager et hull først: den som forvalter applikasjonen, eller brukeren som mangler noe.
• Forespørsel om utvidelse. Gatingen gjør at noen må spørre noen andre. Skal en organisasjon kunne be om en utvidelse den ikke selv kan utføre, som en forespørsel i løsningen, eller er det en supportoppgave utenfor?

Bevisst ikke endret

• krav/krav-oversikt.md — generert, og allerede utdatert mot repoet. Bør regenereres for seg.
• Ingen systemkrav.md for den nye kapabiliteten. Nabokapabiliteten 01 Tilganger har ingen, og kravene er for umodne til å beskrives som systemkrav.
• Ingenting i veikart/.
• Eksisterende krav under applikasjoner er urørt — særlig BRU-APP-API-003, som beskriver applikasjonens egne tilganger. Sammenhengen mellom de to listene er beskrevet i de nye filene, ikke ved å endre den gamle.

Ikke merge — dette skal reviewes, og både gatingen og de åpne spørsmålene bør avklares før kravene kan bli noe annet enn utkast.