Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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:

TicketAudience


Validity

MessageIdentifier


ConversationIdentifier


Action

ActingUserUserType
Udfaldsrum: HealthcareProfessional, Citizen

IdentifierFormat
Udfaldsrum: CPR

Identifier


GivenName


SurName


CredentialsAuthorizationCode


EducataionCode


NationalRole


UnverifiedRole


PowerOfAttorneyPrivileges

PersistentUniqueKey

PrincipalUserUserType
Udfaldsrum: HealthcareProfessional, Citizen

IdentifierFormat
Udfaldsrum: CPR

Identifier


GivenName


SurName


CredentialsAuthorizationCode


EducataionCode


NationalRole


UnverifiedRole


PowerOfAttorneyPrivileges

PersistentUniqueKey

OrganisationIdentifierFormat
Udfaldsrum: CVR

Identifier


Name

ClientName


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
Anvendelse af NSP Security API til at genkende og verificere brugertypen
Borger (borgerbillet)VerifikationMapning til DDS ServiceActor
SecurityContextTicketAudienceMatche audience som findes som konfiguration i Dokumentdelingsservice


ValidityEr valid

Message
Verificeres ikke - må gerne være der

ActingUserUserTypeSkal være CitizenBrugertypen: Borger


IdentifierFormatSkal være CPR


IdentifierSkal være satPersonIdentifier


GivenNameVerificeres ikke - må gerne være der


SurNameVerificeres ikke - må gerne være der


CredentialsVerificeres ikke - må gerne være der


PersistentUniqueKeyVerificeres 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

Brugertypen Borger (sundhed.dk)

VerifikationMapning til DDS ServiceActor
SecurityContextTicketAudienceVerificeres ikke - må gerne være der


ValidityEr valid

Message
Verificeres ikke - må gerne være der

ActingUserUserTypeMå ikke være der

PrincipalUserUserTypeMå ikke være der

OrganisationIdentifierFormatSkal være CVR


IdentifierSkal være der og skal være "niveau 3" whitelistet


NameVerificeres 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

...