Denne vejledning er målrettet mindre sundhedsorganisationer (eksempelvis lægepraksis og apoteker), som ved overgangen til MitId vælger:

De mindre organisationer har hidtil anvendt medarbejdersignatur (MOCES2) som autentifikationsmiddel.

I en begrænset overgangsperiode kan de mindre organisationer anvende MOCES3 som autentifikationsmiddel. Men MOCES3 har en række begrænsninger i forhold til MOCES2, hvilket gør MOCES3 mindre attraktiv for mindre organisationer.

Store organisationer indenfor sundhedsområdet (regioner og kommuner) forventes at etablere egne NSIS registrerede IdP'er, som giver mulighed for at udstede egne identifikationsmidler til organisationens medarbejdere. Etableringsomkostningerne ved denne model er dog betydelige og giver derfor primært mening for større organisationer.

Ovenstående gør at mindre organisationer forventes at anvende MitId Erhverv og login via Nemlog-in.

Den vejledning kommer ikke ind på hvordan medarbejdere oprettes i MitId Erhverv. Information vedrørende dette findes via dette link: https://migrering.nemlog-in.dk. 

Vedledning har fokus på tilslutningen til den Nationale Sundhedsføderation, som gør brug af Nemlog-in og MitId Erhverv.

Flow ved brug af MitId Erhverv i adgang til den nationale sundhedsføderation

Figuren nedenfor illustrerer flowet og de enkelte trin beskrives under figuren.



  1. En medarbejder tilgår organisationens fagsystem. Via fagsystemet ønsker medarbejderen at tilgå patientdata fra en national sundhedstjeneste, eksempelvis det Fælles MedicinKort (FMK). Fagsystemet skal have medarbejderens SOSI idkort for at kunne tilgå patientdata fra en national sundhedstjeneste (step 7 på figuren). SOSI idkort udstedes af SOSI STS’en via omveksling fra et Bootstraptoken (BST) (step 5-6 på figuren). Derfor skal fagsystemet hente medarbejderens BST (step 2-4), før fagsystemet kan hente patientdata fra en national sundhedstjeneste. 
  2. SEB (Sundhedsvæsenets Elektroniske Brugerstyring) er en IdP-broker, som viderestiller medarbejderen til arbejdspladsens valgte IdentityProvider (IdP). For mindre sundhedsorganisationer vil det være Nemlog-in. SEB og Nemlig-in er web-applikationer, der initieres via SAML WEB-SSO protokollen, og forudsætter dermed at medarbejderen har adgang til en browser. For fagssystem, som ikke er web-baseret, skal der etableres web-server og funktionalitet der initierer at medarbejderen via browser videresendes til SEB.
  3. SEB redirecter medarbejderen til Nemlog-in, hvorfra brugeren logger på og efterfølgende sendes tilbage til SEB
  4. SEB opbygger et OIOSAML-H-3.0 token og returnerer dette til web-serveren tilknyttet fagsystemet. 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 såkaldt Bootstraptoken, der kan anvendes til SOSI STS’ens nye BST2SOSI snitflade.
  5. Fagsystemet kalder SOSI STS’ens BST2SOSI snitflade for at omveksle BST tokenet til et SOSI IdKort. I kaldet er det muligt at ’claime’ den autorisation eller nationale rolle som medarbejderen ønsker at agerer på vegne af. Dette er kun relevant hvis medarbejderen har flere autorisationer eller nationale roller. Om dette er tilfældet kan aflæses af OIOSAML-H-3.0 tokenet. 
  6. SOSI STS validerer BST tokenet og returnerer et SOSI Idkort til fagsysemet. 

  7. Fagsystemet modtager medarbejderens SOSI IdKortet.

  8. Med SOSI idkortet kan fagsystemet lave et Den Gode WebService (DGWS) kald til sundhedstjenesten, og sundhedstjenesten kan returnere de ønskede patientdata til fagsystemet. 

 

SAML WEB-SSO kald til SEB

Som beskrevet ovenfor så initieres SEB via SAML WEB-SSO protokollen, og forudsætter en web-server i tilknytning til fagsystemet, samt at medarbejderen har adgang til en browser.

Tilslutning til SEB

Helle eller Klaus: Er der et link, som beskriver tilslutningsprocessen? 

Tokens

Efter medarbejderens succesfulde login returnere SEB et OIOSAML-H-3.0 token til web-serveren i tilknytning til fagsystemet.

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 såkaldt Bootstraptoken, der kan anvendes til SOSI STS’ens nye BST2SOSI snitflade.

Bootstraptokenet er et såkaldt 'Audience restricted' 'Holder off key' token.

'Audience' er den part som skal validere og omveksle tokenet. Dvs. her er det SOSI STS'en.

'Holder of key' er den part som SEB udsteder token til. Dvs. her er det fagsystem eller den tilknyttede web-service, som har initieret SAML WEB-SSO kaldet til SEB.

Linket nedenfor peger på OIOSAML-H-3.0 profilen, som dokumenterer tokenets attributindhold. 

https://www.nspop.dk/display/KLMIDNLIN3/Profiler?preview=/154767530/154774859/OIOSAML_Attribute_Profiles_for_Healthcare-v30.pdf

WS-trust kald til SOSI STS

Som del af SOSI STS'ens validering af indkomne BST-tokens valideres'audience' og 'Holder of key'.


Kryptografisk er det sikret at BST-tokenet kun kan anvendes ved til kald til SOSI STS'en (som er 'audience'). Kryptografisk er det desuden sikret at BST-tokenet kun kan anvendes fra 'Holder off key'. Her det fagsystem eller den tilknyttede web-service, som har inviteret  SAML WEB-SSO kaldet til SEB.


Dvs. det er kryptografisk udstedt til det specifikke fagsystem og kan kun anvendes herfra.


Whitelistning til BST2SOSI snitfladen på SOSI-STS

CHG: hvad er processen til whitelistning?

BST2SOSI omveksling via SOSI-STS

CHG: Vil du beskrive eller linke til hvordan dette gøres