Page Comparison

...

JWT tokens er den eneste autentifikationsform, der bør anvendes af API klienter, idét man herved kun får adgang til det “officielle” API (det der ydes support på).

Kun adgang til læseoperationer

...

API’erne returnerer DTO objekter der repræsenterer en abstraktion af den bagvedliggende datamodel.

OData (

...

V4) REST API

Under stien /odata/* findes KITOS' OData baserede REST APIer. Udover specialiserede endpoints indeholder de fleste et “root query” endpoint som typisk findes på “collection” URI dvs f.eks.:

...

Med denne URI i hånden, kan der foretages OData queries på den delmænge af ressourcen, som brugeren har lov til at se i den aktive kontekst (den organisation som man er logget ind i)kontekst af de rettigheder brugeren har på tværs af dennes organisationsroller.

Det betyder, at hvis man f.eks. er almindelig bruger i en kommuneén (eller flere) kommune(r), så består delmængden af:

• Alle IT-systemer, som er lokalt oprettet i de kommuner som brugeren har roller i.

• Alle IT-systemer i andre organisationer, som er markeret som “Offentlig”.

Ønsker man at få begrænset udfaldsrummet til en specifik kommunes data er det derfor tilrådeligt at benytte de mere specialiserede endpoints, som afgrænser data fra starten af.

Indenfor denne delmængde kan man så anvende standard OData queries til f.eks. at filtrere ($filter), sortere ($orderBy) og begrænse returmængden ($top,$skip).

...

Følgende problemer er identificeret og vil blive løst løbende i forbindelse med videreudviklingen af KITOS.

Sikkerhedsmodellen er ikke implementeret konsekvent

Databeskyttelsen i KITOS gennemtvinges i to skridt.

For det første skal man være en autentificeret bruger - enten ved brug af cookie (fra UI) eller JWT (som API klient).

For det andet, skal man “have lov” (være autoriseret) til at se/ændre på det data man peger ud via APIet.

Den første del - autentifikation - er gennemtvunget konsekvent, mens skridt to - autorisation - ofte fungerer fordi UI kalder endpoints med de rigtige argumenter. Der findes altså endpoints, hvor man kan tilgå lokale data fra andre organisationer selvom man kun er autoriseret til at se data i sin egen kommune. Årsagen hertil findes i, at KITOS ofte realiserer beslutningen om “hvad man må se” i UI, hvorfor APIet “glemmer” at autorisere forespørgslen ned i en konkret organisationskontekst inden data graves frem og sendes tilbage.

Første skridt ift. at løse dette problem blev taget ifm.:

I denne story blev de grundlæggende regler for adgangsstyring i KITOS klarlagt og gennemtvunget på API-niveau for hhv. IT System anvendelser samt IT Systemer i IT System kataloget.

For at løse de resterende vertikaler er der oprettet følgende story:

Alternativt vil den konsoliderede rettighedsmodel blive rullet ud ifm. arbejde i de enkelte vertikaler (Projekter, Kontrakter osv.)

OData-API’erne udstiller domæne/database modellen 1-1

...

Da en stor del af KITOS UI baserer sig på de faciliteter, der er årsag til ovennævnte problemer, vil de eksisterende OData APIer i første omgang bestå i sin nuværende form men vil langsomt blive flyttet væk fra det interne API og kun kunne anvendes af UI.

Endpoints returnerer bredere forspørgsler end man tror

...

• Alle IT Systemer, som man har lov til at se i organisation '1'

• Hvis man er bruger i en komme kommune eller global admin, får man også IT Systemer fra andre organisationer som er delt dvs. “Synlighed=Offentlig”

...

• At overvåge anvendelsen af det nuværende API, således at vi nemmere kan fokusere indsatsen på de områder der anvendes mest.At få udrullet den konsoliderede sikkerhedsmodel, således at vi som minimum kun afleverer data jf. brugerens rettigheder.

• At versionere nye API endpoints.

...