LAKESIDE. Sårjournalen. Løsningsbeskrivelse til ændring af. sikkerhedsarkitekturen. Version juni 2015

Transkript

1 LAKESIDE Sårjurnalen Løsningsbeskrivelse til ændring af sikkerhedsarkitekturen Versin juni 2015 LAKESIDE A/S Marselisbrg Havnevej 32, 1. sal DK-8000 Aarhus C Denmark tlf inf@lakeside.dk

2 Indhldsfrtegnelse 1 INDLEDNING METODE RAMMER OG PRINCIPPER ANVENDELSESSCENARIER DEFINITION AF TERMER OG FORKORTELSER FORRETNINGSMÆSSIGE GEVINSTER NUVÆRENDE LØSNING (AS-IS) KOMMENDE SIKKERHEDSARKITEKTUR (TO-BE) GEVINSTER INFORMATIONSARKITEKTUR PASSIV SCENARIE AKTIV SCENARIE / SIKKER BROWSER-OPSTART PASSIV SCENARIE MED SOSI UDVEKSLING AF LINKS TIL PATIENTDATA LØSNINGENS TEKNISKE ELEMENTER PASSIV SCENARIE AKTIV SCENARIE / SIKKER BROWSER-OPSTART PASSIV SCENARIE MED SOSI ANVENDTE PROFILER ROADMAP FOR ETABLERING REFERENCER APPENDIKS: SIKKERHEDSANALYSE APPENDIKS: ARKITEKTURBESLUTNINGER SOSI IDKORT LOGIN-SESSION OVERFØRSEL AF RETTIGHEDER APPENDIKS: PASSIV SCENARIE MED BEHANDLINGSKONTEKSTOVERFØRSEL APPENDIKS: ALTERNATIV OPSÆTNING TIL SIKKER BROWSER- OPSTART APPENDIKS: INTEGRATION MED ANDRE FØDERATIONER LAKESIDE side 2 / 22

3 1 Indledning Nærværende dkument beskriver etablering af en sikkerhedsarkitektur fr Sårjurnalen. Med afsæt i Sårjurnalens nuværende løsning fr autentifikatin g autrisatin af brugere belyses, hvilke gevinster der gennem etablering af sikkerhedsarkitekturen kan høstes hs de invlverede parter. Løsningens tekniske elementer frklares, g der pstilles et radmap til en trinvis realisering g afprøvning af sikkerhedsarkitekturen. Denne løsningsbeskrivelse er således en kntekstualisering g knkretisering af de af NSI beskrevne sikkerhedsmdeller fr Sårjurnalen [SIKKERHED-SÅRJ]. Dkumentet henvender sig til arkitekter, prjektledere g interesserede parter, sm indgår i piltafprøvningen af sikkerhedsarkitekturen. Der frventes, at læseren har et basalt kendskab til Sårjurnal løsningen. 1.1 Metde Udarbejdelsen af denne løsningsbeskrivelse er inspireret af TOGAF Architecture Develpment Methd (ADM), se [TOGAF]. I ADM gennemgår arkitekturprcessen en række faser startende med en fastlæggelse af rammerne (svarende til afsnit Rammer g principper), hvrefter der frmuleres en arkitekturvisin (afsnit Anvendelsesscenarier), frretningsarkitekturen beskrives (afsnit 2 - Frretningsmæssige gevinster), en lgisk infrmatinssystemarkitektur defineres (afsnit 3 - Infrmatinsarkitektur), løsningens tekniske systemlandskab beskrives (afsnit 4 - Løsningens tekniske elementer) g mdel fr en trinvis etablering præsenteres (afsnit 5 - Radmap fr etablering). 1.2 Rammer g principper Løsningen bygger på de i [SIKKERHED-SÅRJ] identificerede rammer g principper, sm her krt plistes: 1. Udnyt så vidt muligt eksisterende løsninger 2. Brugeradministratin fretages i egne systemer 3. Samme autentifikatinssikkerhed sm ved Fælles Medicinkrt 4. Skab bedre sammenhæng mellem systemer 5. Tænk fremad så kmmende løsninger får gavn af indsatsen 6. Løsningen må ikke være unødigt svær at administrere 7. Følg referencearkitekturer g øvrige analyser 1.3 Anvendelsesscenarier Det er visinen, at sikkerhedsarkitekturen sm minimum understøtter de verrdnede frventede anvendelsesscenarier fr adgangen til Sårjurnalen med den frnødne sikkerhed: A) Sundhedspersner tilgår Sårjurnalen fra et fagsystem igennem en knap løsning, hvr en allerede etableret sikkerheds- g behandlingskntekst verføres til brwseren (sikker brwser-pstart) B) Sundhedspersner g brgere tilgår Sårjurnalen direkte i en brwser (gså fra mbile enheder) C) Sundhedspersner udveksler links til ressurcer i Sårjurnalen i gennem Med- Cm EDI/XML krrespndancemeddelelser LAKESIDE side 3 / 22

4 1.4 Definitin af termer g frkrtelser Frkrtelse / Term Akkreditiver Autentifikatin Autrisatin CA Føderatin IdP TOGAF Frklaring I it-sammenhæng er akkreditiver bevis fr en brugers identitet. En bruger afgiver akkreditiver til et itsystem, g systemet kan på baggrund af disse infrmatiner verificere brugerens identitet. Den mest udbredte frm fr akkreditiver er brugernavn + kderd. Et andet eksempel er digital signatur, der udvider sikkerheden fra alene at mfatte nget, brugeren har kendskab til (et kderd) til gså at mfatte nget, brugeren er i besiddelse af (f.eks. en nøglefil, et kdekrt eller lignende). Kbling mellem en bruger g en digital identitet, baseret på afgivelse af akkreditive der verificerer, at burgeren er den hævdede digitale identitet. Styring g håndtering af brugerens rettigheder til adgang til ressurcer, herunder data, tjenester g funktinalitet. Certificate Authrity. Myndighed, der har ansvaret fr certifikater g udstedelse af disse. Opgaverne g ansvarsmråderne tilhørende en CA er pdelt i Identity Prfing Service (IPS) g Credential Management Service (CMS). En række rganisatiner, der har indbyrdes tillid til hinanden mkring autentificering af brugere. Indenfr en føderatin kan en bruger autentificere sig verfr en lkal autritet g derefter anvende sin identitet i tjenester udbudt af de andre rganisatiner uden at skulle autentificere sig igen. En natinal føderatin på sundhedsmrådet vil bestå af blandt andre reginerne g et antal natinale tjenester, én eller flere CA'er samt et antal parter på lige fd med reginerne (eksempelvis lægepraksis, kmmuner, apteker, sv.). Identity Prvider. En it-tjeneste der ved hjælp af ittekniske hjælpemidler g akkreditiver, kan kntrllere m en bruger er den, vedkmmende udgiver sig fr at være. En IdP prethlder lgin sessiner på tværs af web applikatiner. Dermed kan der pnås Single Sign On, dvs. brugeren behøver kun lgge på én gang fr at få adgang til alle web applikatinerne, der er med i IdP sammenslutningen. Ngle IdP implementeringer understøtter gså Single Lg-ut, så brugeren autmatisk lgges af i alle tilsluttede web applikatiner. TOGAF står fr The Open Grup Architecture Framewrk g er et rammeværk fr Enterprise Arkitektur. LAKESIDE side 4 / 22

