Utkast til designdiskusjon: forvaltning av organisasjonssamlinger (BRU-TIL-SAM-001/002)

[krhoybraten-sikt]

Utkast til krav for forvaltning av organisasjonssamlinger. Alt står @could @draft — dette er lagt fram for designdiskusjon, ikke for godkjenning.

Bakgrunn

En organisasjonssamling er en navngitt, forvaltet mengde organisasjoner. En tilgang kan tildeles mot samlingen i stedet for mot én organisasjon, og gjelder da samlingens medlemmer i det samme miljøet. Poenget er at «alle læresteder» blir en eksplisitt mengde som kan listes og etterprøves, i stedet for en regel ingen kan se.

Datamodellen er merget og ligger i produksjonsløypa (fs-plattform MR 5262): samlingskatalogen, temporale medlemskap per miljø, og temporale tildelinger mot samling. Autorisasjonen leser den allerede — en aktiv tildeling mot en samling utvides til samlingens aktive medlemmer i samme miljø. Én samling finnes, «FS-læresteder» med 37 medlemsorganisasjoner i produksjon, men det er ikke opprettet noen tildeling mot den, så modellen gir foreløpig ingen tilgang gjennom samlinger.

Det som ikke finnes er forvaltningen. I dag kan bare databaseforvaltningen opprette samlinger og skrive medlemskap. Kravene for en forvaltningsflate er ikke skrevet — denne PR-en er et utkast til dem.

Hva som er lagt til

Ny kapabilitet krav/07 Brukeradministrasjon og tilgangsstyring/11 Tilgangsstyring/02 Organisasjonssamlinger/:

Fil	Innhold
forvalte_organisasjonssamlinger.feature (BRU-TIL-SAM-001)	Katalog (liste, detalj, medlemstall per miljø), medlemskap inn og ut per miljø, sporbar medlemskapshistorikk, global forvaltningsrettighet, skalavakt
tildele_tilgang_via_organisasjonssamling.feature (BRU-TIL-SAM-002)	Tildel og fjern tilgang mot samling, miljøavgrensning, rolleomfang og nekt, proveniens i visningen av mine tilganger
forvalte_organisasjonssamlinger.design.md	Designnotat: modellen som finnes, UI-mønster, tilstander, de fire designpoengene og de åpne spørsmålene

Hvorfor egen mappe og ikke under applikasjoner

Strukturen er Domene → Sub-domene → Kapabilitet, og applikasjoner er et sub-domene for administrasjon av applikasjoner (API-brukere). En organisasjonssamling er ikke applikasjonsspesifikk: katalogen og medlemskapene har ingenting med applikasjonsforvaltning å gjøre, og en tildeling mot en samling kan i prinsippet gjelde både brukere og applikasjoner. I tillegg er kapabilitetsmappene under applikasjoner iterasjonsnavngitte — et udatert @could @draft-krav hører ikke inn i en iterasjon som er planlagt for supportflaten.

11 Tilgangsstyring er derimot sub-domenet for tilgangskontroll generelt, og har i dag én kapabilitet (01 Tilganger). Samlinger er lagt som en søskenkapabilitet der.

To ting det er verdt å ta stilling til i review:

• Feature-ID-prefikset. Utledet av mappenavnene blir det BRU-TIL-SAM (domene 07 → BRU, som applikasjoner bruker; sub-domene 11 Tilgangsstyring → TIL; kapabilitet → SAM). Nabofilene i sub-domenet har det eldre prefikset TIL-TIL-TIL, fra da domenemappen het noe annet. Jeg har fulgt konvensjonen slik den er skrevet, ikke naboene — si fra hvis det heller bør være omvendt.
• Hvis review vil ha kravene under applikasjoner likevel, er neste ledige nummer i den serien BRU-APP-API-011 (011–014 er ubrukt, høyeste tildelte er 017). Da bør de to filene slås sammen til én, siden serien har én feature per handling i applikasjonsflaten.

Designpoengene som bærer kravene

