SOSI. (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0

Transkript

1 SOSI (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0

2 Indhold Hvad og hvem er SOSI Visionen og Missionen Begreber, arkitektur og teknik

3 Hvad er SOSI Projekt initieret og drevet af Ribe- og Københavns Amt Mål: Forslag til retningslinier for system-til til- system integration i sundhedssektoren Pilotafprøves i Ribe og KBH amt

4 SOSI organisering Styregruppe Ribe Ribe KBH KBH Sundhed.dk, Sundhed.dk, ACURE, ACURE, VTU VTU Følgegruppe1 Sundhed.dk s arkitektråd Sundhed.dk s arkitektråd Klinisk projektgruppe Ribe Ribe KBH KBH ACURE ACURE Teknisk projektgruppe Sundhed.dk, Sundhed.dk, ACURE, ACURE, Ribe Ribe KBH KBH VTU VTU Følgegruppe2 EPJ arkitekturgruppen EPJ (ARF) arkitekturgruppen (ARF) Aftalegruppe Ribe Ribe KBH KBH LMS, LMS, Sundhed.dk Sundhed.dk Informationsgruppe MedCom,, Teknologisk MedCom, Institut, Teknologisk Institut, CryptoMathic, CryptoMathic,, TDC TDC (CA), (CA), Leverandørforum Leverandørforum

5 Visionen En føderation af serviceudbydere og aftagere Single-sign sign-on (SSO) De 4 vigtigste aspekter: 1.Beskyttet transportvej 2. Identitet 3. Autorisation 4. Formater Autorisations Service

6 Visionen (2) ARF/SST workshop 2004 fastslog: OCES certifikater til identifikation Et register Autorisations Service SOSI sigter påp disse Certifikat Autoritet (CA)

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

8 OIO/NIST - Autenticitetsniveauer 1. Ingen eller lav tillid til brugerens autenticitet (Kendt brugernavn) 2. Lille tillid (Brugernavn/Password) 3. Høj j tillid (Digitale certifikater påp software) 4. Meget høj h j tillid (Kvalificerede digitale certifikater påp hardware) oio.dk/files/horing.b.st.niv.autentisitetssikring.v3.pdf v6_3_3.pdf

9 Konsekvensanalyse hos Serviceudbydere Konsekvenser ved autenticitetsfejl Autenticitetsniveau Ulempe, kval eller tab af anseelse Lille Moderat Moderat Stor Økonomisk tab eller ansvarspådragelse Lille Moderat Moderat Stor Skade på myndighedsaktiviteter eller andre offentlige interesser N/A Lille Moderat Stor Ikke-autoriseret frigivelse af sensitiv information N/A Lille Moderat Stor Fysisk personskade Mulighed for at begå/modvirke opklaring af ulovligheder N/A N/A N/A Lille Lille Moderat Moderat Stor Stor

10 En mulig løsningl Central instans står r inde for en brugers identitet Digitale ID-kort Baseret påp akkreditiver, f.eks. certifikat eller brugernavn/password Påtrykt relevante autorisationsdata

11 SOSI in a nutshell (1)

12 SOSI in a nutshell (2)

13 Løsningens egenskaber Fleksibel Understøtter tter forskellige typer akkreditiver Fremtidige typer af akkreditiver (f.eks. kvalificerede certifikater) Optimering af arbejdsindsats i domænet Central indsamling af relevante brugerinformationer Central verificering af certifikater Effektiv Decentral verifikation af ID-kort Direkte system-til til-system kommunikation

14 Mere fleksibilitet (1) Serviceudbyder kan kræve Autenticitetsniveau (1-4) Autentifikation foretaget inden for X minutter Digital signatur (uafviselighed) Fra brugeren (niveau 3-4) 3 Fra systemet (niveau 1-3) 1 Serviceaftager kan efterspørge rge Digital signatur påp svaret (uafviselighed)

15 Mere fleksibilitet (2) Hvad hvis der ingen bruger er involveret? F.eks. batch indberetninger, overførsel rsel af klassifikationer, indberetninger til statistik Niveau 3 special Identifikation af afsendersystemet systemet med OCES virksomhedscertifikat Fjerner behovet for høkerlh kerløsninger (basic authentication,, tekniske logins etc.)

16 Mere fleksibilitet (3) Digital signatur Bruger Digital signatur afsendersystem Digital signatur Serviceudbyder (svar) Alder på digitalt ID-kort 4 Valgfri Valgfri Obligatorisk 0-30 minutter Autenticitetsniveau 3 2 Valgfri Valgfri Valgfri N/A Valgfri Valgfri 0-8 timer 0-24 timer 1 N/A Valgfri Valgfri 0-24 timer

17 Standarder og blå stempler XML, SOAP, WS-SEC SEC / XML-Signature SAML OIO Tværg rgående brugerstyring MedCom Den gode Webservice Følges af: VTU/ITST, TDC, EPJ- arkitekturgruppen i ARF, Arkitekturrådet i Sundhed.dk,, Teknologisk Institut, Cryptomathic,, Leverandørforum rforum

18 Det digitale ID-kort Opbygges som en SAML assertion Indhold (forslag): Indhold (forslag): 1 2 (MedCom kuvert) 3 Gyldighedsperiode ID-kort ID ID-kort version ID-kort type Autenticitetsniveau Public key CPR-nr Ansættelse Fornavn Efternavn adresse Bruger-rolle IT-system Org.-enhed Org. CVR IdP ens Digitale Signatur af 1+2

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

20 Lidt om SAML OASIS standard der definerer rammerne for udveksling af rettigheder mellem it-systemer på en sikker mådem via XML over forskellige protokoller (bindings)

21 SAML komponenter

22 SOSI SOAP Profile SOSI baseres påp SOAP over HTTP SAML definerer en SOAP binding, men IKKE en SOAP profil Vi laver en selv.

23 Profil oversigt

24 AuthnRequest & Response Certifikater indlejres i AuthnRequest Medarbejdercertifikat (niveau 3+4) Systemcertifikat (niveau 1+2) + brugerid Response indeholder SOSI ID kort som SAML Assertion signeret med IdP ens nøgle eller Fejlkode

25 Servicekald XML struktur (2) SOAP request (niveau 3 uden signatur) 1. SOAP Header 1.1 wsse:security wsu:timestamp (beskedens gyldighed) saml:assertion (Brugerens ID kort) saml:assertion (MedCom konvolut) Brugeren er autentificeret med medarbejdercertifikat Ingen digital signatur Bemærk: niveau 1+2 requests er mage til, men der vil stå niveau 1 eller 2 i ID-kortet 2. SOAP Body

26 Servicekald XML struktur (3) SOAP request (niveau 3 inkl. brugerens signatur) 1. SOAP Header 1.1 wsse:security wsu:timestamp (beskedens gyldighed) saml:assertion (Brugerens ID kort) Brugeren er autentificeret med medarbejdercertifikat Brugerens digitale signatur saml:assertion (MedCom konvolut) ds:signature (brugerns dig. signatur af og 2.) 2. SOAP Body

27 Servicekald XML struktur (4) SOAP request (niveau 3 inkl. system signatur) 1. SOAP Header 1.1 wsse:security wsu:timestamp (beskedens gyldighed) saml:assertion (Brugerens ID kort) saml:assertion (Systemets ID kort) Brugeren autentificeret med medarbejdercertifikat Afsendersystemet medsender uafviselighedsforsikring (digital signatur) saml:assertion (MedCom konvolut) ds:signature (systemets dig. signatur af og 2.) 2. SOAP Body

28 SOSI komponenten Skal samle fælles f udfordringer for Serviceaftager og udbyder Installere system certifikat Danne SOSI/MedCom kuverter Signere kuvertdata og besked Verificere ID-kort Verificere signaturer (system / bruger) Forventes at blive Open Source

29