Loesningsbeskrivelse Saarjournal Sikkerhedsarkitektur-v10 · kommuner, apoteker, osv.). IdP ”Identity Provider”. En it-tjeneste der ved hjælp af it-tekniske hjælpemidler og

LAKESIDE

LAKESIDE A/S || Marselisborg Havnevej 32, 1. sal || DK-8000 || Aarhus C || Denmark

tlf. +45 21607252 || www.lakeside.dk || [email protected]

Sårjournalen

Løsningsbeskrivelse til ændring af

sikkerhedsarkitekturen

Version 1.0

4. juni 2015

LAKESIDE side 2 / 22

Indholdsfortegnelse 1 INDLEDNING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 METODE ............................................................................................................................................. 3 1.2 RAMMER OG PRINCIPPER ................................................................................................................ 3 1.3 ANVENDELSESSCENARIER ............................................................................................................... 3 1.4 DEFINITION AF TERMER OG FORKORTELSER .............................................................................. 4

2 FORRETNINGSMÆSSIGE GEVINSTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 NUVÆRENDE LØSNING (AS-IS) ................................................................................................... 5 2.2 KOMMENDE SIKKERHEDSARKITEKTUR (TO-BE) ...................................................................... 5 2.3 GEVINSTER ......................................................................................................................................... 6

3 INFORMATIONSARKITEKTUR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 PASSIV SCENARIE .............................................................................................................................. 7 3.2 AKTIV SCENARIE / SIKKER BROWSER-OPSTART ......................................................................... 8 3.3 PASSIV SCENARIE MED SOSI ......................................................................................................... 9 3.4 UDVEKSLING AF LINKS TIL PATIENTDATA ................................................................................. 10

4 LØSNINGENS TEKNISKE ELEMENTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 PASSIV SCENARIE ............................................................................................................................ 11 4.2 AKTIV SCENARIE / SIKKER BROWSER-OPSTART ....................................................................... 12 4.3 PASSIV SCENARIE MED SOSI ....................................................................................................... 13 4.4 ANVENDTE PROFILER ..................................................................................................................... 14

5 ROADMAP FOR ETABLERING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6 REFERENCER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7 APPENDIKS: SIKKERHEDSANALYSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8 APPENDIKS: ARKITEKTURBESLUTNINGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8.1 SOSI IDKORT ................................................................................................................................. 18 8.2 LOGIN-SESSION ............................................................................................................................. 18 8.3 OVERFØRSEL AF RETTIGHEDER .................................................................................................... 19

9 APPENDIKS: PASSIV SCENARIE MED BEHANDLINGSKONTEKSTOVERFØRSEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10 APPENDIKS: ALTERNATIV OPSÆTNING TIL SIKKER BROWSER-OPSTART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11 APPENDIKS: INTEGRATION MED ANDRE FØDERATIONER . . . . . . . . . . . . 21


1 Indledning

Nærværende dokument beskriver etablering af en sikkerhedsarkitektur for Sårjournalen. Med afsæt i Sårjournalens nuværende løsning for autentifikation og autorisation af brugere belyses, hvilke gevinster der gennem etablering af sikkerhedsarkitekturen kan høstes hos de involverede parter. Løsningens tekniske elementer forklares, og der op-stilles et roadmap til en trinvis realisering og afprøvning af sikkerhedsarkitekturen.

Denne løsningsbeskrivelse er således en kontekstualisering og konkretisering af de af NSI beskrevne sikkerhedsmodeller for Sårjournalen [SIKKERHED-SÅRJ].

Dokumentet henvender sig til arkitekter, projektledere og interesserede parter, som ind-går i pilotafprøvningen af sikkerhedsarkitekturen. Der forventes, at læseren har et basalt kendskab til Sårjournal løsningen.

1.1 Metode Udarbejdelsen af denne løsningsbeskrivelse er inspireret af TOGAF Architecture Deve-lopment Method (ADM), se [TOGAF].

I ADM gennemgår arkitekturprocessen en række faser startende med en fastlæggelse af rammerne (svarende til afsnit 1.2 - Rammer og principper), hvorefter der formuleres en arkitekturvision (afsnit 1.3 - Anvendelsesscenarier), forretningsarkitekturen beskrives (afsnit 2 - Forretningsmæssige gevinster), en logisk informationssystemarkitektur defi-neres (afsnit 3 - Informationsarkitektur), løsningens tekniske systemlandskab beskrives (afsnit 4 - Løsningens tekniske elementer) og model for en trinvis etablering præsente-res (afsnit 5 - Roadmap for etablering) .

1.2 Rammer og principper Løsningen bygger på de i [SIKKERHED-SÅRJ] identificerede rammer og principper, som her kort oplistes:

1. Udnyt så vidt muligt eksisterende løsninger 2. Brugeradministration foretages i egne systemer 3. Samme autentifikationssikkerhed som ved Fælles Medicinkort 4. Skab bedre sammenhæng mellem systemer 5. Tænk fremad så kommende løsninger får gavn af indsatsen 6. Løsningen må ikke være unødigt svær at administrere 7. Følg referencearkitekturer og øvrige analyser

1.3 Anvendelsesscenarier Det er visionen, at sikkerhedsarkitekturen som minimum understøtter de overordnede forventede anvendelsesscenarier for adgangen til Sårjournalen med den fornødne sik-kerhed:

A) Sundhedspersoner tilgår Sårjournalen fra et fagsystem igennem en ’knap løs-

ning’, hvor en allerede etableret sikkerheds- og behandlingskontekst overføres til browseren (sikker browser-opstart)

B) Sundhedspersoner og borgere tilgår Sårjournalen direkte i en browser (også fra mobile enheder)

C) Sundhedspersoner udveksler links til ressourcer i Sårjournalen i gennem Med-Com EDI/XML korrespondancemeddelelser


1.4 Definition af termer og forkortelser

Forkortelse / Term Forklaring

Akkreditiver I it-sammenhæng er akkreditiver bevis for en brugers identitet. En bruger afgiver akkreditiver til et it-system, og systemet kan på baggrund af disse infor-mationer verificere brugerens identitet. Den mest udbredte form for akkreditiver er brugernavn + kode-ord. Et andet eksempel er digital signatur, der udvider sikkerheden fra alene at omfatte noget, brugeren har kendskab til (et kodeord) til også at omfatte noget, brugeren er i besiddelse af (f.eks. en nøglefil, et kode-kort eller lignende).