Samlinger har ingen eierorganisasjon. Resten av tilgangsstyringen er skopet til (organisasjon, rolle, miljø), og en administrator forvalter det som hører til organisasjonene sine. En samling går på tvers og har ingen eier i modellen, så det finnes ingen organisasjon å skope forvaltningsrettigheten til. Forvaltning må gates på en global rettighet på Sikt-nivå. Det er et bevisst avvik fra mønsteret, med en praktisk følge: en administrator ved et lærested kan ikke melde sitt eget lærested inn i en samling, fordi innmeldingen gir noen andre tilgang til data i andre organisasjoner. Rollen som skal bære rettigheten finnes ikke i dag og hører hjemme i forretningsrollesettet som er under arbeid — kravene sier derfor «global forvaltningsrettighet» og navngir ingen rolle.

Temporal historikk er et løfte vi kan holde. Både medlemskap og tildeling avsluttes ved å lukke en periode, ikke ved å slettes. Kravene lover derfor «når ble organisasjonen medlem, og av hvem», «hvilke organisasjoner besto samlingen av på et gitt tidspunkt», og at gjeninnmelding gir en ny periode ved siden av den gamle framfor å overskrive den.

Proveniens er et åpent spørsmål. En tilgang kan følge av en direkte tildeling, av at en sterkere tilgang omfatter den, eller av at organisasjonen er medlem av en samling det er tildelt mot. Skal samling være en egen tilknytningsverdi i visningen av mine tilganger, en undertype av «arvet», eller ikke skilles i det hele tatt? Valget avgjør også hva flaten kan tilby derfra: en samlingsderivert tilgang kan ikke fjernes på organisasjonen den vises på. Scenarioene som avhenger av svaret er merket @openquestion.

Skalavakt, som ikke-funksjonelt krav. Utvidelsen fra samling til medlemmer skjer i autorisasjonsoppslaget, altså i pålogging og tilgangsvurdering. Målingen 2026-08-17 viser at oppslagene holder seg innenfor rammene ved 500 medlemmer, og at knekkpunktet ligger et sted mellom 500 og 5 000 — altså at 500 er trygt og 5 000 ikke er det, ikke hvor grensen går. Kravet er derfor en vakt, ikke et tak: samlinger over 500 medlemmer skal måles før de tas i bruk. Grensen bør flyttes når noen måler videre. Dagens eneste samling har 37 medlemmer, så vakten er ikke i veien for noe kjent behov.

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

• Navn på den globale forvaltningsrettigheten, og hvilken rolle i forretningsrollesettet som bærer den.
• Hvordan proveniens skal vises i mine tilganger.
• Om 500 medlemmer er en hard grense i flaten eller et varsel.
• Om tildeling mot samling skal gjelde brukere, applikasjoner eller begge.
• Om delegering til en applikasjon senere skal kunne uttrykkes mot en samling (i modellen er delegering bevisst holdt utenfor samlingsformen — en applikasjon må delegeres per organisasjon).
• Om en samling skal kunne avvikles, og hva som da skjer med tildelingene mot den.
• Om forvaltningen hører i FS Admin eller i en egen flate for Sikt-interne oppgaver.

Bevisst ikke endret

• krav/krav-oversikt.md — den er generert og allerede utdatert mot filnavnene i repoet; bør regenereres for seg framfor å håndredigeres her.
• Ingen systemkrav.md for den nye kapabiliteten. Nabokapabiliteten 01 Tilganger har ingen, og kravene er for umodne til å beskrives som systemkrav. Legges til når scopet er besluttet.
• Ingenting i veikart/ — samlinger er ikke en planlagt oppgave ennå.
• Eksisterende krav under applikasjoner er urørt.

Ikke merge — dette skal reviewes, og flere av valgene over bør avklares før kravene kan bli noe annet enn utkast.

[krhoybraten-sikt]

Oppdatering: BRU-TIL-SAM-002 (tildeling via samling) er besluttet og under bygging, og er derfor løftet ut i en egen PR — #548 — med @must @planned og semantikken som faktisk bygges. Denne PR-en fortsetter som designdiskusjon for BRU-TIL-SAM-001 og forvaltningen av samlinger og medlemskap, som fortsatt er uavklart.

Kort om det som er besluttet i #548:

