...

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 Dette dokument er delt op i følgende underafsnit:

1. Tekniksk anvendelseTeknik
   
   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.

...

Teknisk 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:

...

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

Teknisk opsætning og anvendelse af NSP Security API

I forgående afsnit blev det fremhævet, at det ikke er en NSP komponents 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.

...

1. Forholde sig til de understøttede brugertyper
2. Dokumentere hvorledes de understøttede brugertyper valideres og mappes (udfra modellen udbudt af NSP Security API og evt. andre kilder)
3. Implementere mapning fra NSP Security API til brugertyper

...

2. Implementere mapning fra NSP Security API til brugertyper

Disse tre punkter er beskrevet i de følgende afsnit, hvor der også vil være praktisk eksempler. 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?

Understøttede brugertyper og dokumentation i Brugerhistorier

...

En given NSP komponent skal forholde sig til, hvilke brugertyper den understøtter. Dette er i høj grad en forretningsmæssig beslutning, og det er vigtigt at en komponent dokumenterer de understøttede brugertyper. Dokumentationen af brugertyperne og de brugerhistorier, som de indgår i foretages i dokumenttypen Brugerhistorier. Et eksempel på et sådant dokument er DROS - Brugerhistorier. Mange eksisterende NSP komponenter har ikke dette dokument, men en succesfuld anvendelse af NSP Security API forudsætter, at det eksisterer. Derfor bør indførelsen af NSP Security API først ske efter, at denne dokumentation er udarbejdet. Denne dokumenttype er ikke et teknisk dokument og indholdet skal som minimum gennemlæses og verificeres af SDS NSP arkitekt og Product Owner.

Dokumentation af brugerhistorier er den forretningsrettede dokumentation af, hvad en komponent kan, og hvem der kan anvende den og er således også en forudsætning for at anvendere kan scope og designe deres integration i henhold til dokumentationen i Guide til Anvendere. Se f.eks. DROS - Guide til anvendere for et eksempel på at sammenholde anvenderguide og brugerhistorier.

TODO måske tilføje til design og arkitektur: Fremadrettet vil det give mening at ændringer til en NSP komponent udtrykkes som brugerhistorierSe i øvrigt Dokumentationskrav for NSP-platformen for at få et overblik over de dokumentationspakker, der bør være til stede i forbindelse med en NSP leverance.

Mapning fra NSP Security API til understøttede brugertyper og dokumentation i Design og Arkitektur

...

...

Implementation af validering og mapning af brugertyper

...