Autentifikation Kobling mellem en bruger og en digital identitet, baseret på afgivelse af akkreditive der verificerer, at burgeren er den hævdede digitale identitet.

Autorisation Styring og håndtering af brugerens rettigheder til adgang til ressourcer, herunder data, tjenester og funktionalitet .

CA Certificate Authority. Myndighed, der har ansvaret for certifikater og udstedelse af disse. Opgaverne og ansvarsområderne tilhørende en CA er opdelt i Iden-tity Proofing Service (IPS) og Credential Management Service (CMS).

Føderation En række organisationer, der har indbyrdes tillid til hinanden omkring autentificering af brugere. Indenfor en føderation kan en bruger autentificere sig overfor en lokal autoritet og derefter anvende sin identitet i tjenester udbudt af de andre organisationer uden at skulle autentificere sig igen. En national føderation på sundhedsområdet vil bestå af blandt andre regionerne og et antal nationale tjenester, én eller flere CA'er samt et antal parter på lige fod med regionerne (eksempelvis lægepraksis, kommuner, apoteker, osv.).

IdP ”Identity Provider”. En it-tjeneste der ved hjælp af it-tekniske hjælpemidler og akkreditiver, kan kontrollere om en bruger er den, vedkommende udgiver sig for at være. En IdP opretholder ”login sessioner” på tværs af web applikationer. Dermed kan der opnås ”Single Sign On”, dvs. brugeren behøver kun logge på én gang for at få adgang til alle web applikationerne, der er med i IdP sammenslutningen. Nogle IdP implemen-teringer understøtter også ”Single Log-out”, så bru-geren automatisk ”logges af” i alle tilsluttede web applikationer.

TOGAF TOGAF står for ”The Open Group Architecture Framework” og er et rammeværk for Enterprise Arki-tektur .


2 Forretningsmæssige gevinster

I dette afsnit sammenholdes sikkerhedsaspekterne for det nuværende løsning i Sårjour-nalen med den kommende sikkerhedsarkitektur. Desuden beskrives de forretningsmæs-sige gevinster, der kan realiseres gennem etablering af en ny sikkerhedsarkitektur.

2.1 Nuværende løsning (AS-IS) Den etablerede Sårjournalsløsning kan i forhold til sikkerhed og kontekstoverførsel karakteriseres igennem følgende egenskaber:

A) Brugerstyring i Sårjournalen

Sundhedspersoners adgang og rettigheder administreres direkte i Sårjournalen.

B) Særskilt brugernavn/password

Sundhedspersoner tildeles et unikt brugernavn/password til Sårjournalen. Bor-gere kan til gengæld benytte deres NemID akkreditiver.

C) Svag autentifikation

Sårjournalens brugerautentifikation lever i sin nuværende form ikke op til sik-kerhedsanbefalingerne til håndtering af personfølsomme data, se Appendiks: Sikkerhedsanalyse.

D) Kan ikke indgå i Single-Sign-On (SSO)

Sårjournalens brugerautentifikation kan hverken for sundhedspersoner eller borgere indgå i et SSO setup, som eksempelvis Sundhedsjournalen eller FMK-online er del af.

E) Ingen sikkerhedssessionsoverførsel fra fagsystem

Sundhedspersoner, som allerede er autentificeret i et lokalt fagsystem, skal på ny autentificere sig, når de tilgår Sårjournalen.

F) Ingen kontekstoverførsel fra fagsystem

Selvom en sundhedsperson arbejder med en bestemt patients data i sit lokale fagsystem, kan denne behandlingskontekst ikke overføres til Sårjournalen – sundhedspersonen må i stedet fremfinde patienten på ny i Sårjournalen.

2.2 Kommende sikkerhedsarkitektur (TO-BE) Den kommende Sårjournalsløsning kan i forhold til sikkerhed og kontekstoverførsel karakteriseres igennem følgende egenskaber:

A) Lokal brugerstyring

Sundhedspersoners adgang og rettigheder administreres i sundhedspersonens egen organisation på lige fod med adgang og rettigheder til andre it-systemer.

B) Single-set-of-Credentials

Brugerne kan anvende de samme akkreditiver, som de benytter til andre it-systemer.


C) Fornøden stærk autentifikation

Sundhedspersoners adgang til personfølsomme data sikres gennem fornøden stærk autentifikation, se Appendiks: Sikkerhedsanalyse.

D) Kan indgå i Single-Sign-On (SSO)

Brugere kan opnå SSO mellem Sårjournalen og nationale webløsninger som ek-sempelvis FMK-online og Sundhedsjournalen.

E) Sikkerhedssessionsoverførsel fra fagsystem

Ved opstart af Sårjournalen fra et fagsystem kan tilstrækkelig stærk autentifice-rede sundhedspersoner overføre deres allerede etablerede sikkerhedskontekst til Sårjournalen.

F) Kontekstoverførsel fra fagsystem

Sundhedspersoner kan ligeledes overføre den konkrete patientkontekst fra de-res fagsystem til Sårjournalen.

2.3 Gevinster Med etableringen af sikkerhedsarkitekturen er der en række gevinster at høste, såvel for de berørte brugere og patienter, som for sundhedspersoners organisationer.

A) Fra ’Brugerstyring i Sårjournalen’ til ’Lokal brugerstyring’

Brugerstyring til Sårjournalen kan integreres i sundhedspersonens lokale bru-gerstyringssystem, så det dermed håndteres på lige fod med adgangsstyring til andre it-systemer. Dette gør rettighedsadministrationen enklere og mere effek-tiv for de lokale brugeradministratorer.

B) Fra ’Særskilt brugernavn/password’ til ’Single-set-of-Credentials ’

At skulle huske forskellige akkreditiver er en udfordringer for mange brugere. Passwords bliver glemt eller noteres på papir, med risiko for at blive set og mis-brugt af uvedkommende personer. Ved at genbruge, de samme akkreditiver som brugerne også benytter til deres lokale systemer, mindskes risikoen for misbrug. Desuden forsvinder det administrative overhead, som ligger i vedligeholdelse af separate akkreditiver.

C) Fra ’Svag autentifikation’ til ’Fornøden stærk autentifikation’

Gennem fornøden stærk autentifikation formindskes risikoen for sikkerheds-brud, hvor uvedkommende personer skaffer sig adgang til personfølsomme data.

D) Fra ’Kan ikke indgå i Single-Sign-On’ til ’Kan indgå i Single-Sign-On’

Gennem indgåelse i et Single-Sign-On setup på tværs af it-systemer kan unød-vendige arbejdsgange hos brugerne fjernes og dermed tid spares.

