Autentisering av nettkunde i nettutleverers portal

Owned by e-resept
Last updated: Mar 01, 2024 by Sven Erik Johansson
5 min read

Innledning

For å få utlevert informasjon om resepter i nettutleverers portal må kunden autentisere seg. Autentiseringen utføres gjennom pålogging i ID-porten på høyeste sikkerhetsnivå (nivå 4).

Historisk sett har ID-porten benyttet SAML2-standarden. Denne skal fases ut og erstattes av OAuth2.0/OIDC.

Autentiseringsinformasjon utveksles mellom nettutleverer og ID-porten og når kunden har autentisert seg gjennom ID-porten, kan nettutleverer sende forespørsler til Reseptformidleren.

Reseptformidleren vil verifisere kundens autentisering. Forespørsler fra nettkunde til Reseptformidleren (M9NA1 Forespørsel om reseptliste fra nettkunde og M9NA3 Forespørsel om utvidet informasjon på resept fra nettkunde) skal inneholde et teknisk bevis slik at Reseptformidleren kan verifisere autentiseringen.

Det tekniske beviset som nettutleverer mottar fra ID-porten legges ved som vedlegg til hodemeldingen i M9NA1 og M9NA3.

Datautveksling ved bestilling av reseptbelagte varer på internett

For å tilby bestilling av reseptbelagte varer på Internett vil nettutleverers løsning bestå av en portal i tillegg til utleverersystemet. Portalen er tilgjengelig på Internett (ekstern sone), mens utleverersystemet (som er i sikker sone) kommuniserer med Reseptformidleren over helsenettet. Kommunikasjon med Reseptformidleren som initieres fra portal i nettutleverer skal gå gjennom utleverersystemet. Portalen kan ikke kommunisere direkte med Reseptformidleren, og skal ikke benytte meldinger på e-resept format. Dette er illustrert i figuren under.

Verifisering av teknisk bevis på kundens autentisering i portal nettutleverer

OAuth2.0/OIDC basert verifisering

Reseptformidlerens nettutleverertjeneste støtter også OAuth2 eller OIDC basert autentisering av bruker. OAuth2 flyten baserer seg på ID-porten sin støtte for brukerstyrt datadeling. Selve tokenet reseptformidleren forventer er en signert jwt "self-container/by value", hvilke felter som er forventet med hva følger.

Validering av token

Reseptformidleren vil verifisere kundens autentisering ved å validere følgende om OIDC tokenet, terminologien OIDC token og access token brukes om en annen her.

  • Validere at tokenet er en signert jwt

  • Validere at tokenet er utstedt av ID-porten (iss claimet er som idporten beskriver)

    • I test https://test.idporten.no

    • I produksjon https://idporten.no

  • Validere at tokenet ikke er utgått (exp claim)

  • Validere at tokenet er signert av ID-porten (er tokenet signert med privatnøkkelen som tilsvarer den offentlig nøkkelen id-porten referert til fra well-known)

  • Validere at tokenet er tiltenkt reseptformidleren (audience claim “aud”)

    • for alle test miljø: http://nhn.test2-na.reseptformidleren.net/NA/NAWebServiceSoapHttpPort

    • for prod: http://nhn.prod-na.reseptformidleren.net/NA/NAWebServiceSoapHttpPort

  • Validere at tokenet kun har følgende  scope:  "eresept:nettutleverer" og "openid". Dette gjelder for M9NA1 og M9NA3.

  • Nettutlevererens identitet skal verifiseres og stemme over ens i M9NA1/M9NA3 og OIDC token:

    • Nettapotekets juridiske enhet sitt organisasjonsnummer skal være i ISO6523 format i "consumer" claimet, se på ID-porten sin dokumentasjon om access token for mer info.

    • Internt oppslag i Reseptformidlerens register over aktører skal gjøres for å validere at organisasjonsnummeret i nettapotekets virksomhetssertifikat stemmer.

  • Validerer at identiteten angitt som pålogget kunde i M9NA1/M9NA3 er den samme identiteten som angitt i OIDC tokenets pid claim. Identitet er enten fødselsnummer eller d-nummer.

  • Validerer at tokenet har sikkerhetsnivå 4 (claim acr er idporten-loa-high), dvs kunden har logget inn med bankid.

  • Validerer i tokenet at klienten (nettutlevereren) har autentisert seg mot ID-porten med virksomhetssertifikat eller private_key_jwt (d.v.s. integrasjonen mot ID-porten er med "private_key_jwt") effektivt at client_amr claimet er virksomhetssertifikat eller private_key_jwt.

