Page History
...
- sikkerhedsvalidere kald fra anvendersystemer
- hente data i de bagvedliggende registre FSK Registry og FSK
- foretage de nødvendige tjek i forhold til dataspærringer i MinSpærring i forbindelse med fremsøgning af stamkort (da SFSK kun skal anvendes af systembrugere giver filtrering i forhold til spærringer mod enkeltpersoner) ikke mening i SFSK
- foretage logninger i MinLog2 ved fremsøgning og afhentning af stamkort
- foretage auditlogning
...
Når SFSK kalder videre til de bagvedliggende services sker dette også vha DGWS. Dog trækker SFSK sit eget niveau 3 SOSI Idkort i den videre kommunikation med de bagvedliggende services. Identiteten af kaldet skifter således til at være et kald udført af SFSK, hvilket betyder at der kan udføres whitelisting i FSK til at tillade niveau 3 idkort fra det CVR nummer, som er identificeret i SFSKs Idkort.
Der skal være mulighed for værdispring i løsningen, hvorved tjek af spærringer omgås. Værdispring aktiveres ved at med sende HTTP header 'consent-override'. (Den første) værdi af denne header fortolkes som en boolsk variable med lovlige værdier (caseinsensitive true/false). Andre eller manglende værdi fortolkes som, at der ikke foretages værdispring (dvs false). Denne oplysning ligger udenfor sikkerhedsvalideringen men opbevares på SystemUserContext til anvendelse af forretningsregler (se nedenfor).
Flow i forbindelse med "Søg dokumenter" i SFSK
...
Sekvensdiagrammerne nedenfor beskriver flowet i forbindelse med "søg dokumenter". Flowet minder om det tilsvarende flow i Dokumentdelingsservicen, men er simplere, da der ikke tjekkes for spærringer mod enkeltpersoner ligesom kaldet til Behandlingsrelationservice udelades.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Flow i forbindelse med "Hent dokumenter" i SFSK
...