Page History
...
Property | Beskrivelse |
dros.url.prefix | URL prefix der indsættes i wsdl'er og bruges af dks-servlet. |
dros.app.name | Anvendes af dks-servlet |
iti41.service.endpoint | Endpoint på ITI41-backend. |
iti41.service.security.require.person | Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false) Default: false |
iti41.service.xds.validationlevel | Angiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier. |
iti42.service.endpoint | Endpoint på ITI42-backend. |
iti42.service.security.require.person | Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false) Default: false |
iti42.service.xds.validationlevel | Angiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier. |
iti57.service.endpoint | Endpoint på ITI57-backend. |
iti57.service.security.require.person | Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false) Default: false |
iti57.service.xds.validationlevel | Angiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier. |
iti61.service.endpoint | Endpoint på ITI61-backend. |
iti61.service.security.require.person | Angiver, om der skal anvendes personlige sikkerhedsbillet i.e UserIdCard eller det er nok med SystemIdCard (true/false) Default: false |
iti61.service.xds.validationlevel | Angiver hvordan requestet valideres inden der kaldes videre til det bagvedliggende registry. Skal have en af værdierne OFF, WARNING, LOG og REJECT. Se dokumentet 'Design og Arkitektur' for en beskrivelse af disse værdier. |
dros.backend.failure.threshold | Tærskel for, hvor mange gang i træk et kald til en backend må fejle, før denne backend betragtes som 'død' af status-siden. |
dros.backend.failure.interval.minutes | Angiver antal minutter hvorefter fejlkald 'forældes'. Dermed er det kun fejlkald, der er nyere end dette, der medregnes, når det vurderes om backenden fejler. |
cprexists.validationlevel | Valideringsniveau for CPR validering Eksempel: WARNING, REJECT, OFF |
cprexists.url | URL for CPR exist service Eksempel: http://test1-cnsp.ekstern-test.nspop.dk:8080/stamdata-cprexists |
cprexists.maxTotalConnections | Konfiguration af client pool til kald af CPRExists service Default: 200 |
cprexists.defaultMaxConnectionsPerRoute | Konfiguration af client pool til kald af CPRExists service Default: 20 |
handled.type.codes | Angiver en liste af, hvilke type codes DROS håndterer. Er listen tom (property findes, men ingen værdi efter =) accepteres alle type codes. Eksempel på liste: 39289-4,39290-2,53576-5,52460-3,81215-6 Default: tom liste |
log4j konfiguration
Log4j konfiguration findes i samme wildfly modul som servicekonfigurationen
...
- HTTP 200, hvis servicen i øjeblikket kører fint.
- HTTP 203, hvis der er opstået en fejl der kræver indgriben.
- HTTP 500, hvis der er opstået en fejl der kræver indgriben.
Overvågningstyper
Det overvåges for hver backend, om kaldene til backenden går galt. Det kan konfigureres, hvor mange kald i træk der må gå galt, før en backend betragtes som 'død'.
...
ITI41 backend : "0/50 fejl" ITI42 backend : "0/50 fejl" ITI57 backend : "0/50 fejl" ITI61 backend : "0/50 fejl" CprExistsServiceClient : "0/50 fejl"
Whitelisting Database : "ok"
Det fremgår for hver backend, om kaldene til den går godt eller ej.
...
ITI41 backend : "0/50 fejl" ITI42 backend : "0/50 fejl" ITI57 backend : "0/50 fejl" ITI61 backend : "0/50 fejl" CprExistsServiceClient : "55/50 fejl"
Whitelisting Database : "ok"
Hvis kaldene til cprexists backend ikke kan udføres, så returneres statuskode 203 (indenfor failure threshold, som kan sættes op som en konfigurationsparameter).
...
ITI41 backend : "0/50 fejl" ITI42 backend : "0/50 fejl" ITI57 backend : "55/50 fejl" ITI61 backend : "0/50 fejl" CprExistsServiceClient : "0/50 fejl"
Whitelisting Database : "ok"
Hvis kaldene til een af ITI backends ikke kan udføres, så returneres statuskode 500 (indenfor failure threshold, som kan sættes op som en konfigurationsparameter).
Det samme gælder, hvis der ikke kan oprettes forbindelse til databasen (ingen failure threshold).
Auditlogning
Hvert servicekald medfører en ny indgang i auditloggen, som er udfyldt som følger:
...
Hvis CPR validering kører i WARNING mode, så vil ugyldige (ifølge CPRExits service) CPR numre give anledning til en linje i auditloggen. Logninger af denne type ser således ud:
...
De enkelte anvendere skal whitelistes til at bruge DROS. Der findes en tabel whitelist til dette formål.
Det er anvenders CVR, der whitelistes.Det er oplysningen CVR der skal anvendes i til at indsætte i whitelisting tabellenheri muligt at angive enten et CVR nummer eller oces3 UUID. Sidstnævnte whitelister et specifikt certifikat.
Organisationens CVR nummer whitelistes ved følgende SQL:
|
SQL til at indsætte certifkatoplysninger i whitelisttabelCertifikatets UUID id whitelistes ved følgende SQL:
|
|
|
|
Note feltet kan f.eks. anvendes til at referere en supportsag eller lignende for sporingshensyn. Det er kun CVR, der er obligatoriskikke obligatorisk som de øvrige felter.