Versions Compared

Old Version 2

changes.mady.by.user Jesper Brunholm

Saved on

compared with

New Version 3

changes.mady.by.user Jesper Brunholm

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning



Page Properties


STAR Projektleder (PL)Forretningsanalytiker (FA)STAR ReleaseEpic statusEksterne snitflader
Knud de Place (STAR)Jesper Brunholm2020-20,1KSS(t.o.), A-kasse(t.o.), Plannersystemer(t.o.)




Jira Legacy
serverSystem JIRA
columnskey,po,fa,ux,sme,eksterne snitflader,interne snitflader,status,labels
maximumIssues4
jqlQueryissuetype = epic AND cf[10006] = 100.15 order by key
serverId479d1618-4a6f-3f88-8ee1-04c6b02c448a

Jira Legacy
serverSystem JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId479d1618-4a6f-3f88-8ee1-04c6b02c448a
keyDS-38

OBS DETTE SKAL TILPASSES MED DE KORREKTE NUMRE NÅR EPICS OPRETTES I JIRA


Indholdsfortegnelse

Table of Contents
outlinetrue



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.BeskrivelseRelevant for
950.8.1Sikkerhedsmodellen i DFDG validerer for korrekt sammenhæng imellem certifikat og begge metadatalagDFDG







Kriterier for tilsagn til serviceaftager i forhold til STARs snitfladerBerørte acceptkriterierBemærkninger

Acceptkriterie 950.8.1Acceptkriterie <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)

Jira Legacy
serverSystem JIRA
columnssummary,varslingstype,varslingsnote,eksterne snitflader,interne snitflader,project
maximumIssues100
jqlQueryissuetype = Varsling AND linkedIssue in (DS-38) ORDER BY summary, Varslingstype, "Eksterne snitflader", "Interne Snitflader"
serverId479d1618-4a6f-3f88-8ee1-04c6b02c448a


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 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).


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 følgende organisationer:For jobcenalle 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

Overvej for hvert acceptkriterie hvilke systemer der berøres af ændringen:

  • DFDG
    • Services
    • WSRMer
    • Kodelister
    • PersonStatusService (PSS)
    • PersonHistoryService (PHS)
    • LSS (Landssupportsystem) og herunder Registerudtræk (hvis STAR har dataejerskab og der er lavet PHS på domænet)
  • Jobnet
  • VITAS
  • JobKon
  • JobAG
  • BI integrationsplatform
  • Alle områder
    • Nye batchjobs
      • Dokumentation af jobbet til SF (jf. skabelon: xxx link til skabelon) 
    • Dataløft
      • Hvis der i Databaser tilføjes eller fjernes kolonner med personfølsomme data (f.eks. person navne, adresser, email, telefonumre etc.), så skal SF informeres så disse data fremadrettet tilføjes eller fjernes fra scrambling.
  • Kommunalt sagsbehandlingssystem
  • A-kasse sagsbehandlingssystem
  • Kommunalt bookingsystem
    • JobcenterPlanner (JCP)
    • WorkForcePlanner (WFP)
    • Kommunalt ydelsessystem



    Særlige krav til test

    Test scenarieBerø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.