Nærværende notat indeholder en løsningsskitse for validering af nationale roller.
Skitsen vil være organiseret efter de enkelte krav i kravspecifikationen v02.
Der introduceres to nye tabeller i stamdata skemaet.
Tabellerne følger NSP standard for importere med en tabel indeholdende versionerede data og en anden tabel indeholdende en importerstatus.
Det vil således være muligt at se både historiske og aktuelle roller ligesom importerstatus tabellen giver mulighed for at aflæse om data er forældede eller kan betragtes som up-to-date.
Formatet vil være forberedt til senere at spille sammen med en importer følgende det normale importer framework.
Det vil være muligt senere at eksponere data via f.eks. kopiregisterservicen eller øvrige stamdata opslagsservices idet dataformatet følger standarder for øvrige importere.
Dette er dog ikke en del af den aktuelle opgave.
Der indføres en ny database tabel i STS konfigurationsdatabasen. Denne opdateres på backoffice og replikeres ud til CNSP/DNSP noder.
Indeholder en liste af roller med angivelse af kilde (SEB), eksternt navn (som rollen optræder i tabellen fra stamdata) samt offentligt navn (som rollen optræder i id-kortet).
De to navne kan evt. være ens. Men vi har mulighed for at udskyde valget af hvorledes rollerne repræsenteres i SEB.
STS vil indlæse information herfra ved opstart, samt genindlæse med et fast (konfigurerbart) interval, f.eks. hver 10. minut.
Data opdateres i den initielle løsning ved driftsleverandørens udførelse af SQL via change management.
Disse ændringer vil på få sekunder blive replikeret ud på alle NSP miljøer, og efterfølgende slå igennem når den enkelte STS genindlæser sin rolle-konfiguration.
Indlæsning af rolle-konfiguration vil i første omgang benytte den eksisterende datasource til aflæsning af sts konfiguration. Dette vil muligvis skulle ændres senere, hvis man senere vil indføre automatisk indlæsning af konfiguration fra ekstern kilde (i givet fald en ny importer) .
Kommentar: Det kan overvejes senere at udvide denne tabel til at indeholde information om gyldige uddannelseskoder - dette kan evt. blive relevant med indførelse af en ny rolle for Osteopater (hvor udddannelseskoden ikke følger normalt mønster). Tabellens format vil være forberedt til en sådan senere udvidelse.
Den eksisterende algoritme til match af roller er meget specifikt på at der kun findes en enkelt kilde til check.
Dette justeres til at have en liste af valideringer: Hver validering kan enten returnere et positivt eller fejlsvar, eller intet svar (ved intet svar fortsættes med næste validering).
Valideringer i prioriteret rækkefølge:
Dette kan evt. senere udvides med funktionalitet til håndtering af claimede roller fra særligt troværdige 3. parter såfremt disse kan identifieres ud fra enkodning af rollenavn.
Opslag af roller vil benytte en ny datasource "sts-sdm" for at holde en tydelig adskillelse fra øvrige databaseopslag.
I tilfælde af matchende ikke-autoriseret rolle, returneres det offentlige navn fra konfigurationstabellen.
Disse løftes som afledt effekt af løsningerne til 2 og 4. Enkodningen af rolle bestemmes af det offentlige navn angivet i konfigurationstabellen og STS verifikationsalgoritmen sikrer at disse i relevante tilfælde indgår i det udgående id-kort.
Det eksisterende autorisationscheck har et antal identificerede fejlscenarier.
Teknisk fejl (authorization lookup failed \[cprnummer\]) |
Opslag fra en ny kilde til roller giver anledning til præcis de samme naturlige fejlscenarier - blot med "autorisation" erstattet med "national rolle".
NSP har en accesshandler der står for bl.a. audit- og SLA-logning.
Denne opsamler allerede "standard oplysninger" fra kaldet, og vil til førstkommende NSP-release få en opdatering der bedre tillader enkelte komponenter at aflevere information til denne
- via et såkaldt audit API.
Logningen involverer allerede tidsstempel, evt. rolle, autorisationskode, cpr-nummer samt subjectSerialNumber for certifikatet.
Den efterspurgte information er således allerede til stede her - men dog på et format hvor det er vanskeligt at skelne id-kort med ikke-autoriserede roller fra andre.
Det foreslås at benytte det nye audit API til at aflevere relevante rolle informationer som separate felter, således at det bliver let at skelne mellem autoriserede og ikke-autoriserede roller.
Den eksisterende logning omfatter allerede en generisk "rolle" - og det kan vi så udvide med separate felter til (evt.) uddannelseskode og (evt.) national rolle eller (evt.) rollebeskrivelse.
Det er allerede muligt for driftsleverandøren at udtrække periodiske statistikker baseret på f.eks. servermiljø eller cvr nummer.
Med den foreslåede løsning vil det blive muligt for driftsleverandøren at udstille statistikker baseret på allerede benyttede datakilder (logs). Og med kombinationsmuligheder
Monitorering: STS indeholder i dag en monitorerings url der dels giver mulighed for at aflæse om systemet er nede, dels åbner mulighed for at advare om mindre alvorlige ting.
Denne udvides med information omkring status for import - og hvorvidt data er forældede.
Der vil alene være tale om advarsler således at overvågningen kan opsætte modtagelse af en alarm såfremt data er mere end x timer gamle.
Det vil teknisk ske i form af http status kode 202 i svaret fra overvågnings URL'en
Billet-omveksling: Den eksisterende billetomveksling fra Nemlogin-token (brugt fra f.eks. FMK-online eller sundhed.dk) til id-kort behandler i dag ligeledes roller.
Funktionaliteten i dag er marginalt anderledes end det eksisterende flow, idet der for ikke-autoriseret personale kræves angivelse af en "fritekst-rolle".
Det er lidt uklart hvorledes dette kan udvides mht. nationale roller uden at påvirke eksisterende anvendere.
Det foreslås derfor i den initielle løsning at forhindre angivelse af nationale roller og undlade validering af dette - idet vi herved undgår at returnere id-kort med ikke-validerede nationale roller som ville kunne give anvendere forkerte forventninger.
Såfremt der senere opstår behov for understøttelse af dette scenarie betragtes det som en særskilt opgave.
Test: STS leverancen vil indeholde et minimalt sæt af testdata med eksempel-roller for 1-2 sundhedsfaglige personer. Det forventes at der kan modtages 2 nye testcertifikater indeholdende en "Lægesekretær" samt en person med rollerne "Lægesekretær + Portør". De to testbrugere oprettes i DTG.
Dette bliver i sagens natur mere løst, da det konkrete format endnu ikke kendes.
Der forventes implementeret en importer der mht. persistens og status følger normale stamdata importere.
Importer frameworket er gearet til indlæsning af filer der på anden vis er placeret i det lokale fil-system (evt. på et SAN) – i foldere der monitoreres en gang i sekundet.
Dette vil skulle justeres til at håndtere en langsommere schedulering, samt ekstern hentning – så der vil blive behov for kopiering og efterfølgende tilretning af enkelte dele af importer-frameworket. Det vurderes dog muligt at passe ind uden de store udfordringer.
Mht. indlæsning forventes en REST-baseret indlæsning af et fuldt dump, beskyttet af 2-vejs-SSL, men uden yderligere sikkerhedsinformation i forespørgsler.
Det vil kun være praktisk muligt at gemme et audit-trail af de modtagne rå-data, såfremt den eksterne service hos SEB giver mulighed for at detektere tidspunktet for sidste globale data ændring.
Jeg ser følgende aktiviteter i den initielle fase:
I alt fase 1: 36t
QA aktiviteter anslås til ca. 6 timer.
I fase 2 vil vi implementere en ny importer. Denne forudsætter at den eksterne SEB snitflade er tilgængelig.
I fase 2 ser jeg følgende aktiviteter:
I alt fase 2: 47t