Download præsentationen
Præsentation er lastning. Vent venligst
Offentliggjort afMinna Petersen Redigeret for ca. et år siden
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
Lignende præsentationer
© 2024 SlidePlayer.dk Inc.
All rights reserved.