E) Fra ’Ingen sikkerhedssessionsoverførsel fra fagsystem’ til ’Sikkerhedsses-sionsoverførsel fra fagsystem’

Som i Single-Sign-On scenariet undgås re-autentifikation af brugerne, som der-ved sparer tid.


F) Fra ’Ingen kontekstoverførsel fra fagsystem’ til ’Kontekstoverførsel fra fagsystem’

Ved at overføre behandlingskonteksten fra fagsystemet til Sårjournalen undgår brugeren at skulle fremfinde den pågældende patient på ny. Derved spares tid og risikoen for fejl mindskes.

3 Informationsarkitektur

I det følgende præsenteres den kommende sikkerhedsarkitektur for Sårjournalen som opfylder de i afsnit 2.2 (Kommende sikkerhedsarkitektur (TO-BE)) beskrevne egenskaber.

Dette afsnit omhandler informationsarkitekturen for sikkerhedsløsningen. Overordnet og teknologineutralt anskueliggøres informationsflowet mellem de enkelte dele, der udgør den samlede sikkerhedsløsning. Hvordan de enkelte parter konkret interagerer med hinanden og hvordan data konkret udveksles, behandles i afsnit 4 (Løsningens tekniske elementer).

Beskrivelsen er delt op efter de tre overordnede anvendelsesscenarier som skitseret i [PROJEKT-SÅRJ]:

1. Det passive scenarie 2. Det aktive scenarie / sikker browser-opstart 3. Det passive scenarie med SOSI

Der anbefales at organisationer – primært regioner og kommuner – som har en egen IdP (eksempelvis AD FS) at implementere et af de to passive scenarier.

Organisationer som ikke har en egen IdP (eksempelvis lægehuse) kan opnå overførsel af sikkerheds- og behandlingskontekst til Sårjournalen ved at realisere det aktive scenarie.

3.1 Passiv scenarie Det passive scenarie dækker over anvendelsesscenariet, hvor en sundhedsfaglig person tilgår Sårjournalen direkte fra en browser, som illustreret i nedenstående figur.

Hængelåsen på de enkelte data-elementer indikerer at informationen er krypteret under modtagerens nøgle.

I det passive scenarie indgår følgende trin:

Sårjournalen

Lokalt sikkerhedsdomæne

Bruger

National Sundhedsføderation

Browser

1

2

IdP/STS Autentifikation

+ IdP / STS (f.eks. ADFS)

Rolle/Rettigheder (attributter)

3

4

Fællesoffentlig føderation

NemLogin IdP 6

8

Security Token Service

(SOSI STS)

Token

IDkort

NyToken

IDkort

Token

Rettigheder 5

7


1. Brugeren autentificerer sig i sit lokale sikkerhedsdomæne (eksempelvis ved at

logge på sit Windows Active Directory (AD) domæne). 2. Brugeren åbner en browser. 3. Brugeren tilgår Sårjournalen. 4. Sårjournalen konstaterer, at brugeren ikke har nogen gyldig sikkerhedskontekst,

og viderestiller brugeren til sundhedsføderationens IdP. 5. IdP’en indhenter en liste over brugerens Rettigheder i forhold til nationale tje-

nester hos brugerens hjemmeorganisation. 6. Brugeren viderestilles til autentificering hos NemLogin IdP’en. NemLogin returner

et Token som bevis for, at brugeren nu er stærk autentificeret. 7. IdP’en veksler nu NemLogin tokenet til et SOSI IDkort hos SOSI-STS’en. 8. IdP’en danner et NyToken indeholdende attributter fra NemLogin tokenet, ret-

tighederne hentet fra brugerorganisationen som er relevante for Sårjournalen, samt IDkortet fra STS’en. IdP’en sender NyToken’et til Sårjournalen. Sårjournalen giver brugeren adgang svarende til de rettigheder, der fremgår af tokenet. Sår-journalen kan anvende det overførte SOSI-IDkort til at kalde andre tjenester in-denfor sundhedsområdet for brugeren.

Det skitserede flow tager udgangspunkt i at brugeren åbner en browser og derefter til-går Sårjournalen. Alternativt kunne browseren startes fra et fagsystem og dermed un-derstøtte en overførsel af behandlingskonteksten, se Appendiks: Passiv scenarie med behandlingskontekstoverførsel.

Det er værd at bemærke, at scenariet forløber lidt anderledes, når Sårjournalen tilgås fra en mobil enhed. Eksempelvis en iPad, hvor brugeren i trin 1 typisk ikke logger på et sik-kerhedsdomæne, men alene autentificerer sig direkte mod den mobile enhed. I dette tilfælde skal brugeren i trin 5 autentificere sig mod sit lokale sikkerhedsdomæne, eksem-pelvis ved at logge på den lokale IdP med brugernavn og password.

Brugere med flere sundhedsfaglige autorisationer håndteres som beskrevet i afsnit 8.2 - Login-session.

3.2 Aktiv scenarie / Sikker browser-opstart I det aktive scenarie tilgår brugeren Sårjournalen fra sit lokale fagsystem og overfører en allerede etableret sikkerheds- og behandlingskontekst fra fagsystemet til Sårjournalen, når denne opstartes fra en browser.

3

Sårjournalen

Autentifikation (f.eks. AD / Kerberos)

Rolle/Rettigheder (f.eks. AD / LDAP)

Bruger


2 2

Security Token Service (SOSI STS)

National sundhedsføderation

Browser

4

5 Fagsystem

6

7

trust

1 Rettigheder

IDkort

Token

IDkort

Token

IDkort

Rettigheder

IDkort

2

Behandlingskontekst


I det aktive scenarie indgår følgende trin:

1. Brugeren autentificerer sig i sin lokale sikkerhedsdomæne. 2. Brugeren tilgår fagsystemet. 3. Fagsystemet indhenter Rettigheder fra det lokale brugerstyringssystem. 4. I gennem fagsystemet autentificerer brugeren sig med sin digital signatur hos

SOSI-STS’en og får udstedt et IDkort. 5. Fagsystemet veksler IDkortet til et Token med indlejret IDkort hos SOSI-STS’en.

(Tokenets form og indhold er magen til NemLogin tokenet i det passive scena-rie.)

6. Brugeren starter nu browseren fra fagsystemet. 7. Fra browseren overføres tokenet, rettighederne og Behandlingskonteksten til

