1.1. Formål
Formålet med dette dokument er at beskrive design og implementation af en sikkerhedsprotokolneutral konteksmodel.
Tankerne bag en sikkerhedsprotokolneutral kontekstmodel er, at de skal være muligt at...
- implementere forretningsservices - herunder forretningslogik eller adgangsbegrænsninger - baseret på bruger- og brugskontekst uden at vide noget om konkrete sikkerhedsprotokoller. Herved kan forretningslogik vedligeholdes og udvikles uafhængigt af udviklingen i sikkerhedsprotkoller(nes implementation).
- udbyde forretningsservices (f.eks. DDS) på flere måder - dvs. beskyttet af flere sikkerhedsprotokoller. Herved kan den samme forretningsservice udbydes til anvenderne og en gradvis migrering af anvendersystemer fra een sikkerhedsprotokol til en anden bliver mulig.
Dette design er udarbejdet med afsæt i arbejdet med en IDWS udgave af DDS (se https://jira.nspop.dk/browse/SDS-2678 og https://jira.nspop.dk/browse/SDS-3052).
Designet af kontekstmodellen er sket ud fra de konkrete behov som DDS har, men kan bruges som grundlag for en mere generelt kontekstmodel, der kan bruges af andre NSP services. Løbende i dokumentet gives eksempler fra DDSens anvendelse af kontekstmodellen.
1.2. Overordnet design og implementering af kontekstmodel
Den sikkerhedsprotokolneutrale kontekstmodel er i DDS realiseret i konteksten af to mulighed sikkerhedsprotokoller: DGWS (som DDS udbydes med i dag) og IDWS.
Vi er i DDS kommet frem til en model for bruger- og brugskontekst, som giver de nødvendige abstraktioner i forhold til de brugs- og kaldmønstre, der findes for DDS i dag. Det drejer sig helt banalt om den kaldende brugers identitet og egenskaber, men også om mere komplekse anvendelsesmønstre (f.eks. værdispring og på-vegne-af).
Den sikkerhedsprotokolneutral kontekstmodel skal opbygges udfra en konkret implementation af en sikkerhedsprotokol. Denne implementation har følgende ansvar:
- Validering af, at kalderens akkreditiver (tokens, certifikater etc) er korrekte og valide: Ideelt skal disse oplysninger stamme fra en autoritativ kilde (f.eks. et token udstedt af STS), men f.eks. i DGWS tilfældet vil dele af oplysningerne stamme fra HSUID headeren, som er en ikke-signerede kilde.
- Opbygning af kontekstmodel udfra egenskaberne i kalderens akkreditiver: Oplysningerne fra akkreditativerne anvendes til at populere kontekstmodellen. Når kontekstmodellen overgår til den bagvedliggende forretningsservice er den indbyrdes kontrakt mellem sikkerhedsprotokollen og forretningslogikken, at forretningslogikken kan stole på de oplysninger der findes i kontekstmodellen.
Det er realiserbart, at den konkrete kode, der implementerer sikkerhedsprotokollen og koden for forretningsservices kan vedligeholdes uafhængigt af hinanden (evt. af forskellige leverandører). I arbejdet med DDS har vi lagt implementationen af den sikkerhedsprotokolneutrale kontekstmodel og DGWS + IDWS implementationerne af denne som en del af DDS sourcekoden. Opbygningen er dog således, at det umiddelbart er muligt at skille dette ud i et selvstændigt projekt, da der ikke er afhængigheder fra denne kode til DDS koden (kun den anden vej).
I diagrammet ovenfor er det vist, hvordan DDS forretningskoden kun afhænger af den abstrakte kontekstmodel. De to konkrete implementationer (DGWS og IDWS) anvendes af tynde deployment moduler i DDS, der ikke indeholder forretningskode, men hvis eneste ansvar er at pakketere DDSens forretningskode med den rigtige sikkerhedsimplementation. Diagrammet er forsimplet da DDSens forretningskode i praksis består af mange moduler. Derudover findes der både en DDS Registry og en DDS Repository deployable. Både DDS Repository og DDS Registry leveres i en IDWS og DGWS udgave efter skabelonen ovenfor.
Ved kun at vedligeholde en enkelt implementation af sikkerhedsprotokollen (i stedet for at have dette distribueret ud over de konkrete forretningsservices) reducereres vedligeholdelses- og testarbejdet for sikkerhedsprotokollen.
Det kan forekomme, at visse oplysninger kan fremskaffes i den ene sikkerhedsprotokol men ikke i den anden. F.eks. indeholder IDWS tokens oplysninger vedr. samtykke og behandlerrelation, mens dette ikke er tilfældet for DGWS akkreditiver. De bagvedliggende forretningsservices må derfor have en fallback plan i form af defaultværdier eller egne kald til støtteservices i de tilfælde, hvor oplysninger ikke er tilstede i kontekstmodellen. DGWS udgaven af DDS foretager derfor selv et kald til samtykkeservicen for at tilvejebringe de nødvendige oplysninger.
1.2.1. Konkrete erfaringer i forhold til indførelsen af kontekstmodel i DDS forretningskode
I projektet med DDS har det været nødvendigt at lave et større refaktoreringsarbejde på forretningslogikken.
I forretningslogikken for DDS blev kontekstoplysninger i form af DGWS-specifikke objekter båret rundt i koden. For at opnå en afkobling i forhold til sikkerhedsmodellen er alle DGWS-specifikke objekter skiftet ud med den sikkerhedsprotokolneutral kontekstmodel (se næste afsnit for specifikt indhold).
En fordel ved dette arbejde, er (udover at skabe afkobling til sikkerhedsprotokollen) at kontekstmodellen er lettere at arbejde med i forhold til unittests: Det er lettere at mock’e en kontekstmodel (POJO), end det er at mock’e et SAML token, der konstruktionsmæssigt er meget mere komplekst (signaturer, XML osv).
1.3. Kontekstmodellens opbygning og indhold
Selve kontekstmodellen vil indeholde forskellige typer af information. Følgende liste tager udgangspunkt i den konkrete kontekstmodel, som er bygget i DDS i forbindelse med omlægning til IDWS.
Overordnet set falder de forskellige informationer i kontekstmodellen indenfor følgende kategorier:
Type | Beskrivelse |
---|---|
Teknisk | En del af konteksten er af teknisk karakter. Dette er oplysninger, der gør det muligt at spore kald henover services. I DGWS har man således et flowid og et messageid som en del af Medcom-headeren. Disse anvedes f.eks. i logning til sporing af kald på tværs af services. Det kunne måske give mening at bibeholde (dele af) Medcom-headeren også i IDWS. |
Brugerinformation | Dette er oplysninger om brugeren. Hvilken type af bruger er der tale om, hvilket sikkerhedsniveau er vedkommende autoriseret på, andre oplysninger om brugeren. I DGWS er det typisk de oplysninger, der er at finde i SOSI Idkortet. I IDWS står det i IDWS tokenet. |
Brugskontekst | Konteksten, som brugeren arbejder i. Dette er f.eks. oplysninger om, hvilken borger (cpr nummer), som brugeren opererer på, om brugeren opererer på vegne af en anden og diverse oplysninger vedr. I DGWS er det typisk de oplysninger, der står i HSUID headeren. I IDWS tilfældet vil brugskonteksten kunne populeres udfra IDWS tokenet: F.eks. borgerens cprnummer samt evt. oplysninger om samtykke. |
Token | Der kan være brug for at anvende det token (SOSI id kort, SAML assertion osv), hvis forretningsservicen har brug for at kalde andre services. Derfor indlejres denne information som en del af den protokolneutrale kontekst, men forventes kun brugt, der hvor man skal kalde andre services (og der skal man jo alligevel forholde sig til sikkerhedsprotokolen). Denne del af konteksten skal således ikke bruges af forretningslogik. |
I DDS udgaven af kontekstmodellen og de tilhørende implementationer af hhv DGWS og IDWS har vi opereret med følgende attributter.
Selve implementation af kontekstmodellen i DDS koden er i øjeblikket flad - dvs. alle attributter ligger ved siden af hinanden i een lang liste, men i dette afsnit præsenteres en objektorienteret kontekstmodel, som det vil give mening at tage afsæt i i det videre arbejde.
Kontekstattribut | Type og udfaldsrum | Beskrivelse | DGWS mapning | IDWS mapning | Verificeret | Anvendelse i DDS forretningskode |
---|---|---|---|---|---|---|
flowid | String | Teknisk id til sammenkædning af relaterede servicekald | flowid fra MedcomHeader | findes ikke (i DDS har vi autogenereret et ved indgående kald, som anvendes i videre kald) | Ikke relavant | Logning |
messageid | String | Teknisk id til identifikation af det enkelte servicekald | messageid fra MedcomHeader | findes ikke (i DDS har vi autogenereret et ved indgående kald, som anvendes i videre kald) | ikke relevant | Logning |
systemName | String | |||||
systemVersion | String | |||||
securityLevel | 1-4 | fra SOSI Idkort | fra IDWS token | Ja | DDS tillader f.eks. VOCES certifikater for Repository delen men MOCES for Registry | |
userType | CITIZEN, UNAUTHORIZED_PROFESSIONAL, HEALTHCARE_PROFESSIONAL, SYSTEM | Typen af bruger | Brugertypen fra HSUID header sammen med fravær/tilstedeværelse af autorisationsid i SOSI Idkort | ‘dk:healthcare:saml:attribute:UserType’ fra IDWS token (kan være Citizen, Employee, System). System mapper til null i denne sammenhæng, Citizen mappes til CITIZEN og Employee mappes til UNAUTHORIZEDPROFESSIONAL hhv HEALTHCAREPROFESSIONAL alt efter værdi i userAuthorizationCode | Ja | Der er forskellige forretningsregler for borgere (her tjekkes f.eks. ikke samtykke) og for sundhedsprofessionelle (her tjekkes samtykke) samt for ikke-autoriserede (her er f.eks. ekstra filtrering på dokumenttyper). Note: Det diskuteres, hvorvidt UNAUTHORIZED_PROFESSIONAL skal være en del af kontekstmodellen eller om det er op til forretningskoden at udlede dette tilfælde udfra tilstedeværelse/fravær af autorisationsid. |
userRole | String | Brugerens rolle | Brugerrollen kommer fra SOSI IDkorts 'userRole'. Dette kan dække både over en uddannelseskode for autoriserede og over en SEB rolle fra ikke-autoriserede | ‘dk:healthcare:saml:attribute:UserEducationCode’ attribut fra IDWS token. SEB roller håndteres ikke i mapningen på nuværende tidspunkt. | Ja | I DDS er der f.eks. en mapning fra ikke-autoriseredes SEB roller til dokumenttyper som må tilgås. |
actingUserCivilRegistrationNumber | String | Cprnummer for den bruger, der i praksis udfører kaldet | Fra SOSI Idkort | ‘dk:gov:saml:attribute:CprNumberIdentifier’ attribut fra IDWS token | Ja | Anvendes f.eks. til lognin |
orgUsingIdType | Typen for HSUID header Organtisation IdentifierType er brugt Note: Bør modelleres uafhængigt af HSUID, men så længe, at det er en enumeration, så går det nok | Det organisatoriske forhold for den bruger, der i praksis udfører kaldet - typen af id | Fra HSUID header | I strukturen ‘urn:ihe:iti:xua:2017:subject:provider-identifier’ i IDWS token findes en OID i root. Dette mappes på følgende måde: 1.2.208.176.1.1 -> SOR 1.2.208.176.1.4 -> Yder 1.2.208.176.2.3 -> SHAK | Ja (IDWS), Nej (DGWS) | Se anvendelse af orgUsingIdName |
orgUsingIdName | String | Det organisatoriske forhold for den bruger, der i praksis udfører kaldet - selve id | Fra HSUID header | I strukturen ‘urn:ihe:iti:xua:2017:subject:provider-identifier’ i IDWS token anvendes extension | Ja (IDWS), Nej (DGWS) | I DDS kan dette være input til behandlingsrelationservice (BRS) |
alternativeOrgUsingIDType | String | Foretrukken organisationskodetype (hvis anderledes end den der er angivet i orgUsingIDType) | Fra HSUID header (tilsyneladende udokumenteret - bør måske udgå?) | Ikke understøttet, men kan sættes til det samme som orgUsingIDType, indtil det afklares, hvorfor denne attribut findes | Ja (IDWS) Nej (DGWS) | I DDS anvendes denne i kald til samtykkeservice, hvis angivet ellers anvendes orgUsingIDType. |
alternativeOrgUsingIDName | String | Foretrukken organisationskodetype (hvis anderledes end den der er angivet i orgUsingIDName) | Fra HSUID header | Ikke understøttet, men kan sættes til det samme som orgUsingIDName, indtil det afklares, hvorfor denne attribut findes | Ja (IDWS) Nej (DGWS) | I DDS anvendes denne i kald til samtykkeservice, hvis angivet ellers anvendes orgUsingIDName |
userAuthorizationCode | String | Den ansvarlige brugers autorisationsid (hvis dette findes) | SOSI Idkort hvis sundhedsprofessionel optræder som sig selv eller HSUID header (på vegne af) | ‘dk:healthcare:saml:attribute:UserAuthorizationCode’ i IDWS token anvendes. Note: Vi mangler på vegne af | Ja, STS claim (IDWS), Delvist - ikke ved på vegne af (DGWS) | I DDS anvendes dette i opslag til samtykkeregister |
isUserActingOnBehalfOfAnother | boolean | Differentier mellem den kaldende bruger og den anvarlige brugere (hvis den kaldende agerer på vegne af en anden)? Note: Måske laves en generel relationsmodel (se objektmodel) | HSUID header | Note: mangler i nuværende IDWS DDS | Ja, STS claim (IDWS) Nej (DGWS) | |
isRelationChildCustodyHolder | boolean | Er den kaldende borger værge for det barn, der spørges på? Note: Måske laves en generel relationsmodel (se objektmodel) | HSUID header | Borgertokens og claims for disse er ikke understøttet i den nuværende IDWS DDS og borgerrelationstyper har derfor ikke været i scope. | Borgertokens udestår (IDWS) Nej (DGWS) | I DDS kigges på, om der foreligger en relation mellem to borgere, når een borger spørge om data på en anden |
isRelationProxyHolder | boolean | Note: Måske laves en generel relationsmodel (se objektmodel) | HSUID header | Borgertokens og claims for disse er ikke understøttet i den nuværende IDWS DDS og borgerrelationstyper har derfor ikke været i scope. | Borgertokens udestår (IDWS) Nej (DGWS) | Se ovenfor |
isRelationGuardian | boolean | Er den kaldende borger værge for den borger, der spørges på? Note: Måske laves en generel relationsmodel (se objektmodel) | HSUID header | Borgertokens og claims for disse er ikke understøttet i den nuværende IDWS DDS og borgerrelationstyper har derfor ikke været i scope. | Borgertokens udestår (IDWS) Nej (DGWS) | Se ovenfor |
isConsentOverrideRequested | boolean | Er brugeren i gang med at udføre værdispring? | HSUID header | Hvis ‘urn:oasis:names:tc:xspa:1.0: subject:purposeofuse’ attributten i IDWS token er ‘EMERGENCY’, så true ellers false | Ja (IDWS) Nej (DGWS) | I DDS sætter værdispring al samtykketjek og -filtrering ud af kraft. |
consentIndication | POSITIVE, NEGATIVE, DATA_SPECIFIC_CONSENT eller null (for ‘ved ikke’) | Findes der spærringer? | NULL (DGWS indeholder ikke denne info) | ‘dk:healthcare:saml:attribute:GivenConsent’ i IDWS token attributten mappes (værdier er stort set de samme -dog mappes ‘urn:dk:healthcare:consent:none_known’ til NULL | Ja (IDWS) Ikke relevant (DGWS) | DDS anvender denne oplysning (eller slår op selv, hvis den ikke er tilstede i kontekstmodellen) |
citizenCivilRegistrationNumber | String | Den borger, som kaldet vedrører | HSUID header | ‘urn:oasis:names:tc:xacml:2.0:resource:resource-id’ attribut i IDWS token | Ja (IDWS) Nej (DGWS) | |
token | blob-like | HSUID header+SOSI idkort | IDWS token |
Som allerede nævnt er ovenstående model implementeret som en simpel liste af attributter i den nuværende kontekstmodel.
Følgende diagram er en model (to-be) for en objektorienteret udgave af samme.