Omfang av rettigheter delegert i HelseID
HelseID baserer seg på delegering av rettigheter fra en toppnivå-organisasjon i Altinn. Delegeringen som gjøres i HelseID har bare ett tilgangsnivå. Enten har man fått tilgang til alt, eller ingenting.
Den tekniske avgrensningen av hvilke aktører som behandler data i EDI/EbXml-regimet skjer i Adresseregisteret, der ulike leverandører og enkeltpersoner kan gis tilganger til visse registrerte virksomheter gjennom et eget rollebasert innloggingssystem.
Håndtering av kobling mellom HelseID og Adresseregisteret
Det er i utgangspunktet ingen kobling mellom Adresseregisteret og HelseID-delegasjon.
EDI 2.0 håndterer denne koblingen for å kunne knytte en autentisert HelseID-tilgang til et sett med kommunikasjonsparter. Virksomheten som kommunikasjonspartene er registrert under i Adresseregisteret har et organisasjonsnummer. Dette organisasjonsnummeret må tilhøre den toppnivå-enheten som delegerte tilgang i HelseID, eller en underenhet av den delegerende toppnivå-enheten. Først da vil API-klienten bli autorisert til å hente en melding adressert til en kommunikasjonspart.
Autorisering av forespørsler baseres på organisasjonstilhørighet
Implisitt, vil EDI 2.0 autorisere HelseID-klienten for alle tjenester under en virksomhet registrert i Adresseregisteret. Det åpner for at API-klienten din er autorisert for å hente, lese og kvittere meldinger som egentlig (teknisk sett, ikke juridisk sett) skulle til noen andre.
Inntil HelseID har en god mekanisme for å begrense tilgang til visse adresseringer, er det opp til deg, som bruker av EDI 2.0 å konfigurere riktig, slik at du bare henter de meldingene du skal ha.
Meldinger til andre EDI 2.0-brukere er de som teknisk sett står i fare for å lekke ut. Meldinger til helt andre EDI-aktører vil ikke finnes i EDI 2.0-Meldingstjenerens database. Både tradisjonelle EDI- og EDI 2.0-brukere er dog teknisk sett sårbare for endring i konfigurasjonen i Adresseregisteret, som kan gjøres av autoriserte brukere. Det er som regel snakk om teknisk personell som tilhører en tjenesteleverandør for organisasjonen.
Alle API-handlinger mot EDI 2.0 loggføres. All håndtering av en annen parts meldinger vil EDI 2.0 kunne avdekke nøyaktig i ettertid, men ikke hindre i kjøretid.
Det API-spesifikke claimet herid
Claimet herid i HelseID-klientene som kobler seg til EDI 2.0 vil fases ut, fordi api-spesifikke claim i HelseID er for begrensede.
Poenget med claimet var å kunne scope ned en klient til å bare ha tilgang til visse HerID-er, som vi leste ut ifra claimet. Det hadde muliggjort en oversikt over hvilke klienter som hentet fra hvilke adressenter.
Hovedgrunnen til at claimet herid ikke fungerer i praksis, er at lengden på claimet er forholdsvis kort (50 tegn).