5 2 Frretningsmæssige gevinster I dette afsnit sammenhldes sikkerhedsaspekterne fr det nuværende løsning i Sårjurnalen med den kmmende sikkerhedsarkitektur. Desuden beskrives de frretningsmæssige gevinster, der kan realiseres gennem etablering af en ny sikkerhedsarkitektur. 2.1 Nuværende løsning (AS-IS) Den etablerede Sårjurnalsløsning kan i frhld til sikkerhed g kntekstverførsel karakteriseres igennem følgende egenskaber: A) Brugerstyring i Sårjurnalen Sundhedspersners adgang g rettigheder administreres direkte i Sårjurnalen. B) Særskilt brugernavn/passwrd Sundhedspersner tildeles et unikt brugernavn/passwrd til Sårjurnalen. Brgere kan til gengæld benytte deres NemID akkreditiver. C) Svag autentifikatin Sårjurnalens brugerautentifikatin lever i sin nuværende frm ikke p til sikkerhedsanbefalingerne til håndtering af persnfølsmme data, se Appendiks: Sikkerhedsanalyse. D) Kan ikke indgå i Single-Sign-On (SSO) Sårjurnalens brugerautentifikatin kan hverken fr sundhedspersner eller brgere indgå i et SSO setup, sm eksempelvis Sundhedsjurnalen eller FMKnline er del af. E) Ingen sikkerhedssessinsverførsel fra fagsystem Sundhedspersner, sm allerede er autentificeret i et lkalt fagsystem, skal på ny autentificere sig, når de tilgår Sårjurnalen. F) Ingen kntekstverførsel fra fagsystem Selvm en sundhedspersn arbejder med en bestemt patients data i sit lkale fagsystem, kan denne behandlingskntekst ikke verføres til Sårjurnalen sundhedspersnen må i stedet fremfinde patienten på ny i Sårjurnalen. 2.2 Kmmende sikkerhedsarkitektur (TO-BE) Den kmmende Sårjurnalsløsning kan i frhld til sikkerhed g kntekstverførsel karakteriseres igennem følgende egenskaber: A) Lkal brugerstyring Sundhedspersners adgang g rettigheder administreres i sundhedspersnens egen rganisatin på lige fd med adgang g rettigheder til andre it-systemer. B) Single-set-f-Credentials Brugerne kan anvende de samme akkreditiver, sm de benytter til andre itsystemer. LAKESIDE side 5 / 22

6 C) Frnøden stærk autentifikatin Sundhedspersners adgang til persnfølsmme data sikres gennem frnøden stærk autentifikatin, se Appendiks: Sikkerhedsanalyse. D) Kan indgå i Single-Sign-On (SSO) Brugere kan pnå SSO mellem Sårjurnalen g natinale webløsninger sm eksempelvis FMK-nline g Sundhedsjurnalen. E) Sikkerhedssessinsverførsel fra fagsystem Ved pstart af Sårjurnalen fra et fagsystem kan tilstrækkelig stærk autentificerede sundhedspersner verføre deres allerede etablerede sikkerhedskntekst til Sårjurnalen. F) Kntekstverførsel fra fagsystem Sundhedspersner kan ligeledes verføre den knkrete patientkntekst fra deres fagsystem til Sårjurnalen. 2.3 Gevinster Med etableringen af sikkerhedsarkitekturen er der en række gevinster at høste, såvel fr de berørte brugere g patienter, sm fr sundhedspersners rganisatiner. A) Fra Brugerstyring i Sårjurnalen til Lkal brugerstyring Brugerstyring til Sårjurnalen kan integreres i sundhedspersnens lkale brugerstyringssystem, så det dermed håndteres på lige fd med adgangsstyring til andre it-systemer. Dette gør rettighedsadministratinen enklere g mere effektiv fr de lkale brugeradministratrer. B) Fra Særskilt brugernavn/passwrd til Single-set-f-Credentials At skulle huske frskellige akkreditiver er en udfrdringer fr mange brugere. Passwrds bliver glemt eller nteres på papir, med risik fr at blive set g misbrugt af uvedkmmende persner. Ved at genbruge, de samme akkreditiver sm brugerne gså benytter til deres lkale systemer, mindskes risiken fr misbrug. Desuden frsvinder det administrative verhead, sm ligger i vedligehldelse af separate akkreditiver. C) Fra Svag autentifikatin til Frnøden stærk autentifikatin Gennem frnøden stærk autentifikatin frmindskes risiken fr sikkerhedsbrud, hvr uvedkmmende persner skaffer sig adgang til persnfølsmme 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ødvendige arbejdsgange hs brugerne fjernes g dermed tid spares. E) Fra Ingen sikkerhedssessinsverførsel fra fagsystem til Sikkerhedssessinsverførsel fra fagsystem Sm i Single-Sign-On scenariet undgås re-autentifikatin af brugerne, sm derved sparer tid. LAKESIDE side 6 / 22

