SOSI ( ServiceOrienteret SystemIntegration) Quick Tour (E.3)

Præsentationer af emnet: "SOSI ( ServiceOrienteret SystemIntegration) Quick Tour (E.3)"— Præsentationens transcript:

1 SOSI ( ServiceOrienteret SystemIntegration) Quick Tour (E.3)

2 Indhold n Hvad og hvem er SOSI n Motivation og status n Lidt om løsningen n Diskussion

3 Motivation for projektet n Stigende krav om sikker brugeridentifikation og brugerautorisation ifbm. system-til-system integration n Ingen standarder n Flere udbydere udstiller services baseret på forskellige sikkerhedsløsninger n Ingen har overvejet ”single-sign-on” problematikken n Serviceaftagere skal ofte håndtere nye løsninger. n Det er dyrt, besværligt og ”forsinkende” n  Pilotprojekt: PEM-EPJ integration

4 SOSI organisering

5 Status 28/2-2006 n Ambitionerne er steget n Teknisk løsning udarbejdet og i review n 1. Styregruppemøde afholdt n LMS tæt på at træde ind i projektet  KL på vej til at blive knyttet til projektet n Kliniske krav mht. integration af medicinprofilen identificeret.

6 Hovedtidsplan Godkendelse LP-2 Fase 1 Præcisering af krav (3 uger) Fase 2 Estimering / Tilbud (3 uger) Fase 3 Kontrakter (2 uger) Fase 4 Udvikling og Test (XX uger) Fase 5 Evaluering (efterår 2006) POC / SOSI komponent IDP Udvikling af piloter

7 SOSI trosbekendelsen ”Der skal etableres en "Single-Sign-On" (SSO) løsning... hvor det er muligt for serviceudbydere at overbevise sig om brugeres/systemers identitet og autenticitet... og gøre det muligt at autorisere brugere på baggrund af passende data... samt for alle parter at kunne opretholde uafviselighed af beskeder, svar og andre vigtige data... ved brug af åbne internationale og nationale standarder... på en effektiv måde... og uden at introducere unødige "single points of failure"... så løsningen kan skalere til at kunne håndtere en stor del af (helst al) system-til-system integration mellem systemer i sundhedssektoren... uden at påtvinge specifikke platforms-, leverandør- eller værktøjsvalg.”

8 Overbevist om autenticitet Designelementer n Vi ønsker direkte system-til-system kommunikation n Vi ønsker at lægge ansvaret for sikker identificering over til troværdig central part (Identity provider) n IdP’en står inde for brugerens/systemets autenticitet Identity Provider Service udbyder Har tillid til Tillid til autenticitet Medicinprofilen EPJ system

9 Det digitale ID-kort n Alle brugere/systemer udstyres med digitale ID-kort n Skal ”bæres” ved alle servicekald n Gyldighed max. 24 timer n ID-kortet er en slags ”billet” – men indeholder domænespecifik information  CPR, Autorisations-ID, Org-enhed, brugerens rolle etc.  Nogle hentes fra centrale registre  Nogle sendes med fra service aftageren

10 En ”føderation” n Et tillidsdomæne n IdP’en er portvagten n Forevisning af akkreditiver Tjeneste ATjeneste BTjeneste C IdP

11 Autenticitetsniveauer Autenticitetsniveau 1Konsekvenser ved autenticitetsfejl Ulempe, kval eller tab af anseelse Økonomisk tab eller ansvarspådragelse Skade på myndighedsaktiviteter eller andre offentlige interesser Ikke-autoriseret frigivelse af sensitiv information Fysisk personskade Mulighed for at begå/modvirke opklaring af ulovligheder Lille N/A Moderat Lille N/A Lille Moderat Lille Moderat Stor Moderat Stor Stor 234 http://oio.dk/files/Horing.B.st.niv.autentisitetssikring.v3.pdfhttp://www.csrc.nist.gov/publications/nistpubs/800-63/SP800-63v6_3_3.pdf

