STARs sikkerhedsmodel

Introduktion

Denne side beskriver den sikkerhedsmodel, der er anvendes på STARs servicesnitflader. I STARs servicekatalog findes både SOAP-webservices og REST-services. Grundlæggende anvendes samme sikkerhedsmodel i begge tilfælde, hvor der primært er syntaks til forskel.

For alle services gælder, at de udstilles via HTTPS og skal kaldes med et klientcertifikat, som skal være et funktionscertifikat (FOCES). Derudover skal der medsendes metadata, som angiver, hvilken myndighed der kaldes på vegne af, samt hvem aftager agerer som databehandler for. Derudover skal angives hvilken bruger / medarbejder / applikationsproces (ved batch-processeringer) der foretager handlingen, uanset om det er en læse eller skriveoperation, for at dette kan logges. For SOAP-webservices medsendes metadata som soap headers og for REST-services medsendes som http headers.

Se også generelt om sikkerhed her: Sikkerhed

Metadata

Sikkerhedsmodellens metadata består af 3 dele (kun 2 for SOAP):

• ActiveOrganisation (SOAP + REST)
• RequestUserMetadata (SOAP + REST)
• CivilRegistrationIdentifier (REST)

Undtaget fra disse er offentlige webservices, der kan udstilles uden sikkerhed.

ActiveOrganisation

ActiveOrganisation anvendes til tjek af den grundlæggende sikkerhed: Må denne databehandler behandle data for denne myndighed.

RequestUserMetadata

RequestUserMetadata anvendes primært til logning, så der sikres sporbarhed i forhold til, hvem det er, der anvender services, se elementerne i detaljer nedenfor. Elementet anvendes dog også til tjek af anden aktørs adgang til borger, tjek i forbindelse med gæsteadgang samt til adgangshåndtering når STARs systemer agerer på vegne af a-kasser og jobcentre som fx i forbindelse med sagsbehandlerlogin på Jobnet.

: Det er af hensyn til den borgervendte visning i selvbetjeningsløsninger dog vigtigt, at CaseWorker i Body'en er angivet med sagsbehandlers navn.

CivilRegistrationIdentifier

For REST-services gælder, at cprnr. skal angives som http header på samme måde som ActiveOrganisation og RequestUserMetadata vha af en http header, der hedder CivilRegistrationIdentifier. Nedenfor er vist eksempel på de 3 http headers ved kald af en REST-service. Denne header skal udelades på ikke-borgercentriske serviceoperationer. 

Fejlhåndtering

Når der kaldes, tjekkes indholdet af felterne og rettighederne i forhold til kalder. Dette kan resultere i nedenstående fejl, som skal håndteres på tværs af alle kald mod Stars services.

Fejlkoder

Fejlhåndtering specifikt for REST

Ved fejl på REST-services returneres nedenstående datastruktur. Her vil man kunne se, hvilken fejl, der er sket og detaljer om fejlen under details:

{
    "errorCode": 1014,
    "errorMessage": "The submitted message is not valid",
    "details":"{\"\":[\"The field civilRegistrationIdentifier must match the regular expression \'((((0[1-9]|1[0-9]|2[0-9]|3[0-1])(01|03|05|07|08|10|12))|((0[1-9]|1[0-9]|2[0-9]|30)(04|06|09|11))|((0[1-9]|1[0-9]|2[0-9])(02)))[0-9]{6})|0000000000\'.\"]}",
    "correlationId": "d0d006d6-d626-4106-90a2-2d9e94eb1a1f"
}

Http Status koder

Følgende HTTP-statuskoder anvendes på REST-services:

Udfyldelse af OrganisationTypeIdentifier og OrganisationCode felterne

Følgende beskriver, hvorledes sammenhængen er mellem organisationstypen og organisationskoden, derudover gennemgås, hvorledes de forskellige aktører forventes at kalde.