Sårjournalen. Sårjournalen giver brugeren adgang svarende til de rettigheder, der fremgår af tokenet. Patientdata vises i overensstemmelse med den overførte behandlingskontekst.

Bemærk at pilotprojektet i trin 7 ikke overfører brugerrettighederne indlejret i tokenet. Se afsnit 8.3 (Overførsel af rettigheder) for en begrundelse af denne beslutningen.

Udgangspunktet for scenariet illustreret via ovenstående figur er, at fagsystemet inte-grerer til det lokale brugerstyringssystem og SOSI-STS’en, samt står for sikker browser-opstart. Der kan være opsætninger, hvor fagsystemet ikke har adgang til et lokalt bru-gerstyringssystem (idet fagsystemet ikke driftes lokalt) eller der kan være ønskeligt at afkoble logikken omkring sikker browser-opstart fra fagsystemet. I afsnit 10 (Appendiks: Alternativ opsætning til sikker browser-opstart) illustreres en model, hvor integrationen til lokalt brugerstyringssystem, SOSI-STS og Sårjournalen håndteres af en separat lokal sikkerhedskomponent.

3.3 Passiv scenarie med SOSI I det passive scenarie med SOSI er den stærke autentifikation af brugeren hos NemLogin erstattet med en videreførelse af en allerede etableret stærk sikkerhedskontekst i sund-hedsføderationen.

I det passive scenarie med SOSI indgår følgende trin:

Token

Sårjournalen


Bruger


Browser

1

2

National IdP/STS

Autentifikation + IdP / STS (f.eks. ADFS)


3

4

5

SOSI STS IDkort cache (fx. SOSI-GW)

6

7

trust 9

8

Token

IDkort

IDkort

Token

IDkort

Rettigheder

NyToken

IDkort


1. Brugeren autentificerer sig i sit lokale sikkerhedsdomæne. 2. Brugeren åbner en browser. 3. Brugeren tilgår Sårjournalen. 4. Sårjournalen konstaterer, at brugeren ikke har nogen gyldig sikkerhedskontekst

og viderestiller brugeren til sundhedsføderationens IdP. 5. IdP’en viderestiller brugeren til brugerens lokale IdP. 6. I brugerens lokale IdP afgøres, om brugeren har et gyldigt IDkort, dvs. en gyldig

stærk sikkerhedskontekst. 7. Brugerens lokale IdP veksler brugerens IDkort til et Token med indlejret IDkort

hos SOSI-STS’en. 8. Den lokale IdP returner et samlet token, som indeholder det SOSI-STS udstedte

token og brugerens Rettigheder i forhold til nationale tjenester. 9. IdP’en danner nu et NyToken indeholdende attributter fra SOSI-STS tokenet,

rettighederne hentet fra brugerorganisationen som er relevante for Sårjournalen og IDkortet (præcist som i det simple passive scenarie). IdP’en sender NyToken’et til Sårjournalen, som giver brugeren adgang svarende til de rettigheder, der fremgår af tokenet.

3.4 Udveksling af links til patientdata Sundhedsfaglig personer kan udveksle links til patientdata i Sårjournalen med hinan-den, eksempelvis via MedComs ’Korrespondancemeddelelse’.

En opstart af Sårjournalen fra et tilsendt link svarer til et passiv scenarie, hvor behand-lingskonteksten (i form en af reference til patienten og eventuel et konkrete sår) med-sendes, men hvor autentifikations- og autorisations-trinene er uændret.

Dette er illustreret for det simple passive scenarie i nedenstående figur, hvor brugeren i trin 2 åbner det tilsendte link i browseren, og hvor behandlingskonteksten overføres til Sårjournalen i trin 3.

4 Løsningens tekniske elementer

I det følgende beskrives de anvendte profiler og teknologier, der udgør den samlede sikkerhedsløsning for Sårjournalen. Afsnittet henvender sig primært til læsere med en forholdsvis teknisk baggrund.

For hvert af de tre scenarier beskrives, hvordan hver enkel integration realiseres. I dette afsnit dykkes således lidt dybere ned i teknologien.

Sårjournalen


Bruger


Browser

1

2




3

4


NemLogin IdP 6

8


(SOSI STS)

Token

IDkort

NyToken

IDkort

Token

Rettigheder 5

7

Behandlingskontekst


Sikkerhedsarkitekturen bygger på etableret infrastruktur og eksisterende profiler, herun-der specielt OIOSAML WebSSO profilen [OIO-WEBSSO].

For at gøre løsningen robust over for en kompromittering af transportlaget og bruge-rens klient, så foregår al internettransport med SSL/TLS kryptering, og alle internetover-førte SAML tokens krypteres under aftagerens nøgle.

4.1 Passiv scenarie

De enkelte trin i det passive scenarie, hvor brugeren tilgår Sårjournalen direkte i en browser, realiseres på følgende måde.

1. Brugeren autentificerer sig i forhold til den lokale IdP (AD/Kerberos) 2. Brugeren starter en browser 3. Brugeren foretager et HTTP Get kald til Sårjournalens login-side for sundheds-

faglige personer 4. Sårjournalen afgør, hvorvidt brugeren har en eksisterende session (med Sårjour-

nalen). Hvis ikke det er tilfældet, sendes et signeret SAML <AuthnRequest> via HTTP Redirect til sundhedsføderationens IdP.

5. Sundhedsføderationens IdP afgør, hvorvidt brugeren har en eksisterende sessi-on (med sundhedsføderationens IdP). Hvis ikke det er tilfældet, så promptes brugeren til at vælge lokal organisation (og dermed hans lokale IdP). IdP’en gemmer valget i en persistent cookie således, at brugeren kun skal be-kræfte hans organisation, næste gang IdP’en tilgås. IdP’en sender nu et signeret SAML <AuthnRequest> via HTTP Redirect til bruge-rens lokale IdP.

6. Via brugerens lokale sikkerheds-session udtrækker den lokale IdP de rettighe-der/attributter, som er relevant i en national kontekst (herunder rettigheder ift. Sårjournalen og organisationens CVR nummer). En SAML assertion opbygges, krypteres og sendes som SAML <Response> via Post til sundhedsføderationens IdP. Attributterne i SAML assertionen navngives og formateres som specificeret i [OIOSAML-H].

7. Sundhedsføderationens IdP sender et SAML <AuthnRequest> til NemLogin IdP’en via HTTP Redirect (sundhedsføderationens IdP optræder her som service provider (SP)). Hvis brugeren ikke allerede har en aktiv NemLogin-session skal vedkom-mende autentificere sig med digital signatur.

