Indledning
Dokumenthistorik
Formål
Overblik
Snitflader
Komponenter
Webservice
Sikkerhed
Statuskomponent
Forretningslag
Databasedesign
Caching
Ikke funktionelle krav
Sikkerhed
SLA logning
Audit logning
Version | Dato | Ansvarlig | Beskrivelse |
1.1 | 12-12-2017 | Openminds | Ny borgerservice |
1.0 | 14-06-2017 | Openminds |
Dette dokument giver et overblik over MinLog2 applikationerne med fokus på design og arkitektur.
Dokumentet giver et overblik over løsningens snitflader samt den interne struktur. Desuden indeholder det en beskrivelse af håndtering af ikke funktionelle krav.
MinLog2 er delt i to applikationer, Registration og Lookup.
Registration tilbyder services til.
Lookup tilbyder services til.
Forretningsdata persisteres i en relationel database.
Lookup services findes i 2 sikkerhedsvarianter
Løsningen har en ekstern snitflade, der udstiller de ovenfor nævnte services som webservices.
Der er ikke afhængigheder til andre services, men til komponenter til håndtering af autentifikation (SEAL) og SLA logning (NSPUtils).
Udover MinLog2's egen database, er løsningen afhængig af stamdatamodulets databaser, til berigelse af logdata ved Lookup. Principperne for anvendelse af stamdata fra stamdatamodulet afviges dermed, idet der ikke anvendes enkeltopslags- services eller kopiregisterservices. Dette er dog accepteret i MinLog 2-sammenhæng.
Løsningen er designet som en JEE applikation bestående af følgende komponenter. Hvis der er ting der adskiller sig i de to applikationer, bliver det nævnt specifikt:
CXF webservice komponent, der udstiller de forretningsmæssige services. Denne komponent håndterer protokol og headers.
Sikkerheden er implementeret i 2 varianter DGWS og OIOIDWS.
IDCard læses fra SOAPHeader og sættes det på threadlocal. Kan kortet ikke læses, eller er signaturen ugyldig afvises brugeren.
I svaret tilføjes en WSSecurity header med et timestamp.
På vej ind gemmes Medcom header på Threadlocal. På vej ud tilføjes Medcom header baseret på den indkomne.
IDCard fra Threadlocal og autentificerer kalderen ved at kontrollere, at kortet er gyldigt og ikke udløbet.
Herefter autoriseres brugeren, idet det verificeres, at denne har det fornødne niveau (medarbejder eller virksomhed). Bemærk at der efter aftale ikke er gjort brug af whitelisting på det udstillede services.
Sikkerheden omkring signering, kryptering varetages af CXF på baggrund af WS-Policy implementeringen.
DigstSamlAssertionValidator er ansvarlig for at udlede nødvendige autoriseringer heriblandt Audience og udtræk af messageid og CPR/CVR til senere anvendelse. Dette gøres på threadlocal.
Autenficering af brugeren er foretages premature af STS. Bemærk at der efter aftale ikke er gjort brug af whitelisting på det udstillede services.
En simpel servlet, der returnerer ok (http kode 200), hvis systemet er tilgængeligt. Desuden er det muligt at få detaljer om, hvilke komponenter, der er i live eller fejler.
En servlet, der fortælle hvilken version af løsningen, der er den aktuelle.
Indeholder forretningslogikken.
En stateless ejb(controller) modtager kald fra webservicelaget og delegerer til andre klasser, der hver især håndterer hhv. validering, cashing, groupering samt håndtering af persistens.
For Lookup Indeholder domain, JPA klasser til persistering. I Registration er det POJO's.
Indeholder logikken til insert af data fra Registration samt forespørgsel fra Lookup.
Registration, gør udelukkende brug af JPA til at håndtere forbindelsen til databasen. Alt insert sker via standard preparedStatements. Dette er gjort med henblik på af holde JPA ude af domain pakken, da direkte insert i databasen, fra servicen, er en midlertidig løsning.
Lookup, bruger JPA dels til forbindelsen, men også mapning til domain. Dog er alle queries defineret som rå SQL, i koden, således at intet bliver autogeneret. Dette er gjort for at imødekomme tidligere erfaringer på platformen, om at autogeneret SQL fra JPA kan blive unødig kompleks og forringe performance.
Afhængigheder mellem komponenter.
Log events, består af to dele. En source og en destination. Destination indeholder alt information om logningen, mens source er kaldekæden gennem systemerne. Se Løsningsbeskrivelsen for nærmere beskrivelse. Disse gemmes i hver sin tabel. Database layout kan ses i filen "shared/shared-configuration/src/main/resources/sql/initial_schema.sql".
For at forhindre at der kan forekomme dublikater ved insert, laves der en SHA256 hash over en række værdier, af databasen.
I MinLog2-Lookup er der en feature der kan opdele logninger i en række forskellige grupper. Det er et krav at der er mulighed for at bruge paginering ved disse grupper. Det giver problemer da grupperne nødvendigvis skal dannes på baggrund af hele søge resultatet og ikke blot over en delmængde. Hvis det skulle være muligt er man nød til at søge hele resultatet frem hver gang der forespørges på en ny side.
For at imødekomme begge krav, er der anvendt caching(ehcache) i Lookup. Når data er blevet grupperet bliver det cached. Der anvendes en nøgle generet ud fra de forskellige parametere i forespørgselen.
Løsningen er sikret med IDCard, der enten kan repræsentere en person eller en myndighed. I tilfælde af Lookupid anvendes OIOIDWS.
Ved hver enkelt servicekald verificeres det, at kalderen har den fornødne rolle (myndighed eller medarbejder), og at det medfølgende IDCard overholder levetidskravet til det konkrete kald.
Autentifikationen håndteres af en soap handler, der – hvis autentifikationen er succesfuld – binder IDCard til en threadlocal.
Der logges med brug af NSPUtils biblioteket: Et filter opretter en log entitet, der senere beriges med messageID fra Medcom headeren.
SLAloggen gemmes i en tekstfil, og dens udseende kan konfigureres.
Ved alle kald registreres
Auditloggen gemmes i en tekstfil, og dens udseende kan konfigureres.