...

Den nationale sundhedsføderation er adskilt fra den fælles offentlige føderation (OCES/NemIdNemID/NemlogNemLog-in).

• Den nationale sundhedsføderation benytter den fælles offentlige føderation til bruger-autentifikation (log-in)
• Den nationale sundhedsføderation har eget adgangsrolle-koncept, egen sessionsmodel og egne adgangsbilletter (SOSI idkort).

...

Ved overgangen fra NemID/OCES2 til MitID/OCES3 ændres den fællesoffentlige føderation:

• NemId NemID erstattes af MitID
  • Medarbejdere oprettes i MitID Erhverv
• OCES2 erstattes af OCES3 (MOCES2 erstattes af MOCES3 og FOCES2 samt VOCES2 erstattes af VOCES3)
• Nemlogin NemLog-in understøtter ikke medarbejdersignatur (MOCES3)
• Store brugerorganisationer kan etablere egne IdentityProviders (IdP’er)
• NSIS erstattes af NIST (National Standard for Identiteters Sikringsniveauer) anvendes fremover og erstatter anvendelsen af NIST-autentifikationsniveauer
• OIOSAML2 erstattes af OIOSAML3

Den nationale sundhedsføderation, som benytter den fællesoffentlige føderation til bruger-autentifikation, skal tilpasse sig er blevet tilpasset til de ovenstående ændringer.

Hvad påvirkes/påvirkes ikke i den nationale sundhedsføderation ved overgangen til MitID/OCES3?

...

Da den nationale sundhedsføderation benytter den fællesoffentlige føderation til bruger-autentifikation, så sker de største ændringer i forhold til bruger-autentifikation, samt i forhold til omveksling af adgangsbilletter(tokens) fra den fællesoffentlige føderation til adgangsbilletter, der kan benyttes i den nationale sundhedsføderationen. Tokens (SOSI idkort) og sikkerhedsprotokol (DGWS) anvendt indenfor sundhedsføderationen ændres ikke. **CHG: Tilføj noget om at IDWS tokens og protokol for borgere heller ikke ændres **

Ovenstående er illustreret i nedenstående figur og uddybes i teksten nedenfor.

...

De enkelte brugerorganisationer (en lægepraksis, et apotek, en kommune, en region mm.) skal vælge **CHG: Her mangler noget ** eller etablere en Identity Provider (IdP) samt en model til 2-faktor nøgler autentifikation (eksempelvis chip-, kodeviser- eller app-baseret 2-faktor).

