Page History
...
Beslutning angående konfiguration
The service configuration is performed in two (three for the administration service) different properties files that must be deployed on the Web server somewhere in the application’s classpath.
Servicekonfigurationen udføres i to (tre for MinSpærring Administration) forskellige property filer, der leveres som en del af docker setup.
Changes in the configuration should prompt a reboot of the service, as the configuration is loaded and verified on start-up of the individual services.
Ændringer i konfigurationen skal medføre en genstart af den container som servicen den kører i da konfiguration indlæses ved opstart.
...
Placeringen af denne fil findes i applikationskonfigurationen.
Log konfiguration
In the log configuration file, error and debug log configuration is provided by stating a log4j-logger property with the name log4j.logger.dk.nsi.
I logkonfigurationsfilen leveres konfiguration af error og debug I logkonfigurationsfilen leveres konfiguration af error og debug ved at angive en log4j-logger property med navnet log4j.logger.dk.nsi.
Database konfiguration
...
Begge MinSpærring services skal forsynes med en datasource med navnet 'ConsentServiceDS', der har adgang til den database der er beskrevet i MinSpærring - Data Model.
Both services must have access to a data source with the name ’WhitelistDS’ that is used by whitelist validation of calling systems.
Begge tjenester skal have adgang til en Begge tjenester skal have adgang til en datasource med navnet 'WhitelistDS', der bruges af whitelist af anvendersystemer.
...
Beslutninger angående Web
...
Services
De to MinSpærring services er udviklet med en ”Java-first”
...
tilgang,
...
hvor Java-koden er udviklet uafhængigt, og WSDL genereres på tidspunktet for kørsel på webserveren på basis af den implementerede kode.
Java-first-metoden blev valgt for at lette udvikling og vedligeholdelse af tjenesten, da dette gør det muligt at udnytte eksisterende Java-kompetencer. Muligheden for at tilpasse den udsatte WSDL ofres.
Indhold af Web Service kald
Web Service operationerne består af: en Medcom-header, en sikkerheds-header, en HSUID-header MinSpærring - Healthcare Service User Identification Header Interface Description og et body-element.
I MinSpærring Administraition bruges indholdet af HSUID-headeren til at autentificere og validere autorisationen for den kalende bruger ud over at validere, at brugeren har lov til at kalde metoden med de inkluderede parametre i body elementet.
Desuden bruges det 'fungerende bruger'-felt i HSUID-headeren til at indstille felterne' oprettet af' og' modificeret af' på en spærring/samtykke samt for at vurdere om det skal logges at en registrering er oprettet/rettet af en anden borger end den registreringen berører.
Ved MinSpærring Verifikation er kun gyldigheden af HSUID-headeren valideret.
Medcom-headeren bruges til at validere sikkerhedsniveauet og signaturen.
Security Headeren bruges til at validere, om den vedhæftede signatur og STS-sikkerhedstoken er gyldig, jf. den konfiguration, der er brugt til at konfigurere tjenesten.
Alle andre parametre for kald til servicen er indeholdt i SOAP body elementetm for hvilket indhold varierer med hensyn til den enkelte operation (se MinSpærring - Administration Service Interface Description og MinSpærring - Verifikation Service Interface Beskrivelse).
Beslutninger vedrørende service arkitektur
Hver service implementeres som en stateless Java EE-sessionbønne, der implementerer en grænseflade, der definerer de metoder, servucen udstiller. Både implementeringen af bønne og webservicen håndteres via Java EE-kommentarer.
Ved at implementere tjenesten som en Java EE-bønne er det muligt for applikationsserveren at håndtere datasource injection, transaktioner og systemressourcer i stedet for at håndtere dette manuelt i koden.
Hvert aspekt af overholdelse af DGWS, IDWS, sikkerhedshåndtering og logning håndteres af Java EE-interceptorer, der automatisk kaldes af den omgivende EJB-container.
Beslutninger vedrørende data sources
MinSpærring databasen implementeres gennem Hibernate, hvilket gør det muligt at afkoble databashåndteringen fra koden. Datasource til MinSpærring håndteres gennem injektion fra EJB-containeren i applikationsserveren.
DataSournce til whitelisting (der bruges til at kontrollere, om anvendersystemer har adgang til tjenesten), håndteres af et kontekstopslag i koden og injiceres således ikke fra EJB-containeren.
Årsagen til dette er, at whitelist ikke håndteres direkte af bønnen, men af en interceptor, der kan konfigureres uafhængigt af bønneimplementeringen. Interceptoren leveres af et fælles kodemodul og bruges af flere tjenester for at sikre, at DGWS overholdes ud over validering af sikkerhed. For at undgå en afhængighed fra whitelist til bønnen finder datasource opslag sted i det delte modul.
Data Model
Datamodelen er dokumenteret i MinSpærring - Data Model.
Arkitektur
Dette afsnit beskriver både statiske og dynamiske aspekter af systemarkitekturen, herunder grundlaget for de individuelle designvalg.
Statisk struktur
Overblik
Den generelle servicestruktur er, at tjenesten implementeres som en statsløs sessionbønne, der implementerer en Web Service, der er en Java Web Service.
Denne bønne håndterer derefter servicelogikken, DAO'er og anden forretningslogik.
Sikkerhedsvalidering, logning og fejlhåndtering håndteres af et antal Java EE-interceptors.
Tjenesten kører på en applikationsserver, der er ansvarlig for generering af en Web Interface (og WSDL), styring af datasource injection og håndtering af systemressourcer.
Database håndtering
Databasekommunikationen håndteres af et antal DAO'er (en pr. Injiceret datasource), der indkapsler databasekommunikationen i et antal objektrelaterede metoder.
Whitelist håndteres ikke via en DAO. I stedet fremsætter hvidlisteimplementeringen en direkte forespørgsel til sin datakilde.
ConsentVerificationDAO
Håndteres af en EntityManager (defineret i persistence.xml-filen i applikationen) med navnet 'ConsentVerificationService', der injiceres gennem Java EE-kommentaren @PersistenceContext i bønnen.
Denne EntityManager gør brug af datasourcen 'ConsentServiceDS'.
DAO udstiller metoder, der svarer til de funktioner, som webservicen udstiller til anvendersystemer. De bruges af bønnen til at læse en borgers samtykker og spærringer.
ConsentAdministrationDAO
Håndteres af en EntityManager (defineret i persistence.xml-filen i applikationen) med navnet 'ConsentAdmin', der injiceres gennem Java EE-kommentaren @PersistenceContext i bønnen.
Denne EntityManager gør brug af datasourcen 'ConsentServiceDS'.
DAO udstiller metoder, der svarer til de funktioner, som webservicen udstiller til anvendersystemer. De bruges af bønnen til at vedligeholde en borgers samtykker og spærringer.
Databasefunktionerne implementeres ved hjælp af Hibernate
...
Contents of Web service call
The Web service operations consists of: a Medcom-header, a security-header, a HSUID-header [HSUID], and a body element.
In the consent administration, the contents of the HSUID-header is used to authenticate and validate the authorization of the calling user in addition to validate if the user is allowed to call the method with the included body parameters.
Furthermore, the ’acting user’-field in the HSUID-header is used to set the ’created by’ (’oprettet af’) and ’modified by’ (’modificeret af’) fields on consents in addition to assess if it must be logged that a consent has been created/changed by another citizen than the one the consent concerns.
In consent verification, only the validity of the HSUID-header is validated.
The Medcom-header is used to validate the security level and the signature.
The security header is used to validate whether the attached signature and STS security-token is valid, cf. the configuration that has been used to configure the service.
All other parameters for the method calls are contained in the attached body for which content varies in regard to the individual operation (see [Consent Administration Interface Description] and [Consent Verification Interface Description]).
Decision regarding service architecture
Each service is implemented as a Java EE stateless session bean that implements an interface that defines the methods the Web service exposes. Both the bean and the Web Service implementation is handled through Java EE annotations.
By implementing the service as a Java EE bean, it is made possible for the application server to handle data source injection, transactions, and system resources, rather than handling this manually in the code.
Every aspect of complying with DGWS, IDWS, security handling and logging is handled by Java EE interceptors that are automatically invoked by the surrounding EJB container.
Decision regarding data sources
The consent database handling is implemented through Hibernate, which makes it possible to detach the database handling from the code. The data source for the consent database is handled through injection from the EJB container in the application server.
The data source for the whitelist (that is used to verify whether calling systems has access to the service), is handled by a context-lookup in the code and thus is not injected from the EJB container.
The reason for doing so is that the whitelist is not handled directly by the bean, but by an interceptor that can be configured independently of the bean implementation. The interceptor is provided by a common code module and is used by multiple services to ensure that DGWS is obeyed in addition to validation of security. To avoid a dependency from the whitelist to the bean, the data source lookup takes place in the shared module.
Data Model
The data model for consent service is documented in [Data Model].
Architecture Design
This section describes static as well as dynamic aspects of the system architecture, including the basis for the individual design choices.
Static Structure
Overview
The general service structure is that the service is implemented as a stateless session bean that implements a Web interface that is a Java Web service.
This bean then handles the service logic, DAOs and other business logic.
Security validation, logging and error handling is handled by a number of Java EE interceptors.
The service is deployed on an application server that is responsible for generation of a Web interface (and WSDL), managing data source injection and handling of system resources.
Database handling
The database communication is handled by a number of DAOs (one per injected data source) that encapsulates the database communication in a number of object related methods.
The whitelist is not handled through a DAO. Instead, the whitelist implementation makes a direct request to its data source.
ConsentVerificationDAO
Is handled by an entity manager (defined in the persistence.xml-file in the application) named ’ConsentVerificationService’ that is injected through the Java EE annotation @PersistenceContext in the bean.
This entity manager make use of the data source ’ConsentServiceDS’.
The DAO exposes methods that correspond to the functions that the Web service expose to calling systems. It is used by the bean to obtain a citizen’s consents.
ConsentAdministrationDAO
Is handled by an entity manager (defined in the persistence.xml-file in the application) named ’ConsentAdmin’ that is injected through the Java EE annotation @PersistenceContext in the bean.
This entity manager make use of the data source ’ConsentServiceDS’.
The DAO exposes methods that correspond to the functions that the Web service expose for calling systems. It is used by the bean to modify the citizen’s consents.
The database operations are implemented by means of the Hibernate framework.
Interceptors
A number of interceptors are used in the implementation of the specific service for performing SLA-logging, error handling and security validation. These interceptors make use of the interceptor-pattern and prevents the EJB container from calling the specific service implementation directly, as the call hits a proxy that calls the annotated interceptors sequentially.
...