Arkitekturreview. OS2Opgavefordeler. Version: Date: Author: BSG

Transkript

1 Arkitekturreview OS2Opgavefordeler Version: Date: Author: BSG

2 Indhold 1 Introduktion Opsummering på reviewet Overordnet arkitektur Frameworks og afhængigheder Håndtering af boiler-plate kode Håndtering af tværgående funktionalitet Modenhed Systemlogning Auditlogning Opfølgning på eksisterende udestående i kodebasen Dokumentationsniveau Deployment af OS2Opgavefordeler Anvendelsesområder Anvendelse til autorisationsformål / adgangskontrol Anvendelse som autoritativ kilde til støttesystemet Organisation Rammearkitekturen og OS2Opgavefordeler Adgangsstyring via støttesystemerne Adgang til myndigheders organisation via støttesystemerne Adgang til KLE emneindeks via støttesystemerne Sikkerhedsfejl i OS2Opgavefordeler Registrering af brugernavne/kodeord i kodebasen Manglende validering af kodeord i BasicAuthFilter Mangelfuld validering af rettigheder Anvendelse af bruger-input direkte i SQL statements Konklusion og opsummering på anbefalinger Anbefalinger Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 2 / 21

3 1 Introduktion I forbindelse med udbredelsen af OS2Opgavefordeler til flere og flere myndigheder, har der været et ønske om at få reviewet løsningen, med fokus på såvel modenhed som udvidelse af løsningens anvendelsesområder. Dette review har fokuseret på Løsningsarkitektur, med fokus på udvidelsesmuligheder, skalerbarhed og hvorvidt løsningens valgte arkitektur kan give udfordringer på sigt. Mulighed for at anvende løsningens datagrundlag til adgangsstyring, samt KLE opmærkning af organisationen i forhold til støttesystemerne. Afprøvning af løsningen, herunder fokus på installation og dokumentation. 1.1 Opsummering på reviewet Reviewet har generelt fundet at OS2Opgavefordeler er bygget efter sunde principper og med moderne og vedligeholdelsesvenlige teknologier, samt at løsningen håndterer det primære opdrag (opgavefordeling) på en fornuftig og hensigtsmæssig måde. Endvidere vurderes det at OS2Opgavefordeler kan udvides til at være autoritativ kilde for en generel KLE opmærkning af enheder, samt at denne opmærkning på sigt kan anvendes til adgangsstyring når det kommer til afgrænsning af adgang i henhold til KLE. OS2Opgavefordelers nuværende dokumentationsniveau kan være en forhindrende faktor både for lokale installationer, samt for overdragelse af løsningens vedligehold til 3.part, og dette område bør højnes i forbindelse med den større udbredelse af løsningen. 2 Overordnet arkitektur OS2Opgavefordeler er bygget efter en klassisk 4-lags arkitekturmodel, bestående af VIEW. Selve brugergrænsefladen. Brugergrænsefladen er implementeret i AngularJS, der er løst koblet til resten af OS2Opgavefordeler via REST/JSON baserede snitflader. CONTROLLER. Selve REST/JSON laget, der udstiller funktionaliteten i OS2Opgavefordeler til anvendere, herunder brugergrænsefladen. Dette lag håndterer generelt kun konvertering af JSON til/fra interne data-repræsentationer samt kommunikation/transport af data. SERVICE. Forretningslogikken i OS2Opgavefordeler er implementeret i service laget. MODEL. Datamodellen for OS2Opgavefordeler, og håndtering af persistering af data i SQL databasen. I den valgte arkitekturmodel ønsker man at lagene anvender hinanden hierarkisk, dvs Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 3 / 21

4 Figur 1-4-lags arkitektur Generelt er der i OS2Opgavefordeler gjort et godt stykke arbejde i at holde denne 4-lags tilgang til implementeringen, og reviewet har ikke fundet nogen brud på arkitekturmodellen. Koden er pt struktureret således at brugergrænsefladen (VIEW) er et selvstændigt modul, og at backenden (CONTROLLER, SERVICE og MODEL) er samlet i ét modul. Det anbefales at splitte backenden op i flere moduler, ét for hvert lag i den valgte arkitektur, og så anvende almindelige dependency styring mellem modulerne, for at sikre at man ikke bryder den valgte arkitekturmodel. Se Anbefaling 1 for detaljer. 3 Frameworks og afhængigheder Et designvalg der kan have stor indflydelse både på løsningens modenhed, samt omkostningerne ved udvikling og vedligehold, er de komponenter der indgår i løsningen, såvel frameworks som infrastrukturkomponenter (databaser, applikations-servere m.m.). OS2Opgavefordeler er generelt baseret på moderne teknologier, og har forholdsvis få afhængigheder til tunge invasive frameworks. De fleste frameworks anvendes i nye udgaver, dog anvendes en forholdsvis gammel udgave af AngularJS som hele brugergrænsefladen er baseret på. Den version af AngularJS der anvendes af OS2Opgavefordeler er fra marts AngularJS er et forholdsvist ungt framework (som de fleste web-frameworks), under hastig udvikling. AngularJS 1 serien nærmer sig end-of-life, da AngularJS 2 er blevet frigivet i september Det anbefales at undersøge omfanget af en migrering til AngularJS 2, da AngularJS 1 formodentligt ikke tildeles så mange udviklingsressourcer i fremtiden. Se Anbefaling 2 for detaljer. 3.1 Håndtering af boiler-plate kode Java programmeringssproget har over årene udviklet sig til at indeholde en række konventioner som ikke er direkte understøttet af sproget, men som mange frameworks, værktøjer m.m. gør anvendelse af. Det er fx normalt at man anvender getter/setter konventionen til at udstille egenskaber ved sine objekter, og fluint builders er blevet en populær måde at konstruerer objekter på. Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 4 / 21

