Page History
...
Dernæst vises det med et praktisk eksempel hentet fra DROS og Dokumentdelingsservicen, hvordan NSP Security API bliver anvendt i dokumentation og applikationskode til at implementere brugerautentificering og -autorisation.
...
- Hvilke brugertyper er til stede i min komponent?
- Hvordan skal disse brugertyper tjekkes/mappes i forhold til de forretningsregler, der gælder i min komponenkomponent?
Teknisk opsætning og anvendelse af NSP Security API
...
Når dokumentationen af de understøttede brugertyper er på plads, så skal
Eksempler på aktører. Denne liste er ikke udtømmende, og det er vigtigt at overveje, hvad der skal gælde i de enkelte komponenter.:
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
Eksemplerne nedenfor skal beriges med, hvad der IKKE må være tilstede (f.eks. for borger må der ikke være en organisation). Kig på de enkelte attributter i security api f.eks. som en tabel eller ligenden, så man kan se strukturen og de regler der gælder på de forskellige niveauer.
...
Borger (Citizen)
...
Myndig borger på egne vegne
ActingUser er udfyldt:
Sikkerhedsbillettens UserType skal være "Citizen"
Audience fra sikkerhedsbilletten skal kunne verificeres
Borger på vegne af anden borger
...
Borgeren skal have en af disse:
- fuldmagt
- forældremyndighed/værgemål
...
ActingUser er udfyldt:
Sikkerhedsbillettens UserType skal være "Citizen"
Audience fra sikkerhedsbilletten skal kunne verificeres
For fuldmagt, så er PrincipalUser også udfyldt, og der kan på ActingUser findes PowerOfAttorneyPrivileges (ligger på ActingUsers Credentials).
Listen bør gennemløbes, og der bør findes en veldefineret privilgiestreng.
For forældremyndighed og værgemål er PrinicipalUser IKKE til stede, men vil være givet i requestet. Der bør tjekkes (f.eks. via SDM services, at der er en passende forældre- eller værgerelation).
...
Sundhedsfaglig (HealthcareProfessional)
...
Autoriseret sundhedsfaglig
Sundhedsfaglig med national rolle
...
ActingUser er udfyldt:
Sikkerhedsbillettens UserType skal være "HealthcareProfessional"
...
Sundhedsfaglig på vegne af anden sundhedsfaglig
...
Administrativ bruger
...
Benyttes pt. kun i Minspærring
ActingUser er udfyldt:
Sikkerhedsbillettens UserType skal være "HealthcareProfessional"
RequiredNationalRole skal være udfyldt (og den må ikke være slået fra vha. TURN_NATIONAL_ROLE_OFF)
den konkrete mapning fra NSP Security APIs context til sin egen aktørmodel laves.
Komponenten skal modellere disse aktører på en eller anden måde så det giver mening. Dette kan f.eks laves ved hjælp af nedarvningshierarkier eller en simpel enumeration, der lister brugertyperne.
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
...
Systembruger
...
Tilgår servicen med et ID-kort niveau 3
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 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.
| Brugertype | Beskrivelse |
|---|---|
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:
- Kald med en borgerbillet
- Kald fra sundhed.dk med tilhørende HSUID header
Begge tilfælde kræver mapning og verifikation fra NSP Security API, men i tilfælde 2 skal der anvendes yderligere
| Anvendelse af NSP Security API til at genkende og verificere 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 | |||
Anvendelse af NSP Security API til at genkende og verificere 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
Eksemplerne nedenfor skal beriges med, hvad der IKKE må være tilstede (f.eks. for borger må der ikke være en organisation). Kig på de enkelte attributter i security api f.eks. som en tabel eller ligenden, så man kan se strukturen og de regler der gælder på de forskellige niveauer.