• Små brugerorganisationer, som eksempelvis lægepraksis og apoteker, forventes at anvendes NemlogNemLog-in som IdP samt at anvende MitID Erhverv til brugeradministration. NemlogNemLog-in **CHG: Det er vel MitID og ikke NL? ** tilbyder forskellige standard 2-faktor nøgler autentifikationsmekanismer (jf. https://migrering.nemlogNemLog-in.dk og https://www.MitID.dk/kom-i-gang-med-MitID/MitID-identifikationsmidler/)
• Regionerne realiserer egne lokale IdP’er til medarbejder-autentifikation. Et par af regionerne forventer at blive klar med en såkaldt NSIS registreret IdP. Resten af regionerne forventer i en overgang at erstatte deres MOCES2 infrastruktur med en MOCES3 infrastruktur. 
• Kommunerne samarbejder, via Kombit, om at etablere en fælleskommunal NSIS registreret IdP (omtalt Context-handler), som den enkelte kommune IdP tilkobles.

Borger-autentifikation:

Borgere anvender NemlogNemLog-in som IdP, hvorfra de anvender deres nye MitID og MitID app som 2-faktor.

...

Virksomhedscertifikater VOCES2 erstattes med VOCES3.

SEB:

...

IdentityProvide

SEB-IdP'en er en såkaldt broker, der forbinder en ServiceProvider (SP, den tjeneste brugeren tilgår - eksempelvis en webportal som sundhedSundhed.dk, FMK-online, DPSD, SEI2, eller et fagsystem som EOJ eller LPS) med brugerens login-sted (brugerens hjemme-IdP, hvilket kan være NemlogNemLog-in, en regional IdP eller kommunernes contextContext-handlerHandler).

Ved overgange til MitID opdeles SEB i en SEB-borger-IdP og en SEB-medarbejder-IdP. Med opsplitningen opnås en mere robust løsning, hvor medarbejderlogin ikke påvirket af høj trafik på borgerlogin. **CHG: SDK anvender ikke SEB til borgeradgang. Erstat med 'webapotekt' i nedenstående?**

Figuren ovenfor illustrer opsplitningen i SEB-borger-IdP og SEB-Medarbejder-IdP. På højresiden ses SP'erne og på venstresiden ses hjemme-IdP'erne.

...

Medarbejderen vil opleve en anden brugerrejse, da medarbejderen skal tage stillig til, hvilken hjemme-IdP de skal anvende til log-in. Tidligere havde SEB ingen brugergrænseflade og sendte automatisk brugeren videre til login i NemlogNemLog-in. I fremtiden vil medarbejdere skulle vælge hjemme-IdP (NemlogNemLog-in, en regional IdP eller en kommunal IdP) via en grænsefalde i SEB. 

...

Nye Web-portaler, som ikke tidligere har været tilsluttet SEB-IdP, de tilbydes en ny OIOSAML3-H-3.0 baserede integration til SEB. **CHG: Måske skal profiler holdes uden for beskrivelsen her i overblikket **

OIOSAML-H-3.0 er et OIOSAML3 token udvidet med sundhedsattributter. Fra tokenet kan medarbejderens identitet og organisatoriske tilknytning aflæses (på CVR-niveau). Desuden kan medarbejderens sundhedsfaglige autorisationer, ydertilknytning og nationale sundhedsroller aflæses. Tokenet indeholder desuden et Bootstraptoken (BST), der kan anvendes til SOSI STS’ens nye BST2SOSI snitflade.

...

Fagsystemer (i kommuner, lægepraksis og apoteker) skal tilsluttet SEB-medarbejder-IdP ved adgang til patientdata fra en en national sundhedstjeneste: **CHG: Afsnittet er lidt rodet og består både af en beskrivelse af snitflader/integrationsmønstre og en fortælling om hvad parterne har tænkt sig at gøre - kunne sidstnævnte ikke med fordel stå et andet sted? **

Fagsystemer skal anvende medarbejderens SOSI idkort (adgangsbillet) ved adgang til patientdata fra en national sundhedstjeneste (se step 7 på figuren nedenfor).

Enten skal fagsystemer skal fagsystemer selv hente SOSI idkortet, eller alternativt kan fagsystemer kan fagsystemer trække andre infrastrukturkomponenter, der på forhånd har hentet SOSI idkortet, og eventuelt har placeret det i en Gateway, hvorfra flere fagsystemer kan deles om samme SOSI idkortet. **CHG: Noget kringlet sætning, som er svært at forstå - hvad menes der med 'trække andre infrastrukturkomponenter'? **

I det følgende antages at fagsystemet selv henter SOSI idkort.

...

OIOSAML2SOSI snitfladen på SOSI STS’en udfases. Udfasningen bunder i at OIOSAML2SOSI snitfladen bryder med føderation-modellen og korrekt anvendelse af tokens. Sundhedsvæsenets sikkerhedsføderation (SOSI) er adskilt fra den fælles offentlige NemlogNemLog-in føderation. Et OIOSAML token fra NemlogNemLog-in til en webportal er målrettet trust-relationen mellem NemlogNemLog-in og webportalen. Men tokenet er ikke gyldigt udenfor denne trust-relation og kan derfor ikke anvendes mod SOSI føderationen. **CHG: Men bliver jo anvendet i dag Måske skal sidste sætning blødes lidt op **

BST2SOSI er en ny snitfladen på SOSI STS'en. Snitfladen kan omveksle et BST token modtaget fra SEB-medarbejder-IdP'en eller en lokale NSIS registreret IdP til et SOSI idkort.

NewSecurityToken snitfladen på SOSI STS'en ændres så den accepterer signering med MOCES3 tokens. Vær opmærksom på at understøttelse af MOCES3 bliver midlertid og forventes udfaset. **CHG: OCES3 organisationscertifikater udfases ikke **

SOSI2OIOSAML snitfladen på SOSI STS'en ændres ikke. Snitfladen anvendes i forbindelse med Knapløsninger (SikkerBrowserOpstart).forbindelse med Knapløsninger (SikkerBrowserOpstart).

SOSI Gateway ændre ikke. **CHG: Jo - der er tilføjet en ny snitflade der kan få udstedt og placeret et SOSI idkrot pbga. et BST **SOSI Gateway ændre ikke.

SEB: Bruger-rettigheds-administration

En lokal brugerorganisation kan udnævne en lokal SEB administratorsadministrator, som har til opgave at tildele roller til organisationens medarbejdere. Dette gøres via SEB administrationsgrænseflade.  Der Der skelnes mellem nationale rolle og applikationsspecifikke roller. 

De nationale roller anvendes af sundhedspersonermedarbejdere på sundhedsområdet, der ikke har en sundhedsautorisation i autorisationsregisteret, men som skal have adgang til patientdata qua deres arbejdsfunktion. Fx en lægesekretær.

...

Bruger-rettigheds-administration via SEB ændres ikke. Dog tilføjes et enkelt 'Globalt medarbejder UUID' til medarbejderens konto i SEB. 'Globalt medarbejder UUID' er indført i forbindelse med MitID Erhverv.

Sikkerhedsprotokol anvendt til service-integration - DGWS **CHG: Som nævnte længer oppe - IDWS for borgere ændres heller ikke **

Der laves ingen ændringer til Den Gode Web-service sikkerhedsprotokollen og SOSI idkort, som anvendes til service-integration fra et fagsystem til en sundhedsservice.

...

Er dine kunder mindre sundhedsorganisationer (lægepraksis, apoteker mm.), så se vejledningen Hints: Brug af MitID Erhverv i adgang til patientdata fra nationale sundhedsservices (working worl in progress).

Som region, hvordan påvirkes jeg?

...

Der er udarbejdet et vejledningen målrettet det som skal etableres for mindre sundhedsorganisationer. Se Hints: Brug af MitID Erhverv i adgang til patientdata fra nationale sundhedsservices (working worl in progress).

Kontakt din fagsystemsleverandør, så du sikre at leverandøren har en plan for ovenstående.

...

Medarbejderen vil opleve en anden brugerrejse, da medarbejderen skal tage stillig til, hvilken hjemme-IdP de skal anvende til log-in. Tidligere havde SEB ingen brugergrænseflade og sendte automatisk brugeren videre til login i NemlogNemLog-in. I fremtiden vil medarbejdere skulle vælge hjemme-IdP (NemlogNemLog-in, en regional IdP eller en kommunal IdP) via en grænsefalde i SEB. 

...

1. Der kører baggrundsjobs til opdatering af data i DokumentDelingsServicen, hvor sikkerhedsmodellen er baseret på VOCES2 eller FOCES2. Disse integrationer skal fremad anvendes VOCES3 (se "Som anvendes af VOCES2 og FOCES2, hvordan påvirkes jeg?").
2. Der er service-integrationer baseret på DGWS og SOSI idkort. DGWS ændres ikke, men der er ændringer til hvordan medarbejdere logger på og hvordan SOSI idkort hentes (se afsnit "Medarbejder- og borger-autentifikation", "SEB: IdentityProvider" og "Omveksling til SOSI idkort via SOSI STS" ovenfor).
3. Endeligt har Graviditetsmappen en administrativ web-portal, hvor login håndteres via SEB-medarbejder-IdP. Dine bruger vil enten logge på via en regional IdP, en kommunal IdP eller NemlogNemLog-in. Det skal sikres at din brugerorganisation er tilsluttet SEB-medarbejder-IdP (se afsnit "SEB: IdentityProvider").

...