Målet med 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 de nødvendige abstraktioner/termer og tilbyde en passende mapning fra de konkrete sikkerhedsprotokoller.

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

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

Så 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. Et eksempel kan være 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.

Eksempler på aktører:

• Myndig borger på egne vegne
• Autoriseret sundhedsfaglig
• Sundhedsfaglig med national rolle

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 feks være vigtigt at tjekke, at Principal User ikke er sat, hvis man gerne vil matche en borger der handler på egne vegne.

Forslag til