Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
Indholdsfortegnelse
Afgrænsning af epic
| Afgrænsning | ||
|---|---|---|
Som ansvarlig dataejer vil jeg have sikkerhed for at de brugte adgangsdata er sammenhængende med certifikatejer for at kunne give korrekt adgang, og for at kunne redegøre for hvem der har tilgået data. | ||
| Acceptkriterier | ||
| Nr. | Beskrivelse | Relevant for |
| 950.8.1 | Sikkerhedsmodellen i DFDG validerer for korrekt sammenhæng imellem certifikat og begge metadatalag (ActiveOrganisationHeader og RequestUserMetadata) | DFDG |
| Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | |||
|---|---|---|---|---|---|
| Acceptkriterie 950.8.1 | Acceptkriterie <nr.> | Acceptkriterie <nr.> | Acceptkriterie <nr.> | ||
Aftagersystemer sikrer at såvel ActiveOrganisation som RequestUserMetadata repræsenterer egen organisationstype og organisationskode ved kald af STAR systemer | X | ||||
Oversigt over berørte webservices
Manuel oversigt som er synlig for eksterne (links i listen virker kun med STAR Jira konto):
Alle services udstillede af DFDG, med adgangsstyring (dvs. alle andre end CodelistService) er berørte.
Automatisk oversigt (vi arbejder på løsning på at gøre den synlig)
Beskrivelse af epic
Idet metadata er centrale for at man kan logge hvem der har tilgået hvilken borgers data, er det et krav at serviceaftagere med tilslutningsaftale sørger for at de metadata der kaldes med er retvisende for den kaldende myndighed.
Metadata for servicekald til STAR består af 2 hoveddele: ActiveOrganisation og RequestUserMetadata. Hidtil har sikkerhedsløsningen primært været baseret på ActiveOrganisation, fra og med 2019-4 bruges RequestUserMetadata som grundlag for filtrering af data i et enkelt tilfælde, fra 2020-2 generelt til filtrering og sikring af korrekt adgang til data. Derfor oprettes der validering på at RequestUserMetadata er i overensstemmelse med ActiveOrganisation (som allerede valideres til at være i overensstemmelse med certifikatet for den kaldende myndighed).
Fokus bliver lagt på myndighedstype (OrganisationType) og myndighedskode (OrganisationCode). Her et eksempel med kaldende a-kasse:
Krav til sammenhæng i metadata
Generelt vil manglende overholdelse af kravene til metadata medføre at man mødes af fejl "4413 - The authoritytype of the requestheader is invalid".
Kald fra myndigheder generelt
RequestUserMetadata skal indikere samme organisation som ActiveOrganisation (sådan som de gør i eksemplet ovenfor hvor OrganisationType 2 = a-kasse og OrganisationCode 17 = FOA går igen).
Bruger-type (RequestUserType) må kun være "system" når det er batchjob der kalder
Ift. bruger-typen (RequestUserType) så gælder samme regler som hidtil:
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
(citat fra DFDGs sikkerhedsmodel)
Kald med anden aktør eller kommunalansatte
Kald fra anden aktør og kommunalansatte udfyldes som hidtil, som det fremgår af følgende overblik over kald fra KSS systemer:
Feltgruppe | Indhold | Fx |
|---|---|---|
| ActiveOrganisationHeader | OrganisationTypeIdentifier = 8 OrganisationCode = Jobcenterkode | 8 (Jobcenter) 75100 (Aarhus) |
| RequestUserMetadataHeader | Hvis jobcentermedarbejder: OrganisationTypeIdentifier = 8 OrganisationCode = Jobcenterkode / fx 10100 Hvis Kommunalmedarbejder: OrganisationTypeIdentifier = 7 OrganisationCode = Kommunekode Hvis anden aktør medarbejder: OrganisationTypeIdentifier = 4 OrganisationCode = CVR nummer | 8 (Jobcenter) 75100 (Aarhus) 7 (Kommune) 751 (Aarhus) 4 (Anden aktør) 35669035 (Lucky Star ApS) |
Kald på vegne af borger i forbindelse med selvbetjeningsløsninger
Systemkald hvor det er borger der repræsenteres, typisk i borgervendte selvbetjeningsløsninger (fx i forbindelse med Joblog eller indberetning af selvbooket Booking):
Feltgruppe | Indhold | Indholdseksempel |
|---|---|---|
| ActiveOrganisationHeader | OrganisationTypeIdentifier = Kaldende myndighed OrganisationCode = Kaldende myndighed | 2 (A-kasse) 17 (FOA) |
| RequestUserMetadataHeader | RequestUserType = 1 - Citizen OrganisationTypeIdentifier = Kaldende myndighed OrganisationCode = borgers CPR-nummer | 1 (Borger) 2 (A-kasse) (CPR nr) |
RequestUserType sættes til 1 - Citizen. OrganisationCode i RequestUserMetadata sættes til borgers CPR-nummer.
OrganisationType følger det kaldende system i ActiveOrganisation. OrganisationType er ikke kritisk i denne sammenhæng, og der valideres ikke på den.
Kald fra STAR systemer på vegne af borgere følger ovenstående mønster
Kald fra STAR systemer på vegne af sagsbehandler fra Jobcenter eller a-kasse
Feltgruppe | Indhold | Indholdseksempel |
|---|---|---|
| ActiveOrganisationHeader | OrganisationTypeIdentifier = 5 OrganisationCode = Kaldende system | 5 (STAR) 4 (Jobnet) |
| RequestUserMetadataHeader | RequestUserType = 2 - Caseworker OrganisationTypeIdentifier = Anvenders myndighed OrganisationCode = Anvenders myndighedskode | 2 (Sagsbehandler) 2 (A-kasse) 17 (FOA) |
Valideringer med henblik på sikring af ovenstående sammenhænge
Der oprettes validering på at OrganisationType i ActiveOrganisation og RequestUserMetadata er ens når der er tale om kald fra alle andre organisationer end OrganisationType id 5 - STAR.
For jobcentre udgør Anden aktør og kommune-medarbejdere en undtagelse, som gennemgået ovenfor.
Der oprettes IKKE validering på Requestusermetadata når ActiveOrganisation er en STAR organisation
Særlige krav til test
| Test scenarie | Berørte systemområder (herunder nye batchjobs*) | Identificeret af |
|---|---|---|
* Batchjobs
- bør testes både med delta og fuldt load,
- bør hvis der er afhængigheder køres med normalt load fra BI i ét testmiljø i hele testperioden
- bør testes i samarbejde med teams som har afhængigheder
- kørselstid, særligt hvis det er en del af NightlyBatch
Konsekvenser for drift/idriftsættelse
I forbindelse med idriftsættelse:
- Skal der køres et fuldt dataload ved første kørsel af et batchjob - aftal med SF hvornår load skal køres
- skal der køres konvertering
- Skal der køres databasescripts for opdatering af tabeller i databasen
Efter idriftsættelse:
Arkitektur- og implementeringsnoter
Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:
- Nye dataområder
- Nye snitflader
- Nye komponenter
- Nye miljøer
- Nye teknologier
- Nye aftagertyper
- Eller afvigelser fra principperne
- Eventuelle behov for reduktion af teknisk gæld skal afdækkes
Der gives en beskrivelse af hvorledes disse tænkes håndteret/implementeret i løsningen og om dette har været vendt med STAR arkitekten.