7 F) Fra Ingen kntekstverførsel fra fagsystem til Kntekstverførsel fra fagsystem Ved at verføre behandlingsknteksten fra fagsystemet til Sårjurnalen undgår brugeren at skulle fremfinde den pågældende patient på ny. Derved spares tid g risiken fr fejl mindskes. 3 Infrmatinsarkitektur I det følgende præsenteres den kmmende sikkerhedsarkitektur fr Sårjurnalen sm pfylder de i afsnit 2.2 (Kmmende sikkerhedsarkitektur (TO-BE)) beskrevne egenskaber. Dette afsnit mhandler infrmatinsarkitekturen fr sikkerhedsløsningen. Overrdnet g teknlgineutralt anskueliggøres infrmatinsflwet mellem de enkelte dele, der udgør den samlede sikkerhedsløsning. Hvrdan de enkelte parter knkret interagerer med hinanden g hvrdan data knkret udveksles, behandles i afsnit 4 (Løsningens tekniske elementer). Beskrivelsen er delt p efter de tre verrdnede anvendelsesscenarier sm skitseret i [PROJEKT-SÅRJ]: 1. Det passive scenarie 2. Det aktive scenarie / sikker brwser-pstart 3. Det passive scenarie med SOSI Der anbefales at rganisatiner primært reginer g kmmuner sm har en egen IdP (eksempelvis AD FS) at implementere et af de t passive scenarier. Organisatiner sm ikke har en egen IdP (eksempelvis lægehuse) kan pnå verførsel af sikkerheds- g behandlingskntekst til Sårjurnalen ved at realisere det aktive scenarie. 3.1 Passiv scenarie Det passive scenarie dækker ver anvendelsesscenariet, hvr en sundhedsfaglig persn tilgår Sårjurnalen direkte fra en brwser, sm illustreret i nedenstående figur. Hængelåsen på de enkelte data-elementer indikerer at infrmatinen er krypteret under mdtagerens nøgle. Natinal Sundhedsføderatin Fællesffentlig føderatin Lkalt sikkerhedsdmæne Security Tken Service (SOSI STS) Rlle/Rettigheder (attributter) Tken 7 Autentifikatin + IdP / STS (f.eks. ADFS) 5 Rettigheder IdP/STS 6 Tken NemLgin IdP NyTken 2 Brwser 3 Sårjurnalen Bruger I det passive scenarie indgår følgende trin: LAKESIDE side 7 / 22

8 1. Brugeren autentificerer sig i sit lkale sikkerhedsdmæne (eksempelvis ved at lgge på sit Windws Active Directry (AD) dmæne). 2. Brugeren åbner en brwser. 3. Brugeren tilgår Sårjurnalen. 4. Sårjurnalen knstaterer, at brugeren ikke har ngen gyldig sikkerhedskntekst, g viderestiller brugeren til sundhedsføderatinens IdP. 5. IdP en indhenter en liste ver brugerens Rettigheder i frhld til natinale tjenester hs brugerens hjemmerganisatin. 6. Brugeren viderestilles til autentificering hs NemLgin IdP en. NemLgin returner et Tken sm bevis fr, at brugeren nu er stærk autentificeret. 7. IdP en veksler nu NemLgin tkenet til et SOSI hs SOSI-STS en. 8. IdP en danner et NyTken indehldende attributter fra NemLgin tkenet, rettighederne hentet fra brugerrganisatinen sm er relevante fr Sårjurnalen, samt et fra STS en. IdP en sender NyTken et til Sårjurnalen. Sårjurnalen giver brugeren adgang svarende til de rettigheder, der fremgår af tkenet. Sårjurnalen kan anvende det verførte SOSI- til at kalde andre tjenester indenfr sundhedsmrådet fr brugeren. Det skitserede flw tager udgangspunkt i at brugeren åbner en brwser g derefter tilgår Sårjurnalen. Alternativt kunne brwseren startes fra et fagsystem g dermed understøtte en verførsel af behandlingsknteksten, se Appendiks: Passiv scenarie med behandlingskntekstverførsel. Det er værd at bemærke, at scenariet frløber lidt anderledes, når Sårjurnalen tilgås fra en mbil enhed. Eksempelvis en ipad, hvr brugeren i trin 1 typisk ikke lgger på et sikkerhedsdmæne, men alene autentificerer sig direkte md den mbile enhed. I dette tilfælde skal brugeren i trin 5 autentificere sig md sit lkale sikkerhedsdmæne, eksempelvis ved at lgge på den lkale IdP med brugernavn g passwrd. Brugere med flere sundhedsfaglige autrisatiner håndteres sm beskrevet i afsnit Lgin-sessin. 3.2 Aktiv scenarie / Sikker brwser-pstart I det aktive scenarie tilgår brugeren Sårjurnalen fra sit lkale fagsystem g verfører en allerede etableret sikkerheds- g behandlingskntekst fra fagsystemet til Sårjurnalen, når denne pstartes fra en brwser. Lkalt sikkerhedsdmæne Natinal sundhedsføderatin Autentifikatin (f.eks. AD / Kerbers) Rlle/Rettigheder (f.eks. AD / LDAP) 1 3 Rettigheder Bruger 2 Fagsystem 6 5 Tken Security Tken Service (SOSI STS) trust Brwser 7 Tken Sårjurnalen Rettigheder Behandlings kntekst LAKESIDE side 8 / 22

9 I det aktive scenarie indgår følgende trin: 1. Brugeren autentificerer sig i sin lkale sikkerhedsdmæne. 2. Brugeren tilgår fagsystemet. 3. Fagsystemet indhenter Rettigheder fra det lkale brugerstyringssystem. 4. I gennem fagsystemet autentificerer brugeren sig med sin digital signatur hs SOSI-STS en g får udstedt et. 5. Fagsystemet veksler et til et Tken med indlejret hs SOSI-STS en. (Tkenets frm g indhld er magen til NemLgin tkenet i det passive scenarie.) 6. Brugeren starter nu brwseren fra fagsystemet. 7. Fra brwseren verføres tkenet, rettighederne g Behandlingsknteksten til Sårjurnalen. Sårjurnalen giver brugeren adgang svarende til de rettigheder, der fremgår af tkenet. Patientdata vises i verensstemmelse med den verførte behandlingskntekst. Bemærk at piltprjektet i trin 7 ikke verfører brugerrettighederne indlejret i tkenet. Se afsnit 8.3 (Overførsel af rettigheder) fr en begrundelse af denne beslutningen. Udgangspunktet fr scenariet illustreret via venstående figur er, at fagsystemet integrerer til det lkale brugerstyringssystem g SOSI-STS en, samt står fr sikker brwserpstart. Der kan være psætninger, hvr fagsystemet ikke har adgang til et lkalt brugerstyringssystem (idet fagsystemet ikke driftes lkalt) eller der kan være ønskeligt at afkble lgikken mkring sikker brwser-pstart fra fagsystemet. I afsnit 10 (Appendiks: Alternativ psætning til sikker brwser-pstart) illustreres en mdel, hvr integratinen til lkalt brugerstyringssystem, SOSI-STS g Sårjurnalen håndteres af en separat lkal sikkerhedskmpnent. 3.3 Passiv scenarie med SOSI I det passive scenarie med SOSI er den stærke autentifikatin af brugeren hs NemLgin erstattet med en videreførelse af en allerede etableret stærk sikkerhedskntekst i sundhedsføderatinen. Natinal sundhedsføderatin Lkalt sikkerhedsdmæne Rlle/Rettigheder (attributter) 8 Tken Tken Rettigheder Natinal IdP/STS Autentifikatin + IdP / STS (f.eks. ADFS) 6 5 trust cache (fx. SOSI-GW) Tken 7 SOSI STS NyTken 2 Brwser 3 Sårjurnalen Bruger I det passive scenarie med SOSI indgår følgende trin: LAKESIDE side 9 / 22

