Page History
| Navitabs | ||||
|---|---|---|---|---|
| ||||
| Table of Contents |
|---|
Introduktion
Dette dokument beskriver design og arkitektur af NSP Security API til brugerautentificering og autorisering på NSP.
Det første afsnit beskriver den arkitekturmæssige motivation for indførelsen af NSP Security API. I de følgende afsnit gennemgåes modellen i NSP Security API mere detaljeret og ansvarsfordelingen mellem den anvendende NSP komponent og NSP Security API gennemgås.
Motivation for NSP Security API
Målet med NSP Security API er at gøre det let for services at tjekke sikkerhed - både for DGWS, IDWS og JTP-H. Derudover skal NSP Security API gøre det muligt at understøtte sikkerhedsprotokoller i fremtiden.
...
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
Modellen i NSP Security API
Overordnet princip: Udtrykker kun den information, som findes i sikkerhedsbilletten - og ikke andet.
...
I Security API - Guide til anvendere findes eksempler på hvordan den resulterende sikkerhedsmodel ser ud for de tre typer af billetter der understøttes (DGWS, IDWS og JTP-H).
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.
...
Komponenten bør dog forholde sig til, hvad der er muligt i Security API'ets model, og ikke kun på, hvad der er muligt i de aktuelle sikkerhedsbilletter. 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 mange komponenter er forretningslogikken og aktør-modelleringen afhængig af oplysninger, der ikke er en del af Security API. Eksempler kan være:
...