12 Akkreditiver - niveauer n Overordnet to muligheder n Niveau 3+4: Brugeren foreviser bevis for identitet  OCES medarbejdercertifikat / Kvalificeret certifikat  Digital signatur n Niveau 1+2: IdP’en stoler på afsendersystemets autentificering af brugeren  ”Decentral” autentificering  Digital signatur fra afsender-systemet vha. OCES virksomhedscertifikat

13 ID kort – Niveau 3+4 (eksempel)

14 SOSI anvendelse af services

15 Løsningens egenskaber n Fleksibelt design  Understøtter forskellige typer akkreditiver  Fremtidige typer af akkreditiver (f.eks. kvalificerede certifikater med biometri)  ID-kortets indhold kan udvides i takt med nye muligheder  Alle kan komme i gang med SOSI n Optimering af arbejdsindsats i sundhedsvæsenet  Central indsamling af relevante brugerinformationer  Central verificering af certifikater n Effektiv  Decentral verifikation af ID-kort  Direkte system-til-system kommunikation  Brugerinformationer ”sendes med” på ID-kort (vs. ”attributserver” med risiko for ”single point of failure”)

16 Valgfri Mere fleksibilitet Autenticitets- niveau 4 Valgfri 2 1 Digital signatur Bruger Digital signatur afsendersystem Digital signatur (svar) Valgfri N/AValgfri N/AValgfri Alder på digitalt ID-kort X minutter/timer Nej 30 min. PEM - ”Ticket” løsning? 3 Dødsårsagsindberetning? Ja 8 t.

17 En Open Source SOSI komponent n Skal samle fælles udfordringer for Serviceaftager og –udbyder  Danne SOSI/MedCom kuverter  Signere kuvertdata og besked  Verificere ID-kort  Verificere signaturer (system / bruger)  Installere system certifikat

18 Standarder og blå stempler n XML, SOAP, WS-SEC / XML-Signature n SAML n OIO – Tværgående brugerstyring n MedCom – ”Den gode Webservice” n Er præsenteret for:  VTU/ITST, TDC, EPJ- arkitekturgruppen i ARF, Arkitekturrådet i Sundhed.dk, Teknologisk Institut, Cryptomathic, Leverandørforum, IT-temagruppen i ARF, IT Projektlederforum i ARF, MedCom

19 XML struktur n ID-kort udstedelse  SAML Authentication request i SOAP konvolut  SOAP response med signeret digitalt ID-kort n Servicekald  Alm. SOAP request, med digitalt ID-kort og MedCom data i SOAP header, evt. signeret  Alm. SOAP response, evt. signeret

20 Det digitale ID-kort n Opbygges som en SAML assertion n Indhold (version 0.9): • Gyldighedsperiode • ID-kort ID • ID-kort version • ID-kort type • Autenticitetsniveau • SOSI public key • CPR-nr • Ansættelse • Fornavn • Efternavn • e-mail adresse • Bruger-rolle • IT-system • Org.-enhed • Org. CVR IdP’ens Digitale Signatur af 1+2 1 2 3 (MedCom data)

21 SOSI XML eksempel (request) 1. SOAP Header (formatet blander vi os ikke i) 2. SOAP Body 1.1 wsse:Security 1.1.1 wsu:TimeStamp (beskedens gyldighed) 1.1.3 saml:Assertion (MedCom konvolut) SOAP request (niveau 1+2 uden uafviselighedsdata) 1.1.2 saml:Assertion (Brugerens ID kort -uden OCES) 1.1.4 ds:Signature (sikkerhedsblok)

22 Sikkerhed i løsningen n Udfordring: Hvordan knyttes ID-kortet sammen med beskeden?  Uden sammenknytningen, kan enhver ”stjæle” et ID-kort og sende beskeder n ID-kortets tekniske nøglepar  ”Short lived certificates” (max. 24 timer)  System-genereret digital signatur (ikke juridisk bindende) n Juridisk bindende digital signatur  OCES (!)

23 Diskussion n MedCom’s og Sundhed.dk’s rolle  IdP kan placeres hos Sundhed.dk n Sammenhæng mellem ”Den gode Web service” og SOSI