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 DGWS, IDWS. Derudover skal NSP Security API gøre det muligt at understøtte sikkerhedsprotokoller i fremtiden.

Dette skal gøres på en måde, så de anvendende services/komponenter tilbydes de nødvendige abstraktioner/termer og passende mapning fra de konkrete sikkerhedsprotokoller til en model, der gør det muligt at tilgå forskellige elementer i den indkommende sikkerhedsbillet.

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å NSP Security API opererer på et lavere niveau, hvor denne mapning giver mening.

NSP Security API design overblik

Modellen i NSP Security API

Overordnet princip: Udtrykker kun den information, som findes i sikkerhedsbilletten - og ikke andet.

Stiller informationen til rådighed for komponenten gennnem SecurityContext hvorfra, der er adgang til alle information bl.a. ActingUser (den bruger, der trykker på knapperne), PrincipalUser (den bruger, der er ansvarlig for handlingen), Organisation, Message og Ticket.

Modellen er mere generel end de nuværende sikkerhedsprotokoller og udfaldrummet for de aktuelle sikkerhedsbilletter giver anledning til. TODO Menes der at modellen er mere generel end de udfaldsrum de nuværende sikkerhedsprotokoller- og billetter giver anledning til, og er derfor godt rystet på til at håndtere fremtidige protokoller?

F.eks. findes der i praksis i dag ikke en 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).

Modellen for den kaldende brugeres sikkerhedsmæssige egenskaber stilles til rådighed for den anvendende komponent gennem en statisk metode på en eneste klasse:

dk.sds.nsp.security.SecurityContext dk.sds.nsp.security.Security.getSecurityContext()

Retursvaret er den model, som NSP Security API udbyder. Nedenstående tabel er en oversigt over egenskaberne for denne model:

TicketAudience

Begrænsning i forhold til, hvor den givne sikkerhedsbillet kan anvendes

Validity

Er sikkerhedsbilletten gyldig (udsteder, gyldighedsperiode o.s.v)?
MessageIdentifier

Identifier på beskeden (web service kaldet)

ConversationIdentifier

Identifier på "samtalen" mellem anvender og komponent. Flere beskeder kan således grupperes til en samlet interaktion.

Action

Den action, som ønskes udført på den modtagende service
ActingUserUserType
Udfaldsrum: HealthcareProfessional, CitizenDen udførende brugers (d.v.s den bruger, der udfører af kaldet) brugertype

IdentifierFormat
Udfaldsrum: CPRUdførende brugers identifikator type

Identifier

Udførende brugers identifikator - i praksis et CPR nummer

GivenName

Udførende brugers fornavn

SurName

Udførende brugers efternavn

CredentialsAuthorizationCode
Er udfyldt, hvis den udførende bruger er en sundhedsfaglige bruger med et autorisations-id. Autorisations-id er et unikt alment tilgængeligt id, er udstedes til alle autoriserede sundhedsfaglige i Danmark. Se f.eks. Autorisation.


EducationCode
Er udfyldt, hvis den udførende bruger er en sundhedsfaglige bruger, der tilhører en specifik faggruppe. F.eks. angiver uddannelseskoden '7170', at brugeren er 'læge'. Se f.eks. Autorisation for en liste over uddannelseskoder.


NationalRole
Er udfyldt, hvis den udførende bruger er i besiddelse af en national rolle opsat i Sundhedsdatastyrelsens Elektoniske Brugerstyring (SEB). Se Stamdataregister: SEB. Udfyldelse af NationalRole og UnverifiedRole er i praksis gensidigt udelukkende.


UnverifiedRole
Udførende brugers rolle (er ikke verificeret af den udstedende part - i praksis SOSI STS). I praksis er disse roller "lokale" roller dvs. roller, der ikke er nationale roller (se ovenfor). Udfyldelse af NationalRole og UnverifiedRole er i praksis gensidigt udelukkende.


PowerOfAttorneyPrivileges

Er udfyldt, hvis den udførende bruger er en borger og hvis der findes en anden borger som Principal User i sikkerhedsmodllen. Hvis dette er tilfældet så udtrykker denne liste "udførende brugers fuldmagtsstrenge i forhold til den ansvarlige bruger". De konkrete fuldmagtsstrenge vedligeholdes hos Digitaliseringsstyrelsen.

Borgere kan vedligeholde deres fuldmagtstildelinger via portalen http://borger.dk.


PersistentUniqueKey

TODO: Udførende brugers autentifikations unikke nøgle
PrincipalUserUserType
Udfaldsrum: HealthcareProfessional, CitizenDen ansvarlige brugers (d.v.s den bruger, kaldet foretages "på vegne af") brugertype

IdentifierFormat
Udfaldsrum: CPRAnsvarlige brugers identifikator type. Se tilsvarende beskrivelse for ActiveUser.

Identifier

Ansvarlige brugers identifikator. Se tilsvarende beskrivelse for ActiveUser.

GivenName

Ansvarlige brugers fornavn. Se tilsvarende beskrivelse for ActiveUser.

SurName

Ansvarlige brugers efternavn. Se tilsvarende beskrivelse for ActiveUser.

CredentialsAuthorizationCode
Ansvarlige brugers legitimationsoplysninger. Se tilsvarende beskrivelse for ActiveUser.


EducataionCode
Ansvarlige brugers uddannelseskode. Se tilsvarende beskrivelse for ActiveUser.


NationalRole
Ansvarlige brugers nationale rolle. Se tilsvarende beskrivelse for ActiveUser.


UnverifiedRole
Ansvarlige brugers rolle. Se tilsvarende beskrivelse for ActiveUser.


PowerOfAttorneyPrivileges
Ansvarlige brugers fuldmagtsstrenge. Findes ikke på PrincipalUser men udelukkende på ActiveUser, da fuldmagt udtrykker ActiveUsers privilegier i relation til PrincipalUser.

PersistentUniqueKey

TODO Ansvarlige brugers autentifikations unikke nøgle
OrganisationIdentifierFormat
Udfaldsrum: CVRDen udførende brugers organisations identifikator type - i praksis et CVR nummer.

Identifier

Den udførende brugers organisations identifikator - i praksis et CVR nummer.

Name

Den udførende brugers organisations navn
ClientName

Den udførende klients navn (kaldende systems navn)

PersistentUniqueKey

TODO

TODO: eksempel hvor vi har en DGWS billet og en IDWS billet og kan se hvilken model de så giver anledning til.

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.

Dette betyder dog, at det kan være ligeså vigtigt, at en komponent validerer både attributter der findes, og dem der ikke findes, for at mappe korrekt til de relevante aktører.

F.eks kan eksemplet fra før, hvor en sundhedsfaglig, der handler på vegne af en anden sundhedsfaglig, udtrykkes i Security API, men der findes ikke (i dag) en sikkerhedsbillet, der kan bære denne information.

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:

  • HSUID Header: Mulighed for at udtrykke på vegne af mellem sundhedspersoner
  • Særlige 'admin' URL'er: Mulighed for at kalde som en særlig kraftig brugertype
  • Request parametre: Input parametre, som er en del af komponentens servicesnitflade

I aktørmodellen må komponenten gerne tage disse oplysninger med i aktørmodelleringen.

Det skal dog være tydeligt i dokumentationen og mapningen for den enkelte komponent, 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 en ekstra kontekst).

  • No labels