Edit profile

Page History

Versions Compared

Old Version 4

changes.mady.by.user Jan Riis

Saved on 23-07-2025

compared with

New Version Current

changes.mady.by.user Anni Markussen

Saved on 22-08-2025

Key

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

...

Navitabs

root	Din digitale tandlægevælger (DDTV) - Leverancebeskrivelse
includeroot	true

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:

Image Modified

Den aktive del af DDTV lever udelukkende i NSP backend, og alle oplysninger opbevares i én simpel database (DDTV DB, se 5. Udkast til ER-diagram på DDTV projektområdetmodel)

Der er i praksis er tale om 3 typer af services:

...

For yderligere indflyvning, sekvensdiagrammer, state-diagrammer mv. henvises til Din digitale tandlægevælger projektområdet.===== Ole tager over herfra :) =======Arkitektur og design.

Moduler og driftsarkitektur

De tre services er ret 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.

De fire tre services har tilsammen følgende moduler i maven:

Modulnavn	Beskrivelse
idsasddtv-apischemas	Dette modul definerer Selve API'en , for de tre eksterne services, defineres i dette modul som WSDL-filer. Modules 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.
idsasddtv-common	Fælles kode for de to moduler services, primært utility-funktioner og , bl.a. til logning, samt DAO-klasser.
idsasddtv-integration-tests	En modul som indeholder alle integrationstests for begge services.
idsas-integrations	Et modul som indeholder integrationer, pt. kun "personinformation". Anvendes af "idsas-services".
idsas-services	Forretningslogik til alle services findes i dette modul, samt forretningslogik til de to batchjobs i "idsas-operations-web".
idsas-lookup-web	Web-modulet til Opslag, som håndterer opstart af service og producerer den war-fil, der skal deployes.
idsas-registration-web	Web-modulet til Slørring, som håndterer opstart af service og producerer den war-fil, der skal deployes.
idsas-salt-web	Web-modulet til hentning af salt, som håndterer opstart af service og producerer den war-fil, der skal deployes.
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-service	Modul, som implementerer den borgervendte OIO-IDWS webservice.
ddtv-dentist-service	Modul, som implementerer den DGWS webservicen til brug for tandlæger.
ddtv-batch-service	Modul, som implementerer de 5 batchjobs nævnt ovenfor.
ddtv-integrationtest	Modul som indeholder integrationstests for de services, der kan kaldes eksternt	idsas-operations-web	Web-modulet med endpoints til automatiske jobs: Fornyelse af salt, sletning af inaktive sløringer.

Driftsarkitektur

I praksis er de forskellige alle services fordelt på BackOffice og en eller flere Frontend-miljøer. Registration, Lookup og Salt kører alle på et NSP Frontend-miljø, og via en Kafka-kø, bliver alle ændringer sendt igennem MirrorMaker til Operations-servicen på NSP BackOffice. Det er her installeret i BackOffice. Det er også her at alle ændringer bliver persisteret til databasen.

Dog vil der i en overgangsperiode også være en Registration-service kørende på NSP BackOffice, som skriver direkte til databasen, når den bliver kaldt. Dette er for er være bagudkompatibel med de anvendere, som tog IDSAS i brug, før der blev omlagt til at sende alle ændringer igennem en Kafka-kø.

...

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: HealthcareProfessionalBorger			Verifikation	Mapning til IdsasActorDdtvActor
SecurityContext	Ticket	AudienceVerificeres ikke - må gerne være der	Skal matche audience for IDWS servicen, defineret i property ddtv.audience i application.properties
		Validity	Er valid
	Message		Verificeres ikke - må gerne være der
	ActingUser	UserType	Skal være HealthcareProfessionalCitizen	actorType
		IdentifierFormatIdentifier	Skal være CPRder	actorIdType
		IdentifierIdentifierFormat	Skal være satder	actorId
		GivenName	Verificeres ikke - må gerne være der
		SurName	Verificeres ikke - må gerne være der
		Credentials	Verificeres ikke - må gerne være der
	PrincipalUser		Identifier	Hvis angivet, skal der være givet fuldmagt (PowerOfAttorneyPrivileges)	procurationGiverId
	Organisation	Identifier	Må ikke være der
		IdentifierFormat	Må ikke være der
	Client		Verificeres ikke - må gerne være der

Brugertypen: System

Verifikation

Mapning til IdsasActorDdtvActor

SecurityContext

Ticket

Audience

Verificeres ikke - må gerne være der

Validity

Er valid

Message

Verificeres ikke - må gerne være der

ActingUser

Må ikke være der

PrincipalUser

Må ikke være der

Organisation

Identifier

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

IdentifierFormat

Skal være der

actorIdType

IdentifierFormat

Skal være der og skal være CVR

actorIdType

Client

name

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.

clientSystemName

persistentUniqueKey

Skal 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.

Content

Space Tools