Page History

...

Løsningen er designet som en web applikation opdelt i 4 jeefølgende struktur jee bestående af henholdsvis lookup og registration applikationerne, consumer, producer og shared.  

├── jee
│   ├── lookup
│   │   ├── lookup-core
│   │   ├── lookup-ear
│   │   ├── lookup-idws
│   │   ├── lookup-minlog1-ws
│   │   └── lookup-ws
│   ├── registration
│   │   ├── registration-core
│   │   ├── registration-earwar
│   │   ├── registration-minlog1-ws
│   │   └── registration-ws
├── shared
│   ├── shared-configuration
│   ├── shared-db
│   ├── shared-domain-api
│   ├── shared-test
│   ├── shared-test-idws
│   └── shared-ws
├── Consumer      
└── Producer

...

Er opdelt i lookup og registration. . Navnet JEE antyder, at der er tale om en JEE baseret applikation. MinLog er lavet som en web applikation - ikke jee - navnet er bibeholdt af historiske årsager.

Som det fremgår er der flere webservices i modulerne lookup og regstration - de deler deres kode i xxxx-core. Modulerne med postfix "-ws" indeholder selve implementeringen af webservicens operationer. Ear modulerne Modulerne registration-war og lookup-ear er udelukkende holdere af deployment information samt initialiseringskode til applikationerne.

Consumer

Consumer modulet lytter på et kafka topic efter entries til MinLog2 og ved modtagelse indsættes de i databasen. Koden har taget udgangspunkt i Den Gode Brug af Kafka og følger dennes retningslinier. 

...

dk.nsi.minlog2.registration.webservice.RegisterServiceImpl implements RegisterservicePort
dk.nsi.minlog2.registration.webservice.RegisterServiceImpl implements Service (Minlog1)
dk.nsi.minlog2.lookupid.LookupidImpl implements LookupidServicePortType
dk.nsi.minlog2.lookup.webservice.LookupServiceImpl implements LookupServicePort 
dk.nsi.minlog2.lookup.webservice.LookupServiceImpl implements Minlog (Minlog1)

Funktionalitet udover SOAP protokol håndteringen er lavet som Handlers/Interceptor - feks special håndtering af headers, sla-logning, audit-logning mm. I forbindelse med deployment skal man være opmærksom på at subsystemerne i Jboss Wildfly til logning og webservices er slået fra - for at opnår den fulde kontrol over stakken. 

...

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 varetages af indgående og udgående CXF interceptorer.

Den indgående interceptor foretager:

• Validering af signaturer
• Validering af korrekt Audience
• Validering af eventuel Samtykke
• Udtræk af messageid og CPR/CVR til senere anvendelse

Data gemmes på threadlocal.

Den udgående interceptor foretager:

• Signering

Autentifikation og autorisation

.

I begge tilfælde anvendes det af platformen tilbudte Security API til at tjekke indkommende credentials og restriktioner i forhold til medsendte oplysninger i sikkerhedsbilletter.

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

Vær opmærksom på at whitelisting heller ikke er implementeret for MinLog1.

...

Sikkerhed

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 kalddet af platfomen udbudte Security API.

SLA logning

Der logges med brug af NSPUtils biblioteket: Et filter opretter en log entitet, der senere beriges med messageID fra Medcom headeren. Logning foretages gennem NSP-Util og følger retningslinier herfor.

...