Bemærk at der ikke er validering på at indberetninger med en given OrganisationCode indberetter jf. ovenstående formater.

 1) Hvis der kaldes ind fra systemet, forventes RequestUserType sat til 3 - System og OrganisationCode er et CVR nummer. Derimod forventes kald fra borgervendt selvbetjeningsløsning at komme med RequestUserType 1 - Citizen og UserIdentifier: CPR-nummer.

Kommunalt Jobcenter sagsbehandlingssystem - KSS

Dette omhandler systemer som:

• KMD Momentum (Opera og Workbase)
• Schultz FASIT
• Andre jobcentersystemer

Der anvendes (mindst) ét FOCES certifikat pr. system. Metadata udfyldes ud fra følgende:

Hvis der skal laves sagsbehandling på en borger, der ikke ”ejes” af pågældende myndighed, skal myndigheden forinden overtage borgeren. Myndighedstilknytningen udledes via borgerens adresse, men den er selvstændig og kan ændres. Borgeren kan til enhver tid kun have én myndighedstilknytning.

Resource planning system / planner system

Der skal kaldes på vegne af den myndighed som man agerer på vegne af. Hvis der indrapporteres selvbooking skal RequestUserMetadata indikere borgerdata

Kommunal selvbetjeningsløsning

Ydelsescentersystemer

Dette dækker systemer som:

• KMD-Aktiv og KOMBIT KY

• KMD eDagpenge og KOMBIT KSD

• Andre ydelsescentersystemer

Der anvendes (mindst) ét FOCES certifikat pr. system. Metadata udfyldes ud fra følgende:

Anden aktør sagsbehandlingssystemer

Anden Aktør (uanset om denne varetager myndighedsopgaver) eller fx en kursusleverandør, der skal foretage læse- eller skriveoperationer i DFDG, opererer på vegne af en myndighed og det er derfor pågældende myndigheds ansvar, at Anden Aktør eller fx en kursusleverandør kun har den adgang, de må have. Anden aktør eller fx en kursusleverandør skal derfor anvende myndighedens certifikat. Vi kan via metadata se at det er AA eller fx en kursusleverandør, der har foretaget læsning eller registrering, se eksempel senere i dokumentet.

I forhold til at have adgang til borger så validerer DFDG på om der foreligger en henvisning til borgeren for CVR nummeret for AA eller fx en kursusleverandør.

Se også: ExternalOperatorRegistrationService (Version 6)

STAR's systemer

Jobnet for jobkonsulenter 

I forbindelse med at sagsbehandlerne kommer online på Jobnet via NemID erhverv, skal der i kommunikationen med DFDG stadig anvendes FOCES certifikatet. Medarbejderens myndighed fra NemID sendes som en del af metadata i dette tilfælde.

Jobnet

Jobnet er et STAR system som fortrinsvis anvendes af borgerne. Jobnet bruger uafhængigt af borgers kommunetilknytning samme FOCES certifikat, og kalder med følgende:

Jobnet for arbejdsgivere 

Når JobAG gennem online snitflade eller WS snitflade agerer på vegne af anden myndighed eller virksomhed fremgår denne af RequestUserMetadata

VITAS

Når VITAS gennem online snitflade, batchjob eller WS snitflade agerer på vegne af anden myndighed eller virksomhed fremgår denne af RequestUserMetadata

Vitas - og anden aktør

Ved kald fra VITAS pva. Anden aktør mangler vi et "på vegne af - lag", hvorfor vi - for at kaldet sikkerhedsteknisk kan gennemføres - tillader at man ikke kan genkende at det er VITAS der er kaldt fra/igennem.

Metadata sættes derfor op som om der kaldes direkte til DFDGs services, ActiveOrganisation indikerer det jobcenter der ageres på vegne af, og RequestUserMetadata indikerer den organisation der udfører kaldet:

Certifikater og testmiljøer

STAR stiller testcertifikater til rådighed som giver adgang til at agere som en eller flere myndigheder på et eller flere testmiljøer.

Serviceaftagers forpligtigelser

Web service aftageren skal etablere og opretholde fornødne sikkerhedsmæssige tiltag til sikring af, at meddelelser, der udveksles via Webservices, ikke kommer til uvedkommendes kendskab, forvanskes eller går til grunde.

