SOSI ( ServiceOrienteret SystemIntegration) Quick Tour 2.0.

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

1 SOSI ( ServiceOrienteret SystemIntegration) Quick Tour 2.0

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

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

4 SOSI organisering

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

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

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å baggrund af passende data... samt for alle parter i føderationen 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å 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 OIO/NIST - Autenticitetsniveauer 1. Ingen eller lav tillid til brugerens autenticitet (Kendt brugernavn) 2. Lille tillid (Brugernavn/Password) 3. Høj tillid (Digitale certifikater på software) 4. Meget høj tillid (Kvalificerede digitale certifikater på hardware) http://oio.dk/files/Horing.B.st.niv.autentisitetssikring.v3.pdfhttp://www.csrc.nist.gov/publications/nistpubs/800-63/SP800-63v6_3_3.pdf

9 Konsekvensanalyse hos Serviceudbydere 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

10 En mulig løsning n Central instans står inde for en brugers identitet  Digitale ID-kort  Baseret 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 n Fleksibel  Understøtter forskellige typer akkreditiver  Fremtidige typer af akkreditiver (f.eks. kvalificerede certifikater) n Optimering af arbejdsindsats i domænet  Central indsamling af relevante brugerinformationer  Central verificering af certifikater n Effektiv  Decentral verifikation af ID-kort  Direkte system-til-system kommunikation

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

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

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

17 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 Følges af:  VTU/ITST, TDC, EPJ- arkitekturgruppen i ARF, Arkitekturrådet i Sundhed.dk, Teknologisk Institut, Cryptomathic, Leverandørforum

18 Det digitale ID-kort n Opbygges som en SAML assertion n Indhold (forslag): Gyldighedsperiode ID-kort ID ID-kort version ID-kort type Autenticitetsniveau 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 kuvert)

19 XML struktur (1) 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 Lidt om SAML n OASIS standard der definerer … n … rammerne for udveksling af rettigheder mellem it-systemer n … på en sikker måde n … via XML n … over forskellige protokoller (bindings)

21 SAML komponenter

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

23 Profil oversigt

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

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

26 Servicekald XML struktur (3) n Brugeren er autentificeret med medarbejdercertifikat n Brugerens digitale signatur 1. SOAP Header 2. SOAP Body 1.1 wsse:Security 1.1.1 wsu:TimeStamp (beskedens gyldighed) 1.1.2 saml:Assertion (Brugerens ID kort) 1.1.3 saml:Assertion (MedCom konvolut) 1.1.4 ds:Signature (brugerns dig. signatur af 1.1.3 og 2.) SOAP request (niveau 3 inkl. brugerens signatur)

27 Servicekald XML struktur (4) 1. SOAP Header 2. SOAP Body 1.1 wsse:Security 1.1.1 wsu:TimeStamp (beskedens gyldighed) 1.1.2 saml:Assertion (Brugerens ID kort) 1.1.4 saml:Assertion (MedCom konvolut) 1.1.5 ds:Signature (systemets dig. signatur af 1.1.4 og 2.) 1.1.3 saml:Assertion (Systemets ID kort) SOAP request (niveau 3 inkl. system signatur) n Brugeren autentificeret med medarbejdercertifikat n Afsendersystemet medsender uafviselighedsforsikring (digital signatur)

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

29