5 Den kode der skrives for at overholde disse konventioner kaldes ofte boiler-plate kode, da den i praksis kun kan skrives på én måde, og blot påtrykkes koden de rette steder. OS2Opgavefordeleren indeholder en mængde boiler-plate kode, der fint modsvarer projektets størrelse. Denne kode skal løbende vedligeholdes, og kan potentielt indeholde fejl og mangler. Det anbefales at kigge på frameworks der kan auto-generere så meget af boiler-plate koden som muligt. Se Anbefaling 3 for detaljer. 3.2 Håndtering af tværgående funktionalitet Tværgående funktionalitet dækker over den funktionalitet i koden der ikke er bundet til et bestemt område i koden, det kan være håndtering af sikkerhed, systemlogning, auditlogning, overvågning m.m. OS2Opgavefordeler håndterer disse problemstillinger inde i forretningskoden, fx kan man kigge på klassen RoleEndpoint.java, der ligger i CONTROLLER laget. Klassen laver trace-logning, hvor den fx i metoden deleterole(), logger kaldets input parametre til system-loggen. Klassen håndterer også sikkerhed, hvor den fx i metoden getroles() validerer om den bruger der kalder har rollen Admin før den tillader at listen af roller returneres. Denne tilgang har en række ulemper, bl.a. Koden bliver mindre læsbar, da den kommer til at indeholde en del kode som ikke har noget med kodens primære formål at gøre. Kodebasen bliver betydeligt større, med tilhørende øgede omkostninger til vedligehold. Der er en overhængende sandsynlighed for fejl i koden, da udvikleren skal implementere den tværgående funktionalitet korrekt i samtlige metoder. Eksempelvis er der i den nævnte klasse implementeret kontrol af rettigheder i getroles() metoden, men der er ikke implementeret kontrol af rettigheder i deleteroles() metoden. Og omvendt for trace-logning, der kun er implementeret i deleteroles(). Det anbefales at man kigger på frameworks til håndtering af tværgående funktionalitet, fx frameworks der anvender en annoteringsdreven mekanisme. Hermed reduceres kodebasen, kvaliteten af den kode der udvikles til at håndtere den tværgående funktionalitet kan øges til at have en højere kvalitet, og man kan anvende værktøjer til at scanne for uhensigtsmæssig håndtering af tværgående problemstillinger. Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 5 / 21

6 Figur 2 - Tværgående funktionalitet Se Anbefaling 4 for detaljer. 4 Modenhed OS2Opgavefordeler er stadig et ungt kodeprojekt, og har nogle hjørner der ikke er helt modne endnu. For at sikre en et modent og stabilt produkt der kan skalere til mange anvendere, bør følgende områder kvalitetssikres 4.1 Systemlogning Det primære formål med en systemlog er at kunne afhjælpe fejl og mangler i produktion. Loggen er typisk det bedste redskab man har til at finde årsagen til en rapporteret fejl, og dermed kunne fixe fejlen indenfor rimelig tid. Kvaliteten og omfanget af data man skriver til systemloggen er bærende for hvor god driftssupport der kan ydes i tilfælde af rapporterede fejl. OS2Opgavefordeler har samlet 23 steder i koden hvor der skrives systemhændelser til logfilen, af disse er under halvdelen logninger af fejl, resten af trace-logninger. Det anbefales at anvende et framework til tracelogning (se Anbefaling 4), og at trace-logning kan enables/disabled efter behov. Hermed sikres der trace-logning i hele kodebasen, og ikke blot de få steder hvor det har været relevant i forbindelse med tidligere fejlsøgningsscenarier. Det anbefales samtidig at fokusere på at øge mængden af fejl-logninger i OS2Opgavefordeler. Som udgangspunkt bør der logges Alle afgivelser i flowet fra solskins-scenariet (evt bare som info-beskeder) Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 6 / 21

7 Alle valideringsfejl (fx input valideringsfejl på kald til REST services) Alle egentlige fejl (bemærk det er ikke nødvendigvis tilfældet at en exception logges hvis en af de bagvedliggende frameworks mapper denne exception til en brugervendt fejlkode, så ses den ikke i loggen) Frameworks kan sættes op til at inspicere exceptions der kastes af SERVICE laget, og logge disse (og efterfølgende kaste dem videre). På den måde behøves man ikke manuelt håndtere logning af exceptions hvert sted de opstår. Det anbefales at få lavet en systematisk gennemgang af systemlogningen i OS2Opgavefordeler. Se Anbefaling 5 for detaljer. 4.2 Auditlogning Auditloggens formål er at kunne svare på spørgsmålet hvem gjorde hvad hvornår?, og kan eksistere af lovmæssige årsager. I OS2Opgavefordeler er det dog næppe tilfældet af lovgivningen stiller krav til auditloggen. OS2Opgavefordeler har samlet 7 steder i koden hvor der skrives til audit-loggen. Dette vurderes ikke at være dækkende for den mængde af handlinger der kan foretages i OS2Opgavefordeler. Som udgangspunkt bør der skrives til auditloggen hver gang en forretningsentitet oprettes, ændres eller slettes. Det anbefales at få lavet en systematisk gennemgang af auditlogning i OS2Opgavefordeler. Se Anbefaling 6 for detaljer. 4.3 Opfølgning på eksisterende udestående i kodebasen OS2Opgavefordeler 36 TODO s nævnt i kodebasen, hvoraf de 33 er i backend koden. De fleste af disse TODO har beskrivelser der antyder at den udestående ændring er af en non-funktionel karakter, og det primære formål er at få ryddet koden op, eller håndtere nogle specielle situationer lidt pænere. Der er dog TODO s der antyder at der er tale om rettelser der skal udføres inden OS2Opgavefordeler sættes i produktion, og disse bør adresseres snarest. Eksempler på dette er fx 1) DistributionRuleEndpoint.java, metoden allowedtoupdate(distributionrule existing) Metoden returnerer altid true, da der ikke foretages nogen validering, men der er en længere kommentar om præcist hvilke valideringer der bør eksistere i produktion. 2) KleServiceImpl.java, metoden storeallklemaingroups(list<kle> groups) Her er en kommentar om at tilgangen med at slette alle eksisterende KLE og så indlæse de nye ikke er en acceptabel løsning til produktion, men at til test-formål er det fint nok. Det anbefales at de TODO s der er nævnt i kodebasen gennemlæses, og der laves en vurdering af hvilke der skal adresseres nu, og hvilke der evt ikke længere er relevante. Se Anbefaling 8 for detaljer. Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 7 / 21

