Dette dokument er en analyse af og udkast til teknisk arkitektur og design i SOSI. Målet med siden er, at fastlægge usecases og workflows, argumentere for arkitekturvalg samt angive konkrete løsninger på nogle centrale punkter i arkitekturen. Den tekniske analyse danner grundlag for de tekniske krav og skal ses som et supplement til disse, som kan konsulteres, hvis eller når kravteksten ikke i sig selv er fyldestgørende for forståelse af kravet.

Vi har søgt at tilrettelægge dokumentet med stigende konkretisering. De to første kapitler kan læses med kun begrænset viden om sikkerhed og teknik. De resterende kapitler er skrevet til teknikere, dvs. applikationsarkitekter og -udviklere. Specielt er kapitelerne om SAML og SOSI XML meget tekniske og kræver god kendskab til XML og til sikkerhed baseret på digitale certifikater. Det er en fordel, hvis læseren er bekendt med sundheds-IT, specielt i forbindelse med eksempler - men det er ikke noget krav.

Godt arkitektur- og designarbejde bør altid tage udgangspunkt i nogle forretningsmæssige mål.

Warning: Can't find topic Main.SOSITechGoals

Så ambitiøse mål stiller temmeligt store krav til sikkerheden og andre "quality of service" aspekter af løsningen. Derfor lægges der stor vægt på disse aspekter i dette dokument. Da SOSI ved evt. standardisering vil få betydning for mange instanser og leverandører, er der også et implicit krav om simplicitet. Designet må derfor ikke kræve unødigt mange ressourcer at realisere, eller skal kunne realiseres i passende tempi.

Dette dokument har samtidigt til formål at konkretisere nogle af de internationale og nationale standarder, som omgiver serviceorienteret systemintegration. Mange af disse standarder er nemlig tilpas bredt formuleret til, at de kan anvendes i mange forskellige sammenhænge, uden helt præcist at angive hvordan de skal anvendes. Disse standarder er derfor mere "framework standarder" end egentlige konkrete standarder. Her tænker vi specielt på SAML 2.0 standarden, der anbefales i OIO's "Anbefaling om fælles arkitektur for tværgående autenticitetssikring". I SOSI benytter vi begrebsapparat, der defineres i denne standard, og tilrettelægger XML beskederne så de overholder standarden. Koblingen til SAML er behandlet dybtgående i SAML kapitlet.

Designet er endvidere inspireret af Shibboleth, men tilrettet så flg. egenskaber kan opfyldes:

• PKCS
  Designet baseres på (optionel) anvendelse af public/private key standarder, dvs. anvendelse af digitale certifikater, så brugerautentifikation på niveau 3 eller højere kan opnås jf. ITST retningslinier og NIST - Electronic Authentication Guideline.
• ID kort
  Designet anvender informationsbærende "artefakter" (herefter kaldet ID kort)
• Decentral verificering af ID kort
  De ovennævnte ID kort skal af performancemæssige årsager kunne verificeres effektivt decentralt.
• System-til-System komunikation
  Designet fokuserer på system-til-system kommunikation.

Jf. OIO's "Vejledning vedrørende niveauer af autenticitetssikring" bør kravet til autenticitetssikring vurderes ud fra, hvor store konsekvenser et brud på autenticitet kan have. I dokumentet defineres fire niveauer:

Følgende tabel anvendes ved konsekvensanalyse af autenticitetsfejl:

Da man i sundhedssektoren nogle gange overfører data der er meget personfølsomme eller ved kompromittering/korumpering kan have store konsekvenser for patientsikkerheden, skal vi understøtte alle niveauer i SOSI. På niveau 1 og 2 har vi endvidere valgt at forøge sikkerheden ved at anvende system ID-kort baseret på OCES virksomhedscertifikater. Helt konkret benyttes flg. teknologier til autenticitetssikring i SOSI:

Bemærk: Det er ikke muligt at opnå autenticitetssikring på niveau 4 med OCES certifikater, idet dette kræver kvalificerede certifikater, dvs. certifikater udstedt på baggrund af personligt fremmøde jf. "Bekendtgørelse om sikkerhedskrav mv. til nøglecentre §6 stk. 2". Selv om vi lægger op til at anvende OCES certifikater i SOSI, er designet og dermed SOSI ikke begrænset til ikke-kvalificerede certifikater.

Den opmærksomme læser og/eller den erfarne systemintegrator har måske bemærket, at der ovenfor kun findes niveauer for autenticitetssikring for brugere. I praksis vil mange serviceudbydere dog stille services til rådighed for systemer og ikke for brugere. I teorien kunne man definere nogle andre autenticitetstrin for systemer, eller man kunne abstrahere og lade trinene gælde en principal (der så enten kunne være en bruger eller et system eller ...). I SOSI vælger vi dog af praktiske og sikkerhedsmæssige årsager kun at autentificere systemer på baggrund af digitale certifikater. Systemautentifikation er dermed et specialtilfælde af niveau 3. Se mere om dette i afsnittet om systemautentifikation.

Autenticitetssikring er kun ét sikkerhedsaspekt, der skal håndteres i en føderation. Andre væsentlige sikkerhedsaspekter som konfidentialitet, integritet, autorisation og uafviselighed skal også håndteres. Dette kan man læse mere om i kapitlet om sikkerhed og andre Quality-of-Service aspekter.