Dette dokument beskriver NSP Security API til brugerautentificering og autorisering på NSP.

Det første afsnit beskriver den arkitekturmæssige motivation for indførelsen af NSP Security API.

Dernæst Først vises hvordan NSP Security API rent praktisk indføres i en NSP komponent med konkrete eksempler på anvendelse. Denne sektion er især relevant for udviklere, der skal bruge NSP Security API i forbindelse med en konkret opgave. Det anvendelsesorienterede afsnit er delt op i følgende underafsnit:

1. Teknik
   1. Dependency management: Viser, hvordan Maven dependency management samt deployment descriptors til NSP base Docker image anvendes til at få de nødvendige afhængigheder på plads for anvendelse af NSP Security API.
   2. Snitfladebeskrivelser og fejlhåndtering
2. Brugermodellering og mapning: Viser, hvordan en komponent kan anvende håndtagene i NSP Security API til at verficere indkommende kald. Herunder også dokumentation.

Arkitekturoverblik og motivation for NSP Security API

Målet med NSP Security API er at gøre det let for services at tjekke sikkerhed - både DGWS, IDWS. Derudover skal NSP Security API gøre det muligt at understøtte sikkerhedsprotokoller i fremtiden.

Dette skal gøres på en måde, så de anvendende services/komponenter tilbydes de nødvendige abstraktioner/termer og passende mapning fra de konkrete sikkerhedsprotokoller til en model, der gør det muligt at tilgå forskellige elementer i den indkommende sikkerhedsbillet.

Termerne spiller også ind i måden, som SDS ønsker at modellere brugere/aktører i forhold til de user stories som beskriver opførsel og komponenter. Det er op til komponenterne selv at modellere de aktører, som de skal servicere, så NSP Security API opererer på et lavere niveau, hvor denne mapning giver mening.

Modellen i NSP Security API

Overordnet princip: Udtrykker kun den information, som findes i sikkerhedsbilletten - og ikke andet.

Stiller informationen til rådighed for komponenten gennnem SecurityContext hvorfra, der er adgang til alle information bl.a. ActingUser (den bruger, der trykker på knapperne), PrincipalUser (den bruger, der er ansvarlig for handlingen), Organisation, Message og Ticket.

Modellen er mere generel end de nuværende sikkerhedsprotokoller og udfaldrummet for de aktuelle sikkerhedsbilletter giver anledning til.

F.eks. finder der i praksis i dag ikke billet, hvor en sundhedsperson kan arbejde på vegne af en anden sundhedsperson (dvs. både ActingUser og PrincipalUser er tilstede). Dette kan udtrykkes i Security API'ets model og det er meget tænkeligt, at der kommer support for dette i fremtiden (når XUA kommer på banen).

Nedenstående tabel er en oversigt over den model, der stilles til rådighed for anvenderen af NSP Security API:

TODO: SecurityContextProvider dokumenteres (og findes som development udgave)

TODO: Mere forklaring på de enkelte properties (hvad er en autorisationskode f.eks.? Hvad er en uddannelseskode?)

TODO: eksempel hvor vi har en DGWS billet og en IDWS billet og kan se hvilken model de så giver anledning til.

...

Ansvarsfordeling mellem komponent og NSP Security API

Som det blev beskrevet før, så er NSP Security APIs model meget generel og kan udtrykke ting, som der i øjeblikket ikke kan forekomme i praksis.

Dette betyder dog, at det kan være ligeså vigtigt, at en komponent validerer både attributter der findes, og dem der ikke findes, for at mappe korrekt til de relevante aktører.

I eksemplet fra før, hvor en sundhedsfaglig, der handler på vegne af en anden sundhedsfaglig: Dette kan udtrykkes i Security API, men der findes ikke (i dag) en sikkerhedsbillet, der kan bærer denne information.

Komponenten bør dog forholde sig til, hvad der er muligt i Security API'et model, og ikke kun på, hvad der er muligt i de aktuelle sikkerhedsbilletter. Hvis en komponent ikke ekplicit tillader "på-vegne-af" bør den tjekke, at sikkerhedsbilletten ikke er af en sådan type.

Hvad med alt det, der ikke er i sikkerhedsbilletten?

I mange komponenter er forretningslogikken og aktør-modelleringen afhængig af oplysninger, der ikke er en del af Security API. Eksempler kan være:

• HSUID Header: Mulighed for at udtrykke på vegne af mellem sundhedspersoner
• Særlige 'admin' URL'er: Mulighed for at kalde som en særlig kraftig brugertype
• Request parametre: Input parametre, som er en del af komponentens servicesnitflade

I aktørmodellen må komponenten gerne tage disse oplysninger med i aktørmodelleringen.

...

1. .

Anvendelse af NSP Security API i NSP komponenter

...