...

Arkitekturoverblik og motivation for NSP Security API

Målet med security NSP Security API er at gøre det let for services at tjekke sikkerhed - både DGWS, IDWS og eventuelle sikkerhedsprotokoller i fremtiden.

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

TODO tegning, der viser hvordan det hænger sammen

securityapi (m billet) --→  komponent med mapning --→ aktørmodel -→ forretningslag

Modellen i NSP Security API

...

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.

Der anvendes Optionals rundt omkring.

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

...

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.

...

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

...

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