You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »


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

  • at administrere organisationens medarbejdere via MitId Erhverv
  • at organisationens medarbejdere skal logge på via Nemlog-in ved adgang til den nationale sundhedsføderation.


Små organisationer har frem til nu anvendt medarbejdersignatur (MOCES2) som autentifikationsmiddel.

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

  • MOCES3 understøttes kun i en overgangsperiode
  • MOCES3 stiller højere krav til opbevaring af certifikat
  • MOCES3 kan ikke anvendes fra Nemlog-in.

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 brugere. Etableringsomkostningerne ved denne model er dog store og giver derfor kun mening for større organisationer.

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


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 er en web-applikation og tilgås via SAML WEB-SSO protokollen fra en web-server i tilknytning til fagsystemet. Fagsystemet skal aktivere at den tilknyttede webserver sender medarbejdereje til SEB (Sundhedsvæsenets Elektroniske Brugerstyring).
  3. SEB redirecter medarbejderen til Nemlog-in, hvorfra brugeren logger på og redirectes tilbage til SEB
  4. SEB opbygger et OIOSAML-H-3.0 token og returnerer dette til web-serveren tilknytet fagsystemetfagsystemer. OIOSAML-H-3.0 er et OIOSAML3 token udvidet med sundhedsattributter. Fra tokenet kan brugerens identitet og organisatoriske tilknytning aflæses (på CVR-niveau). Desuden kan brugerens 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. Loginkomponenten kalder SOSI STS for at få omvekslet BST tokenet til et SOSI Idkort (dette kan ske via en SOSI-Gateway – ikke vist på figuren). 
  1. SOSI STS validerer BST tokenet og returnerer et SOSI idkort 
  1. 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



Tilslutning til SEB

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


Protokol


Tokens


WS-trust kald til SOSI STS


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

  • No labels