8. NemLogin IdP’en udsteder og sender et OIOSAML token til sundhedsføderatio-nens IdP via Post. Sundhedsføderationens IdP validerer, at CVR nummeret i OIO-SAML tokenet matcher CVR nummeret i tokenet fra den lokale IdP. Dette sikrer, at attributter fra en organisation ikke anvendes i en anden organisations kon-tekst.

Sårjournalen


Bruger


Browser

1

2




3

4

5


NemLogin IdP 7

6 8

11


(SOSI STS)

9 10


9. Sundhedsføderationens IdP laver et WS-trust kald til SOSI-STS’ens OIO-SAML2SOSI snitflade med NemLogin OIOSAML tokenet som input. Hvis brugeren har flere sundhedsfaglige autorisationer, så returnerer SOSI-STS’en et fejlsvar indeholdende brugerens mulige autorisationer. Sundhedsføde-rations IdP’en vælger i givet fald den første autorisation, se også begrundelsen under afsnit 8.2 - Login-session. WS-trust kaldet gentages efterfølgende med autorisationen som yderlig inputparameter.

10. SOSI-STS’en udsteder et SOSI IDkort for brugeren, som returneres i WS-trust re-sponsen til sundhedsføderationens IdP.

11. Sundhedsføderationens IdP udsteder nu et SAML token med indlejret SOSI ID-kort, som følger subprofilen beskrevet i [OIOSAML-H]. SAML tokenet sendes i en SAML <Response> via Post til Sårjournalen. Sårjournalen validerer tokenet og logger brugeren ind med de rettigheder, der fremgår af tokenet.

Bemærk at trin 3 – 8 og 11 foregår igennem brugerens browser, hhv. som HTTP Get, Redi-rect eller Post kald.

4.2 Aktiv scenarie / Sikker browser-opstart

For enkeltheds skyld tager den tekniske beskrivelse udgangspunkt i, at det er fagsyste-met, som integrerer direkte med såvel det lokale brugerstyringssystem, SOSI-STS’en og Sårjournalen. For en alternativ realisering se Appendiks: Alternativ opsætning til sikker browser-opstart.

I det aktive sikker browser-opstart scenarie, hvor der ikke etableres en session i Sund-hedsføderations IdP, indgår følgende trin:

1. Brugeren autentificerer sig i forhold til den lokale IdP (AD/Kerberos) 2. Brugeren tilgår fagsystemet. 3. Fagsystemet indhenter brugerens rettigheder til Sårjournalen fra det lokale bru-

gerstyringssystem via en lokal protokol. 4. Fagsystemet udformer et SOSI IDkort for brugeren, som brugeren underskriver

med digital signatur. Fagsystemet foretager et WS-Trust kald mod SOSI-STS’en med det bruger-underskrevne IDkort som input.

5. SOSI-STS’en validerer det bruger-underskrevne IDkort og udsteder et nyt beriget IDkort. IDkortet signeres og sendes til fagsystemet i en WS-Trust response.

6. Fagsystemet laver et WS-Trust Issue kald til SOSI-STS’ens SOSI2OIOSAML snit-flade. Som input sendes det STS-signerede SOSI IDkort og en angivelse af Sår-journalen som audience parameter.

Sårjournalen



3

Bruger


2 2



Fagsystem

8

10

trust

1

2 4

6 7

5

9

Browser


7. SOSI-STS’en udsteder et OIOSAML token med indlejret SOSI IDkort. Tokenet krypteres med Sårjournalens offentlige nøgle og returneres via WS-Trust re-sponse.

8. Fagsystemet klargør input parametrene til sikker browser-opstart af Sårjourna-len, dvs. OIOSAML tokenet, rettighederne og behandlingskonteksten. Derefter genererer fagsystemet en en-gangs-nøgle med kort levertid og knytter de tre input parametre til Sårjournalen til den. Slutteligt dannes en URL som peger til-bage på fagsystemet og som indeholder en-gangs-nøglen som URL parameter, hvorefter browseren startes med denne URL.

9. Fagsystemet modtager HTTP GET kaldet med en-gangs-nøglen og danner ud fra den modtagne en-gangs-nøgle en HTML side med et POST kald til Sårjournalen som indeholder OIOSAML tokenet i en SAML <Response> og rettighederne og behandlingskonteksten som yderlige parametre.

10. Sårjournalen dekrypterer og validerer tokenet, logger brugeren ind med de med-sendte rettigheder og viser de patientdata der hører til den medsendte behand-lingskontekst.

Bemærk at trin 8 og 9 er nødvendige til at generere POST kaldet, idet en browser kun kan startes med en (GET) URL. POST kald genereres typisk ved at returnere en HTML side med et onload script som submitter en FORM via POST med de relevante parametre.

4.3 Passiv scenarie med SOSI

De enkelte trin i det passive scenarie med SOSI, hvor brugeren tilgår Sårjournalen direkte i en browser og viderefører den i SOSI føderationen etablerede sikkerhedskontekst, rea-liseres på følgende måde.

Det passive scenarie med SOSI minder om det almindelige passive scenarie. For god or-dens skyld er alle trinene her gengivet i deres helhed, men bemærk at kun trin 6 – 10 er forskellig fra det almindelige passive scenarie.

1. Brugeren autentificerer sig i forhold til den lokale IdP (AD/Kerberos) 2. Brugeren starter en browser 3. Brugeren foretager et HTTP Get kald til Sårjournalens login-side for sundheds-

faglige personer

Sårjournalen


Bruger


Browser

1

2

National IdP/STS



3

4

5

SOSI STS IDkort cache (fx. SOSI-GW)

trust 11

10

6 9

8

7


4. Sårjournalen afgør, hvorvidt brugeren har en eksisterende session (med Sårjour-nalen). Hvis ikke det er tilfældet, sendes et signeret SAML <AuthnRequest> via HTTP Redirect til sundhedsføderationens IdP.

5. Sundhedsføderationens IdP afgør, hvorvidt brugeren har en eksisterende sessi-on (med sundhedsføderationens IdP). Hvis ikke det er tilfældet, så promptes brugeren til at vælge lokal organisation (og dermed hans lokale IdP). IdP’en gemmer valget i en persistent cookie således, at brugeren kun skal be-kræfte den lokale organisation næste gang IdP’en tilgås. IdP’en sender nu et signeret SAML <AuthnRequest> via HTTP Redirect til bruge-rens lokale IdP.

