Security API - Leverancebeskrivelse

Release 1.0.6

22 Mar 2022 

• Jira
  server NSI JIRA serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-5470

Security API - Guide til anvendere

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.

...

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.

...

F.eks. finder der i praksis i dag ikke billet, hvor en sundhedsperson kan arbejde på vegne af en anden sundhedsperson (dvs. både ActingUser og PrincipalUser er tilstede). Dette kan udtrykkes i Security API'ets model og det er meget tænkeligt, at der kommer support for dette i fremtiden (når XUA kommer på banen).

Ansvarsfordeling mellem komponent og Security API

Som det blev beskrevet før, så er Security APIs model meget generel og kan udtrykke ting, som der i øjeblikket ikke kan forekomme i praksis.

...

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

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:

...

Det skal dog være tydligt, 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

• Javadoc bliver i dag ikke loadet korrekt af IDE - af en eller anden grund. Så hvis man vil se Javadoc, så skal man kigge i SVN.
• 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.

...