1. Introduktion

Nuværende NemID for borgere og erhvervspersoners medarbejdersignatur bliver fra fællesoffentlig side afløst af henholdsvis MitID og MitID Erhverv, hvilket medfører en række ændringer til den nationale infrastruktur på sundhedsområdet, som tilpasses til at kunne understøtte MitID, NemLog-in3 og OCES3.

Denne tekniske guide henvender sig til leverandører, der udvikler løsninger til sundhedsområdet og skal migrere fra NemID/medarbejdersignatur/OCES2 til MitID og OCES3.

Det forventes, at læseren har kendskab til nuværende anvendelse af NemID og OCES på sundhedsområdet, herunder DGWS, SOSI og SOSI-STS.

Overgangen til den opdaterede nationale infrastruktur på sundhedsområdet, som understøtter MitID, NemLog-in3 og OCES3 tager afsæt i parternes Målbillede for sammenhængende brugerstyring og er konkretiseret i detaljer i Målarkitektur for sammenhængende brugerstyring transition 1: Overgang til MitID og NemLog-in3.

Ved overgangen fastholdes på sundhedsområdet de nuværende protokoller og adgangsbilletter, herunder DGWS og SOSI idkort for medarbejdere og systemer, samt IDWS på borgerområdet. Med der sker ændringer i forhold til hvordan det nye MitID, NemLog-in3 og OCES3 anvendes i integrationerne og t det følgende gennemgås de ændringer overgangen medfører for de forskellige typer løsninger på sundhedsområdet.

2. Borgervendte (web)løsninger

For borgervendte webløsninger, som eksempelvis webapoteker og praksislægers borgerportaler, der anvender NemLog-in via SEB IdP og tilgår nationale services som FMK via IDWS protokollen sker der kun minimale ændringer. Konkret kommer det indlejrede bootstraptoken, som webløsninger i dag omveksler via SOSI-STS'ens BST2IDWS snitflade, fremover til at være krypteret til SOSI-STS'en, dvs. tokenet modtages som <saml:EncryptedAssertion> fremfor som almindelig <saml:Assertion>. Der bemærkes, at kun bootstraptokenet som alene anvendes til omveksling vil være krypteret til SOSI-STS - selve OIOSAML assertionen med borgerens attributter, vil fortsat kunne læses.

I første omgang holdes der således fast i OIOSAML2 profilen og attributter fra SEB til de borgervendte webløsninger.

Se også Snitfladeændringer i SEB ved overgang til MitID NemLog-in3 og OCES3 v01.pdf.

3. System-til-system integrationer

System-til-system integrationer baseret på DGWS og SOSI systemidkort videreføres og udbygges til at understøtte OCES3. SOSI-STS'ens (New)SecurityTokenService snitflade udsteder fremover SOSI systemidkort ikke kun på baggrund af FOCES2/VOCES2 signerede idkortrequests, men også på baggrund af FOCES3/VOCES3 signerede requests.

4. Medarbejdervendte løsninger - fagsystemer

Nuværende MOCES medarbejdersignatur anvendes til autentifikation af medarbejdere på sundhedsområdet i forhold til deres tilgang fra fagsystemer (EPJ, EOJ, LPS, apotekssystemer mfl.) til nationale services som fx FMK. Medarbejdersignaturen anvendes til at signere idkortrequests til SOSI-STS'ens (New)SecurityTokenService snitflade, som udsteder SOSI useridkort, se i øvrigt STS - Guide til anvendere: DGWS for detaljerne omkring autorisations- og rollehåndtering i udstedelsesprocessen. Lokalt håndteres medarbejdersignaturen typisk enten i en signatur-mobilitetsløsning eller som nøglefiler.

Med overgangen til MitID erhvervs-identiteter bliver der fremover tre forskellige muligheder for at udstyre medarbejderne med identifikationsmidler, som kan anvendes til autentifikation og SOSI idkort udstedelse.

  • MitID Erhverv, hvor autentifikation af brugerne foregår i NemLog-in (enten med et personligt MitID identifikationsmiddel eller med et dedikeret MitID Erhverv identifikationsmiddel)
  • Lokal IdP, hvor brugerorganisations selv står for autentifikation af brugerne i egen NSIS-anmeldt IdP og med egne identifikationsmidler (fx smartcards)
  • MOCES3 certifikater, hvor autentifikation i SOSI-STS foregår efter samme flow som med nuværende MOCES2. MOCES3 understøttes som overgangsløsning for de brugerorganisationer, som tidsmæssigt ikke når at etablere egne lokale IdP'er.

Se i øvrigt også Snitfladeændringer i NSP komponenter ved overgang til MitID NemLog-in3 og OCES3 v03.pdf.

Anvendelse af MitID Erhverv

