Unilogin, klasselister og netværk

Unilogin er den fælles danske løsning, som skoler og uddannelsesinstitutioner bruger til at logge elever og ansatte ind med. Eleven bruger altså den konto, skolen allerede har givet dem, og skolen skal ikke oprette endnu et login til os.

Vi bruger login-tjenesten til at få svar på ét spørgsmål: hvem er det her? Identiteten, vi gemmer, er den identifikator tjenesten giver tilbage. Vi behandler den som en nøgle til at logge ind. Den er aldrig en tilladelse til at se noget.

Klasselisterne kommer fra skolens eget brugerregister. Der er to veje ind, og skolen vælger den, der passer til dens opsætning.

• Synkronisering, når skolen har en binding hos UNI-Login eller EasyIQ. Skolen henter elever og lærere fra sit brugerregister, og hver kørsel gemmes med sin liste over hvad der blev tilføjet, ændret eller stod i konflikt.
• Import af en CSV-fil, som skolen selv kører. Den kan bruges uden en udbyderbinding, og den viser først en gennemgang af rækkerne, før noget skrives.

Synkroniseringen kører som et planlagt job, og skolen kan også starte en kørsel manuelt. Hvor ofte jeres job kører, er en aftale mellem skolen og udbyderen af skolens register - vi offentliggør ikke et fast interval, fordi vi ikke vil love en kadence, vi ikke styrer.

Status på den seneste kørsel står på udbyderkortet sammen med tidspunktet for den, så en kørsel der ikke gik igennem, kan ses i stedet for at blive læst som en liste, der bare ikke ændrede sig.

Der er tre situationer, og de har hver sit svar.

• Eleven står ikke i registeret endnu. Synkroniseringen rapporterer forskellen, så skolen kan se præcis hvad der blev tilføjet, ændret eller stod i konflikt - i stedet for at opdage det på eksamensdagen.
• Eleven er stoppet på skolen. Kørslen viser ændringen med tidsstempel, og brugeren kan sættes inaktiv på skolen med det samme. Data kan samtidig slettes før opbevaringsvinduet udløber, og sletningen kvitteres.
• Eleven har ikke noget Unilogin. Så kan eleven ikke komme ind den vej. Skolens administrator opretter en lokal konto i stedet - se afsnittet nedenfor.

Rettelser i ExamWatcher vinder over registeret: en klasse, skolen selv har rettet, bliver ikke overskrevet af den næste synkronisering. Konflikten vises som et badge på det felt, der ellers ville være ændret, så skolen kan se hvad den har tilsidesat.

Det giver en forholdsvis enkel arbejdsdeling.

• Det kan skolen rette selv: en klasse eller et navn, der står forkert i ExamWatcher, om en bruger er aktiv eller inaktiv, og brugere skolen opretter i hånden eller importerer fra en CSV-fil.
• Det kræver kilden: selve klasselisterne, som kun kommer ind via en synkronisering eller en import, UNI-Login-bindingen, som er en aftale mellem skolen og UNI-Login, og et login eleven ikke har.

En lokal konto oprettes af skolens administrator og består af et brugernavn og en adgangskode. Den er til elever og ansatte, der ikke kan eller skal bruge UNI-Login.

De to ting forholder sig sådan til hinanden: en person kan i stedet have en lokal konto, og adgangskoden ligger da som et hashet felt på netop den konto. En person, der kun logger ind via UNI-Login, har slet ingen adgangskode hos os - den findes ikke. En adgangskode til en lokal konto udleveres af skolen og kan nulstilles af skolen.

Vælger eleven MitID, sker det inde i UNI-Login. Der er ikke en selvstændig MitID-metode hos os endnu: vores konti kender UNI-Login og lokale konti, og hvordan MitID skal kobles på vores brugerkonti, er en åben beslutning i teamet, ikke en funktion, der er på vej ud.

Der er heller ikke et sted i skolens overblik, hvor I selv kan slå en MitID-politik til. Indtil det er besluttet, er svaret på et MitID-krav: brug UNI-Login, og skriv til os, før I beslutter jer, hvis MitID er et ufravigeligt krav fra jeres side.

Det vi kan oplyse om status, er det, der står på driftsstatussen, og det vi ikke kan oplyse, skriver vi om på kontaktsiden. Vi sætter ikke en dato på MitID, fordi vi ikke har en.

Klienten kræver ikke en permanent forbindelse. Mister en computer nettet under et forløb, registrerer den videre og lægger data i kø lokalt, og når forbindelsen kommer tilbage, uploades det, der mangler.

Tidsrummet uden forbindelse vises som et hul i tidslinjen. Et hul er en registreret hændelse og ikke en fejl i gennemgangen, og vi udfylder det aldrig med gætteri eller sammenhængende data - hullet skal kunne ses af den, der læser forløbet bagefter.

1. 01

   Aftal hvem der ejer klienten

   Klienten installeres centralt af skolens IT-ansvarlige. Aftal hvem der udruller den, og hvem læreren ringer til, hvis en maskine ikke melder ind.

2. 02

   Beslut opbevaringsvinduet

   Vinduet sættes, før den første eksamen afvikles, fordi det er det, eleven skal informeres om. Standard er tre måneder.

3. 03

   Få klasselisterne ind

   Kør en synkronisering, hvis skolen har en UNI-Login-binding. Ellers importerer I en CSV-fil med elever og lærere og retter listen manuelt bagefter.

4. 04

   Kontrollér rækkerne bagefter

   Hver synkronisering gemmes med sin ændringsliste, så I kan se hvad der blev tilføjet, ændret eller stod i konflikt, før den første eksamen bruger listen.

5. 05

   Sæt en lokal konto op til de elever, der mangler

   En elev uden skolekonto kan ikke komme ind via UNI-Login. Skolens administrator opretter en lokal konto i stedet - adgangskoden udleveres af skolen.

6. 06

   Informér eleverne

   Skolen er dataansvarlig og skal informere om, hvad der registreres og hvorfor, inden eksamen starter.