...

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.

TODO tegning, der viser hvordan det hænger sammen

Modellen i NSP Security API

...

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

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.

Det skal dog være tydeligt i dokumentationen og mapningen for den enkelte komponent, hvilke oplysninger, der stammer hvorfra (hvilke, der er en del af de STS-validerede oplysninger og hvilke der er kontekst-oplysninger, der essentielt bare er en udvidelse af det af komponenten udbudte API med ekstra kontekst).

Anvendelse af NSP Security API i NSP komponenter

For at anvende NSP Security API i en konkret NSP komponent i udviklingsmæssig sammenhæng, så er der et par tekniske øvelser, der skal være på plads. Da hovedparten af NSP'ens komponenter er bygget op på samme måde, så vil denne vejledning umiddelbart kunne anvendes i langt de fleste tilfælde. Antagelsen i denne vejledning er derfor at:

• Komponenten anvender Maven til styring af dependencies
• Komponenten afvikles på Wildfly (evt via et af NSP'ens Docker images)

I de følgende afsnit gennemgåes først, hvordan en komponent forberedes teknisk til at kunne anvende NSP Security API ved at udtrykke både en kodemæssig og en afviklingsmæssig afhængighed til NSP Security API.

...

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.

Det skal dog være tydeligt i dokumentationen og mapningen for den enkelte komponent, hvilke oplysninger, der stammer hvorfra (hvilke, der er en del af de STS-validerede oplysninger og hvilke der er kontekst-oplysninger, der essentielt bare er en udvidelse af det af komponenten udbudte API med ekstra kontekst).

Anvendelse af NSP Security API i NSP komponenter

For at anvende NSP Security API i en konkret NSP komponent i udviklingsmæssig sammenhæng, så er der et par tekniske øvelser, der skal være på plads. Da hovedparten af NSP'ens komponenter er bygget op på samme måde, så vil denne vejledning umiddelbart kunne anvendes i langt de fleste tilfælde. Antagelsen i denne vejledning er derfor at:

• Komponenten anvender Maven til styring af dependencies
• Komponenten afvikles på Wildfly (evt via et af NSP'ens Docker images)

I de følgende afsnit gennemgåes først, hvordan en komponent forberedes teknisk til at kunne anvende NSP Security API ved at udtrykke både en kodemæssig og en afviklingsmæssig afhængighed til NSP Security API.

Dernæst vises det med et praktisk eksempel hentet fra DROS og Dokumentdelingsservicen, hvordan NSP Security API bliver anvendt i dokumentation og applikationskode til at implementere brugerautentificering og -autorisation.

Det er vigtigt at notere sig, at eksempler i denne anvenderguide er ment som inspiration til anvendere af NSP Security API. Det er således ikke en udtømmende facitliste. Anvendelsen af NSP Security API kræver komponentspecifikke og forretningsspecifikke overvejelser:

• Hvilke brugertyper er til stede i min komponent?
• Hvordan skal disse brugertyper tjekkes/mappes i forhold til de forretningsregler, der gælder i min komponent?

Teknisk opsætning og anvendelse af NSP Security API

I forgående afsnit blev det fremhævet, at det ikke er en NSP komponents ansvar selv at inkludere NSP Security API i dens færdigbyggede modul.

I stedet udtrykker komponenten, at den regner med, at de omgivelser, hvori den efterfølgende afvikles, stiller NSP Security API til rådighed på afviklingstidspunktet.

Maven Dependency Management

Langt de fleste NSP komponenter anvender Maven til at holde styr på afhængigheder til tredjeparts biblioteker.

NSP Security API adskiller sig ikke fra andre tredjeparts biblioteker i den forstand og kræver således blot, at følgende tilføjes til rækken af dependencies (NB! tjek versionsnummer i forhold til den gældende version) i konfigurationsfilen (pom.xml):

<dependency>
    <groupId>dk.sds.nsp.security</groupId>
    <artifactId>security-api</artifactId>
    <version>1.0.6</version>
    <scope>provided</scope>
</dependency>

Det er vigtigt at notere sig, at eksempler i denne anvenderguide er ment som inspiration til anvendere af afhængigheden til NSP Security API . Det er således ikke en udtømmende facitliste. Anvendelsen af NSP Security API kræver komponentspecifikke og forretningsspecifikke overvejelser:

• Hvilke brugertyper er til stede i min komponent?
• Hvordan skal disse brugertyper tjekkes/mappes i forhold til de forretningsregler, der gælder i min komponent?

Teknisk opsætning og anvendelse af NSP Security API

I forgående afsnit blev det fremhævet, at det ikke er en NSP komponents ansvar selv at inkludere NSP Security API i dens færdigbyggede modul.

...

skal have provided scope.

Provided scope i Maven benyttes til at udtrykke en afhængighed til et library uden dette inkluderes i det færdigbyggede modul (jar/war), men som i stedet antages at blive stillet til rådighed (provided) af de omgivelser, som modulet afvikles i.

Afviklingsomgivelserne for en NSP komponent er Wildfly (evt via et af NSP'ens Docker images). I det følgende afsnit vises, hvordan man sørger for, at Wildfly rent faktisk stiller NSP Security API til rådighed for den anvendende komponent og derved opfylder kontrakten, som blev udtrykt i Maven konfigurationsfilen.

Wildfly Dependency Management

Afviklingsomgivelserne for en standard NSP komponent er Wildfly (evt via et af NSP'ens Docker images). På Wildfly findes en række tredjeparts biblioteker, der leveres med platformen - herunder også NSP Security API.TODO pom.xml som i audit api

Som default er de fleste af disse bibliotekter afskærmet og således ikke til rådighed for komponenten på afviklingstidspunktet - men via en særlig konfigurationsfil (som Wildfly forstår) kan det udtrykkes, at komponenten ønsker, at få adgang til et eller flere af disse biblioteker.

...

TODO kode eksempel fra DDS (måske pseudokode for at hjælpe).?

TODO Hvordan beskrive brugertyper og sikkerhedsprotokoller for anvenderne?