MitID Erhverv kan i princippet anvendes i andre MitID brokere end NemLog-in, men for at kunne understøtte udstedelse af SOSI idkort skal autentifikation af brugerne foregå i NemLog-in. Der er to integrationsmuligheder for at kunne få udstedt SOSI idkort - begge integrationer er baseret på at der modtages et omvekslingstoken (et såkaldt bootstraptoken), som i SOSI-STS'ens nye BST2SOSI snitflade kan veksles til et SOSI idkort.

  1. Integration via SEB IdP (anbefalet), hvor SEB fungerer som proxy IdP for NemLog-in IdP'en og beriger OIOSAML tokenet med sundhedsattributter (autorisationer, nationale roller), samt med et (til SOSI-STS krypteret) bootstraptoken. Indholdet af det OIOSAML token, som modtages af SEB IdP overholder 'OIOSAML Assertion Profile for Healthcare' i OIOSAML Attribute Profiles for Healthcare v30.pdf.
  2. Integration via NemLog-in IdP og STS, hvor der fra NemLog-in IdP'en modtages et fællesoffentligt bootstraptoken, som ved NemLog-in STS'en via et WS-Trust SOAP kald veksles til et nyt  krypteret (sundheds) bootstraptoken, som til sidst kan veksles til et SOSI idkort.

Begge integrationsmuligheder er baseret på SAML WebSSO protokollen til kommunikation med henholdsvis SEB IdP'en eller NemLog-in IdP'en og kræver dermed, at log-in fra fagsystemet foregår i en browser (eller alternativt i en indlejret browserkomponent).

Anvendelse af Lokal IdP

Store brugerorganisationer som har valgt at implementere egen NSIS-anmeldt IdP kan registreres som trusted udsteder af bootstraptokens til SOSI-STS. Bootstraptokens udstedt af egen IdP skal overholde OIO Healthcare Bootstrap Token Profile v10.pdf. Bemærk, at kommunikation mellem fagsystem og Lokal IdP ikke nødvendigvis behøver at være browserbaseret, men er overladt til lokalt implementering.

Omvekslinger af bootstraptokens (MitID Erhverv og Lokal IdP scenarier)

I begge scenarier kan bootstraptokenet fra fagsystemet omveksles til et SOSI idkort via et WS-Trust SOAP kald til SOSI-STS'ens BST2SOSI snitflade, se STS - Guide til anvendere: Medarbejderomvekslinger. WS-Trust omvekslingen følger OIO Healthcare WS-Trust Profile v10.pdf.

OBS: Bemærk, at bootstraptokens er såkaldte 'holder-of-key' tokens, som er kryptografisk bundet til klienten som modtager tokenet og skal veksle det via SOSI-STS'ens BST2SOSI snitflade. I praksis betyder det, at tokenudstederen (fx SEB IdP'en i MitID Erhverv scenariet) indlejrer (den offentlig del af) certifikatet i selve bootstraptokenet (som i SEB IdP tilfælde tages fra SAML Metadata for ens tilslutning) og at det er det samme certifikat (her den private nøgle), som skal benyttes til signering af BST2SOSI omvekslingskaldet.

Anvendelse af MOCES3

Flowet for autentifikation med MOCES3 er identisk med nuværende MOCES2 autentifikation i SOSI-STS, se  STS - Guide til anvendere: DGWS. Bemærk, at SOSI-STS kræver at MOCES3 certifikater udstedes med medarbejderens globale UUID fra MitID Erhvervsadministrationen (EIA) og ikke et certifikatspecifik UUID. (Dette styres via en indstilling i EIA for den pågældende brugerorganisation.)

4.1. Integration via SOSI-Gateway

Udover at SOSI-Gateway kan understøtte oprettelse af idkort på baggrund af MOCES3 certifikater er SOSI-Gateway blevet udvidet med en ny 'createIdCardFromBST' snitflade, der kan oprette SOSI idkort i SOSI-Gateway'ens cache ud fra et bootstraptoken, som STS'en truster (fx fra en lokal IdP eller SEB IdP'en). Input til snitfladen 'createIdCardFromBST' er samme WS-Trust request som anvendes i kald til SOSI-STS'ens BST2SOSI, se også SOSI-GW - Guide til anvendere.

5. Medarbejdervendte løsninger - webbaserede

Webapplikationer der benytter enten NemLog-in IdP'en eller SEB IdP'en til autentifikation af brugerne vil fortsæt kunne anvende de to IdP'er. I første omgang med de nuværende OIOSAML2 baserede protokoller/attributter, som skal migreres til OIOSAML3 baserede protokoller/attributter - for SEB-tilslutninger dog først på lidt længere sigt. Bemærk, at nuværende OIOSAML2SOSI snitflade på SOSI-STS (som kan anvendes til at omveksle en OIOSAML2 assertion fra NemLog-in IdP'en) ikke opdateres til OIOSAML3. I det omfang, der fra webapplikationen er behov for at kunne kalde videre via DGWS, bør applikationen i stedet omveksle det bootstraptoken, som modtages fra henholdsvis NemLog-in IdP'en eller SEB IdP'en, til et SOSI idkort som beskrevet i ovenstående.