6. Den lokale IdP afgør, hvorvidt brugeren har en etableret sikkerhedskontekst i SOSI føderationen, dvs. har et gyldigt SOSI IDkort, eksempelvis i SOSI-GW.

7. Den lokale IdP laver et WS-Trust Issue kald til SOSI-STS’ens SOSI2OIOSAML snit-flade. Som input sendes SOSI IDkort og en angivelse af Sundhedsføderationens IdP som audience parameter.

8. SOSI-STS’en udsteder et OIOSAML token med indlejret SOSI IDkort. Tokenet krypteres med en offentlig nøgle for sundhedsføderations IdP, og det returneres i et WS-Trust response.

9. Fra en eventuel IDkort cache sendes det SOSI-STS-udstedte OIOSAML token vi-dere til den lokale IdP.

10. Via brugerens lokale sikkerheds-session udtrækker den lokale IdP rettighe-der/attributter, som er relevant i en national kontekst (herunder rettigheder ift. Sårjournalen og organisationens CVR nummer). En SAML assertion opbygges (med det SOSI-STS-udstedet OIOSAML token indlejret), krypteres og sendes i en SAML <Response> via Post til sundhedsføderationens IdP. Attributterne i SAML assertionen navngives og formateres som specificeret i [OIOSAML-H].

11. Sundhedsføderationens IdP dekrypterer det modtagne SAML token og udsteder et nyt SAML token med indlejret SOSI IDkort, som følger subprofilen beskrevet i [OIOSAML-H], og sender denne i en SAML <Response> via Post til Sårjournalen. Sårjournalen validerer tokenet og logger brugeren ind med de rettigheder, der fremgår af tokenet.

Bemærk at trin 3 – 5 og 10 – 11 foregår i gennem brugerens browser, hhv. som HTTP Get, Redirect eller Post kald.

4.4 Anvendte profiler I nedenstående tabel sammenfattes anvendte protokoller, bindings og tokenprofiler. Sikkerhedsarkitekturen baserer sig på det fællesoffentlige OIOSAML profil (se [OIO-WEBSSO]) og subprofilereringerne i [OIOSAML-H].

Protokol Bindings Tokenprofiler

SAML Authen-tication Request

HTTP Redirect Binding

HTTP Post Binding

OIOSAML OCES Attribute Profile

OIOSAML OCES Attribute Profile for Healthcare

OIOSAML Authentication Assertion Pro-file for Healthcare

WS-Trust Issuance Binding SOSI IDkort


HTTP GET

POST


I forhold til de anvendte bindings gælder der for SAML Authentication Request protokol-len, at requests sendes som HTTP Redirect med parametrene i URL’en og at der til re-sponses benyttes HTTP Post bindingen – præcis som i OIOSAML WebSSO.


Med hensyn til de anvendte tokenprofiler så er format og indhold af SOSI IDkort og OIOSAML token specificeret i henholdsvis [DGWS] og [OIO-WEBSSO].

SAML tokens som udstedes af henholdsvis lokale IdP’er og Sundhedsføderationens IdP profileres i [OIOSAML-H].

5 Roadmap for etablering

Sikkerhedsarkitekturen anbefales etableret i 3 spor, hvor hvert spor består af en afprøv-ning af et af de beskrevne scenarier.

Spor 1 og spor 2 kan med fordel forløbe parallelt, hvorimod spor 3 bør ligge i forlængelse af spor 2.

For hvert spor angives i det følgende kort, hvilke aktiviteter der skal gennemføres for at nå til en afprøvning af scenarieret. Nogle af aktiviteterne kan foregå parallelt, aktivite-terne er derfor listet i ikke-nummereret form.

Bemærk, at det første spor er uafhængigt af etableringen af Sundhedsføderationens IdP.

Aktiviteter i spor 1: Afprøvning af det aktiv scenarie

o Etablering af en SAML snitflade i Sårjournalen, som kan modtage et unsolicited SAML response, hvor rettigheder og behandlingskontekst medsendes som sepa-rate parametre.

o Etablering af trust til SOSI-Føderationen i Sårjournalens SAML snitflade. Typisk etableres trust ved at konfigurere en SAML snitflade med IdP’ens certifikat. SOSI-føderationen opererer derimod ikke med faste føderationscertifikater, men an-vender en familie af føderationscertifikater (som er defineret i gennem et sæt simple regler).

o Konfigurering af SOSI-STS’en med Sårjournalen som aftager af SAML tokens. o Etablering af sikker-browser-opstarts løsning hos pilotdeltageren. o Pilotafprøvning af det aktive scenarie.

Aktiviteter i spor 2: Afprøvning af det passive scenarie

o Etablering af Sundhedsføderationens IdP. o Integration af Sundhedsføderationens IdP med NemLogin IdP’en. o Integration af Sundhedsføderationens IdP med SOSI-STS’en, herunder håndte-

ring af flere sundhedsfaglige autorisationer i Sundhedsføderationens IdP. o Integration af Sundhedsføderationens IdP med pilotdeltagerens lokale IdP, her-

under etablering af funktionalitet i Sundhedsføderationens IdP til, at brugeren kan vælge egen organisation.

o Etablering af funktionalitet til udstedelse af OIOSAML-H token i Sundhedsføde-rationens IdP, herunder validering af om CVR nummeret i tokens fra den lokale IdP og NemLogin er ens.

o Integration af Sårjournalen med Sundhedsføderationens IdP, herunder metadata udveksling og etablering af trust.

o Pilotafprøvning hos pilotorganisationen. o Afprøvning af link udveksling via korrespondancemeddelelse.

Aktiviteter i spor 3: Afprøvning af det passive scenarie med SOSI

o Integration af pilotdeltagerens lokale IdP med SOSI-STS’en. o Konfigurering af SOSI-STS’en med Sundhedsføderationens IdP som aftager af

SAML tokens. o Integration af pilotdeltagerens lokale IdP med Sundhedsføderationens IdP, her-

under udstedelse af SAML token med indlejret krypteret OIOSAML token i pilot-deltagerens lokale IdP.

o Udstedelse af OIOSAML-H token i Sundhedsføderations IdP på baggrund af SAML tokenet fra pilotdeltagerens lokale IdP.

o Pilotafprøvning hos pilotorganisationen.


Under pilotafprøvningen af sikkerhedsarkitekturen for Sårjournalen må der ikke ændres på SOSI-STS’en, hvilket medfører, at der i det aktive scenarie overføres brugerrettigheder uden for tokenet, se også appendiks 8.3 - Overførsel af rettigheder.