Et eksempel på base 64 de-enkodet access token fra ID-porten er gitt under:

// Header (merk denne linjen er kun hjelpetekst) { "kid" : "digitaliseringsdirektoratet--cert0", "alg" : "RS256" } // Payload (merk denne linjen er kun hjelpetekst) { "sub" : "19108209340", "iss" : "https://test.idporten.no", "client_amr" : "private_key_jwt", "pid" : "19108209340", "client_id" : "57308738-56fa-4676-b422-83269165b00e", "aud" : [ "http://nhn.test2-na.reseptformidleren.net/NA/NAWebServiceSoapHttpPort", "57308738-56fa-4676-b422-83269165b00e" ], "acr" : "idporten-loa-high", "scope" : "eresept:nettutleverer openid", "supplier" : { "authority" : "iso6523-actorid-upis", "ID" : "0192:994598759" }, "exp" : 1698852734, "iat" : 1698852434, "jti" : "-DmVMB32Cmo", "consumer" : { "authority" : "iso6523-actorid-upis", "ID" : "0192:983044778" } } // Signatur (merk denne linjen er kun hjelpetekst) mm2PqEEdKW-f-OjdpGlsDJcHjv6WzWLaObbqcZ40XPQ8YorS2EPq_588Pz0QJ-kEQpdTNfDm5OQadIgSeGWn8LXh7ePE5Q9B4blf9rtXlJ_Uhn43XyZ7793kaKer41VTXgKi68Ltt8lny_X9aOk2J409WOLBWp17mrIbt4M2sU8M04_jx931X_z6n5U3Jse2wkzoXL9f4bp_nlbC-_tzho8dH-b6EIBgV3lFJCe7XuAabtYl9cGL11TQ4FmEyhF2GyM7UqAzWiDhKiM0gPjl92dflb-9PThq0Z7ljnB4Q8dKC92zeny0mTC_vQ50-ElvH4NSJekeM4SWzXCK9OlkiPni4ci8tICpz0Ove9mK3xo2J9N-V3gAv7p3a37DETtYjSsomVcMKCdNCdlaunYejyO9edKCXz8NAKPNzs8BXE89hffep3YJJbfuB3joDUhmUtf9Z0j_Ce7oo9TKOGJ9ePOkUIIoDOH9JdyG3_x8OSuu2tMLnrl-vnUIPd5FyBb3

Merk at "supplier" feltet eksisterer kun fordi vi er en leverandør som

Det tilsvarende rå access tokenet er en jwt (json web token) som sett under

Rå access token jwt
eyJraWQiOiJkaWdpdGFsaXNlcmluZ3NkaXJla3RvcmF0ZXQtLWNlcnQwIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIxOTEwODIwOTM0MCIsImlzcyI6Imh0dHBzOi8vdGVzdC5pZHBvcnRlbi5ubyIsImNsaWVudF9hbXIiOiJwcml2YXRlX2tleV9qd3QiLCJwaWQiOiIxOTEwODIwOTM0MCIsImNsaWVudF9pZCI6IjU3MzA4NzM4LTU2ZmEtNDY3Ni1iNDIyLTgzMjY5MTY1YjAwZSIsImF1ZCI6WyJodHRwOi8vbmhuLnRlc3QyLW5hLnJlc2VwdGZvcm1pZGxlcmVuLm5ldC9OQS9OQVdlYlNlcnZpY2VTb2FwSHR0cFBvcnQiLCI1NzMwODczOC01NmZhLTQ2NzYtYjQyMi04MzI2OTE2NWIwMGUiXSwiYWNyIjoiaWRwb3J0ZW4tbG9hLWhpZ2giLCJzY29wZSI6ImVyZXNlcHQ6bmV0dHV0bGV2ZXJlciBvcGVuaWQiLCJzdXBwbGllciI6eyJhdXRob3JpdHkiOiJpc282NTIzLWFjdG9yaWQtdXBpcyIsIklEIjoiMDE5Mjo5OTQ1OTg3NTkifSwiZXhwIjoxNjk4ODUyNzM0LCJpYXQiOjE2OTg4NTI0MzQsImp0aSI6Ii1EbVZNQjMyQ21vIiwiY29uc3VtZXIiOnsiYXV0aG9yaXR5IjoiaXNvNjUyMy1hY3RvcmlkLXVwaXMiLCJJRCI6IjAxOTI6OTgzMDQ0Nzc4In19.mm2PqEEdKW-f-OjdpGlsDJcHjv6WzWLaObbqcZ40XPQ8YorS2EPq_588Pz0QJ-kEQpdTNfDm5OQadIgSeGWn8LXh7ePE5Q9B4blf9rtXlJ_Uhn43XyZ7793kaKer41VTXgKi68Ltt8lny_X9aOk2J409WOLBWp17mrIbt4M2sU8M04_jx931X_z6n5U3Jse2wkzoXL9f4bp_nlbC-_tzho8dH-b6EIBgV3lFJCe7XuAabtYl9cGL11TQ4FmEyhF2GyM7UqAzWiDhKiM0gPjl92dflb-9PThq0Z7ljnB4Q8dKC92zeny0mTC_vQ50-ElvH4NSJekeM4SWzXCK9OlkiPni4ci8tICpz0Ove9mK3xo2J9N-V3gAv7p3a37DETtYjSsomVcMKCdNCdlaunYejyO9edKCXz8NAKPNzs8BXE89hffep3YJJbfuB3joDUhmUtf9Z0j_Ce7oo9TKOGJ9ePOkUIIoDOH9JdyG3_x8OSuu2tMLnrl-vnUIPd5FyBb3

