Designdokument eValg

Detaljert og teknisk oversikt over løsningen eValg - elektronisk valg for universitet og høgskoler.

Innledning

eValg skal gjøre det enkelt å gjennomføre valg på universitet og høgskoler elektronisk. Dette styrker både integriteten, anonymiteten og ressursbruken i gjennomføring av valg, sammenlignet med papirstemmer.

Løsningen har et nettbasert grensesnitt for velgerene, og et eget for valgadministratorene. Pålogging gjøres med Feide. I tillegg har valgadministratorene en opptellingsløsning som er en java-applikasjon. Funksjonalitet som eValg støtter:

  • Valgadministratorer kan opprette valg, av ulike valgtyper
  • Velgere kan stemme
  • Valgadministratorer kan telle opp valget, og få ut sluttresultat og valgprotokoll

Se mer om eValg i BNT sin applikasjonsoversikt.

Kontaktpunkt

Primært kontaktpunkt for eValg-løsningen er evalg-drift@usit.uio.no. For spørsmål relatert til valgprosessen: valgsekreteriatet@admin.uio.no.

USIT, ved seksjonen Integrasjoner og elektroniske identiteter (INT), er systemeier for eValg, mens Avdeling for personalstøtte (AP) er prosesseier for den overordna valgprosessen ved UiO. eValg bidrar bare i selve gjennomføringen og opptellingen av valget, mens valgstyrer tar seg av forberedelser og publiseringen i etterkant.

Redegjørelse

Datamodellen ble modellert etter UiOs reglement i 2006. Når andre senere skulle bruke systemet, ble det gjort avsjekk mot dette, og kunden kunne i de fleste tilfeller akseptere føringer basert på dette.

Valgreglementer har en sterk føring på hvordan eValg skal oppføre seg. Hvert universitet har sitt eget valgreglement, som må vere i henhold til føringer fra Universitets- og høyskolelova.

Bakgrunn

I 2006 (efter sterkt påtrykk fra studentene) besluttet Universitetsstyret at man skulle implementere elektronisk valg ved UiO. Dette ble gjort ved en utviklingsoppgave, og Rune Frøysa ble gitt oppgaven å skrive dette. Ettersom Rune Frøysa i skrivende stund ikke lenger er tilsatt ved UiO, finnes ingen begrunnelser for de designvalg som ble tatt.

Tidligere var valgene arrangert (for studenter) som urnevalg eller (for ansatte) som postvalg. For studentene var avkryssing i manntallet ekvivalent med å få et kryss på semesterkortet, noe som ikke akkurat sikrer at ingen får stemt flere ganger. Ansatte ville putte stemmeseddel i en konvolutt og sende den i internposten. Løsningen med elektronisk valg øker dermed sikkerheten i valget (gitt at velgerne ikke påvirkes av frykt for elektroniske løsninger). Anonymt valg fungerte for studentene på samme måte som stortings-, fylkestings- og kommunevalg, men for de ansatte var det mulige forbedringer på dette området.

Opptelling av papirstemmer er noe som tar tid – spesielt når man har et komplisert opptellingsreglement, som preferansevalget vårt (single transferable vote/STV) er. Adskillige opptellingstimer er spart, og datamaskiner regner ikke feil (gitt at program og maskinvare er korrekt nok).

