Versions Compared

Old Version 48

changes.mady.by.user Søren Mikkelsen

Saved on

compared with

New Version Current

changes.mady.by.user Helle Mørch

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • MOCES3 understøttes kun i en overgangsperiode
  • MOCES3 stiller høje krav til identitetssikring af medarbejderne, samt udstededelse, opbevaring og anvendelse af certifikat i lokal infrastruktur
  • MOCES3 kan ikke anvendes fra NemLog-in, og derfor skal medarbejderen ud over MOCES3 også have et MitID, som anvendes ved login til sundhedsvæsenet web-portaler. Alternativt skal brugerens lokale IdP kunne levere et token til SEB indeholdende et SOSI-ID-kort som bevis for, at brugeren allerede har autentificeret sig op mod NSP'ens autentifikationstjeneste (SOSI-STS).

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 høje og giver derfor primært mening for større organisationer.

...

Vejledning har fokus på, hvordan et fagsystem tilslutter sig til  den Nationale Sundhedsføderation (SEB og SOSI STS).

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

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

View file
nameLPR-apoteker.pdf
height400

Image Added


  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 et SOSI idkort for medarbejderen 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 et BST for medarbejderen (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, som benytter MitID identifikationsmidler, vil det være NemLog-in. SEB og NemLog-in er web-applikationer, der initieres via SAML WEB-SSO protokollen, og de forudsætter dermed, at medarbejderen har adgang til en browser. For et 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 Bootstraptoken (BST), 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 agere 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. Med SOSI idkortet kan fagsystemet lave et Den Gode WebService (DGWS) kald til sundhedstjenesten, og sundhedstjenesten kan returnere de ønskede patientdata til fagsystemet.

Ovenstående flow er nødvendig når medarbejderen skal tilgå patientdata fra en national sundhedstjeneste. Flowet er ikke nødvendig i forbindelse med medarbejderens initiale login til fagsystemet, og så længe medarbejderen via fagsystemet ikke tilgår patientdata fra en national sundhedstjeneste. I det OIOSAML-H-3.0 token, der returneres i step 4 til fagsystemet, kan medarbejderens identitet aflæses og anvendes i en brugerkonto-mapning mod fagsystemets interne brugerregister. 

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

En webserver integreres til SEB via gennemførelse af følgende trin.

  1. Udveksling af SAML metadata med SEB IdP, så der kan etableres en tilslutning mellem IdP’en og webapplikationen (dvs. fagsystemet)
  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 (CHG: Her skal vi præcisere hvad der forventes af fagystemet. Vi ønsker vel ikke at brugeren skal logges ud af fagsystemet eller får slettet det lokalt cachede SOSI idkort når SEB sessionen timer ud? Givetvis vil brugeren have lukket browservinduet og dermed lukket alle web-sessioner (med SEB og NL). Jeg tror vi skal lige gentænke logout delen (smile) )

Via linket nedenfor findes en vejledning i integration til SEB:

Link til dokumentet 'Integration til SEB'. (*HELM*: Linket skal lægges ind - jeg er med på at vi afventer placeringen af den)For mere information - se Integration til SEB. 

SEB tilslutningsaftale

Der skal indgås en tilslutningsaftale for adgang til SEB IdP. Kontakt SEB systemforvalter Noshaba Hayat omkring dette: NOHA@sundhedsdatadriftsforvaltningen på SEBDRIFT@sundhedsdata.dk.

Tokens

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

...

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-komponenter' viser et eksempel-BST, samt reguest og response fra BST2SOSI omvekslingskaldet.

Omveksling af bootstraptoken til SOSI IdKort 

WS-Trust SOAP kald til SOSI-STS'ens BST2SOSI snitflade er dokumenteret her: STS - Guide til anvendere: Medarbejderomvekslinger.

...

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 undgås, hvis det sikres, at brugerne altid kun har én autorisation eller én nationale rolle.

Fagsystemets FOCES/VOCES-certifikat skal whitelistes i SOSI-STS’ BST2SOSI snitflade

Fagsystemets FOCES/VOCES-certifikat skal whitelistes til at må kalde SOSI-STS’ens BST2SOSI snitflade, dette gøres via henvendelse til NSP-ServiceDesk. Pt. understøttes både VOCES version 2 og 3 til whitelistning, men på sigt kun VOCES3.

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/sdnog http://medcom.dk/systemforvaltning/sundhedsdatanet-sdn

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

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

Der henvises til den generelle dokumentation for DenGodeWebservice, samt service-udbydernes egen dokumentation af DGWS medarbejdersnitfladerne.

Bilag: Eksempel på OIOSAML-H-3.0 token

"..." er indsat de steder i 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å nationale roller, autorisationer, ydertilknytning indlejret i https://data.gov.dk/model/core/eid/privilegesIntermediate attributten

<?xml version="1.0" encoding="UTF-8"?>
<bpp:PrivilegeListxmlns: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>

...