Anchor
_Toc500925727 _Toc500925727

Minlog 2

Anchor
_Toc500925728 _Toc500925728

Design og arkitektur

Anchor
_Toc500925729 _Toc500925729

Indledning

Anchor
_Toc500925730 _Toc500925730

Dokumenthistorik

Anchor
_Toc500925731 _Toc500925731

Formål

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.

Anchor
_Toc500925732 _Toc500925732

Overblik

MinLog2 er delt i to applikationer, Registration og Lookup.

...

Lookup services findes i 2 sikkerhedsvarianter

1. DGWS
2. OIOIDWS

Anchor
_Toc500925733 _Toc500925733

Snitflader

Løsningen har en ekstern snitflade, der udstiller de ovenfor nævnte services som webservices.

...

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.

Anchor
_Toc500925734 _Toc500925734

Komponenter

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:

Anchor
_Toc379537356 _Toc379537356

Anchor
_Toc379810716 _Toc379810716

Anchor
_Toc500925735 _Toc500925735

Webservice

CXF webservice komponent, der udstiller de forretningsmæssige services. Denne komponent håndterer protokol og headers.

Anchor
_Toc500925736 _Toc500925736

Sikkerhed

Sikkerheden er implementeret i 2 varianter DGWS og OIOIDWS.

DGWS – Registration og Lookup

WSSecurity

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.

Medcom

På vej ind gemmes Medcom header på Threadlocal. På vej ud tilføjes Medcom header baseret på den indkomne.

Autentifikation og autorisation

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.

OIOIDWS – Lookupid

Sikkerheden omkring signering, kryptering varetages af CXF på baggrund af WS-Policy implementeringen.

WSSecurity

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.

Autentifikation og autorisation

Autenficering af brugeren er foretages premature af STS. Bemærk at der efter aftale ikke er gjort brug af whitelisting på det udstillede services.

Anchor
_Toc500925737 _Toc500925737

Statuskomponent

Anchor
_Toc368486171 _Toc368486171

Monitorering

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.

Versionsinfo

En servlet, der fortælle hvilken version af løsningen, der er den aktuelle.

Anchor
_Toc500925738 _Toc500925738

Forretningslag

Indeholder forretningslogikken.

Forretningslogik

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.

Anchor
_Toc368486167 _Toc368486167

Domain

For Lookup Indeholder domain, JPA klasser til persistering. I Registration er det POJO's.

Data Access

Indeholder logikken til insert af data fra Registration samt forespørgsel fra Lookup.

...

Afhængigheder mellem komponenter.

Anchor
_Toc500925739 _Toc500925739

Databasedesign

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

For at forhindre at der kan forekomme dublikater ved insert, laves der en SHA256 hash over en række værdier, af databasen.

Anchor
_Toc500925740 _Toc500925740

Caching

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.

Anchor
_Toc500925741 _Toc500925741

Ikke funktionelle krav

Anchor
_Toc500925742 _Toc500925742

Sikkerhed

Løsningen er sikret med IDCard, der enten kan repræsentere en person eller en myndighed. I tilfælde af Lookupid anvendes OIOIDWS.

...

Autentifikationen håndteres af en soap handler, der – hvis autentifikationen er succesfuld – binder IDCard til en threadlocal.

Anchor
_Toc500925743 _Toc500925743

SLA logning

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.

Anchor
_Toc500925744 _Toc500925744

Audit logning

Ved alle kald registreres

...