10 1. Brugeren autentificerer sig i sit lkale sikkerhedsdmæne. 2. Brugeren åbner en brwser. 3. Brugeren tilgår Sårjurnalen. 4. Sårjurnalen knstaterer, at brugeren ikke har ngen gyldig sikkerhedskntekst g viderestiller brugeren til sundhedsføderatinens IdP. 5. IdP en viderestiller brugeren til brugerens lkale IdP. 6. I brugerens lkale IdP afgøres, m brugeren har et gyldigt, dvs. en gyldig stærk sikkerhedskntekst. 7. Brugerens lkale IdP veksler brugerens til et Tken med indlejret hs SOSI-STS en. 8. Den lkale IdP returner et samlet tken, sm indehlder det SOSI-STS udstedte tken g brugerens Rettigheder i frhld til natinale tjenester. 9. IdP en danner nu et NyTken indehldende attributter fra SOSI-STS tkenet, rettighederne hentet fra brugerrganisatinen sm er relevante fr Sårjurnalen g et (præcist sm i det simple passive scenarie). IdP en sender NyTken et til Sårjurnalen, sm giver brugeren adgang svarende til de rettigheder, der fremgår af tkenet. 3.4 Udveksling af links til patientdata Sundhedsfaglig persner kan udveksle links til patientdata i Sårjurnalen med hinanden, eksempelvis via MedCms Krrespndancemeddelelse. En pstart af Sårjurnalen fra et tilsendt link svarer til et passiv scenarie, hvr behandlingsknteksten (i frm en af reference til patienten g eventuel et knkrete sår) medsendes, men hvr autentifikatins- g autrisatins-trinene er uændret. Dette er illustreret fr det simple passive scenarie i nedenstående figur, hvr brugeren i trin 2 åbner det tilsendte link i brwseren, g hvr behandlingsknteksten verføres til Sårjurnalen i trin 3. Natinal Sundhedsføderatin Fællesffentlig føderatin Lkalt sikkerhedsdmæne Security Tken Service (SOSI STS) Rlle/Rettigheder (attributter) Tken 7 Autentifikatin + IdP / STS (f.eks. ADFS) 5 Rettigheder IdP/STS 6 Tken NemLgin IdP NyTken Bruger 2 Brwser 3 Behandlings kntekst Sårjurnalen 4 Løsningens tekniske elementer I det følgende beskrives de anvendte prfiler g teknlgier, der udgør den samlede sikkerhedsløsning fr Sårjurnalen. Afsnittet henvender sig primært til læsere med en frhldsvis teknisk baggrund. Fr hvert af de tre scenarier beskrives, hvrdan hver enkel integratin realiseres. I dette afsnit dykkes således lidt dybere ned i teknlgien. LAKESIDE side 10 / 22

11 Sikkerhedsarkitekturen bygger på etableret infrastruktur g eksisterende prfiler, herunder specielt OIOSAML WebSSO prfilen [OIO-WEBSSO]. Fr at gøre løsningen rbust ver fr en kmprmittering af transprtlaget g brugerens klient, så fregår al internettransprt med SSL/TLS kryptering, g alle internetverførte SAML tkens krypteres under aftagerens nøgle. 4.1 Passiv scenarie Natinal Sundhedsføderatin Fællesffentlig føderatin Lkalt sikkerhedsdmæne Security Tken Service (SOSI STS) Rlle/Rettigheder (attributter) 9 10 Autentifikatin + IdP / STS (f.eks. ADFS) 7 6 IdP/STS 8 5 NemLgin IdP Brwser 3 Sårjurnalen Bruger De enkelte trin i det passive scenarie, hvr brugeren tilgår Sårjurnalen direkte i en brwser, realiseres på følgende måde. 1. Brugeren autentificerer sig i frhld til den lkale IdP (AD/Kerbers) 2. Brugeren starter en brwser 3. Brugeren fretager et HTTP Get kald til Sårjurnalens lgin-side fr sundhedsfaglige persner 4. Sårjurnalen afgør, hvrvidt brugeren har en eksisterende sessin (med Sårjurnalen). Hvis ikke det er tilfældet, sendes et signeret SAML <AuthnRequest> via HTTP Redirect til sundhedsføderatinens IdP. 5. Sundhedsføderatinens IdP afgør, hvrvidt brugeren har en eksisterende sessin (med sundhedsføderatinens IdP). Hvis ikke det er tilfældet, så prmptes brugeren til at vælge lkal rganisatin (g dermed hans lkale IdP). IdP en gemmer valget i en persistent ckie således, at brugeren kun skal bekræfte hans rganisatin, næste gang IdP en tilgås. IdP en sender nu et signeret SAML <AuthnRequest> via HTTP Redirect til brugerens lkale IdP. 6. Via brugerens lkale sikkerheds-sessin udtrækker den lkale IdP de rettigheder/attributter, sm er relevant i en natinal kntekst (herunder rettigheder ift. Sårjurnalen g rganisatinens CVR nummer). En SAML assertin pbygges, krypteres g sendes sm SAML <Respnse> via Pst til sundhedsføderatinens IdP. Attributterne i SAML assertinen navngives g frmateres sm specificeret i [OIOSAML-H]. 7. Sundhedsføderatinens IdP sender et SAML <AuthnRequest> til NemLgin IdP en via HTTP Redirect (sundhedsføderatinens IdP ptræder her sm service prvider (SP)). Hvis brugeren ikke allerede har en aktiv NemLgin-sessin skal vedkmmende autentificere sig med digital signatur. 8. NemLgin IdP en udsteder g sender et OIOSAML tken til sundhedsføderatinens IdP via Pst. Sundhedsføderatinens IdP validerer, at CVR nummeret i OIO- SAML tkenet matcher CVR nummeret i tkenet fra den lkale IdP. Dette sikrer, at attributter fra en rganisatin ikke anvendes i en anden rganisatins kntekst. LAKESIDE side 11 / 22

