Udveksling af login- og brugeroplysninger mellem Odense Kommunes brugerkatalog og Google Apps skoleløsning Version 1.0, 30.

Transkript

1 Udveksling af login- og brugeroplysninger mellem Odense Kommunes brugerkatalog og skoleløsning Version 1.0, 30. september 2010 Dette dokument giver et kort overblik hvordan brugeroplysninger i Odenses løsning oprettes og vedligeholdes samt den tilhørende login-løsning (der anvendes til autenticitetssikring ). Der foretages en beskrives af de trin, som bør indgå i en vurdering af autenticitetssikringens styrke, og disse trin perspektiveres i forhold til Odenses løsning, Gratis-udgaven af, samt den gratis Gmail-tjeneste, som alle frit kan anvende. Løsninger til udveksling af data vedrørende brugere og autenticitetssikring mellem Odense kommune og Odenses brugere er registreret i kommunens brugerkatalog (fremover kaldet Active Directory) med brugernavn og kodeord. Active Directory indeholder også en række grupper, som er relevante for løsningen. Active Directory er den autoritative kilde i Odense i forhold til oprettelse, vedlighold, nedlæggelse og gruppetilhørsforhold for brugere. I forhold til er der to former for integration til Active Directory Provisionering overførsel og opdatering af brugeroplysninger fra Active Directory til Autenticitetssikring (login) Brugerne verificeres i mod Active Directory og i tilfælde af succesfuld login overføres information om hvilken bruger der er logget ind til De tekniske komponenter i disse integrationer er vist på figuren nedenfor Flowet i forbindelse med de aktuelle integrationer vises på de to følgende figurer.

2 Provisionering Information om oprettelse og nedlæggelse af brugere og grupper kopiere (provisioneres) én gang i døgnet fra Odenses Active Directory til, som vist på den følgende figur. Synkroniseringen sker vha. Google Directory Sync, som er et script i Java, samt et Headnetudviklet script i Python - til oprettelse grupper på baggrund af oplysninger i Active Directory. De nævnte scripts afvikles i Odense kommune. Følgende information kopieres: Brugere oplysninger o Brugerid (samaccount) o Fornavn (GivenName) o Efternavn (SN) Grupper, som brugeren er medlem af o Gruppenavn beregnes fra klassenavn, skolenavn og medlemskab af overordnet gruppe for elever, lærere, skole/fritidsordning eller teknisk/administrativt personale (ELEVER, LAERERE, SFOer, TAPer). Informationen transporteres over en SSL-sikret-linie (Der anvendes Google Provisioning API som bruger SSL)

