Implementere full autorisasjonskontroll på dialoger i søke-API for sluttbrukere

[elsand]

Søke-API-et skal i likhet med oppslag på enkelt-dialoger (#43) være gjenstand for autorisasjons. Hvorvidt tilgang skal gis for et gitt elemeent defineres på samme måte som i #43, altså at den autentiserte brukeren er gitt enten en rolle eller tjeneste-/instansrettighet for den aktuelle dialogen. Det skilles altså ikke på "actions" her; brukeren kan f.eks. kun være gitt "sign", men også det vil være nok til å kunne se dialogen i både søke- og detalj-API-et i Dialogporten.

En "naiv" tilnærming til være å først foreta søket i databasen basert på de parametre som oppgis, og så autorisere dem etterpå (enten én og én eller i batcher av multi-requests). Dette vil ikke fungere, siden det vil være mulig å konstruere søk som treffer veldig mange elementer i databasen, men hvor brukeren bare er autorisert til å se en liten del av dem. LIMIT-delen av spørringen vil derfor kunne føre til at man ikke treffer noe av det brukeren er autorisert for i det hele tatt, og vil da ende opp med en tom liste. I Altinn2 er dette "løst" med at man gjør en noenlunde spisset spørring på en "kandidatliste" på inntil 5000 elementer, som da autoriseres etterpå. Dette er ineffektivt, og gjør bl.a. paginering vanskeligere.

En bedre løsning er å foreta en autorisasjonforespørsel først basert på søkeparametrene, og basert på svaret man får, bygge en spørring til database som inkorporerer denne informasjonen, slik at det en får tilbake fra databasen alltid er noe brukeren er autorisert til å se. Dette har vesentlige fordeler:

• Det blir én forespørsel til autorisasjonskomponenten per request til Dialogporten
• For påfølgende requests som itererer over sider med dialoger (via after-parameter), eller bare endrer på sortering, blir autorisasjonsforespørselen den samme; så en kortlevd cache på denne requesten vil ha god effekt
• Paginering kan implementeres på vanlig måte

En utfordring med denne løsningen er at det vil føre til stor ulikhet i queries mot databasen, og noen vil potensielt kunne innholde store mengder parametere i worst case (f.eks. DAGL hos et stort regnskapshus vil med søk kun på tjenesteressurs ende opp med at det blir sendt noe tilsvarende en WHERE party IN (...) med titusenvis av verdier. Instansdelegeringer må også håndteres. Det antas dog at dette er et enklere problem å skulle optimalisere, enn en tilnærming hvor én og én autoriseres i etterkant.

Per kriteriene i #34 vil vi som et minimum enten ha en liste med tjenesteressurser eller en liste med parties brukeren ønsker å filtrere på, så det er disse tre casene som må støttes:

For autentisert bruker, uthenting av alle autoriserte dialoger ...

• Case 1: ... for en eller flere parties og hvilken som helst tjenesteressurs
• Case 2: ... for en eller flere tjenesteressurser og hvilken som helst party
• Case 3: ... for en eller flere tjenesteressurer for en eller flere parties

Antagelsen er at et case hvor det verken filtreres på tjenesteressurs eller parties vil være for krevende ytelsesmessig (siden man for hver eneste party (eller ressurs) også må finne ut alle autoriserte ressurser (eller parties). En slags "upper bound" for antall "ressurstilganger" (altså en eller annen tilgang til en ressurs for en party) vil være antall ressurser*antall avgivere, som for enkelte brukere vil kunne være mange millioner. Ved å kreve én av delene, og ha et maks antall verdier i disse listene kan man begrense størrelsen på reponse-payloads for brukere som har svært mange avgivere.

Oppslag mot API-er i access-management

For case 2 kan det benyttes noe ala /{party}/authorizedparties/filtered, hvor man da oppgir autentisert bruker som {party} og legger inn oppgitte tjenesteressurser i filterResource. En utvidelse i må imidlertid på plass for å kunne håndtere å vite hvilke av de oppgitte tjenesteressursene er det gitt tilgang til for hver party, samt instansdelegering, altså hvor autentisert bruker kun er autorisert for enkelte instanser knyttet til en tjenesteressurs. F

EDIT: utlisting av ressurser er blitt forsøkt, men dette blir for ytelseskrevende og resulterer i enorme DTOer. Dette API-et vil kun gi en liste over hvilke roller/access groups innlogget bruker har for et gitt party. Instansdelegering vil komme ettehvert.

For case 1 vil det være behov for det "inverse" oppslaget, altså noe ala /{party}/authorizedresources/filtered, hvor man sender inn en request-modell med en filterParties, og får tilbake en liste med de tjenesteressursene brukeren har tilgang til. Også her vil det være behov for en håndtering av tjenesteressurser/parties, samt instansdelegering tilsvarende utvidelsen skissert for case 2.

EDIT: case 1 vil ikke implementeres i denne omgang

Eksempel på responsmodell for authorizedresources

{
    "hasAccessToResources": [
        { "resource": "urn:altinn:someresource1", "forParties": [ "/org/91001337" ] },
        { "resource": "urn:altinn:someresource2", "forParties": [ "/org/91001337", "/org/91001338" ] },
        { "resource": "urn:altinn:someresource3", "forParties": [ "/org/91001338" ] }
    ],
    "hasAccessToInstances": [
        "e4ae8a00-ad20-4aae-bbe8-3b922c901a5d", "b8643c00-c826-41c7-8758-bfc0ca5c19fa"
    ]
}

For case 3 vil begge oppslagene kunne brukes, hvorpå Dialogporten etterpå filtrerer resultatet utfra oppgitt party- eller tjenesteressurs-filter. Her vil man potensielt kunne dynamisk velge det ene eller det andre kallet avhengig av hvor mange parties eller tjenesteressurser det filtreres på.

EDIT: det må etableres en cache i Dialogporten som mapper ressurs og rolle/access group. Dette krever et nytt API i resource registry, samt en mekanisme for synkronisere.

Tasks

Preview Give feedback

1. Diskutere alternativ med arkitekter i Team Tilgangsstyring / Tilgangskontroll
2. Etablere nytt API i resource registry for å kunne hente endrede ressurs/subject-par
3. Etablere join mot ressurs/subject-tabell i Dialogporten
4. Etabler synkroniseringsmekanisme (function app?) som regelmessig oppdaterer Dialogporten-kopien

Akseptansekriterier

GITT en autentisert bruker som foretar en request til søke-API-et
NÅR brukeren har tilgang til en gitt dialog som omfattes av søket
SÅ skal dialogen inkluderes i responsen

GITT en autentisert bruker som foretar en request til søke-API-et
NÅR brukeren ikke har tilgang til en gitt dialog som omfattes av søket
SÅ skal dialogen ikke inkluderes i responsen

De funksjonelle kriteriene for #34 ligger for øvrig til grunn.

Avhenger av

• Authorized Parties API (aka new ReporteeList) altinn-access-management#563

Se også

• Etablere søke-API for dialoger for sluttbrukere #34
• Implementere autorisasjonskontroll på detaljvisninger av dialoger for sluttbrukere #43