STS trust af nationale roller.

Indledning

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.

Krav1 : Ny SDM tabel

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.

Krav 3: Opsætning af gyldige ikke-autoriserede roller.

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.

Krav 4: Match af roller

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:

• match af autoriseret rolle angivet i input (i form af uddannelseskode eller autorisationskode)
• Opslag af autoriseret rolle
• Match af ikke-autoriseret rolle angivet i input
• Opslag af ikke-autoriseret rolle.
• Returnering af evt. input i rolle.

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.

Krav 5-6:

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.

Krav 7: Fejlsvar

Det eksisterende autorisationscheck har et antal identificerede fejlscenarier.

• Teknisk fejl (authorization lookup failed [cprnummer])

• Manglende autorisation (hvis angivet i input men brugeren ikke autoriseret)
• Autorisation ikke matchet (hvis angivet i input, men brugeren har andre autorisationer)
• Autorisation kan ikke entydigt bestemmes.

Opslag fra en ny kilde til roller giver anledning til præcis de samme naturlige fejlscenarier - blot med "autorisation" erstattet med "national rolle".

Krav 8: Logning

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 

Yderligere kommentarer

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.

Krav 2: Efterfølgende import af roller fra ekstern kilde.

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.

Estimat

Jeg ser følgende aktiviteter i den initielle fase:

• Initielle afklaringer / løsningsskitse: 5t
• Fjernelse af mulighed for "fritekst-rolle" ved NBO der ligner national rolle: 2t
• Anvendelse af audit API til logning af oplysninger : 4t
• Dokumentation af fejlscenarier / anvender guides: 4t
• Database opslag af roller incl. ny datasource: 4t
• Databaseopslag og caching af rolledefinitioner: 5t
• Nye stamdata tabeller ifølge importer "standard": 3t
• Justeringer af algoritme til opslag: 4t
• STS-Monitorering af status : 2t
• Oprettelse af testcertifikater, samt DTG testbrugere: 3t

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:

• Opsætning af "skelet for ny importer": 15t
• Indlæsning og parsning af data fra ekstern webservice: 15t
• Persistering af (versionerede) parsede data med detektering af ændringer: 10t
• Databasemaintenance efter "Importer standard": 2t
• Importer monitorering ved lang tid mellem imports: 2t
• Sanity check ved store afvigelser mellem ny og gamle data: 3t   

I alt fase 2: 47t

Forventet tidsplan:

• 4.9. Initiel kravspecifikation
• 6.9 Aflevering af løsningsskitse
• 6.9 – 14.9. Implementering af løsning
• 12.9 Modtagelse af testcertifikater fra SSI.
• 14.9 Aflevering af STS release 2.6.1 til Arosii QA afdeling.
• 21.9 STS Release afleveres til Netic som del af NSP 2.52.
• ?.9 STS Release tilgængelig på test1.
• 1.10 Tilgængelig i produktion som del af NSP 2.52.
• 15.10 Release deployes i produktion som del af NSP 2.52.
• 28.9 ??: SEB service forventes implementeret og tilgængelig i et testmiljø
• 1.10-12.10 : Implementering af ny SDM importer
• 15.10-19.10: QA og overlevering til Netic
• 24.10: Idriftsætning i testmiljø
• Primo november: Idriftsætning i produktion.