For å være tydelige forventer reseptformidleren at det rå access token jwt’en er base64 enkodet. Altså:

val accessTokenJwtString = "eyJraWQiOi..." val forventetFormat = Base64.encode(accessTokenJwtString)

 

SAML basert verifisering

SAML basert verifisering i ID-porten fases ut og erstattes av OAuth2.0/OIDC.

SAML Assertion profilene til ID-porten er dokumentert på: http://begrep.difi.no/ID-porten

Reseptformidleren vil verifisere kundens autentisering ved å validere følgende i SAML Assertion:

  • Validere SAML Assertion mot skjema

  • Validere at SAML Assertion er utstedt av ID-porten

  • Validere at tidsstempel i SAML Assertion er gyldig (NotBefore og NotOnOrAfter i Conditions, innenfor et tidsintervall konfigurert i Reseptformidleren)

  • Validere at signaturen er gyldig for SAML Assertion

  • Validere sertifikatet, ved å validere både signatursertifikatet og hele sertifikatkjeden:

    • Sertifikatet er utstedt av godkjent CA

    • Sertifikatet har gyldig tid og dato (sjekk ‘not before’ og ‘not after’)

    • Sertifikatet har ikke blitt revokert

    • Sertifikatet har korrekt «Key usage» : digitalSignature (0) eller contentCommitment(1)

    • Signatursertifikatet er utstedt til godkjent SAML Assertion utsteder: Difis orgnummer skal ligge i SERIALNUMBER

  • Nettapotekets identitet skal verifiseres og stemme over ens i M9NA1/M9NA3 og SAML Assertion:

    • Nettapoteket blir autentisert gjennom å kontrollere signaturen på meldingen M9NA1/M9NA3. Dette virksomhetssertifikatet skal inneholde apotekets organisasjonsnummer på standard måte; Det vil si at organisasjonsnummeret ligger i OU-feltet på Buypass-sertifikater (ikke avklart for Commfides-sertifikater)

    • Nettapotekets interne ID-porten-identitet ligger i SAML Assertion i feltet Audience (Audience i Conditions). Som en del av registreringsprosessen for nettapotek må denne identiteten oppgis til e-helse, og registreres i Reseptformidleren sammen med nettapotekets HER-ID og organisasjonsnummer.

    • Internt oppslag i Reseptformidlerens register over aktører skal gjøres for å validere at organisasjonsnummeret i nettapotekets virksomhetssertifikat stemmer over ens med nettapotekets ID-porten identifikator Audience.

  • Identiteten angitt som pålogget kunde i M9NA1/M9NA3 er den samme identiteten som angitt i SAML Assertion (<saml:Attribute Name="uid">). Identitet er enten fødselsnummer eller d-nummer

  • SAML Assertion skal ha sikkerhetsnivå 4(<saml:Attribute Name="SecurityLevel">)

Et eksempel på SAML Assertion fra ID-porten er gitt under:

SAML Assertion eksempel