Krav: forvalte tilgangskatalogen gjennom API, med eget nivå for dokumentasjon (BRU-TIL-KAT-001/002) - #563
Krav: forvalte tilgangskatalogen gjennom API, med eget nivå for dokumentasjon (BRU-TIL-KAT-001/002)#563krhoybraten-sikt wants to merge 1 commit into
Conversation
…1/002) Tilgangskatalogen forvaltes i dag bare av databaseforvaltningen. Kravene gir den et API med to rettighetsnivåer: utviklere hos Sikt kan opprette, endre og ta en tilgang ut av bruk, mens en egen rettighet gir rett til å oppdatere beskrivelsen — og ingenting annet. Skillet er hensikten. Dokumentasjonen av en tilgang eldes raskest og skrives best av dem som kan fagområdet, mens ingen får eller mister tilgang av at teksten endres. Avgrensningen til beskrivelsen er derfor formulert som et håndhevingskrav: et forsøk på å endre noe annet skal avvises i API-et og i datalaget, uansett inngang, også når det følger med i den samme forespørselen som en gyldig beskrivelsesendring. Kravene omfatter også en listespørring over hele katalogen, paginert og forutsigbart sortert. Ingen av dagens innganger viser katalogen i sin helhet — alle listene er avledet av tildelinger — så en tilgang uten tildelinger er i dag usynlig i løsningen. Begge nivåene trenger den listen, dokumentasjonsnivået mest, siden det er de udokumenterte tilgangene arbeidet handler om. Designnotatet peker på de to hullene kravene forutsetter tettet: listespørringen, og en markør for at en tilgang er tatt ut av bruk — katalogen har i dag ingen livsløpstilstand, og sletting er utelukket fordi tildelinger og tak refererer koden.
Kravutvidelse: rolleforvaltningens semantikkDenne saken dekker i dag opprettelse, endring og dokumentasjon av enkelttilganger, med håndhevet kolonneskop og listespørring. Når forvaltningen åpnes gjennom API, trenger seks forhold som i dag bare finnes som databasepolicyer, tabellkommentarer eller praksis, kravstatus. Uten dem har implementasjonen ingenting å reviewes mot. 1. Eskaleringsgrensen for implikasjoner (forslag: BRU-TIL-KAT-003)En rolleimplikasjon («har du A, har du også B») kan bare opprettes eller fjernes av en som har forvaltningsprivilegiet i begge de berørte rollenes navnerom-eierorganisasjoner. Uten tokravet kan en forvalter i ett navnerom gi sine egne roller rekkevidde inn i et annet. Regelen håndheves i dag av databasepolicy, men er ikke kravfestet. 2. Asyklisitet på implikasjonsgrafen (forslag: BRU-TIL-KAT-004)Implikasjonsgrafen skal være asyklisk, og en endring som ville skapt en syklus skal avvises i sin helhet. Det finnes i dag ingen skranke og ingen test; med et skrive-API er en syklus ett kall unna, og konsekvensen er total privilegiesammensmelting mellom rollene i syklusen. 3. Delegeringstakets forhold til katalogendringer (forslag: BRU-TIL-KAT-005)En delegeringstak-rad refererer rollen som levende definisjon: endres rollens implikasjoner, endres takets effektive rekkevidde tilsvarende — det er tilsiktet, ikke en lekkasje. Implikasjonsendringer skal derfor ikke avvises fordi de utvider et eksisterende tak. Konsekvensen som må kravfestes er den motsatte veien: den som forvalter implikasjoner må forstå at endringen virker inn i alle tak som refererer rollene — semantikken skal være dokumentert på operasjonene. 4. Utgått-semantikk for roller — ⚠ venter på teambeslutningHva det betyr å ta en rolle ut av bruk: hva skjer med eksisterende tildelinger (foreslått: ingenting — frys framover), om rollen kan gjenopptas, og om en utgått rolle kan inngå i nye implikasjonskanter (foreslått: nei). Skrives inn når beslutningen er tatt; punktet står her for fullstendighet. 5. Rollekodeformat og navneromsprefiks (forslag: BRU-TIL-KAT-006)Om API-et skal validere rollekodens form, og forholdet til kodeprefiks per navnerom. Må være avklart før navnerom av typen «organisasjon» får skriverett — ellers kan to navnerom skape koder som kolliderer i den globale katalogen. 6. Flytting mellom navnerom som sporbar operasjon (forslag: BRU-TIL-KAT-007)Flytting av en rolle til et annet navnerom er en egen governance-operasjon, ikke en vanlig feltendring: den krever forvaltningsprivilegiet i begge navnerommenes eierorganisasjoner (USING på det gamle, WITH CHECK på det nye). Merk at datamodellen i dag bare bærer siste endring ( Punkt 1, 3 og 6 er premisser de kommende endringene bygger inn i koden; punkt 2 er sikkerhetskritisk fra første skriveoperasjon. Bare punkt 4 venter på en beslutning. |
2 participants
Tilgangskatalogen — listen over hvilke tilganger som finnes, og hva hver av dem gir — forvaltes i dag bare av databaseforvaltningen. Denne PR-en beskriver kravene til å forvalte den gjennom API, med to rettighetsnivåer.
De to nivåene
Begrunnelsen for det andre nivået er at dokumentasjonen av en tilgang eldes raskest og skrives best av dem som kan fagområdet, mens risikoen er lav på en presis måte: en beskrivelse leses ikke av autorisasjonen. Ingen får eller mister tilgang av at teksten endres, og ingen tildeling berøres. Uten et eget nivå må hver tekstforbedring gå gjennom dem som kan endre modellen — og da blir den ikke gjort.
Kolonneskopet er et håndhevingskrav
Den delen som er verdt review: at dokumentasjonsrettigheten bare omfatter beskrivelsen er formulert som et krav til håndhevingen, ikke til hvilke felter en flate viser. En flate som skjuler kodefeltet, over et API som tar imot hele katalograden, oppfyller ikke kravet — da er avgrensningen bare en presentasjon, og enhver klient som snakker med API-et direkte står utenfor den.
Featuren har derfor egne scenarioer for de to formene som skiller et håndhevet kolonneskop fra et presentert et: en forespørsel som endrer både beskrivelsen og noe annet avvises i sin helhet, og avgrensningen gjelder likt når API-et brukes direkte. Designnotatet anbefaler dessuten at dokumentasjonsnivået får sin egen operasjon, som bare tar imot en kode og en beskrivelse, framfor å dele en generell endringsoperasjon og filtrere på rettighet inne i den.
Katalogen kan ikke listes i dag
Kravene omfatter også en listespørring over hele katalogen, paginert og forutsigbart sortert, lesbar for begge nivåene. Ingen av dagens innganger viser katalogen i sin helhet: listene som finnes er alle avledet av noe annet — tilgangene en applikasjon har, tilgangene jeg selv har, tilgangene jeg kan tildele. En tilgang som ennå ikke er tildelt noen finnes dermed i modellen, men er usynlig i løsningen.
Det rammer begge nivåene, og dokumentasjonsnivået hardest: de udokumenterte tilgangene er nettopp dem som ofte ikke er tildelt noen, altså dem ingen liste viser. Paginering er tatt inn i kravet framfor å overlates til utformingen, fordi katalogen verken har organisasjon eller miljø å avgrense på.
To hull kravene forutsetter tettet
Designnotatet navngir dem eksplisitt, siden begge er modellarbeid og ikke bare flatearbeid:
Valg
BRU-TIL-KAT-001ogBRU-TIL-KAT-002, etter mønsteret fra naboene under samme kapabilitet (BRU-TIL-SAM-*for organisasjonssamlinger,BRU-TIL-DEL-*for delegeringstak). Plassert i en ny kapabilitetsmappe11 Tilgangsstyring/04 Tilgangskatalogen.Implementasjonen kommer i FS-plattformen; denne PR-en dekker kravsiden.
Ikke merge — til gjennomlesning.