Page History
...
| Navitabs | ||||
|---|---|---|---|---|
| ||||
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
===== Ole tager over herfra :) =======
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 modulerservices, 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. |
| idsas-operations-web | Web-modulet med endpoints til automatiske jobs: Fornyelse af salt, sletning af inaktive sløringer. |
...
| integrations | Modul som indeholder integrationer:
|
| 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. |
Driftsarkitektur
I praksis er de forskellige 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 alle services 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ø.
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
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.
| 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 | Må ikke være derIdentifier | Hvis angivet, skal der være givet fuldmagt (PowerOfAttorneyPrivileges) | procurationGiverId | ||
| Organisation | Identifier | SkalMå ikke være der | |||
| IdentifierFormat | SkalMå ikke være der | og skal være CVR||||
| 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 | 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). | 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 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.
. 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 |
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 kan kun anvendes af 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.