12 9. Sundhedsføderatinens IdP laver et WS-trust kald til SOSI-STS ens OIO- SAML2SOSI snitflade med NemLgin OIOSAML tkenet sm input. Hvis brugeren har flere sundhedsfaglige autrisatiner, så returnerer SOSI- STS en et fejlsvar indehldende brugerens mulige autrisatiner. Sundhedsføderatins IdP en vælger i givet fald den første autrisatin, se gså begrundelsen under afsnit Lgin-sessin. WS-trust kaldet gentages efterfølgende med autrisatinen sm yderlig inputparameter. 10. SOSI-STS en udsteder et SOSI fr brugeren, sm returneres i WS-trust respnsen til sundhedsføderatinens IdP. 11. Sundhedsføderatinens IdP udsteder nu et SAML tken med indlejret SOSI, sm følger subprfilen beskrevet i [OIOSAML-H]. SAML tkenet sendes i en SAML <Respnse> via Pst til Sårjurnalen. Sårjurnalen validerer tkenet g lgger brugeren ind med de rettigheder, der fremgår af tkenet. Bemærk at trin 3 8 g 11 fregår igennem brugerens brwser, hhv. sm HTTP Get, Redirect eller Pst kald. 4.2 Aktiv scenarie / Sikker brwser-pstart Lkalt sikkerhedsdmæne Natinal sundhedsføderatin Autentifikatin (f.eks. AD / Kerbers) Rlle/Rettigheder (f.eks. AD / LDAP) 1 3 Bruger Fagsystem Security Tken Service (SOSI STS) trust Brwser 10 Sårjurnalen Fr enkeltheds skyld tager den tekniske beskrivelse udgangspunkt i, at det er fagsystemet, sm integrerer direkte med såvel det lkale brugerstyringssystem, SOSI-STS en g Sårjurnalen. Fr en alternativ realisering se Appendiks: Alternativ psætning til sikker brwser-pstart. I det aktive sikker brwser-pstart scenarie, hvr der ikke etableres en sessin i Sundhedsføderatins IdP, indgår følgende trin: 1. Brugeren autentificerer sig i frhld til den lkale IdP (AD/Kerbers) 2. Brugeren tilgår fagsystemet. 3. Fagsystemet indhenter brugerens rettigheder til Sårjurnalen fra det lkale brugerstyringssystem via en lkal prtkl. 4. Fagsystemet udfrmer et SOSI fr brugeren, sm brugeren underskriver med digital signatur. Fagsystemet fretager et WS-Trust kald md SOSI-STS en med det bruger-underskrevne sm input. 5. SOSI-STS en validerer det bruger-underskrevne g udsteder et nyt beriget. et signeres g sendes til fagsystemet i en WS-Trust respnse. 6. Fagsystemet laver et WS-Trust Issue kald til SOSI-STS ens SOSI2OIOSAML snitflade. Sm input sendes det STS-signerede SOSI g en angivelse af Sårjurnalen sm audience parameter. LAKESIDE side 12 / 22

13 7. SOSI-STS en udsteder et OIOSAML tken med indlejret SOSI. Tkenet krypteres med Sårjurnalens ffentlige nøgle g returneres via WS-Trust respnse. 8. Fagsystemet klargør input parametrene til sikker brwser-pstart af Sårjurnalen, dvs. OIOSAML tkenet, rettighederne g behandlingsknteksten. Derefter genererer fagsystemet en en-gangs-nøgle med krt levertid g knytter de tre input parametre til Sårjurnalen til den. Slutteligt dannes en URL sm peger tilbage på fagsystemet g sm indehlder en-gangs-nøglen sm URL parameter, hvrefter brwseren startes med denne URL. 9. Fagsystemet mdtager HTTP GET kaldet med en-gangs-nøglen g danner ud fra den mdtagne en-gangs-nøgle en HTML side med et POST kald til Sårjurnalen sm indehlder OIOSAML tkenet i en SAML <Respnse> g rettighederne g behandlingsknteksten sm yderlige parametre. 10. Sårjurnalen dekrypterer g validerer tkenet, lgger brugeren ind med de medsendte rettigheder g viser de patientdata der hører til den medsendte behandlingskntekst. Bemærk at trin 8 g 9 er nødvendige til at generere POST kaldet, idet en brwser kun kan startes med en (GET) URL. POST kald genereres typisk ved at returnere en HTML side med et nlad script sm submitter en FORM via POST med de relevante parametre. 4.3 Passiv scenarie med SOSI Natinal sundhedsføderatin Lkalt sikkerhedsdmæne Rlle/Rettigheder (attributter) 10 Natinal IdP/STS Autentifikatin + IdP / STS (f.eks. ADFS) trust cache (fx. SOSI-GW) 7 8 SOSI STS 2 Brwser 3 Sårjurnalen Bruger De enkelte trin i det passive scenarie med SOSI, hvr brugeren tilgår Sårjurnalen direkte i en brwser g viderefører den i SOSI føderatinen etablerede sikkerhedskntekst, realiseres på følgende måde. Det passive scenarie med SOSI minder m det almindelige passive scenarie. Fr gd rdens skyld er alle trinene her gengivet i deres helhed, men bemærk at kun trin 6 10 er frskellig fra det almindelige passive scenarie. 1. Brugeren autentificerer sig i frhld til den lkale IdP (AD/Kerbers) 2. Brugeren starter en brwser 3. Brugeren fretager et HTTP Get kald til Sårjurnalens lgin-side fr sundhedsfaglige persner LAKESIDE side 13 / 22