• Mottakeren er en applikasjon (applikasjonsadministratorens flyt, som tildeling mot én organisasjon — bare rettet mot en mengde).
• Gatingen er den vanlige tildelingsretten, men den kreves i miljøet for hver aktive medlemsorganisasjon i samlingen — en anti-eskaleringsregel, siden én tildeling mot en samling gir tilgangen i alle medlemmene. Ingen ny rolle, og altså ikke det globale samlingsprivilegiet som forvaltningen må gates på.
• Temporalt og sporbart, idempotent i begge retninger, og tilbaketrekking berører ikke tilgang som består via en direkte tildeling eller en annen samling.
• Reglene er formulert mot en samling som finnes og en medlemsliste som gjelder, så de gjelder uansett om samlingene forvaltes gjennom løsningen eller av databaseforvaltningen.

Praktisk for denne PR-en: #548 bruker samme mappe men et nytt filnavn (tildele_tilgang_mot_organisasjonssamling.feature) og gjenbruker id-en BRU-TIL-SAM-002, så de to kan leve side om side uten konflikt. tildele_tilgang_via_organisasjonssamling.feature her bør fjernes ved neste oppdatering av denne PR-en, slik at 002 bare finnes ett sted.

To spørsmål fra 002 følger med hit, fordi de hører til forvaltningen: revalidering på medlemskapssiden (dekningen vurderes ved tildelingstidspunktet, så en senere innmelding utvider rekkevidden uten at noen sjekk ser det) og provenienssporet i visningen av tilganger.

[krhoybraten-sikt]

Ett moment til forvaltningsdiskusjonen her, fra vurderingen som nå ligger i #547: innmeldingens konsekvensvekt kan øke.

Designnotatet i #547 har fått en underseksjon om samling-skop for de beslektede mekanismene, og anbefaler at også delegeringstak og nekt skal kunne uttrykkes mot en organisasjonssamling (mens gulv og åpne roller ikke bør det, siden en nyinnmeldt organisasjon der er kilden til data som åpnes, ikke mottaker av rekkevidde).

Følgen er relevant for denne PR-en: blir det slik, utøver en innmelding ikke bare de tildelingene som alt står mot samlingen (BRU-TIL-SAM-002, #548), men flytter også taket og nektene for organisasjonen som meldes inn. Medlemskapsforvaltningen blir da ytterligere sikkerhetsbærende, og det skjerper spørsmålene som alt ligger her — hvem som får endre en medlemsliste, og hva som skal revalideres eller varsles når den endres.

[krhoybraten-sikt]

Et erfaringsmoment til forvaltningsspørsmålet, fra uken 18.–25. august. Tre uavhengige hull traff produksjonsflyten, og alle tre hadde samme rotårsak:

• Rolletildelinger fantes i production og i test, men ikke i demo.
• Medlemslisten til en organisasjonssamling var befolket i production, men tom i demo — så tildelinger mot samlingen som eksplisitt gjaldt demo hadde ingenting å utvide seg til, og ga ingen tilgang noe sted.
• Datakilderegisteret som maskinbruker-provisjoneringen leser var tomt i alle deployerte miljøer, til det ble lastet manuelt.

Fellesnevneren er ikke modellen, men forvaltningen: register- og medlemskapsdata vedlikeholdes manuelt, ett miljø om gangen, og demo er miljøet ingen går gjennom før en bruker treffer det. Fail-closed-designet gjorde jobben sin i alle tre tilfellene — avvisningene var presise, og ingen av dem etterlot en stille delvis tilstand — men hver mangel ble likevel funnet reaktivt, av den som først trengte den.

Det er relevant her fordi det er nøyaktig den forvaltningen denne diskusjonen skal avgjøre. Uansett om samlinger og medlemskap ender med å forvaltes gjennom en flate eller gjennom migreringer, bør beslutningen inkludere en miljødisiplin: alle miljøer i samme operasjon, eller et eksplisitt begrunnet avvik. Et medlemskap som bare finnes i ett miljø er et gyldig valg — mengden er per miljø — men det bør være et valg noen har tatt, ikke et miljø noen glemte.

Helst bør bæreren også være reproduserbar, altså en migrering eller et seed framfor en manuell last. Forskjellen viser seg først når en base bygges opp på nytt: en manuell last må gjentas av noen som husker den, mens en reproduserbar bærer følger med. Det er et argument som veier mot ren manuell forvaltning, og for at forvaltningsflaten — hvis den bygges — skriver noe som kan etterprøves og gjenskapes.