I en senere fase bør de fornødne udvidelser i SOSI-STS’en etableres således, at rettighe-derne kan blive en del at det SOSI-STS-udstedte token (som dermed også kommer til at overholde tokenprofilen i [OIOSAML-H]).

På længere sigt kunne sikkerhedsarkitekturen integreres til fælleskommunale eller fæl-lesregionale føderationer, se Appendiks: Integration med andre føderationer.

Sikkerhedsarkitekturen kunne desuden udvides med et passivt scenarie med decentral stærk autentifikation. Baseret på en lokal stærk autentifikationsmekanisme, der lever op til kravene til autentifikationsniveau 3, frem for NemLogin eller SOSI-STS’en - se også Appendiks: Sikkerhedsanalyse.

6 Referencer

[AUTHN-SIK] Vejledning vedrørende niveauer af autenticitetssikring

http://www.digst.dk/~/media/Files/Arkitektur-og-standarder/Service-orienteret-infrastruktur/HoringBstnivautenticitetssikringv5.pdf

[AUTHN-VURD] Vurdering af autentifikationsstrategier for nationale tjenester i sundhedssektoren, version 1.1, 22. januar 2009

Fås ved henvendelse til NSI.

[DGWS] Den Gode Webservice, version 1.0.1

http://www.medcom.dk/wm110731

[FIBS] Federal Information Processing Standards Publication 140-2 – Securi-ty Requirements for Cryptographic Modules

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

[NIST] NIST Special Publication 800-63-2 – Electronic Authentication Guide-line

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf

[OIOSAML-H] OIOSAML Attribute Profiles for Healthcare (OIOSAML-H)

Under udarbejdelse

[OIO-WEBSSO] OIO Web SSO Profile V2.0.9

https://digitaliser.dk/resource/2377872/artefact/OIO+Web+SSO+Profile+V2+09.pdf

[PROJEKT-SÅRJ] ”Projektdokument: Sårjournalen - Ændring af sikkerhedsarkitektu-ren”, Version 1.1, MedCom, 10. Marts 2015

Fås ved henvendelse til MedCom.

[SIKKERHED-SÅRJ] ”Føderative sikkerhedsmodeller til Sårjournalen - Overordnet arki-tektur”, v.0.95, NSI, 17. november 2014

Fås ved henvendelse til NSI.

[TOGAF] TOGAF - Architecture Development Method (ADM)

http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html


7 Appendiks: Sikkerhedsanalyse

I [NIST] defineres der fire niveauer for tillid til autentifikationsløsninger for brugere, hvor niveau 1 er det laveste og niveau 4 det højeste. I det daværende IT- og Telestyrelsens regi blev der udformet en national vejledning vedrørende niveauer af autentifikations-sikring, som bygger på NIST’s opdeling i fire niveauer [AUTHN-SIK].

I vejledningen anbefales det at benytte nedenstående tabel til at vurdere en tjenestes behov for niveau af sikkerhed ved brugerautentifikation.

Som der fremgår af tabellen, bør der allerede ved lille risiko for fysisk personskade fore-tages brugerautentifikation på niveau 3.

I og med, at der i Sårjournalen er risiko for personskade ved misbrug, bør brugerautenti-fikation derfor foregå på niveau 3.

Indenfor sundhedssektoren har daværende Sammenhængende Digital Sundhed i Dan-mark (SDSD) i en analyse konkluderet, at autentifikationsløsninger baseret på OCES medarbejdersignatur lever op til autentifikationsniveau 3, hvorimod løsninger der base-rer sig på netværks login ikke opfylder kravene til niveau 3, se [AUTHN-VURD].

Der anbefales således at basere autentifikationsløsning til Sårjournalen på OCES medar-bejdersignatur, der på nuværende tidspunkt er den eneste bredt etablerede autentifika-tionsløsning i Danmark, som lever op til niveau 3.


8 Appendiks: Arkitekturbeslutninger

Under udformning af denne løsningsbeskrivelse blev der sammen med de involverede parter truffet en række arkitekturbeslutninger, som fastholdes her.

8.1 SOSI IDkort

Problem Bør SOSI IDkortet altid indlejres i de tokens sundhedsføderationens IdP udsteder?

Alternativer A) Ja, SOSI IDkortet indlejres altid

B) Nej, SOSI IDkortet kan udlades

Analyse De etablerede sikkerhedspolitikker omkring udstedelse, opbevaring og anvendelse af de kryptografiske nøgler, som benyttes til at udstede SOSI IDkort (og NemLogin tokens), lever op til FIBS niveau 2 [FIBS], herunder opbevaring af nøgler på et tamper-proof hardware sikkerhedsmodul.

Nøglerne til den nationale føderation er ikke beskyttet på sammen ni-veau, hvilket medfører, at risikoen for kompromittering af sundhedsføde-rationens IdP er større.

Indlejring af SOSI IDkortet i alle tokens, som sundhedsføderationens IdP udsteder, imødegår denne risiko, idet der dermed ikke kan udstedes tokens alene ud fra sundhedsføderationens IdP’s (kompromitterede) nøgler.

Beslutning A) SOSI IDkortet indlejres altid i de udstedte tokens

8.2 Login-session

Problem Nogle sundhedsfaglige brugere optræder i forskellige roller i løbet af en arbejdsdag – såvel lokale roller (arbejdsfunktioner) som nationale roller (sundhedsfaglig autorisationer).

Hvordan kan brugere med flere sundhedsfaglige autorisationer understøt-tes i forbindelse med login til den nationale føderation i det passive sce-narie ?

Alternativer A) Lad brugeren vælge rolle (sundhedsfaglig autorisation) ved login til den nationale føderation. Dermed bliver login-sessionen i den nationale føderation på rolle-niveau.

B) Lad login-sessionen til den nationale føderation alene være på identi-tets-niveau, og lad brugeren vælge rolle i de enkelte applikationerne (her Sårjournalen), hvis applikationen har behov for at kende rollen.

Analyse Medarbejdere med én sundhedsfaglig autorisation vil af SOSI-STS’en få angivet autorisationen i det udstedte SOSI IDkort. Medarbejdere med flere autorisationer skal på udstedelsestidspunktet angive, hvilken autorisation de arbejder under, så denne kan angives i SOSI IDkortet.

