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 er en forenkling, da der i praksis er tale om to services:

idsas: Den primære service som håndterer "Slørring". Her findes operationerne "CreateBlurring" og "GetCurrentSalt".
idsas-lookup: En service der kun håndterer "Opslag", dvs. operationen "GetBlurredOrganisations".

De to services ret ens opbygget, har en del fælles kode som de deler om via et maven-modul, har samme programstruktur og bruger samme database.

De to integrationer, "personinformation" og "SORES" bruges kun i den første service, "idsas".

Selve løsningen består af følgende moduler i maven:

Modulnavn	Beskrivelse
idsas-api	Selve API'en, for begge 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 de to integrationer til "personinformation" og "SORES". Anvendes af "idsas-service".
idsas-lookup-web	Web-modulet til Opslag, som håndterer opstart af service og producerer den war-fil, der skal deployes.
idsas-services	Forretningslogik til alle services findes i dette modul, samt forretningslogik til de to batchjobs i "idsas-operations-web".
idsas-web	Web-modulet til "Slørring", 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.

Sikkerhed

Brugertyper

Der findes følgende brugertyper i IDSAS:

Sundhedsfaglig
System

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

Brugertypen: Sundhedsfaglig			Verifikation	Mapning til IDSAS ServiceActor
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	Brugertypen: Sundhedsfaglig
		IdentifierFormat	Skal være CPR
		Identifier	Skal være sat
		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	organisationIdentifier
		IdentifierFormat	Skal være der og skal være CVR
	Client		Verificeres ikke - må gerne være der

Brugertypen: System			Verifikation	Mapning til IDSAS ServiceActor
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	Brugertypen: System
	PrincipalUser		Må ikke være der
	Organisation	Identifier	Skal være der	organisationIdentifier
		IdentifierFormat	Skal være der og skal være CVR
	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
		getPersistentUniqueKey	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