Identifisering, autentisering og tilgangskontroll for representanter. 10. September 2019 // IT-arkitektur // Håkon Jendal

Transkript

1 Identifisering, autentisering og tilgangskontroll for representanter 10. September 2019 // IT-arkitektur // Håkon Jendal

2 Hvem skal digitalt kunne benytte NAVs løsninger? Person Person representerer annen person Ansatt i virksomhet System i virksomhet Ansatt representerer person Person med embedsfullmakt representerer person Ansatt i en virksomhet på vegne av en annen virksomhet System i en virksomhet på vegne av en annen virksomhet Ditt NAV Arbeidsgiverportal APIer NAV løsninger 2

3 Identifisering og autentisering av representant En forutsetning for å kunne tilby digitale løsninger til representanter er at representanten først må identifiseres og autentiseres digitalt (bunnplanke) Enhetlig måte å logge seg på offentlig sektor Uavhengig av om man skal representere seg selv, en annen eller en virksomhet Identifisert og autentisert bruker representeres på standardisert måte Standard token Må ha full tillit til token utsteder Sentral del av tillitskjeden i offentlig sektor 3

4 Identifisering og autentisering av representant ved møte med offentlig virksomhet ID-porten eller annen tiltrodd 3 part for offentlig sektor Identifisering Autentisering Standardisert token Person Representant Ditt NAV 4

5 Tilgangskontroll representant For å kunne tilby digitale løsninger for representanter er man avhengig av at representasjonsforhold er digitalisert (bunnplanke) Det må finnes digitale mastre (Autorative kilder) for forskjellige typer representasjonsforhold Eksempler for personer Verge Foresatt Advokater og andre personer med embedsfullmakt NAV spesifikke fullmakter Helse spesifikke fullmakter Eksempler for ansattforhold Arbeidsforhold (Arbeidsgiverregisteret) Roller ansatt har i en virksomhet (Altinn Autorisasjon)

6 For å kunne tilby digitale tjenester til en representant, må man ha digitaliserte representasjonsforhold av god kvalitet Representant Digital behandling Advokater Verge Foresatt Helse roller (HPR) Eksempler på kilder som vil benyttes ved tilgangskontroll for å avklare om representant har tillatelse til å utføre digital handling på vegne av den man representerer

7 Tilgangskontroll arkitektur (XACML arkitektur) Forespørsel Data eller avslag Policy enforcement point (PEP) Forespørsel hvis tilgangskontroll OK Data (eller handling utført) Tjeneste Tilgangskontroll sjekk Tilgangskontroll beslutning Policy decision point (PDP) Attributt forespørsel Attributter Policy information point (PIP) Policy lager Attributt lager

8 Tilgangskontroll på tjeneste IDporten Person Representant 1. Bruker representerer seg selv Ett sett med tilgangsregler 2. Bruker blir representert av andre Ett annet sett med tilgangsregler Ditt NAV Hvem som gjør handling blir sporet av tjenesten, uavhengig av om det er bruker eller representant. PEP NAV-tjeneste Sporingslogg Pålogget bruker (dokumentert i token) jobber på ressurs (den man representerer) PDP Autorative kilder F. eks. Altinn Autorisasjon, NAV Fullmakt etc. PIP 8

9 Å tenke på Bruker må for hver enkelt virksomhet velge hvem man skal representere Hvordan bør dette gjøres? Bør kanskje peke på en beste praksis? Et eksempel: På helsenorge.no velger man hvem man representerer etter pålogging Hvordan skal advokater og andre som har en embedsfullmakt velge hvem man skal representere? Hva når representant skal representere den representerte på tvers av flere offentlige virksomheter? Hvordan bør brukeropplevelsen for bruker da være? Hvor reell er denne problemstillingen? Vil de fleste tilfellene være at man er representant mot kun en virksomhet der og da? Skal vi eller skal vi ikke stille krav på hvordan autorative kilder gir informasjon om representasjonsforhold i rollen som Policy information point (PIP)? Det er krav om at alle handlinger må spores og resultat arkiveres Dette blir ikke mindre viktig når en representant utfører en handling på vegne av noen 9

10 Token kan benyttes mot bakenforliggende løsninger for å muliggjøre at bruker henter egne data (bruker eier egne data) Subjekt er representant, ressurs er den man representerer. Person Representant Ekstern applikasjon Tjeneste må kontrollere om representant har rett til å hente noe på vegne av den representerte. Tjeneste må tydelig må skille mellom mekanismer benyttet for sikkerhet og behandling knyttet til ressurs. Hva betyr dette for API utforming? NAV tjeneste 10

11 Ansatt gjør digital handling på vegne av virksomhet Tilsvarende mønster som vi har gått igjennom for personer ID-porten støtter identifisering og autentisering Tilgangskontroll benytter de autorative kildene man har behov for 11