DDS - Sikkerhedsprotokolneutral kontekstmodel

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:

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.

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.