Page History
...
Når dokumentationen af de understøttede brugertyper er på plads, så skal den konkrete mapning og verifikation fra NSP Security APIs context til sin egen aktørmodel laves.
...
Nedenstående tabel er en oversigt over den model, der stilles til rådighed for anvenderen af NSP Security API:
Ticket | Audience | ||
Validity | |||
Message | Identifier | ||
ConversationIdentifier | |||
Action | |||
ActingUser | UserType | Udfaldsrum: HealthcareProfessional, Citizen | |
IdentifierFormat | Udfaldsrum: CPR | ||
Identifier | |||
GivenName | |||
SurName | |||
Credentials | AuthorizationCode | ||
EducataionCode | |||
NationalRole | |||
UnverifiedRole | |||
PowerOfAttorneyPrivileges | |||
PersistentUniqueKey | |||
PrincipalUser | UserType | Udfaldsrum: HealthcareProfessional, Citizen | |
IdentifierFormat | Udfaldsrum: CPR | ||
Identifier | |||
GivenName | |||
SurName | |||
Credentials | AuthorizationCode | ||
EducataionCode | |||
NationalRole | |||
UnverifiedRole | |||
PowerOfAttorneyPrivileges | |||
PersistentUniqueKey | |||
Organisation | IdentifierFormat | Udfaldsrum: CVR | |
Identifier | |||
Name | |||
Client | Name | ||
PersistentUniqueKey |
Det er komponentens ansvar at verificere følgende:
- Er der en sikkerhedsbillet 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.
Nedenstående stammer fra Dokumentdelingsservicen. I tabellen vises eksempler på forkellige brugertyper og en kort beskrivesle af disse.
...
For hver af de understøttede brugertyper, skal det i Design og Arkitektur dokumentet for en komponent fremgå, hvorledes disse brugertyper bestemmes, verificeres og mappes.
Som et eksempel tages udgangspunkt i Dokumentdelingsservicen.
I Dokumentdelingsservicen understøttes brugertypen borger. En borger er en myndig person, som tilgår information om sig selv. I Dokumentdelingsservicen
Borger (Citizen)
...
Myndig borger på egne vegne
Derudover er der en beskrivelse, hvordan de enkelte brugertyper genkendes og verificeres vha NSP Security API.
For at illustrere, hvordan mapningen kan laves tager vi udgangspunkt i tabellen ovenfor. I
DDS kan man ende med at blive borger på to forskellige måder:
...
Begge tilfælde kræver mapning og verifikation fra NSP Security API, men i tilfælde 2 skal der anvendes yderligere information (fra den indkommende HSUID header).
Til dokumentationsformål kan man for eksempel anvende følgende metode, hvor de to tilfælde dokumenteres i tabelformat som nedenstående.
Brugertypen |
Borger (borgerbillet) | Verifikation | Mapning til DDS ServiceActor | ||
SecurityContext | Ticket | Audience | Matche audience som findes som konfiguration i Dokumentdelingsservice | |
Validity | Er valid | |||
Message | Verificeres ikke - må gerne være der | |||
ActingUser | UserType | Skal være Citizen | Brugertypen: Borger | |
IdentifierFormat | Skal være CPR | |||
Identifier | Skal være sat | PersonIdentifier | ||
GivenName | Verificeres ikke - må gerne være der | |||
SurName | Verificeres ikke - må gerne være der | |||
Credentials | Verificeres ikke - må gerne være der | |||
PersistentUniqueKey | Verificeres ikke - må gerne være der | |||
PrincipalUser | Må ikke være der | |||
Organisation | Må ikke være der | |||
Client | Verificeres ikke - må gerne være der |
Brugertypen Borger (sundhed.dk) | Verifikation | Mapning til DDS ServiceActor | ||
SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
Validity | Er valid | |||
Message | Verificeres ikke - må gerne være der | |||
ActingUser | UserType | Må ikke være der | ||
PrincipalUser | UserType | Må ikke være der | ||
Organisation | IdentifierFormat | Skal være CVR | ||
Identifier | Skal være der og skal være "niveau 3" whitelistet | |||
Name | Verificeres ikke - må gerne være der | |||
Client | Verificeres ikke - må gerne være der | |||
HSUID Header | Det verificeres, at HSUID headeren findes, og at den modellerer en borger | Brugertypen: Borger PersonIdentifier |
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
...