8 4.4 Dokumentationsniveau OS2Opgavefordelers samlede dokumentation består af 3 tegninger i PNG format En konfigurationsfil der ligner opsætningen til en http server Et dump af hvad der ligner en partiel datamodel i tekst-form Et tekst-dokument på 90 linjer, der på stikordsform beskriver opsætningen af JBoss serveren Et tekst-dokument på 237 linjer, der kort beskriver nogle af tankerne bag koden Omfanget af dokumentationen gør det besværligt for 3.part at foretage Lokale installationer af softwaren Videreudvikling og vedligehold af softwaren Overvågning af kørende installation Hvis OS2 ønsker at genudbyde vedligehold, videreudvikling og drift af løsningen, vil det være nødvendigt at højne dette dokumentationsniveau før et sådan udbud vil kunne lade sig gøre. Endvidere gør den manglende dokumentation OS2 afhængig af nøgle-ressourcer hos nuværende leverandør, hvilket kan være en flaskehals i forbindelse med udruldningen hos flere myndigheder. Det anbefales at kvaliteten af dokumentationen på OS2Opgavefordeler højnes, med fokus på installations- og driftsdokumentation, samt arkitektur og kodedokumentation, med det specifikke forretningsfokus at gøre sig uafhængig af nøgle-ressourcer. Se Anbefaling 17 for detaljer. 4.5 Deployment af OS2Opgavefordeler OS2Opgavefordeler er lige blevet omlagt til at anvende Docker 1, der er en container teknologi, der pakker software, runtime, afhængigheder m.m. ind i en enkelt pakke, der let kan deployes på en Docker server. Docker er med til at sikre at softwaren altid fungerer på præcist samme måde, lige meget hvor den deployes. Dokumentationen til hvordan man bygger og deployer disse Docker containere er dog ikke indeholdt i OS2Opgavefordeler. Under reviewet er det lykkedes at bygge OS2Opgavefordeler som et Docker image, og deploye denne, men det har ikke været muligt at tilgå OS2Opgavefordeler efterfølgende, da forsøg på at bootstrappe systemet ikke har fungeret. Den eksisterende Anbefaling 17 vil være med til at sikre at installationen med Docker er bedre dokumenteret. Det bemærkes også at OS2Opgavefordeler bygges lokalt på udviklingsmaskinen, for derefter at blive kopieret til Docker imaget. I et continuous integration/delivery setup vil man typisk forsøge at bygge softwaren i et kontrolleret miljø, fx på en byggeserver, men anvendelsen af Docker gør det også muligt at bygge software i samme miljø som man efterfølgende ønsker at deploye det i, nemlig Docker containeren. Se Anbefaling 18 for detaljer. 1 Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 8 / 21

9 5 Anvendelsesområder Et interessant spørgsmål vedrørende OS2Opgavefordeler, er hvorvidt den opmærkning af KLE på enheder der foretages i OS2Opgavefordeler kan finde anvendelse i andre sammenhæng. Den nuværende datamodel (og tilhørende forretningslogik) i OS2Opgavefordelers er designet til at kunne svare på spørgsmålet hvilken enhed, evt medarbejder, skal modtage opgaver opmærket med KLE xx.yy.zz, hvor KLE opmærkningen kan suppleres med partens CPR nummer eller en tekststreng der matches op mod bestemte søgeord i fordelingsreglerne. OS2Opgavefordeler anvendes i dag til automatisk routning af opgaver (fx postfordeling), og giver derfor ikke tvetydige svar, så hvis man har flere enheder der arbejder med samme KLE emneområder, så vil man i konfigurationen af distributionsregler i OS2Opgavefordeler nødvendigvis måtte vælge hvilken af disse enheder, der er opgavemodtager for dette KLE område. Denne restriktion kan være en udfordring for anden anvendelse af KLE opmærkningen. Hvis man kigger mere bredt på KLE, og ikke bare til fordeling af opgaver, kan man groft sige at KLE opmærkningen af en enhed kan have 3 forskellige betydninger 1. Enheden er den ansvarlige part for dette KLE emneområde og/eller den primære udførende for opgaver indenfor dette område 2. Enheden udfører opgaver indenfor dette område, men er ikke den primært ansvarlige 3. Enhedens medarbejdere skal have adgang til data opmærket med dette KLE, men udfører ikke nødvendigvis opgaver indenfor dette område OS2Opgavefordeler forholder sig til (1) i denne liste, dvs en opmærkning af en enhed med et givent KLE emneområde, vil blive tolket som at enheden er den primære udførende/ansvarlige enhed for dette område. Scenarie (2) i listen er interessant, da der er tilfælde hvor der er flere enheder der udfører opgaver indenfor samme KLE (fx indenfor skoleområdet, eller i tilfælde hvor man har teams på tværs af enheder der arbejder med samme opgaver). I anvendelsesscenarier hvor man ønsker at gøre brug af en sådan opmærkning, så vil OS2Opgavefordeler komme til kort med den nuværende datamodel. Det anbefales at undersøge om OS2Opgavefordeler kan udvides så flere enheder kan opmærkes med samme KLE, og hvilken indflydelse det vil have på OS2Opgavefordelers evne til utvetydig opgavefordeling. Se Anbefaling 7 for yderligere detaljer. 5.1 Anvendelse til autorisationsformål / adgangskontrol Den fælleskommunale rammearkitektur, specifikt som den er konkretiseret i støttesystemerne og dennes sikkerhedsmodel, baserer sig tungt på KLE som en parameter til at styre hvilke medarbejdere der må få adgang til hvilke data. Det vil være oplagt at genbruge det opmærkningsarbejde der er foretaget i OS2Opgavefordeler til at foretage adgangskontrol for medarbejdere. Det vil dog betyde at OS2Opgavefordeler enten direkte, eller indirekte, skal kunne understøtte scenarie (3) i tabellen ovenfor. Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 9 / 21