14 4. Sårjurnalen afgør, hvrvidt brugeren har en eksisterende sessin (med Sårjurnalen). Hvis ikke det er tilfældet, sendes et signeret SAML <AuthnRequest> via HTTP Redirect til sundhedsføderatinens IdP. 5. Sundhedsføderatinens IdP afgør, hvrvidt brugeren har en eksisterende sessin (med sundhedsføderatinens IdP). Hvis ikke det er tilfældet, så prmptes brugeren til at vælge lkal rganisatin (g dermed hans lkale IdP). IdP en gemmer valget i en persistent ckie således, at brugeren kun skal bekræfte den lkale rganisatin næste gang IdP en tilgås. IdP en sender nu et signeret SAML <AuthnRequest> via HTTP Redirect til brugerens lkale IdP. 6. Den lkale IdP afgør, hvrvidt brugeren har en etableret sikkerhedskntekst i SOSI føderatinen, dvs. har et gyldigt SOSI, eksempelvis i SOSI-GW. 7. Den lkale IdP laver et WS-Trust Issue kald til SOSI-STS ens SOSI2OIOSAML snitflade. Sm input sendes SOSI g en angivelse af Sundhedsføderatinens IdP sm audience parameter. 8. SOSI-STS en udsteder et OIOSAML tken med indlejret SOSI. Tkenet krypteres med en ffentlig nøgle fr sundhedsføderatins IdP, g det returneres i et WS-Trust respnse. 9. Fra en eventuel cache sendes det SOSI-STS-udstedte OIOSAML tken videre til den lkale IdP. 10. Via brugerens lkale sikkerheds-sessin udtrækker den lkale IdP rettigheder/attributter, sm er relevant i en natinal kntekst (herunder rettigheder ift. Sårjurnalen g rganisatinens CVR nummer). En SAML assertin pbygges (med det SOSI-STS-udstedet OIOSAML tken indlejret), krypteres g sendes i en SAML <Respnse> via Pst til sundhedsføderatinens IdP. Attributterne i SAML assertinen navngives g frmateres sm specificeret i [OIOSAML-H]. 11. Sundhedsføderatinens IdP dekrypterer det mdtagne SAML tken g udsteder et nyt SAML tken med indlejret SOSI, sm følger subprfilen beskrevet i [OIOSAML-H], g sender denne i en SAML <Respnse> via Pst til Sårjurnalen. Sårjurnalen validerer tkenet g lgger brugeren ind med de rettigheder, der fremgår af tkenet. Bemærk at trin 3 5 g fregår i gennem brugerens brwser, hhv. sm HTTP Get, Redirect eller Pst kald. 4.4 Anvendte prfiler I nedenstående tabel sammenfattes anvendte prtkller, bindings g tkenprfiler. Sikkerhedsarkitekturen baserer sig på det fællesffentlige OIOSAML prfil (se [OIO- WEBSSO]) g subprfilereringerne i [OIOSAML-H]. Prtkl Bindings Tkenprfiler SAML Authenticatin Request HTTP Redirect Binding HTTP Pst Binding WS-Trust Issuance Binding SOSI HTTP GET POST OIOSAML OCES Attribute Prfile OIOSAML OCES Attribute Prfile fr Healthcare OIOSAML Authenticatin Assertin Prfile fr Healthcare OIOSAML OCES Attribute Prfile OIOSAML OCES Attribute Prfile I frhld til de anvendte bindings gælder der fr SAML Authenticatin Request prtkllen, at requests sendes sm HTTP Redirect med parametrene i URL en g at der til respnses benyttes HTTP Pst bindingen præcis sm i OIOSAML WebSSO. LAKESIDE side 14 / 22

15 Med hensyn til de anvendte tkenprfiler så er frmat g indhld af SOSI g OIOSAML tken specificeret i henhldsvis [DGWS] g [OIO-WEBSSO]. SAML tkens sm udstedes af henhldsvis lkale IdP er g Sundhedsføderatinens IdP prfileres i [OIOSAML-H]. 5 Radmap fr etablering Sikkerhedsarkitekturen anbefales etableret i 3 spr, hvr hvert spr består af en afprøvning af et af de beskrevne scenarier. Spr 1 g spr 2 kan med frdel frløbe parallelt, hvrimd spr 3 bør ligge i frlængelse af spr 2. Fr hvert spr angives i det følgende krt, hvilke aktiviteter der skal gennemføres fr at nå til en afprøvning af scenarieret. Ngle af aktiviteterne kan fregå parallelt, aktiviteterne er derfr listet i ikke-nummereret frm. Bemærk, at det første spr er uafhængigt af etableringen af Sundhedsføderatinens IdP. Aktiviteter i spr 1: Afprøvning af det aktiv scenarie Etablering af en SAML snitflade i Sårjurnalen, sm kan mdtage et unslicited SAML respnse, hvr rettigheder g behandlingskntekst medsendes sm separate parametre. Etablering af trust til SOSI-Føderatinen i Sårjurnalens SAML snitflade. Typisk etableres trust ved at knfigurere en SAML snitflade med IdP ens certifikat. SOSIføderatinen pererer derimd ikke med faste føderatinscertifikater, men anvender en familie af føderatinscertifikater (sm er defineret i gennem et sæt simple regler). Knfigurering af SOSI-STS en med Sårjurnalen sm aftager af SAML tkens. Etablering af sikker-brwser-pstarts løsning hs piltdeltageren. Piltafprøvning af det aktive scenarie. Aktiviteter i spr 2: Afprøvning af det passive scenarie Etablering af Sundhedsføderatinens IdP. Integratin af Sundhedsføderatinens IdP med NemLgin IdP en. Integratin af Sundhedsføderatinens IdP med SOSI-STS en, herunder håndtering af flere sundhedsfaglige autrisatiner i Sundhedsføderatinens IdP. Integratin af Sundhedsføderatinens IdP med piltdeltagerens lkale IdP, herunder etablering af funktinalitet i Sundhedsføderatinens IdP til, at brugeren kan vælge egen rganisatin. Etablering af funktinalitet til udstedelse af OIOSAML-H tken i Sundhedsføderatinens IdP, herunder validering af m CVR nummeret i tkens fra den lkale IdP g NemLgin er ens. Integratin af Sårjurnalen med Sundhedsføderatinens IdP, herunder metadata udveksling g etablering af trust. Piltafprøvning hs piltrganisatinen. Afprøvning af link udveksling via krrespndancemeddelelse. Aktiviteter i spr 3: Afprøvning af det passive scenarie med SOSI Integratin af piltdeltagerens lkale IdP med SOSI-STS en. Knfigurering af SOSI-STS en med Sundhedsføderatinens IdP sm aftager af SAML tkens. Integratin af piltdeltagerens lkale IdP med Sundhedsføderatinens IdP, herunder udstedelse af SAML tken med indlejret krypteret OIOSAML tken i piltdeltagerens lkale IdP. Udstedelse af OIOSAML-H tken i Sundhedsføderatins IdP på baggrund af SAML tkenet fra piltdeltagerens lkale IdP. Piltafprøvning hs piltrganisatinen. LAKESIDE side 15 / 22

