...

Dernæst 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. Dette 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 verficerer verficere indkommende kald. Herunder også dokumentation.
3. Logning og fejlhåndtering

Arkitekturoverblik og motivation for NSP Security API

...

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å security 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.

...

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:

Ansvarsfordeling mellem komponent og 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.

...

• 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.

...

Komponenten skal modellere disse aktører på en eller anden måde så det giver mening. Dette kan f.eks laves ved hjælp af nedarvningshierarkier eller en simpel enumeration, der lister brugertyperne.

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

...

For hver af de understøttede brugertyper, skal det i Design og Arkitektur dokumentet for en komponent fremgå, hvorledes disse brugertyper bestemmes, verificeres og mappes.

Som et eksempel tages her udgangspunkt i Dokumentdelingsservicen.

I Dokumentdelingsservicen understøttes blandt andre brugertypen borger. En borger er en myndig person, som tilgår information om sig selv.

I Dokumentdelingsservicen kan man ende med at blive borger på to forskellige måder:

1. Kald med en borgerbillet
2. Kald fra sundhed.dk med SOSI System Idkort med tilhørende HSUID header

...

Til dokumentationsformål kan man for eksempel anvende følgende metode, hvor de to tilfælde dokumenteres i tabelformat som nedenstående (udgangspunktet er tabellen ovenfor i dokumentationen af NSP Security API.

...