10 Der er en stor forskel i at være udførende indenfor et emneområde, og at have indsigt i data indenfor samme emneområde. I den nuværende datamodel i OS2Opgavefordeler er opmærkningen foretaget snævrere endnu, da der kun er tale om hvem der er den primært udførende indenfor et givent emneområde. Det vurderes dog at man kan implementere fornuftig adgangsstyring hvis blot OS2Opgavefordeler kan understøtte scenarie (2), dvs hvilke enheder der er udførende for et givent KLE emneområde. Samme anbefaling (Anbefaling 7) som tidligere kan løfte dette behov. 5.2 Anvendelse som autoritativ kilde til støttesystemet Organisation Den fælleskommunale rammearkitektur, her støttesystemet Organisation, agerer som integrationspunkt for it-systemer der skal bruge oplysninger om de enkelte myndigheders organisatoriske data. En af de oplysninger det er muligt at registrere og vedligeholde i støttesystemet Organisation er hvilke opgaver (KLE emneområder) de enkelte enheder varetager. OS2Opgavefordeler kan integrere (direkte eller indirekte via STSOrgSync) til de snitflader som støttesystemet Organisation udstiller, og enten agerer master for denne opmærkning, eller gøre brug af den opmærkning som myndigheden vedligeholder på anden måde. Det anbefales at undersøge om OS2Opgavefordeler skal sættes op som autoritativ kilde for KLE opmærkningen af enheder, og/eller om OS2Opgavefordeler skal trække på den eksisterende opmærkning (hvis en sådan findes). I begge tilfælde vil det dog kræve at OS2Opgavefordeler understøtter scenarie (2) i listen ovenfor. Se Anbefaling 9 for detaljer. Figur 3 - OS2Opgavefordeler som autoritativ kilde for KLE opmærkning af enheder 6 Rammearkitekturen og OS2Opgavefordeler Som allerede bemærket i afsnit 5.1 og afsnit 5.2, er der potentiale for synergi mellem OS2Opgavefordeler og støttesystemerne. Der er 3 yderligere funktionelle områder i OS2Opgavefordeler der kan integreres tættere med støttesystemerne, disse er Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 10 / 21

11 1) Brugerstyring, herunder administration af brugere, brugernes roller, og selve login proceduren 2) Opdatering og vedligehold af organisatoriske stamdata, herunder enheder og medarbejdere 3) Opdatering og vedligehold af KLE 6.1 Adgangsstyring via støttesystemerne I den fælleskommunale sikkerhedsmodel trækkes alt brugerstyring ud af de enkelte itsystemer, og udstilles i stedet via SAML 2.0. Effekten for OS2Opgavefordeler er at man kan fjerne hele brugerstyrings-elementet, og blot integrere til støttesystemet Context Handler, der er en SAML 2.0 Identity Provider. Rolle/rettighedsmodellen i den fælleskommunale sikkerhedsmodel kan favne den rettighedsmodel der eksisterer i OS2Opgavefordeler i dag. Se Anbefaling 10 for detaljer. Figur 4 - Brugerstyring via Context Handler 6.2 Adgang til myndigheders organisation via støttesystemerne På samme måde udstiller alle myndigheder deres organisatoriske stamdata via støttesystemet Organisation, og OS2Opgavefordeler kan trække de enkelte myndigheders organisatoriske stamdata ud via denne snitflade på den måde sikres det at OS2Opgavefordelers billede af myndighedernes organisation altid stemmer overens med resten af it-infrastrukturen i myndighederne. Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 11 / 21

12 Figur 5 - OS2Opgavefordeler henter myndighedens organisatoriske data fra Organisation Se Anbefaling 11 for detaljer. 6.3 Adgang til KLE emneindeks via støttesystemerne Endeligt udstiller KL hele KLE via støttesystemet Klassifikation, og OS2Opgavefordeler kan trække KLE ud via denne snitflade på den måde sikres det at OS2Opgavefordeler altid har et opdateret billede af hvilke KLE der er gyldige, og hvilke der er udgåede. Figur 6 - OS2Opgavefordeler henter KLE fra Klassifikation Se Anbefaling 12 for detaljer. 7 Sikkerhedsfejl i OS2Opgavefordeler Under reviewet af OS2Opgaverfordeler blev der konstateret nogle sikkerhedsfejl, som er beskrevet nedenfor. Det anbefales at disse sikkerhedsfejl rettes snarest, da de gør det muligt for 3.part at tilgå og ændre i de enkelte myndigheders opsætning af distributionsregler, samt modificere disse myndigheders registrering af organisatoriske data i OS2Opgavefordeler. 7.1 Registrering af brugernavne/kodeord i kodebasen I klassen ProviderRepository er der hardkodet 2 brugernavne/kodeord til at tilgå hhv Google Login og OS2 SSO. Det har været uklart under reviewet hvad disse brugernavne og kodeord skal bruges til, men i det tilfælde at de skal holdes hemmelige, bør de fjernes fra kodebasen, og kodeordene ændres. Se Anbefaling 13 for detaljer. Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 12 / 21

