Indhold
Introduktion
Formål
Formålet med dette dokument er at beskrive systemarkitekturen for IDSAS.
Læsevejledning
Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i IDSAS og dens opbygning.
Overblik over IDSAS
Løsningens afhængigheder
IDSAS anvender NSP libraries:
- audit-api
- security-api
Løsningens opbygning
Nedenstående diagram viser opbygningen af IDSAS som service. Diagrammet viser "registration" som eksempel, men "lookup" og "salt" er bygget op efter samme model, dog uden integration til "personinformation" eller "SORES".
Der er i praksis er tale om fire services:
- idsas-registration: Den primære service som håndterer "Slørring". Her findes operationen "CreateBlurring". Under udvikling: Herinde finder man også det kommende "afdelingssløring".
- idsas-lookup: En service der kun håndterer "Opslag", dvs. operationen "GetBlurredOrganisations".
- idsas-salt: En service der håndterer hentning af salt, dvs. operationen "GetCurrentSalt".
- idsas-operations: En service der kun benyttes af driften til automatiske jobs.
De fire services er ret ens opbygget, har en del fælles kode som de deles om via et maven-modul, har samme programstruktur og bruger samme database.
De fire services har tilsammen følgende moduler i maven:
| Modulnavn | Beskrivelse |
|---|---|
| idsas-api | Selve API'en, for de tre eksterne services, defineres i dette modul som WSDL-filer. Modules primære formål er at generere Java-kode ud fra WSDL'erne, som kan bruges i de andre moduler. |
| idsas-common | Fælles kode for de to moduler, primært utility-funktioner og DAO-klasser. |
| idsas-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. |
Driftsarkitektur (TODO)
Denne del er under udvikling
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 IdsasActor" kan man se, hvordan værdierne bliver gemt i selve IdsasActor-klassen i Java-koden.
| Brugertypen: HealthcareProfessional | Verifikation | Mapning til IdsasActor | ||
| SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | UserType | Skal være HealthcareProfessional | actorType | |
| IdentifierFormat | Skal være CPR | actorIdType | ||
| Identifier | Skal være sat | 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 der | |||
| Organisation | Identifier | Skal være der | ||
| IdentifierFormat | Skal være der og skal være CVR | |||
| Client | Verificeres ikke - må gerne være der | |||
| Brugertypen: System | Verifikation | Mapning til IdsasActor | ||
| 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.
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.