Page History

...

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

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. Brugermodellering og mapning: TODOViser, hvordan en komponent kan anvende håndtagene i NSP Security API til at verficerer indkommende kald.
3. Logning og fejlhåndtering

...

Dette skal gøres på en måde, så det der tilbydes de anvendende services/komponenter de nødvendige abstraktioner/termer og tilbyde en 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å security API opererer på et lavere niveau, hvor denne mapning giver mening.

Modellen i Security API

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

...

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.

Eksempler på aktører. Denne liste er ikke udtømmende, og det er vigtigt at overveje, hvad der skal gælde i de enkelte komponenter.:

TODO: Dokumentationskrav: 1) Brugerhistorier med komplet liste af brugertyper og beskrivelse af dem, så de giver mening for anvenderne 2) De enkelte brugertyper og de regler, der omgiver dem (hvad tjekkes i security api) skal beksrives i design og arkitekturguide

Eksemplerne nedenfor skal beriges med, hvad der IKKE må være tilstede (f.eks. for borger må der ikke være en organisation). Kig på de enkelte attributter i security api f.eks. som en tabel eller ligenden, så man kan se strukturen og de regler der gælder på de forskellige niveauer.

...

Borger (Citizen)

...

Myndig borger på egne vegne

ActingUser er udfyldt:

Sikkerhedsbillettens UserType skal være "Citizen"

Audience fra sikkerhedsbilletten skal kunne verificeres

Borger på vegne af anden borger

...

Borgeren skal have en af disse:

•  fuldmagt 

• forældremyndighed/værgemål

...

ActingUser er udfyldt:

Sikkerhedsbillettens UserType skal være "Citizen"

Audience fra sikkerhedsbilletten skal kunne verificeres

For fuldmagt, så er PrincipalUser også udfyldt, og der kan på ActingUser findes PowerOfAttorneyPrivileges (ligger på ActingUsers Credentials). Listen bør gennemløbes, og der bør findes en veldefineret privilgiestreng.

For forældremyndighed og værgemål er PrinicipalUser IKKE til stede, men vil være givet i requestet. Der bør tjekkes (f.eks. via SDM services, at der er en passende forældre- eller værgerelation).

...

 Sundhedsfaglig (HealthcareProfessional)

...

Autoriseret sundhedsfaglig

Sundhedsfaglig med national rolle

...

ActingUser er udfyldt:

Sikkerhedsbillettens UserType skal være "HealthcareProfessional"

...

Sundhedsfaglig på vegne af anden sundhedsfaglig

...

Administrativ bruger

...

Benyttes pt. kun i Minspærring

ActingUser er udfyldt:

Sikkerhedsbillettens UserType skal være "HealthcareProfessional"

RequiredNationalRole skal være udfyldt (og den må ikke være slået fra vha. TURN_NATIONAL_ROLE_OFF)

...

Systembruger

...

Tilgår servicen med et ID-kort niveau 3

Komponenten skal modellere disse aktører på en eller anden måde (f.eks nedarvning eller en simpel enumeration, der lister typerne).

Komponenten skal selv mappe fra security context til sin egen aktørmodel:

...

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 aktørmodellen må komponenten gerne tage disse oplysninger med i aktørmodelleringen.

Det skal dog være tydligttydeligt, 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).

Forslag til forbedringer

...

• Modelleringen af aktører i komponenernet skal være eksplicit i RFC'er (både omlægningopgaver og ændringsønsker). Det har stor impact på en komponent, hvilke aktører man har, og hvordan de modelleres, og forretningen bør være en del af denne beslutning. Det skal ikke være et "biprodukt af en teknisk opgave".
• KIT foreslår, at man laver eksempler (enten i pseudokode på denne side eller på en anden måde) med modellering og validering af "gængse aktørtyper". Selvom Security API ikke vil begrænse komponenten i forhold til dette, så kunne det være en stor hjælp og afgørende i forhold til ensartethed henover komponenter at have eksempler på "gængse aktørtyper" og hvordan man mapper/validerer disse korrekt. Det er f.eks. "borger, der handler på vegne af sig selv" eller "borger, der handler på vegne af anden borger". Der er højst sandsynligt ikke den store forskel på, hvordan komponenter vil mappe/validere disse.

...

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.

...

• Hvilke brugertyper er til stede i min komponent?
• Hvordan skal disse brugertyper tjekkes/mappes i forhold til de forretningsregler, der gæder gælder i min komponent=?Eksempler på aktører. Denne liste er ikke udtømmende, og det er vigtigt at overveje, hvad der skal gælde i de enkelte komponenter.:komponen?

Teknisk opsætning og anvendelse af NSP Security API

...

root@7e07691acb13:~# cd /tmp
root@7e07691acb13:/tmp# jar xf /pack/wildfly/modules/system/layers/base/dk/sds/nsp/security/main/nsp-security-api.jar
root@7e07691acb13:/tmp# cat META-INF/MANIFEST.MF 
Manifest-Version: 1.0
Implementation-Title: NSP Security API
Implementation-Version: 
Archiver-Version: Plexus Archiver
Built-By: root
Created-By: Apache Maven 3.5.4
Build-Jdk: 1.8.0_275
Specification-Version: 1.0.6

I ovenstående eksempel er det NSP Security API version 1.0.6, der stilles til rådighed af den konkrete version af Wildfly, hvilket hænger fint sammen med det versionsnummer, der blev udtrykt i Maven afhængigheden (i pom.xml).

Aktørmodellering og dokumentation

Som nævnt i første afsnit, så stiller NSP Security API en række håndtag til rådighed for den anvendende komponent. Det er komponentens egen opgave at

1. Forholde sig til de understøttede brugertyper
2. Implementere mapning fra NSP Security API til brugertyper

Understøttede brugertyper

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.

Fremadrettet vil det give mening at ændringer til en NSP komponent udtrykkes som brugerhistorier.

Mapning fra NSP Security API til understøttede brugertyper

Når dokumentationen af de understøttede brugertyper er på plads, så skal

Eksempler på aktører. Denne liste er ikke udtømmende, og det er vigtigt at overveje, hvad der skal gælde i de enkelte komponenter.:

TODO: Dokumentationskrav: 1) Brugerhistorier med komplet liste af brugertyper og beskrivelse af dem, så de giver mening for anvenderne 2) De enkelte brugertyper og de regler, der omgiver dem (hvad tjekkes i security api) skal beksrives i design og arkitekturguide

Eksemplerne nedenfor skal beriges med, hvad der IKKE må være tilstede (f.eks. for borger må der ikke være en organisation). Kig på de enkelte attributter i security api f.eks. som en tabel eller ligenden, så man kan se strukturen og de regler der gælder på de forskellige niveauer.

Komponenten skal modellere disse aktører på en eller anden måde (f.eks nedarvning eller en simpel enumeration, der lister typerne).

Komponenten skal selv mappe fra security context til sin egen aktørmodel:

• Er der en billet og er den valid?
• I forhold til de enkelte aktører skal man forholde sig til sikkerhedsmodellen og tjekke, at alle betingelser er opfyldt. Det kan f.eks. være vigtigt at tjekke, at Principal User ikke er sat, hvis man gerne vil matche en borger der handler på egne vegne.
• Det er vigtig at lave en korrekt og gensidig udelukkende match mellem SecurityContext og aktør, så man ikke ved et uheld ender op med en forkert aktørtype. Det er nok særlig relevant i "på vegne af" tilfældet, hvor eksistensen af en PrincipalUser er afgørende.