13 7.2 Manglende validering af kodeord i BasicAuthFilter OS2Opgavefordeler anvender HTTP Basic Authentication som autentifikationsmekanisme på de servicekald der foretages mod backenden. Klassen BasicAuthFilter er et servlet filter der validerer alle indkommende kald ved at kigge på det brugernavn/kodeord der medsendes som en HTTP header der følger med alle kald. BasicAuthFilter trækker brugernavn/kodeord ud af det indkommende request, validerer at de er tilstede og at de har den korrekte form, hvorefter den overlader selve valideringen til klassen AuthService. AuthService foretager ingen validering af brugernavnet og/eller kodeords gyldighed, så det er muligt at tilgå alle services med et vilkårligt brugernavn og kodeord. Det anbefales at der implementeres korrekt validering af brugernavn/kodeord i filteret, alternativt at der anvendes et framework til håndtering af sikkerhed i OS2Opgavefordeler. Se Anbefaling 4 og Anbefaling 14 for detaljer. 7.3 Mangelfuld validering af rettigheder OS2Opgavefordeler har en rolle/rettighedsmodel hvor den enkelte bruger kan tildeles en eller flere roller. Visse operationer kan kun udføres hvis man har en bestemt rolle tildelt. Eksempelvis udstiller klassen UserEndpoint en metode til at liste alle brugere der er oprettet i OS2Opgavefordeler. For at kunne kalde denne service, kræver det at man er tildelt rollen admin. Som nævnt i afsnit 3.2, så håndteres valideringen af om brugeren er tildelt den rette rolle i selve forretningslogikken, hvilket har resulteret i at den fornødne validering ikke er til stede i alle metoder. Som OS2Opgavefordeler håndterer autentifikation nu, skal den enkelte metode i SERVICE laget først validere om brugeren er logget på (hvis det er relevant for den givne metode) og efterfølgende om brugeren har den fornødne rolle tildelt. I flere metoder foretages der ingen validering, med den effekt at enhver kan kalde disse metoder direkte, uden at være logget på. Det gør sig fx gældende for UserEndpoint.java, metoden create(). Her er det muligt at oprette nye brugere (inkl at tildele dem rettigheder). MunicipalityEndpoint.java, metoden delete(). Her er det muligt at slette en hel myndighed, inkl myndighedens data. Ovenstående er blot 2 eksempler på mangelfuld validering af rettigheder, og det anbefales at alle metoder gennemløbes, og tilrettes så der udføres korrekt validering af rettigheder. Alternativt at der anvendes et framework til håndtering af rettighedsvalidering. Se Anbefaling 4 og Anbefaling 14 for detaljer. For at teste ovenstående sikkerhedsfejl, er metoden create() på UserEndpoint blevet anvendt i OS2Opgavefordelres test-miljø, for at oprette en bruger med administrator rettigheder, og efterfølgende er denne bruger blevet brugt til at kalde services der kræver administrator adgang, med succes. Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 13 / 21

14 7.4 Anvendelse af bruger-input direkte i SQL statements I klassen MunicipalityEndpoint genereres der en række SQL statements, hvor disse statements opbygges via konkatenering af tekststrenge, hvori input direkte fra REST kaldet indgår. Dette er en klassisk angrebsvektor for SQL Injection, og man bør altid anvende de mekanisme (fx PreparedStatements) som ens SQL framework tilbyder. I dette tilfælde er det eneste brugerinput tal, så der vurderes ikke at være nogen større risiko i dette tilfælde, men det anbefales dog stadig at undlade at anvende streng konkatenering til opbygning af SQL statemens. Se Anbefaling 16 for detaljer. 8 Konklusion og opsummering på anbefalinger Som nævnt i introduktionen, er OS2Opgavefordeler generelt bygget efter sunde principper og med moderne og vedligeholdelsesvenlige teknologier, og det vurderes at løsningen kan finde anvendelse både som autoritativ kilde til KLE opmærkning af enheder, samt som datagrundlag til adgangsstyring på KLE niveau. Der er nedenfor listet en række anbefalinger, som der er refereret til i løbet af dokumentet. Flere af disse anbefalinger er alene med til at øge kvaliteten af kodebasen, og dermed reducere vedligeholdelsesomkostninger på sigt. Disse anbefalinger kan implementeres over tid, og har ikke nogen kritisk karakter. Følgende anbefalinger har dog en mere kritisk karakter, og det anbefales at de behandles som nogen af de første. Anbefaling 4Anbefaling 7 Anvendelse af frameworks til at håndtere tværgående funktionalitet Anbefaling 7 understøtte flere enheder kan opmærkes med samme KLE Anbefaling 13 fjerne hardkodede kodeord fra kodebase Anbefaling 14 korrekt validering af brugernavn/kodeord Anbefaling 15 korrekt validering af brugeres rettigheder Anbefaling 17 højne dokumentationsniveauet 8.1 Anbefalinger Nedenfor er listet de anbefalinger dette review er kommet med til OS2Opgavefordeler. Anbefaling 1 Beskrivelse: Split OS2Opgavefordeler op i flere kodemoduler OS2Opgavefordeler anvender i forvejen Maven som byggeværktøj, og Maven tilbyder muligheden for at opsplitte sit projekt i flere moduler. Hver modul kan så opsættes med afhængigheder til en eller flere af de andre moduler. Det anbefales at splitte backenden op i 3 moduler, ét for Controller laget, ét for Service laget og endeligt ét for Model laget. Hvis muligt, opbyg afhængighederne mellem moduler, så Controller laget er afhængig af Service laget, og Servicelaget er afhængig af Model laget. Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 14 / 21