16 Under piltafprøvningen af sikkerhedsarkitekturen fr Sårjurnalen må der ikke ændres på SOSI-STS en, hvilket medfører, at der i det aktive scenarie verføres brugerrettigheder uden fr tkenet, se gså appendiks Overførsel af rettigheder. I en senere fase bør de frnødne udvidelser i SOSI-STS en etableres således, at rettighederne kan blive en del at det SOSI-STS-udstedte tken (sm dermed gså kmmer til at verhlde tkenprfilen i [OIOSAML-H]). På længere sigt kunne sikkerhedsarkitekturen integreres til fælleskmmunale eller fællesreginale føderatiner, se Appendiks: Integratin med andre føderatiner. Sikkerhedsarkitekturen kunne desuden udvides med et passivt scenarie med decentral stærk autentifikatin. Baseret på en lkal stærk autentifikatinsmekanisme, der lever p til kravene til autentifikatinsniveau 3, frem fr NemLgin eller SOSI-STS en - se gså Appendiks: Sikkerhedsanalyse. 6 Referencer [AUTHN-SIK] [AUTHN-VURD] Vejledning vedrørende niveauer af autenticitetssikring Vurdering af autentifikatinsstrategier fr natinale tjenester i sundhedssektren, versin 1.1, 22. januar 2009 Fås ved henvendelse til NSI. [DGWS] Den Gde Webservice, versin [FIBS] [NIST] [OIOSAML-H] [OIO-WEBSSO] [PROJEKT-SÅRJ] [SIKKERHED-SÅRJ] [TOGAF] Federal Infrmatin Prcessing Standards Publicatin Security Requirements fr Cryptgraphic Mdules NIST Special Publicatin Electrnic Authenticatin Guideline 2.pdf OIOSAML Attribute Prfiles fr Healthcare (OIOSAML-H) Under udarbejdelse OIO Web SSO Prfile V V2+09.pdf Prjektdkument: Sårjurnalen - Ændring af sikkerhedsarkitekturen, Versin 1.1, MedCm, 10. Marts 2015 Fås ved henvendelse til MedCm. Føderative sikkerhedsmdeller til Sårjurnalen - Overrdnet arkitektur, v.0.95, NSI, 17. nvember 2014 Fås ved henvendelse til NSI. TOGAF - Architecture Develpment Methd (ADM) LAKESIDE side 16 / 22

17 7 Appendiks: Sikkerhedsanalyse I [NIST] defineres der fire niveauer fr tillid til autentifikatinsløsninger fr brugere, hvr niveau 1 er det laveste g niveau 4 det højeste. I det daværende IT- g Telestyrelsens regi blev der udfrmet en natinal vejledning vedrørende niveauer af autentifikatinssikring, sm bygger på NIST s pdeling i fire niveauer [AUTHN-SIK]. I vejledningen anbefales det at benytte nedenstående tabel til at vurdere en tjenestes behv fr niveau af sikkerhed ved brugerautentifikatin. Sm der fremgår af tabellen, bør der allerede ved lille risik fr fysisk persnskade fretages brugerautentifikatin på niveau 3. I g med, at der i Sårjurnalen er risik fr persnskade ved misbrug, bør brugerautentifikatin derfr fregå på niveau 3. Indenfr sundhedssektren har daværende Sammenhængende Digital Sundhed i Danmark (SDSD) i en analyse knkluderet, at autentifikatinsløsninger baseret på OCES medarbejdersignatur lever p til autentifikatinsniveau 3, hvrimd løsninger der baserer sig på netværks lgin ikke pfylder kravene til niveau 3, se [AUTHN-VURD]. Der anbefales således at basere autentifikatinsløsning til Sårjurnalen på OCES medarbejdersignatur, der på nuværende tidspunkt er den eneste bredt etablerede autentifikatinsløsning i Danmark, sm lever p til niveau 3. LAKESIDE side 17 / 22

18 8 Appendiks: Arkitekturbeslutninger Under udfrmning af denne løsningsbeskrivelse blev der sammen med de invlverede parter truffet en række arkitekturbeslutninger, sm fasthldes her. 8.1 SOSI Prblem Alternativer Analyse Beslutning Bør SOSI et altid indlejres i de tkens sundhedsføderatinens IdP udsteder? A) Ja, SOSI et indlejres altid B) Nej, SOSI et kan udlades De etablerede sikkerhedsplitikker mkring udstedelse, pbevaring g anvendelse af de kryptgrafiske nøgler, sm benyttes til at udstede SOSI (g NemLgin tkens), lever p til FIBS niveau 2 [FIBS], herunder pbevaring af nøgler på et tamper-prf hardware sikkerhedsmdul. Nøglerne til den natinale føderatin er ikke beskyttet på sammen niveau, hvilket medfører, at risiken fr kmprmittering af sundhedsføderatinens IdP er større. Indlejring af SOSI et i alle tkens, sm sundhedsføderatinens IdP udsteder, imødegår denne risik, idet der dermed ikke kan udstedes tkens alene ud fra sundhedsføderatinens IdP s (kmprmitterede) nøgler. A) SOSI et indlejres altid i de udstedte tkens 8.2 Lgin-sessin Prblem Alternativer Analyse Ngle sundhedsfaglige brugere ptræder i frskellige rller i løbet af en arbejdsdag såvel lkale rller (arbejdsfunktiner) sm natinale rller (sundhedsfaglig autrisatiner). Hvrdan kan brugere med flere sundhedsfaglige autrisatiner understøttes i frbindelse med lgin til den natinale føderatin i det passive scenarie? A) Lad brugeren vælge rlle (sundhedsfaglig autrisatin) ved lgin til den natinale føderatin. Dermed bliver lgin-sessinen i den natinale føderatin på rlle-niveau. B) Lad lgin-sessinen til den natinale føderatin alene være på identitets-niveau, g lad brugeren vælge rlle i de enkelte applikatinerne (her Sårjurnalen), hvis applikatinen har behv fr at kende rllen. Medarbejdere med én sundhedsfaglig autrisatin vil af SOSI-STS en få angivet autrisatinen i det udstedte SOSI. Medarbejdere med flere autrisatiner skal på udstedelsestidspunktet angive, hvilken autrisatin de arbejder under, så denne kan angives i SOSI et. SOSI et indlejres i det natinale tken g vil i princippet kunne benyttes til at fretage webservice kald på brugerens vegne. Dette behv har Sårjurnalen i sin nuværende frm ikke SOSI et inkluderes alene sm bevis på at udstedelsen af det natinale tken lever p til kravene til FIBS niveau 2 [FIBS]. LAKESIDE side 18 / 22

