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

Compare with Current View Page History

« Previous Version 31 Next »


Denne vejledning er målrettet mindre sundhedsorganisationer (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.

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.

  • MOCES3 understøttes kun i en overgangsperiode
  • MOCES3 stiller højere krav til opbevaring af certifikat i lokal infrastruktur
  • 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 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 (trin 2-4 på figuren)

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.

Integration til SEB

For at få ens webapplikation integreret med SEB  er der nogle trin der skal gennemføres.

  1. Udveksling af SAML metadata med SEB IdP, så der kan etableres en tilslutning mellem IdP’en og webapplikationen
  2. Etablering af login-funktionalitet på webapplikationen, således autentificeringen foregår gennem SEB IdP’en
  3. Etablering af logout funktionalitet på webapplikationen, således der logges ud af både webapplikationen og SEB IdP’en

Via linket nedenfor findes en vejledning i integration til SEB:

Link.

SEB tilslutningsaftale

Tilslutningsaftale for adgang til SEB IdP håndteres gennem aftalerammeværket for NSP-tilslutninger (sehttps://www.nspop.dk/pages/viewpage.action?pageId=2362617).

Tokens

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

Web-serveren skal validere OIOSAML-H.3.0 tokenet for gyldig signatur, trust til signatur og gyldighed i tid. Dette håndteres af standard SAML biblioteker og bør ikke kræve udvikling af applikationsspecifik kode.

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.

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

I bilagsafsnittet nederst i denne vejledning ses et eksempel på et OIOSAML-H-3.0 token.

Indlejret i XML-elementet <AttributeStatement> findes de attributter:

  • som beskriver brugeren (navn, cpr, cpruud) - anvendes evt. til at mappe til fagsystemets interne brugerkonto
  • som beskriver brugerens organisatoriske tilknytning (oragvnisations navn, rid, professionel UUID)
  • brugerens autorisationer, ydertilknytning og nationale roller (encoded som Base64 og indlejret i attributten privilegesIntermediate) - decoded eksempel findes i bilag.
  • det BST som kan omveksles til et SOSI IdKort (encoded som Base64 og indlejret i attributten bootstrapToken)

BST 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 fagsystemet eller den tilknyttede web-server, som har initieret SAML WEB-SSO kaldet til SEB.

WS-trust kald til BST2SOSI snitfladen på SOSI STS (trin 5-6 på figuren)

Afsnit '1.4.2 BST2SOSI billetomveksling' i vejledningen 'Snitfladeændringer i NSP-kommponenter' (se link nedenfor) viser et eksempel-BST, samt reguest og response fra BST2SOSI omvekslingskaldet.

https://www.nspop.dk/download/attachments/131139579/Snitfladeændringer%20i%20NSP%20komponenter%20ved%20overgang%20til%20MitID%20NemLog-in3%20og%20OCES3%20v03.pdf?version=1&modificationDate=1653305466726&api=v2

Omvekslinger af bootstraptokens (MitID Erhverv og Lokal IdP scenarier)

WS-Trust SOAP kald til SOSI-STS'ens BST2SOSI snitflade er dokumenteret her STS - Guide til anvendere: Medarbejderomvekslinger. WS-Trust omvekslingen følger OIO Healthcare WS-Trust Profile v10.pdf.

Såvel Seal.java og Seal.NET bibliotekerne understøtte håndtering af bootstraptokens  - se kode eksempler her https://www.nspop.dk/pages/viewpage.action?pageId=162827041#Tekniskoverbliktilanvendere-Eksempelkode-omvekslingafbootstraptokenstilSOSIidkort.

Vær opmærksom på at en medarbejder kan have flere autorisationer og flere nationale roller (se eksempel i bilag, hvor privilegesIntermediate attributten indeholder flere autorisationer og nationale roller). I det udstedte SOSI IdKort kan der kun indgå én autorisation eller én national roller. Som parameter til BST2SOSI kan der medsendes et claim på den autorisation eller rolle som skal indgå i SOSI IdKortet.

Fagsystemet skal realisere noget logik, der automatisk eller ud fra brugerinput bestemmer den autorisation eller national rolle, som skal opsættes i SOSI IdKortet. Dette kan dog undgåes hvis de sikres at brugerne altid kun har en autorisation eller nationale rolle.

Anvenderens VOCES-certifikat skal whitelistes i SOSI-STS’ BST2SOSI snitflade

Anvenderens VOCES-certifikat skal whitelistes i SOSI-STS’ BST2SOSI snitflade, dette gøres i gennem NSP-servicedesk, se https://www.nspop.dk/display/resources/Supporthenvendelse. 

Sundhedsdatanet aftale mellem fagsystem og hhv. SOSI STS og sundhedsservice, der integreres til

I produktion foregår kommunikation med både SOSI-STS og sundhedsservicen (fx FMK) over Sundhedsdatanettet. Aftaler oprettes i gennem MedComs aftalesystem for Sundhedsdatanettet på https://aftale.medcom.dk/. Se også http://services.nsi.dk/sdn og http://medcom.dk/systemforvaltning/sundhedsdatanet-sdn


Kald af sundhedsservice med SOSI IdKort (trin 7 på figuren)

SOSI-idkortet kan benyttes til på medarbejderens vegne at foretage service-kald til nationale services der følger DenGodeWebService (DGWS).

Der henvises til den generelle dokumentation for DenGodeWebservice på https://www.medcom.dk/standarder/webservice-standarder/den-gode-webservice, samt service-udbydernes egen dokumentation af DGWS medarbejdersnitfladerne.

Bilag

Bilag 1: Eksempel på OIOSAML-H-3.0 token

"..." er indsat de steder eksemplet, hvor indholdet formateret som Base64.  

<?xml version="1.0" encoding="UTF-8"?>
<Assertion ID="id4dc7177d3dc14383b4f2d6e6b125dcd9" IssueInstant="2022-09-14T10:53:26.804Z"
    Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>https://t-seb.dkseb.dk/runtime/</Issuer>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
            <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <Reference URI="#id4dc7177d3dc14383b4f2d6e6b125dcd9">
                <Transforms>
                    <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </Transforms>
                <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <DigestValue>...</DigestValue>
            </Reference>
        </SignedInfo>
        <SignatureValue>...</SignatureValue>
        <KeyInfo>
            <X509Data>
                <X509Certificate>...</X509Certificate>
            </X509Data>
        </KeyInfo>
    </Signature>
    <Subject>
        <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
            >79f30dae-e945-4c7b-941f-94cd4c7a3cf1</NameID>
        <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <SubjectConfirmationData InResponseTo="id7970d754ae48499886d89d78cd862f84"
                NotOnOrAfter="2022-09-14T10:58:26.804Z"
                Recipient="https://t-seb.dkseb.dk/samlclaimapp11/login.ashx"/>
        </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2022-09-14T10:53:26.804Z" NotOnOrAfter="2022-09-14T11:53:26.804Z">
        <AudienceRestriction>
            <Audience>https://t-seb.dkseb.dk/samlclaimapp11/</Audience>
        </AudienceRestriction>
    </Conditions>
    <AuthnStatement AuthnInstant="2022-09-14T10:53:26.804Z" SessionIndex="DxtYXLE2lmxJyfM2BuiX2A==">
        <AuthnContext>
            <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Unspecified</AuthnContextClassRef>
        </AuthnContext>
    </AuthnStatement>
    <AttributeStatement>
        <Attribute Name="https://data.gov.dk/model/core/eid/cprUuid"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>f094778e-9b64-45a8-a254-d299dbde7614</AttributeValue>
        </Attribute>
        <Attribute Name="https://data.gov.dk/model/core/eid/professional/uuid/persistent"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>79f30dae-e945-4c7b-941f-94cd4c7a3cf1</AttributeValue>
        </Attribute>
        <Attribute Name="dk:gov:saml:attribute:AssuranceLevel"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <AttributeValue>3</AttributeValue>
        </Attribute>
        <Attribute Name="https://data.gov.dk/model/core/eid/privilegesIntermediate"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>...</AttributeValue>
        </Attribute>
        <Attribute Name="https://data.gov.dk/model/core/eid/bootstrapToken"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>...</AttributeValue>
        </Attribute>
        <Attribute Name="https://data.gov.dk/model/core/eid/fullName"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>Karl Kristensen</AttributeValue>
        </Attribute>
        <Attribute Name="https://data.gov.dk/model/core/eid/email"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>xxx@xxxxx.dk</AttributeValue>
        </Attribute>
        <Attribute Name="https://data.gov.dk/model/core/eid/cprNumber"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>231096xxxx</AttributeValue>
        </Attribute>
        <Attribute Name="https://data.gov.dk/model/core/eid/professional/cvr"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>25252525</AttributeValue>
        </Attribute>
        <Attribute Name="https://data.gov.dk/model/core/eid/professional/rid"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>85479288</AttributeValue>
        </Attribute>
        <Attribute Name="https://data.gov.dk/model/core/eid/professional/orgName"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>Organisation X</AttributeValue>
        </Attribute>
        <Attribute Name="https://data.gov.dk/model/core/specVersion"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>OIO-SAML-3.0</AttributeValue>
        </Attribute>
        <Attribute Name="https://healthcare.data.gov.dk/model/core/specVersion"
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <AttributeValue>OIOSAML-H-3.0</AttributeValue>
        </Attribute>
    </AttributeStatement>
</Assertion>


Eksempel på autorisationer, ydertilknytning og nationale roller indlejret i https://data.gov.dk/model/core/eid/privilegesIntermediate attributten

<?xml version="1.0" encoding="UTF-8"?>
<bpp:PrivilegeList xmlns:bpp="http://itst.dk/oiosaml/basic_privilege_profile"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <PrivilegeGroup Scope="urn:dk:gov:saml:cvrNumberIdentifier:25450442">
        <Privilege>urn:dk:healthcare:national-federation-role:SundAssistR1</Privilege>
        <Privilege>urn:dk:healthcare:national-federation-role:PlejeAssR3</Privilege>
    </PrivilegeGroup>
    <PrivilegeGroup Scope="urn:dk:healthcare:saml:userAuthorization:National">
        <Privilege>urn:dk:healthcare:saml:userAuthorization:AuthorizationCode:CLDSX:EducationCode:5265:EducationName:Kiropraktor</Privilege>
        <Privilege>urn:dk:healthcare:saml:userAuthorization:AuthorizationCode:KQQ1F:EducationCode:7170:EducationName:Læge</Privilege>
    </PrivilegeGroup>
    <PrivilegeGroup Scope="urn:dk:healthcare:saml:yderNumberIdentifier:344123:regionCode:83">
        <Privilege>urn:dk:healthcare:saml:yder:roleCode:42:roleName:Ansat</Privilege>
    </PrivilegeGroup>
</bpp:PrivilegeList>


 

  • No labels