SOSI IDkortet indlejres i det nationale token og vil i princippet kunne benyttes til at foretage webservice kald på brugerens vegne. Dette behov har Sårjournalen i sin nuværende form ikke – SOSI IDkortet inkluderes alene som bevis på at udstedelsen af det nationale token lever op til kravene til FIBS niveau 2 [FIBS].


Autorisationsattributterne tilkommer Sårjournalen som en del af det nationale token og Sårjournalen autoriserer brugere alene på baggrund af attributterne i det nationale token.

Beslutning B) Lad login-sessionen til den nationale føderation alene være på identi-tets-niveau, og lad brugeren vælge rolle i de enkelte applikationerne (her Sårjournalen), hvis applikationen har behov for at kende rollen.

Dels for ikke at besvære brugerne for information der ikke er relevant i Sårjournalen og dels for at begrænse udviklingsomkostningerne vælger sundhedsføderationens IdP (for brugere med flere sundhedsfaglig autori-sationer) hvilken autorisation der skal inkluderes i SOSI IDkortet. Samti-digt forpligtes Sårjournalen til ikke at anvende IDkortet til efterfølgende webservice kald.

Bemærkning Ovenstående beslutning vedrører alene afprøvningen af sikkerhedsarki-tekturen for Sårjournalen.

Der udestår en afklaring af hvilken type national føderation, der ønskes skabt inden for sundhedsvæsnet. Fx hvorvidt der operereres på rolle- eller identitetsniveau.

Der udestår ligeledes en afklaring af hvordan et egentlig boot-strap token til det nationale token bør udformes. Formålet med et boot-strap token er at give applikationer mulighed til at foretage webservice kald på brugerens vegne (efter passende omveksling af boot-strap tokenet).

Disse afklaring ligger uden for rammen for etableringen af sikkerhedsarki-tekturen for Sårjournalen.

8.3 Overførsel af rettigheder

Problem Skal lokalt administrerede rettigheder i det aktive scenarie overføres som en del af tokenet?

Alternativer A) Ja, rettigheder er en del af tokenet.

B) Nej, rettigheder overføres separat.

Analyse Ved at lade rettigheder indgå i det krypterede token sikres disse mod modikation i en kompromitteret browserklient. Derved vil også indholdet af tokenet blive ens i det aktive og det passive scenarie.

Indlejring i tokenet kræver en ændring i vekslingssnitflade hos SOSI-STS’en.

Beslutning B) Overfør rettigheder separat, idet sikkerhedsarkitekturen for Sårjourna-len i første omgang ønskes etableret uden ændringer i SOSI-STS.

Risiko for kompromittering af browseren accepteres under afprøvningen.


9 Appendiks: Passiv scenarie med behandlingskontekstoverførsel

Nedenstående figur illustrerer flowet for et passivt scenarie hvor behandlingskonteksten overføres fra fagsystemet.

Det er kun de første 4 trin der afviger fra det standard passive scenarie.

Bemærk endvidere at såfremt der allerede er etableret et SOSI IDkort i det lokale sikker-hedsdomæne kunne trin 7 erstattes med en tilføjelse af et SOSI STS token i trin 6. Der-med kunne der realiseres et passivt scenarie med SOSI og behandlingskontekstoverfør-sel.

10 Appendiks: Alternativ opsætning til sikker browser-opstart

I nedenstående figur illustreres et alternativt setup for det aktive scenarie, hvor integra-tion til lokal IdP, SOSI-STS’en og Sårjournalen varetages af en særskilt sikkerhedskom-ponent.

Sårjournalen


Bruger


Browser

1

2

IdP/STS



4

5


NemLogin IdP 7

9


(SOSI STS)

Token

IDkort

NyToken

IDkort

Token

Rettigheder 6

8

Behandlingskontekst

Fagsystem

3


I det alternative aktive scenarie indgår følgende trin:

1. Brugeren autentificerer sig i sit lokale sikkerhedsdomæne. 2. Brugeren tilgår fagsystemet. 3. Brugeren starter browseren fra fagsystemet. 4. Fra browseren overføres Behandlingskonteksten til en lokal Sikkerhedskom-

ponent 5. Sikkerhedskomponenten indhenter Rettigheder fra det lokale brugerstyringssy-

stem/rolleregister. 6. I sikkerhedskomponenten autentificerer brugeren sig med sin digital signatur

hos SOSI-STS’en og får udstedt et IDkort. 7. Sikkerhedskomponenten veksler IDkortet til et Token med indlejret IDkort hos

SOSI-STS’en. 8. Fra sikkerhedskomponenten overføres tokenet, rettighederne og behandlings-

konteksten til Sårjournalen. Sårjournalen giver brugeren adgang på baggrund af de medsendte rettigheder og viser de patientdata, der hører til den overførte be-handlingskontekst.

Bemærk at fagsystemet i denne opsætning kan være driftet uden for den lokale sikker-hedsdomæne.

11 Appendiks: Integration med andre føderationer

For de anvendere, der selv indgår i en fælles føderation, eksempelvis i gennem KOMBITs kommende IdP (også kaldt ’ContextHandler’), kunne brugernes rettigheder i det passive scenarie hentes via fællesføderationens IdP som skitseret i nedenstående figur.

5

Sårjournalen



Bruger




Browser

6

7 Fagsystem

3 trust

1 Rettigheder

IDkort 2

Sikker-heds

Kompo-nent

4 8

Behandlingskontekst

IDkort

Token

IDkort

Token

IDkort

Rettigheder Behandlings

kontekst


Bemærk at autentifikation af brugerne i ovenstående figur foregår hos NemLogin IdP’en.

Under forudsætning af at der kan opnås stærk autentifikation af brugerne i deres lokale sikkerhedsdomæne vil den centrale NemLogin autentifikation kunne erstattes med lokal stærk autentifikation, hvilket er vist i nedenstående figur.

Regional/Kommunal føderation

Sårjournalen


Bruger


Browser

1

2




3

4 10


(SOSI STS)

IDkort

NyToken

IDkort

6

9

IdP/STS 5

7

NyToken NyToken

NyToken

Regional/Kommunal føderation

Sårjournalen


Bruger


Browser

1

2




3

4


NemLogin IdP 8

10


(SOSI STS)

Token

IDkort

NyToken

IDkort

Token

Rettigheder 6

9

IdP/STS 5

7

Rettigheder

Documents

Loesningsbeskrivelse Saarjournal Sikkerhedsarkitektur-v10 · kommuner, apoteker, osv.). IdP ”Identity Provider”. En it-tjeneste der ved hjælp af it-tekniske hjælpemidler og