Derimod vil nye tilslutninger til SEB IdP'en skulle basere sig på OIOSAML3, konkret er det 'OIOSAML Assertion Profile for Healthcare' fra OIOSAML Attribute Profiles for Healthcare v30.pdf som beskriver attributsættet, som webløsninger kan modtage. 

5.1. Adgang via sikker browseropstart (SBO)

Overgangen ændrer ikke ved sikker browseropstart konceptet. Uanset om en brugeres SOSI idkort er blevet udstedt på baggrund af et bootstraptoken eller en autentifikation med MOCES2 eller MOCES3 vil idkortet forsat kunne omveksles til et SBO token (et til webapplikationen krypteret OIOSAML token) i SOSI-STS'ens SOSI2OIOSAML snitflade.

6. Biblioteksunderstøttelse

Såvel Seal.java og Seal.NET bibliotekerne er opdateret til at kunne understøtte håndtering af bootstraptokens og OCES3 certifikater (fra version 2.6.0 for Seal.Java og fra version 4.2.0 for Seal.NET). Anvendere bør om muligt altid anvende seneste version af Seal bibliotekerne.

Se endvidere anvenderdokumentationen for de to biblioteker:

6.1. Eksempelkode - omveksling af bootstraptokens til SOSI idkort

I de to biblioteker og i eksemplerne anvendes følgende akronymer til de forskellige typer at bootstraptokens:

  • OIO2HBST: Bootstraptokens udstedt af SEB IdP (som er baseret på OIOSAML2)

  • OIO3BST: Bootstraptokens udstedt af NemLog-in STS’en (som er krypteret til SOSI-STS, men baseret på OIOSAML3)

  • OIO3HBST: Bootstraptokens udstedt af lokale IdP’er

Java eksempler ligger som en del af integrationstests til SOSI-STS'en under

https://svn.nspop.dk/src/components/sts/trunk/modules/sts-server/src/test/java/dk/sosi/sts/server/facade/bst2sosi/ 

.NET eksemplerne er en del af Seal.NET og ligger i

https://svn.nspop.dk/src/libraries/seal/net/trunk/SealTest/Model/ 

6.2. Eksempelkode - oprettelse af SOSI idkort i SOSI-Gateway på baggrund af et bootstraptoken

Java eksempler findes som som del af integrationstests til SOSI-Gateway, se

https://svn.nspop.dk/src/components/sosigw/trunk/src/test/java/com/trifork/sosigw/inttest/CreateIdCardFromBstIT.java 

.NET eksempler er under udarbejdelse

https://svn.nspop.dk/src/libraries/seal/net/trunk/SealTest/SosiGWTest.cs

6.3. Eksempelkode - anvendelse af OCES3 ved autentifikation i STS

Java eksemplerne er en del af Seal.java, se fx

https://svn.nspop.dk/src/libraries/sosi-seal/trunk/modules/seal/src/test/java/dk/sosi/seal/TestSOSIFactory.java

.NET eksemplerne er den del af Seal.NET, se fx

https://svn.nspop.dk/src/libraries/seal/net/trunk/SealTest/Model/FederationTest.cs

6.4. Eksempelkode - anvendelse af MOCES3 ved oprettelse af idkort i SOSI-Gateway

Java eksemplerne er en del af SOSI-Gateway, se

https://svn.nspop.dk/src/components/sosigw/trunk/src/test/java/com/trifork/sosigw/inttest/SignIdCardIT.java

.NET eksemplerne er den del af Seal.NET og er under udarbejdelse

https://svn.nspop.dk/src/libraries/seal/net/trunk/SealTest/SosiGWTest.cs

7. Spørgsmål og fejl

Spørgsmål til løsningen eller dokumentationen heraf rettes til projektleder i Sundhedsdatastyrelsen Helle Mørch: HELM@sundhedsdata.dk.

Disclaimer: MitID projektet kan ikke hjælpe med generelle spørgsmål til de anvendte teknologier og internationale standarder, herunder SAML (fx WebSSO protokollen, holder-of-key tokens), WS-Security og X509Certifikater - her skal man som anvender selv sørge for at have den fornødne kompetencer.

Fejl som konstateres i NSP i forbindelse med omstilling til MitID, Lokale identifikationsmidler og MOCES3 oprettes som supportsag på vanlig vis. Vælg venligst den særskilte forretningsservice "MitID/NemLog-in3" til disse henvendelser.





  • No labels