19 Autrisatinsattributterne tilkmmer Sårjurnalen sm en del af det natinale tken g Sårjurnalen autriserer brugere alene på baggrund af attributterne i det natinale tken. Beslutning Bemærkning B) Lad lgin-sessinen til den natinale føderatin alene være på identitets-niveau, g lad brugeren vælge rlle i de enkelte applikatinerne (her Sårjurnalen), hvis applikatinen har behv fr at kende rllen. Dels fr ikke at besvære brugerne fr infrmatin der ikke er relevant i Sårjurnalen g dels fr at begrænse udviklingsmkstningerne vælger sundhedsføderatinens IdP (fr brugere med flere sundhedsfaglig autrisatiner) hvilken autrisatin der skal inkluderes i SOSI et. Samtidigt frpligtes Sårjurnalen til ikke at anvende et til efterfølgende webservice kald. Ovenstående beslutning vedrører alene afprøvningen af sikkerhedsarkitekturen fr Sårjurnalen. Der udestår en afklaring af hvilken type natinal føderatin, der ønskes skabt inden fr sundhedsvæsnet. Fx hvrvidt der perereres på rlle- eller identitetsniveau. Der udestår ligeledes en afklaring af hvrdan et egentlig bt-strap tken til det natinale tken bør udfrmes. Frmålet med et bt-strap tken er at give applikatiner mulighed til at fretage webservice kald på brugerens vegne (efter passende mveksling af bt-strap tkenet). Disse afklaring ligger uden fr rammen fr etableringen af sikkerhedsarkitekturen fr Sårjurnalen. 8.3 Overførsel af rettigheder Prblem Alternativer Analyse Beslutning Skal lkalt administrerede rettigheder i det aktive scenarie verføres sm en del af tkenet? A) Ja, rettigheder er en del af tkenet. B) Nej, rettigheder verføres separat. Ved at lade rettigheder indgå i det krypterede tken sikres disse md mdikatin i en kmprmitteret brwserklient. Derved vil gså indhldet af tkenet blive ens i det aktive g det passive scenarie. Indlejring i tkenet kræver en ændring i vekslingssnitflade hs SOSI- STS en. B) Overfør rettigheder separat, idet sikkerhedsarkitekturen fr Sårjurnalen i første mgang ønskes etableret uden ændringer i SOSI-STS. Risik fr kmprmittering af brwseren accepteres under afprøvningen. LAKESIDE side 19 / 22

20 9 Appendiks: Passiv scenarie med behandlingskntekstverførsel Nedenstående figur illustrerer flwet fr et passivt scenarie hvr behandlingsknteksten verføres fra fagsystemet. Lkalt sikkerhedsdmæne Rlle/Rettigheder (attributter) Natinal Sundhedsføderatin Security Tken Service (SOSI STS) Fællesffentlig føderatin 1 Autentifikatin + IdP / STS (f.eks. ADFS) 6 Rettigheder Tken 8 IdP/STS 7 Tken NemLgin IdP 2 Fagsystem NyTken Bruger Brwser 4 Behandlings kntekst Sårjurnalen 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 i det lkale sikkerhedsdmæne kunne trin 7 erstattes med en tilføjelse af et SOSI STS tken i trin 6. Dermed kunne der realiseres et passivt scenarie med SOSI g behandlingskntekstverførsel. 10 Appendiks: Alternativ psætning til sikker brwser-pstart I nedenstående figur illustreres et alternativt setup fr det aktive scenarie, hvr integratin til lkal IdP, SOSI-STS en g Sårjurnalen varetages af en særskilt sikkerhedskmpnent. LAKESIDE side 20 / 22

21 Lkalt sikkerhedsdmæne Natinal sundhedsføderatin Autentifikatin (f.eks. AD / Kerbers) Rlle/Rettigheder (f.eks. AD / LDAP) 1 5 Rettigheder 6 Bruger 2 Fagsystem 3 Sikkerheds Kmpnent 7 Tken Security Tken Service (SOSI STS) trust Brwser 4 8 Behandlings kntekst Tken Rettigheder Sårjurnalen Behandlings kntekst I det alternative aktive scenarie indgår følgende trin: 1. Brugeren autentificerer sig i sit lkale sikkerhedsdmæne. 2. Brugeren tilgår fagsystemet. 3. Brugeren starter brwseren fra fagsystemet. 4. Fra brwseren verføres Behandlingsknteksten til en lkal Sikkerhedskmpnent 5. Sikkerhedskmpnenten indhenter Rettigheder fra det lkale brugerstyringssystem/rlleregister. 6. I sikkerhedskmpnenten autentificerer brugeren sig med sin digital signatur hs SOSI-STS en g får udstedt et. 7. Sikkerhedskmpnenten veksler et til et Tken med indlejret hs SOSI-STS en. 8. Fra sikkerhedskmpnenten verføres tkenet, rettighederne g behandlingsknteksten til Sårjurnalen. Sårjurnalen giver brugeren adgang på baggrund af de medsendte rettigheder g viser de patientdata, der hører til den verførte behandlingskntekst. Bemærk at fagsystemet i denne psætning kan være driftet uden fr den lkale sikkerhedsdmæne. 11 Appendiks: Integratin med andre føderatiner Fr de anvendere, der selv indgår i en fælles føderatin, eksempelvis i gennem KOMBITs kmmende IdP (gså kaldt CntextHandler ), kunne brugernes rettigheder i det passive scenarie hentes via fællesføderatinens IdP sm skitseret i nedenstående figur. LAKESIDE side 21 / 22

22 Natinal Sundhedsføderatin Fællesffentlig føderatin Lkalt sikkerhedsdmæne Security Tken Service (SOSI STS) 1 Rlle/Rettigheder (attributter) Autentifikatin + IdP / STS (f.eks. ADFS) Rettigheder 6 Reginal/Kmmunal føderatin IdP/STS Rettigheder 7 5 Tken 9 IdP/STS 4 10 NyTken 8 Tken NemLgin IdP 2 Brwser 3 Sårjurnalen Bruger Bemærk at autentifikatin af brugerne i venstående figur fregår hs NemLgin IdP en. Under frudsætning af at der kan pnås stærk autentifikatin af brugerne i deres lkale sikkerhedsdmæne vil den centrale NemLgin autentifikatin kunne erstattes med lkal stærk autentifikatin, hvilket er vist i nedenstående figur. Natinal Sundhedsføderatin Lkalt sikkerhedsdmæne Security Tken Service (SOSI STS) Rlle/Rettigheder (attributter) Autentifikatin + IdP / STS (f.eks. ADFS) NyTken 6 Reginal/Kmmunal føderatin NyTken 7 IdP/STS 5 NyTken 9 IdP/STS NyTken 2 Brwser 3 Sårjurnalen Bruger LAKESIDE side 22 / 22