Versions Compared

Key

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

...

Navitabs
rootDin digitale tandlægevælger (DDTV) - Leverancebeskrivelse
includeroottrue



Indhold

Table of Contents

Introduktion

Formål

Formålet med dette dokument er at beskrive systemarkitekturen for DDTV.

Læsevejledning

Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i DDTV og dens opbygning.

Overblik over DDTV

Løsningens afhængigheder

DDTV anvender NSP libraries:

...

Øvrige afhængigheder:

  • EDI Portal API

Løsningens overordnede opbygning

Nedenstående diagram viser opbygningen af DDTV services: 

...

For yderligere indflyvning, sekvensdiagrammer, state-diagrammer mv. henvises til Arkitektur og design.

Moduler og driftsarkitektur

De tre services er forholdsvis ens opbygget, og har en del fælles kode som de deles om via et maven-modul, har samme programstruktur og bruger samme database-modul.

...

ModulnavnBeskrivelse
ddtv-schemas   Dette modul definerer API'en for de to services, der kan kaldes ekternt, hhv. en OIO-IDWS WSDL fil for den borgervendte service DDTV-citizen, samt en DGWS WSDL fil for DDTV-dentist-servicen. Modulets primære formål er at generere Java-kode ud fra WSDL'erne, som kan bruges i de andre moduler.
ddtv-common

Fælles kode for de services, primært utility-funktioner, bl.a. til logning, samt DAO-klasser.

ddtv-integrations

Modul som indeholder integrationer:

  • PersonInformation til CPR-opslag
  • SORES til opslag af tandlæger i SOR
  • DigitalPost til afsendelse af digital post til borgere
  • EDIMessage til afsendelse af EDI beskeder til tandlæger
ddtv-citizen-serviceModul, som implementerer den borgervendte OIO-IDWS webservice.
ddtv-dentist-serviceModul, som implementerer den DGWS webservicen til brug for tandlæger.
ddtv-batch-serviceModul, som implementerer de 5 batchjobs nævnt ovenfor.
ddtv-integrationtestModul som indeholder integrationstests for de services, der kan kaldes eksternt.

Driftsarkitektur

I praksis er de alle services installeret i BackOffice. Det er også her at alle ændringer bliver persisteret til databasen.

Sikkerhed

Brugertyper

De enkelte brugertyper bestemmes ud fra modellen, der udstilles i Security API. Disse regler er opsummeret i skemaerne herunder. Sikkerhedsmodellen tager udgangspunkt i Security API - Guide til anvendere.

I kolonnen "Mapning til IdsasActorDdtvActor" kan man se, hvordan værdierne bliver gemt i selve IdsasActorDdtvActor-klassen i Java-koden. 

Må ikke være derSkal Skal og skal være CVR
Brugertypen: BorgerVerifikationMapning til IdsasActorDdtvActor
SecurityContextTicketAudienceVerificeres ikke - må gerne være derSkal matche audience for IDWS servicen, defineret i property ddtv.audience i application.properties  


ValidityEr valid

Message
Verificeres ikke - må gerne være der

ActingUserUserTypeSkal være HealthcareProfessionalCitizenactorType


IdentifierFormatIdentifierSkal være CPRderactorIdType


IdentifierIdentifierFormatSkal være satderactorId


GivenNameVerificeres ikke - må gerne være der


SurNameVerificeres ikke - må gerne være der


CredentialsVerificeres ikke - må gerne være der

PrincipalUserIdentifierHvis angivet, skal der være givet fuldmagt (PowerOfAttorneyPrivileges)
procurationGiverId

OrganisationIdentifierMå ikke være der


IdentifierFormatMå ikke være der

Client
Verificeres ikke - må gerne være der
Brugertypen: SystemVerifikationMapning til IdsasActorDdtvActor
SecurityContextTicketAudienceVerificeres ikke - må gerne være der 


ValidityEr valid

Message
Verificeres ikke - må gerne være der

ActingUser
Må ikke være der

PrincipalUser
Må ikke være der

OrganisationIdentifier

Skal være der

actorId

.

Hvis der i property'en whitelisted.cvrs i application.properties er angivet en ikke-tom kommasepareret liste af cvr-numre skal actorId kunne findes i listen.

actorId


IdentifierFormatSkal være deractorIdTypeIdentifierFormatSkal være der og skal være CVRactorIdTypeClientname

Skal være der ved kald til GetBlurredOrganisations, og må også gerne være der ellers (men verificeres ikke).
Bruges aktuelt til at tjekke at det er STS'en der kalder, og ingen andre.

clientSystemNamepersistentUniqueKeySkal være der ved kald til GetCurrentSalt, og må også gerne være der ellers (men verificeres ikke)
Bruges til whitelisting af de anvendersystemer der skal hente salt til pseudoanonymisering.
clientKey

Beslutninger

På NSP har man flere brugertyper, herunder følgende, som er relevante for DDTV:

  • Citizen er en borger
  • System er en systembruger

Servicen DDTV-Citizen skelner man imellem brugertyperne HealthcareProfessional (sundhedsfaglig person) og Citizen (borger). IDSAS kan kun anvendes af HealthcareProfessional. Alle HealthcareProfessional har adgang til at kalde IDSAS, uanset om de har en gyldig autorisation eller ej.Citizen med OIOIDWS-kald. En borger kan selv anvende servicen, eller den kan anvendes af en fuldmagtshaver.

Servicen DDTV-Dentist kan kun anvendes af System, dvs. der kaldes med DGWS systemkald.Som det ses i skemaet under sikkerhed, skelnes der i praksis på, om der er tale om en systembruger eller ej. Ved systembrugere må der ikke angives en ActingUser, og derfor heller ingen UserType. Kaldende til getCurrentSalt (pt. kun fra MinLog) og lookup (kun STS) må kun være systembrugerkald.