15 Hermed sikres det at de underliggende lag ikke kommer til at kalde tilbage i de overliggende lag (fx at Service laget kalder funktionalitet i Controller laget). En adskillelse mellem lagene gør det lettere at vedligeholde de enkelte lag, da risikoen for uhensigtsmæssige afhængigheder på tværs af lagene reduceres. Anbefaling 2 Migrer frontenden til AngularJS 2 Beskrivelse: Google (der står bag AngularJS) er midt i en migrering fra AngularJS 1 til 2, og det forventes at den løbende udvikling af AngularJS 1 reduceres betragteligt, med den tilhørende risiko for at rettelsen af fejl og mangler (herunder sikkerhedsfejl) i AngularJS 1 vil blive nedprioriteret fra Googles side. Det anbefales at opgradere frontenden til AngularJS 2, eller løbende holde øje med de udmeldinger der måtte komme fra Google vedrørende AngularJS 1. Anbefaling 3 Beskrivelse: Anvend framework til auto-generering af boiler-plate kode Der findes en række letvægts frameworks til Java, der kan generere de fleste typer af boiler-plate kode. En af de mere modne af disse er Project Lombok ( der har over 7 år på bagen, og er tilgængelig som en Maven dependency. Lombok (og tilsvarende frameworks) fungerer ved at scanne koden for annoteringer, og så autogenerer den nødvendige boiler-plate kode på kompileringstidspunktet. Lombok har ligeledes plugins til de fleste IDE er, så den autogenererede kode bliver synlig for IDE et mht auto-completion m.m. Anvendelsen af en af disse frameworks til autogenerering af boiler-plate kode vil både reducere den kodebase der skal vedligeholdes i OS2Opgavefordeler, men vil også kunne sikre eksistensen af Fluint Builders, fornuftige tostring() metoder m.m. på alle relevante klasser. Anbefaling 4 Beskrivelse: Anvend framework til håndtering af tværgående funktionalitet OS2Opgavefordeler håndterer både fejl- og tracelogning, auditlogning, autentifikation og autorisation som en del af forretningslogikken, hvilket gør koden mindre læsbar og mindre overskuelig, men også introducere en forhøjet risiko for fejl og mangler i implementeringen af denne tværgående funktionalitet. OS2Opgavefordeler anvender JBoss CDI (Context and Dependency Injection) til at sikre løse koblinger mellem de enkelte software komponenter, hvilket betyder at OS2Opgavefordeler med fordel kan anvende CDI s understøttelse for Crosscutting Concerns via Interceptors. Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 15 / 21

16 En kort introduktion til Crosscutting Concerns i CDI kan findes her 2. Et alternativ til CDI er Spring, der kan løfte de samme udfordringer via Interceptors og Spring AOP. Tracelogning kan håndteres via simple interceptors, der kan logge alle kald (inkl input/output) til metoder i koden, og konfigurationen af disse interceptors kan holdes helt adskilt fra resten af kodebasen, og enables/disables efter behov. På samme måde kan sikkerhed håndteres via annoteringer af de enkelte metoder, der angiver hvilket sikkerhedsniveau (og roller) som er krævet for at kalde metoden, og så lade en af disse frameworks (Spring Security eller den tilsvarende CDI kompatible udgave) håndtere håndhævelsen. Interceptors på DAO klasserne kan også være med til at understøtte logning af hvem der tilgår og/eller ændrer i data, uden at dette skal håndteres af forretningslogikken. Anbefaling 5 Beskrivelse: Systematisk gennemgang af systemloggen Det primære formål med systemloggen er at understøtte hurtig og effektiv fejlsøgning i tilfælde af supportsager. OS2Opgavefordeler bør logge alle afvigelser fra standard flowet i koden, med relevante oplysninger om hvorfor der blev afveget fra standard flowet. Hermed kan man hurtigt afgøre hvad der er gået galt, når en bruger oplever at systemet ikke opfører sig som ønsket. Specielt hvis antallet af brugere af systemet øges, kan det blive mere kritisk at sikre at den fornødne logning er på plads, da omkostningerne til fejlsøgning ellers kan stige unødigt. Anbefaling 6 Beskrivelse: Systematisk gennemgang af auditloggen Alle sikkerheds- og audithændelser bør logges, herunder Alle login forsøg (fejlede såvel som succesfulde) Alle ændringer af data i systemet (hvem ændrede hvilke data hvornår) Hvis Anbefaling 4 implementeres kan man anvende den tilgang til at sikre at dette sker, ellers bør man tilføje den fornødne logning både til sikkerhedsfilteret, samt til forretningslogikken, så der auditlogges alle relevante steder. Anbefaling 7 Beskrivelse: Undersøg om flere enheder kan opmærkes med samme KLE For at understøtte de i afsnit 5 nævnte anvendelsesområder, bør OS2Opgavefordeler udvides med mulighed for at opmærke flere enheder med samme KLE. 2 Development/ /2/ch02lvl1sec22/CDI%20and%20crosscutting%20concerns Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 16 / 21

17 Da OS2Opgavefordelers primære forretningsfunktionalitet er utvetydig opgavefordeling på baggrund af KLE, er det nødvendigt at sikre at denne funktionalitet stadig er mulig. Der er forskellige tilgange til at løse opgaven, nedenfor listes 2 mulige løsninger, som bør undersøges nærmere (bl.a. for hvilke omkostninger der er forbundet med de enkelte løsninger, og hvilke konsekvenser det kan have for brugeroplevelsen af systemet) Løsning 1 angivelse af primær enhed OS2Opgavefordeler udvides, så det er muligt at have mere end én enhed der er ansvarlig for et givent KLE emneområde. For at sikre utvetydig opgavefordeling, skal præcis én af disse opmærkninger angives som værende den primære. - Første gang et KLE tildeles til en enhed bliver den automatisk den primære tildeling - Ved efterfølgende tildeling af samme KLE til andre enheder, angives dette som værende en sekundær tildeling - Det er muligt på en sekundær tildeling at ændre denne til den primære tildeling, hvorefter den tidligere primære tildeling ændres til en sekundær (så det sikres at der altid er præcis én primær tildeling) - Opgavefordeling vil se bort fra sekundære tildelinger, og kun anvende de primære tildelinger - REST services udvikles der tillader opslag hvor også sekundære tildelinger fremgår som output Denne løsning vurderes at være den nemmeste løsning, og vil have den mindste indflydelse på brugergrænsefladen, og dermed brugeroplevelsen. Det antages dog at alle myndigheder ønsker at postfordeling skal ske via en primær tildeling, og at denne primær/sekundær opdeling kan dække fremtidige behov. Løsning 2 rolleopmærkning af KLE tildelinger OS2Opgavefordeler udvides, så der ved hver tildeling af KLE til en enhed knyttes en rolle til tildelingen. Rollen angiver hvordan tildelingen skal fortolkes. - Der skal udvikles funktionalitet til at oprette og vedligeholde KLE roller, herunder hvilke restriktioner en given rolle lægger ned over en tildeling (fx skal det være muligt at angive at en rolle er en unik restriktion, dvs at denne rolle sikrer en entydig tildeling af KLE til en enhed) - Ved hver tildeling af KLE til en enhed, skal der angives under hvilken rolle tildelingen er foretaget - REST services der laver opslag på KLE, skal tage højde for roller (fx ved at man kan angive en rolle som opslagsparameter, og så ser man det specifikke view i udtrækket). Et eksempel kan fx være Postfordeling, hvor rollen tvinger tildelingen til at være unik, dvs at et givent KLE kun kan tildeles én enhed (under rollen Postfordeling ). Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 17 / 21

18 Denne løsning er en udvidelse af løsningsmodel 1, og vurderes at have en større indflydelse på brugergrænsefladen, og dermed den brugeroplevelse som slutbrugerne udsættes for. Til gengæld sikrer den en højere fleksibilitet for den enkelte myndighed (hvor løsningsmodel 1 mere er en one-size-fitsall tilgang). Anbefaling 8 Beskrivelse: Lav en vurdering af hvilke TODOs i kodebasen der skal adresseres Der er nogle enkelte TODO s i koden som peger på planlagt funktionalitet, der bør være på plads inden ibrugtagning i produktion. Følgende TODO s vurderes at have højeste prioritet. OrgUnitServiceImpl.java (metoden importorganization) KleServiceImple.java (metoden storeallklemaingroups) DistributionRuleEndpoint.java (metoden allowedtoupdate) Anbefaling 9 Beskrivelse: Autoritativ kilde til KLE opmærkning af enheder i Organisation Over tid vil kommunerne i Danmark blive bedt om at opmærke deres organisation med KLE, og registrere disse oplysninger i støttesystemet Organisation. OS2Opgavefordeler er en oplagt autoritativ kilde til dette, da den allerede anvendes til opmærkning af enheder med KLE. Det anbefales at planlægge OS2Opgavefordeler ind i registreringsflowet mod støttesystemet Organisation, og overveje anvendelsen af STSOrgSync som synkroniseringsmekanisme, så det sikres at organisationsdata synkroniseres via 1 kanal. Anbefaling 10 Anvend støttesystemerne til brugerstyring Beskrivelse: En af præmisserne ved støttesystemerne er at deres værdi stiger jo flere systemer der anvender dem. Udvikling og vedligehold af brugerstyringsløsninger i de enkelte fagsystemer er en omkostning som er unødvendig, givet at støttesystemerne tilbyder funktionalitet til at håndtere dette. Samtidig giver det den enkelte kommune ét samlet sted at håndtere rettighedstildeling, samt ét sted at få et overblik over de rettigheder som den enkelte medarbejder er tildelt. OS2Opgavefordeler bør integrere til støttesystemernes adgangsstyringsløsning, herunder at anvende den fælleskommunale rettighedsmodel. Den nuværende rettighedsmodel i OS2Opgavefordeler kan nemt indeholdes i den fælleskommunale, og man kan fjerne hele Bruger begrebet fra OS2Opgavefordeler efterfølgende. Støttesystemerne anvender SAML 2.0 som føderationsteknologi, og stiller en SAML 2.0 Identity Provider (kaldet Context Handleren) til rådighed, der kan autentificere alle 98 kommuners medarbejdere, samt udstille brugerens Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 18 / 21

19 rettigheder overfor OS2Opgavefordeler (sættet af roller som OS2Opgavefordeler understøtter skal registreres i støttesystemerne). Anbefaling 11 Anvend støttesystemerne til vedligehold af organisatoriske data Beskrivelse: OS2Opgavefordeler udstiller i dag snitflader til indlæsning af organisatoriske data. Kommunerne skal i forvejen registrere deres organisatoriske data i støttesystemet Organisation, hvor fagsystemerne skal hente dem fra. OS2Opgavefordeler kan hente disse organisatoriske data på lige fod med andre fagsystemer, og kan efterfølgende nedlægge de snitflader der udstilles til vedligehold af organisatoriske data. Dette reducerer samtidig den enkelte kommunes implementeringsopgave, da de ikke længere skal læse deres organisatoriske data ind i OS2Opgavefordeler for at anvende løsningen. Det bemærkes at der er et gap mellem de data som pt er registreret i OS2Opgavefordeler, og de oplysninger der er registreret i støttesystemet Organisation, specifikt de oplysninger der vedrører ESDH. Det bør undersøges hvordan dette gap lukkes hvis denne anbefaling implementeres. Anbefaling 12 Anvend støttesystemerne til vedligehold af KLE Beskrivelse: OS2Opgavefordeler udstiller i dag snitflader til indlæsning af KLE. Støttesystemet Klassifikation udstiller KLE via en servicesnitflade, og OS2Opgavefordeler bør hente KLE via disse snitflader, da det bliver den officielle kanal for KLE i fremtiden. Anbefaling 13 Fjerne hardkodede kodeord fra kodebasen Beskrivelse: Der ligger i klassen ProviderRepository.java 2 hardkodede brugernavne og kodeord, som bør flyttes til en konfigurationsfil, der anvendes i driften af løsningen. Kodeord m.m. bør efterfølgende skiftes, da de har været publiceret på et offentligt tilgængeligt website. Anbefaling 14 Lav korrekt validering af brugernavn/kodeord Beskrivelse: Klassen BasicAuthFilter er et såkaldt Servlet filter, der inspicerer alle indkommende kald mod backenden. Dette filter antyder at det laver en validering af det medsendte brugernavn/kodeord, men det er ikke tilfældet. Resultatet er at alle services kan kaldes, hvad end man har angivet et validt brugernavn/kodeord eller ej. Backend koden kalder ofte blot metoden isauthenticated på AuthService, der blot checker om der var angivet et brugernavn i kaldet. Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 19 / 21

20 BasicAuthFilter bør foretage en hård validering af det medsendte brugernavn/kodeord, og afvise kald hvor der ikke angives et brugernavn/kodeord, hvor brugernavnet ikke eksisterer eller hvor kodeordet er forkert. I de tilfælde hvor der er services der skal tilgås uden brugernavn/kodeord, så kan de placeres på et endpoint der ikke beskyttes af BasicAuthFilter. Alternativt så kigges på Anbefaling 4, og så i stedet anvende et framework til håndtering af autentifikationen. Anbefaling 15 Lav korrekt validering af brugeres rettigheder i SERVICE laget Beskrivelse: Mange af metoderne i Service laget foretager ikke nogen validering af om brugeren har de fornødne rettigheder (korrekt rolle tildelt). De forskellige metoder i Service laget bør gennemgås, og der bør laves en konkret vurdering af hver enkelt metode, om hvilken rolle brugeren skal have for at kalde denne metode, og så håndhæves autorisationen ud fra dette. Alternativt så kigges på Anbefaling 4, og så i stedet anvende et framework til håndtering af autorisation. Anbefaling 16 Anvend ikke tekst konkatenering til SQL statements Beskrivelse: OS2Opgavefordeler anvender i stort omfang statements, hvor variable korrekt anvendes via parametre til det opbyggede SQL statement. Der er dog et enkelt sted i koden hvor der anvendes streng konkatenering i stedet. Dette bør rettes for at undgå potentielle SQL Injection angreb. Se MunicipalityEndpoint.java. Anbefaling 17 Højne dokumentationsniveauet Beskrivelse: Der bør udarbejdes følgende dokumenter for OS2Opgavefordeler Installationsvejledning. Dokumentet bør dække alle nødvendige trin for at kunne installere softwaren. Dette inkluderer at bygge kodebasen, pakke resultatet ind i et Docker image, og deploye dette Docker image i et rigtigt produktionsmiljø. Eksterne afhængigheder, fx databaser m.m. bør ligeledes dokumenteres, så en 3.part kan installere softwaren uden yderligere kendskab til løsningen end den der står i dokumetationen. Driftsvejledning. Dokumentet bør dække over relevante områder for succesfuld drift at løsningen, herunder dokumentation af logfiler, konfiguration af driftsparameter (logniveau, tracing m.m.), certifikater der skal overvåges, endpoints der skal overvåges, samt typiske fejlsituationer og hvordan disse håndteres. Løsningsbeskrivelse. Dokumentet bør beskrive løsningens forretningsområde, så en ikke-teknisk person kan læse og forstår hvad OS2Opgavefordeler er, og hvilket forretningsdomæne den hører til, og hvilke opgaver løsningen anvendes til. Arkitektur og kode. Dette dokument bør beskrive selve den tekniske løsning på et niveau, så en kompetent udvikler kan trække koden ud fra Github, opsætte et udviklingsmiljø og påbegynde Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 20 / 21

21 videreudviklingen af løsningen uden først at skulle bruge uhensigtsmæssigt meget tid på at læse og forstå koden. Anbefaling 18 Bygge OS2Opgavefordeler inde i Docker containeren Beskrivelse: OS2Opgavefordeler anvender Docker som deployment mekanisme, men bygger stadig kodebasen på udviklerens maskine. Docker er også anvendelig som et byggemiljø, og ved at bygge kodebasen på samme miljø som det skal afvikles på, kan man reducere evt risici for manglende afhængigheder m.m. Samtidig gør det det også muligt at bygge løsningen alene ved hjælp af værktøjer, så byg og deployment kan ske uden installation af udviklingsværktøjer. Digital Identity ApS, Hasselager Centervej 17,1, 8260 Viby J 21 / 21