Versjon 1 ble laget i 2006 av Rune Frøysa. Robert Bauck Hamar tok over stort sett all utvikling av prosjektet, og gikk mot versjon 2, som hadde mer modularisert kode og en litt endret datamodell. (Versjon 1 støttet kun to valgtyper, implementert ved «if type = L then listevalg else preferansevalg

Stemmegivning

Stemmegivningen i eValg baseres på web-løsning. Utformingen av denne har en del føringer: krav til stemmesedler i valgreglementer, samt web accessability guidelines. Det bør også kunne håndteres av alle mulige enheter og brukerinnstillinger, derfor er det f.eks. ikke brukt JavaScript i opptellingsmodulen.

For å ivareta anonymiteten til velgerene så langt det lar seg gjøre, vil alle stemmesedler bli asynkront kryptert. Valgstyret som administrerer et valg tar vare privatnøkkelen, eValg har ikke tilgang til denne og kan derfor ikke se hva som er stemt etter at det er lagret. Det skal vere mulig for personer å levere en ny stemme, som overskriver den gamle, som gjør av eValg må ta vare på en kobling mellom person og stemmeseddel. Ved opptelling vil eValg levere en dump av alle stemmesedler, men der koblingen mellom person og stemmeseddel er brutt.

Brukerroller

Applikasjonen sine primære brukerroller, definert utfrå Scrum og «suksess for produktet»:

  • Velgar [ODT] (alle som vil/kan avgje stemme)
    • Funksjonsnedsett velgar
    • Velgar utanfor eller i feil manntal
  • Valarrangør [ODT] (alle som (med)arrangerer eit val)
    • Valadmin (full tilgang til eit val)
    • Stemmerevisor (begrensa tilgang til å vurdere om stemmesedlar er gyldige - manntal)
    • På-vegne-av-operatør (tilgang til å legge inn papirstemmer på vegne av andre)
  • Kontrollør [ODT] (alle som vil sjekke at løysing/val er etterretteleg/truverdig)
    • Intern kontrollør (med taushetsplikt)
    • Ekstern kontrollør (inkludert presse, myndigheter, men også privatpersonar)
  • Kunde (alle som bestemmer i løysinga)
    • Sentralt valstyre
    • Sentralt valsekretariat
    • UH-kunde
    • Studentparlamentet

Se også referat fra workshop 1 og workshop 2.

Mangler

Datamodellen har flere tabeller for kandidater, skjønt listevalg+ kan være fleksibelt nok til alle.

Alle kandidater ligger også i Person_info. Men det forekommer ofte nok at en kandidats navn i FS e.l. ikke er det han/hun bruker og ønsker å stille med. Ved enkelte institusjoner er dette løst ved å sette inn egne personobjekter (pid like 'candidate-%', f.eks.) for kandidaten.

Mangler funksjonalitet i brukergrensesnittet for:

  • Opplasting av persondata
  • Legge inn personer («personer») manuelt
  • Håndtere tilganger
  • I tillegg til at admingrensesnittet er dårlig designet.

Deler av brukergrensesnittet (f.eks. stemmegivning) bærer preg av å være designet av komité; valgreglementer stiller krav som om det var papirvalg, og enkelte med ansvar synes wall of texts er god idé.

Kjønnskvoteringstabellene er tilpasset UiOs preferansevalgreglement, og det har klare mangler i å spesifisere regler for varaer.

Vektede stemmer er i datamodellen angitt med et tall. Det finnes andre mer kompliserte vektingsregler som ikke er mulig:

  • Institusjon X er spredd over flere steder (fusjon av to høyskoler, f.eks.)
  • De ønsker vekting ikke bare basert på kategori, men også en overordnet vekting av stedene, slik at lillebror ikke blir overkjørt.

Det har forekommet med flikking at noen har klart å slette kandidater, og opprettet på nytt med annen kandidatid etter at noen har stemt på kandidaten. I så måte burde det ikke slettes rader fra kandidattabellene.

Struts, eValg bruker Struts 1, er ett av flere biblioteker som implementerer MVC-modellen i Java. Struts 1 har nådd end of life, så det er på tide å gå over til noe annet, f.eks. Struts 2.

Detaljebeskrivelse

Se INTs miljøoversikt for navn på maskiner og tilganger.

Høynivådesign

Forenkla systemoversikt

Datamodell

datamodell.png

Merk: Databasen inneholder ikke stemmesedlene. Dette er et bevisst valg.

Valgprosessen

Overordna og ideell valgprosess, der valgadministrator gjør det meste selv (mørkeblå bokser markerer hva eValg gjør). Vanligvis gjør USIT mesteparten av det som går direkte mot eValg-løsningen.

eValg tar bare for seg en del av en større valgprosess. Informasjon utad, innsamling av kandidater og publisering av valgresultat er noen elementer som ligger utenfor eValg.

Valgadministratorer har tilgang til å sette opp og gjennomføre valg i eValg, men i de fleste tilfeller er det USIT som gjør dette for valgarrangører. Overordna prosess:

  1. Valgarrangør ber om oppretting av valg i et nettskjema, med tidspunkt for valget og andre relevante opplysninger.
  2. Valgarrangør sender inn liste over kandidater og manntall, når frist for nominering av kandidater er passert.
  3. INT oppretter valget, med kandidater, manntal og andre innstillinger. Valgnøkkel til blir evt. generert, med passord.
  4. Valgarrangør informerer og gjennomfører valget.
  5. Valgstyret går gjennom stemmesedler utenfor manntallet, og avgjør om de skal telle med eller ikke. Dette gjørest eventuelt i samarbeid med INT.
  6. INT og valgstyret teller opp valget, via e-post, telefon eller i møte - dette varierer fra enhet til enhet. INT overleverer valgprotokoll til valgstyret.
  7. Valgstyret godkjenner om valget har gått riktig for seg.
  8. Valgarrangør publiserer valgresultatet.

Se brukerveiledning i å arrangere valg for flere detaljer.

Lavnivådesign

Systemets hovedfunksjon er en Java servlet som kommuniserer med en Postgresdatabase. GnuPG må være installert på maskinen som kjører valg. Denne håndterer blant annet opptelling og import av personer.

Nettsidene er utviklet med Java, og følger standard måte å lage nettsider i java på:

  • Man pakker sammen en war-ball (zip-fil med spesifisert struktur og filefternavn «.war», for web archive)
  • War-filen gis til en servlet container, som f.eks. Resin eller Tomcat. (Det finnes flere også)
  • WEB-INF/classes/ legges inn i classpath av servlet container
  • WEB-INF/libs/ inneholder jar-filer som også legges inn i classpath
  • WEB-INF/web.xml leses inn spesifisert format av Sun/Oracle/Java (kall det hva du vil).
  • JSP-filer i warballen kompileres først til Java-kode, som så kompileres til java byte code.

I web.xml gjør vi følgende:

  • Definerer en servlet for biblioteket struts. Alle requests til urler som matcher *.do i stien, vil sendes til org.apache.struts.action.ActionServlet, denne leser WEB-INF/struts-config.xml for å mappe stier til klasser.
  • I tillegg har vi også en servlet for OIOSAML, som er en wrapper rundt OpenSaml. alt som havner under $SERVLET_ROOT/saml/ sendes til OIOsamls dispatcher.
  • Struts definerer også egne tags i JSP-filene, gjennom taglibs.

Det som ellers ligger i roten av warballen vil serves som normalt av en http daemon.

Flyt av HTTP request via Struts:

request.png

Avhengigheter

Prosjektet avhenger av en del eksterne biblioteker, som listet opp i byggescriptet, build.gradle. Det kjøres som en Java servlet, og bruker Resin som servlet container (men dette bør kunne byttes ut).

Databasen er Postgresql, men det er lite som avhenger spesifikt av Postgres.

Til autentisering brukes SAML 2.0. Systemet var i utgangspunktet skrevet med antagelsen at fødselsnummer vil være bijektiv for personer. Som backup bør man kunne bruke feide-id, men denne er ikke injektiv.

Lenker og referanser

Publisert 4. sep. 2018 11:29 - Sist endret 20. feb. 2023 21:27