3 Log-in, Autenticitetssikring Login af brugere til Odense Kommunes -løsning foregår således: 1. Brugeren tilgår, 2. som kræver autenticitetssikring og derfor omdirigerer brugerens browser til Odense Kommunes Login-server over SSL 3. Odense Login-server viser brugeren en side hvorpå der kan logges ind (springes over hvis brugeren allerede er logget ind og har en valid session på login-serveren 4. Når Login-serveren har sikret at brugeren er autenticitetssikret, sendes der et bevis (assertion) om dette til. Beviset er krypteret med offentlige nøgle og signeret af Odense Kommunes Login-server. I beviset medsendes brugerens ID (som fx kan se sådan ud: ejbaps 5. Google opretter en session for brugeren, og giver vedkommende adgang til Odenses Google Apps Den beskrevne kommunikation er krypteret via SSL. Brugeren er på den ovenstående figur vist som siddende op Odense kommunes netværk, men kan godt befinde sig fysisk udenfor Odense kommune (på internettet). Nogle ting, som er værd at bemærke: Det er Odense Kommune som er ansvarlig for autenticitetssikringen af sine brugere o Derudover står login-serveren fysisk hos Odense Kommune Til Google overføres Odense Kommunes tidsbegrænsede uafviselige bevis på at en konkret bruger-id er autenticitetssikret korrekt o Brugerne kodeord lagres og anvendes kun på servere som er under Odenses fysiske kontrol o Kodeord overføres aldrig til Google Brugerens ID hentes fra samaccount attributen i Odense Kommunes brugerkatalog, og er på formen o Lærere: Skole, som læreren er tilknyttet (3 tegn) plus lærerens initialer (2-3 tegn)

4 Eksempel: ejbaps o Elever: Skole + startår + klasse + løbenumme Eksempel: ejb05a7 Styrke af autenticitetssikringen Til vurdering af autenticitetssikringens kvalitet må følgende trin i autenticitetssikrings-processen vurderes Oprindelige registrering Efterfølgende anvendelse af it-systemet Verificering af akkreditiverne Transaktionshåndtering Dokumentjournalisering, historik, logning etc. Suspendering, inddragelse af akkreditiver og genudstedelse Revision I den følgende tabel beskrives Odenses løsning for hvert af trinene, og der sammenlignes med forholdene for gratis-udgaven af såvel som den forbrugerrettede internetjenste Gmail, Trin Oprindelige registrering Odense Elever registreres i forbindelse med indskrivning til skolen. Ansatte registreres i forbindelse med ansættelse. Både elever og lærere kan nemt verificeres ved fysisk fremmøde Gratisudgaven af administratoren opretter brugerne i Google Apps, og står dermed inde for den oprindelige registrering. Gmail Bruger foretager selvregistrering. Der er mulighed for at tilknytte en sekundær adresse, som verificeres, men det er ingen forudsætning for at registrere sig. Efterfølgende anvendelse af itsystemet Verificering af akkreditiverne Information fra elev- og personalesystemerne overføres til Odenses Active Directory hvor brugernes ID og kodeord lagres Verificering sker ved afgivelse af brugernavn og kodeord på loginserveren hos Odense kommune. Risikoen for Phishing vurderes at være lille. Brugerens kodeord lagres i Verificering sker ved afgivelse af brugernavn og kodeord. Der vurderes at være en mindre risiko for Phishing Brugerens kodeord lagres hos Google Verificering sker ved afgivelse af brugernavn og kodeord. Der vurderes at være en vis risiko for Phishing hvis brugeren vælger at anvende Google bruger-id som OpenID hos andre udbydere (som fx Facebook) Transaktionshåndtering Dokumentjournalisering, historik, logning etc. Suspendering, Håndteres af Odense kommunes login-server Nødvendig dokumentjournalisering og historik i forbindelse med oprettelse og vedligeholdelse af brugere på skoleområdet foretages af Odense Kommune og lagres på Odense kommunes systemer. Logning i forbindelse med autenticitetssikring sker på Odense Lommunes loginserver Håndteres af Det er op til Administratoren at sikre nødvendig dokumentjournalisering og historik i forbindelse med oprettelse og vedligeholdelse af brugere. Der sker logning hos Google i forbindelse med autenticitetssikringen, men der er ingen mulighed for at få adgang til loggen i gratisudgaven Håndteres af Google Kontrolleres af Google og er ikke umiddelbart tilgængeligt for brugeren Processerne herfor er dokumenteret Alle disse ting er Brugeren kan nedlægge sin

5 inddragelse af akkreditiver og genudstedelse Revision af Odense kommune og resultatet udmøntes i kommunens Active Directory. Så snart en bruger er suspenderet eller nedlagt i Active Directory vil vedkommende ikke have mulighed for at logge ind på Odenses. Genudstedelse sker også via Odense kommunes Active Directory. Alle de ovenfor beskrevne trin kan revideres af Odense Kommune. administratorens ansvar Vil bero dels på en revision af Administratorens procedurer såvel som brugeradministrations-systemet i Google. Det er ikke undersøgt om Google har revisionsrapporter, som er dækkende for dette tilfælde egen konto. Resten er under Googles kontrol Ingen så vidt vides Nogle ting, som er værd at bemærke: Hele Autenticitetssikringsprocessen er under Odense kommunes direkte kontrol Der er tale om en autenticitetssikringsproces, som er væsentlig mere robust end hos forbrugerrettede internetjenster, som fx Facebook eller GMail Der er en flere relationer fra Odense kommune til brugerne og brugerne i mellem, der i praksis gør det meget svært for udefrakommende at overtage en valid brugers identitet