Det er web service aftagernes eget ansvar at sikre, at dennes IT-systemer er konfigureret og eventuelt tilrettet i nødvendigt omfang til at kunne få adgang til de i dette dokument beskrevne Web services.

Ligeledes er web service aftagernes ansvar at sikre, at der er knyttet forsvarlige sikkerhedsforanstaltninger til de applikationer og systemer, denne benytter for at kunne anvende de i dette dokument beskrevne Webservices.

Yderligere specifikation af de krav der stilles til webservice aftageren findes i tilslutningsaftalen. 

Følgende beskriver de forpligtelser serviceaftageren påtager sig i forbindelse med en hver form for brug af de i dette dokument beskrevne services.

Serviceaftageren forpligter sig til følgende:

• Såfremt serviceaftageren tilgår webservices der kræver unik identifikation af hvilken medarbejder/sagsbehandler/bruger der har fortaget handlingen, skal aftager enten anvende en certifikatmodel, der understøtter dette eller specifikt anvende versioner af webservices, hvor der medsendes brugerid.
• Serviceaftager skal i webservices, hvor det er beskrevet, at der skal medsendes navn på den sagsbehandler, der er ansvarlig eller den sagsbehandler, der foretager læsning eller registrering af oplysninger, som minimum oplyse medarbejdernes for- og efternavn i servicekaldet, dvs.
  • der skal oplyses konkret navn på medarbejder, når der er tale om ws-kald foranlediget af sagsbehandleres læsning eller opdatering af oplysninger DFDG eller STARs øvrige systemer - der må i sådanne tilfælde ikke oplyses fx "Unknown" eller et systemnavn som navn på medarbejderen
  • angivelse af kun systemnavn er alene tilstrækkeligt, hvis ws-kald til DFDG er foranlediget af batchjob i det aftagende system
• Serviceaftageren er forpligtet til at logge de kvitteringer der returneres af servicen
• Serviceaftageren forpligter sig til at logge alle SOAP faults inkl. fejl koden som en del af deres fejl log.
• Serviceaftageren forpligter sig til, at reagere på de SOAP-falts som DFDG og STARs andre it-systemer returnerer ved forsøg på registrering i DFDG og STARs andre it-systemer

Krav til logging hos aftageren

Web service aftageren skal gennemføre en grundlæggende logging i forhold til kommunikationen med de i dette dokument beskrevne web services.

Web service aftageren skal opretholde en log med de kvitteringer der returneres til aftageren når serviceaftageren sender hændelser til de udstillede services.

Hvis der i kommunikationen opstår en fejl skal web service aftageren logge fejlen incl. allle fejl informationer der returneres fra servicen, samt den afsendte besked.

Web service aftageren skal som minimum også logge følgende indformationer:

• BrugerID – Unik identifikation af brugeren
• Den organisationstype brugeren repræsenterer f.eks. jobcenter eller a-kasse
• Den organisationskode der er knyttet til den organisation brugeren repræsenterer
• Timestamp

Hvis der indgår personoplysninger i applikationen skal logningen være i overensstemmelse med Bekendtgørelse nr 528 af 15/06/2000 - Bekendtgørelse om sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning.

Se iøvrigt: Krav til logning i applikationer

Anvendelse af OrganisationType ved WSRM

Når der skal hentes beskeder over WSRM anvendes OrganisationType på følgende måde:

• Jobcenter medarbejdere kalder med OrganisationType=8
• Kommunale medarbejdere kalder med OrganisationType=7
• A-kassen kalder med OrganisationType=2

SAML og medarbejdercertifikater

Der er stadig behov for at have et SAML login i forbindelse med de administrative systemer: AMP, JCP, JN Administration, LSS, JobKon med videre.

AMPs sikkerhedsmodul (baseret på MOCES/nemid erhverv) fortsætter med at fungerer. Brugerdatabasen indeholder kun brugere, der anvender SAML løsningen. Denne løsning er separat fra webservices FOCES sikkerhedsmodel og beskrives derfor ikke yderligere her.