1 Innledning
Passordbytte er en årlig plikt for samtlige brukere ved universitetet - dette betyr at en passordbyttetjeneste har et stort nedslagsfelt.
Den nye passordtjenesten skal gi et enkelt og brukervennlig henvendelsespunkt for å sette passord, uavhengig av om brukeren kjenner til sitt tidligere passord, eller setter passord for første gang. En egen tjeneste - "Passordtjenester" (passord.uio.no), gir et tydelig henvendelsespunkt, uten å pakke på annen funksjonalitet som bidrar til å trekke oppmerksomhet bort fra hensikten med tjenesten.
Tjenesten tilbyr funksjonalitet for:- Tradisjonelt passordbytte, hvor brukeren logger inn med sitt nåværende brukernavn og passord, for så å sette nytt passord.
- Glemt passord, hvor brukeren kan sette passord med en engangskode sendt på SMS til sin mobiltelefon eller ved å logge seg inn via ID-porten. Dette tillater brukere å bytte passord selv om de ikke kjenner sitt nåværende passord.
- Liste brukerkontoer, hvor brukeren kan liste ut alle sine brukernavn. Dette tillater brukere å bytte passord, selv om vedkommende har glemt hvilket brukernavn de har blitt tildelt.
Tjenesten er generell, og kan også tilbys til andre organisasjoner i og utenfor UH-sektoren. Ved å splitte ut brukergrensesnitt (frontend) fra applikasjonen, tilrettelegges det for å tilpasse grensesnittet til organisasjonen, eller integrere brukergrensesnitt i organisasjonens applikasjoner. Backend-applikasjonen er modulær, slik at tjenesten kan benyttes mot andre systemer enn Cerebrum og UiO sin SMS-gateway.
Kontaktpunkt for tjenesten
2 Redegjørelse
Behovet for en utbedret passordopplevelse ble belyst av en brukerundersøkelse gjennomført ved UiO. Valget om å utvikle en helt ny tjeneste for passordbytte oppstod i lys av dette, for å unngå problematikk rundt teknisk gjeld i eksisterende tjenester (Brukerinfo, Glemt Passord og Cerebrum). I tillegg er den nye tjenesten utviklet i tråd med sjekkliste for utviklingsaktiviteter. Dette har gitt oss en applikasjon…
- med god informasjon og mye innsyn
- som er enkel å sette opp og drifte
- som er enkel å vedlikeholde og videreutvikle
- som er brukervennlig og attraktiv å bruke
For mer bakgrunnsinformasjon, se dokument om forslag til endret tjeneste.
2.1 Mål
- Ansatte og studenter skal oppleve at passordtjenesten er enkel og brukervennlig. Dette kan måles i brukerundersøkelser og ved hjelp av statistikk som samles inn gjennom løsningen.
- Gjennomsnittstiden som brukes på å skifte passord skal reduseres. Ny tjeneste vil produsere statistikk på dette, og noe statistikk vil være tilgjengelig fra den gamle tjenesten. Vi har også noe statistikk fra brukerundersøkelse som kan brukes som sammenligningsgrunnlag.
- Antall brukere som avbryter prosessen med å skifte passord skal reduseres. Ny tjeneste vil produsere statistikk på dette, og noe statistikk vil være tilgjengelig fra gammel tjeneste. Vi har også noe statistikk fra brukerundersøkelse som kan brukes som sammenligningsgrunnlag.
- Passordtjenesten erstatter passordbytte-funksjonalitet i alle andre applikasjoner ved UiO og ved alle andre universiteter og høgskoler som er partnere i Cerebrum-samarbeidet.
Tjenesten vil også være i tråd med prinsipper for ny integrasjonsarkitektur ved UiO:
- Ved å skreddersy en løsning for et formål, passordbytte, får vi en tjeneste som har dette målet i fokus. Applikasjonen er fleksibel, og kan tilpasses systemendringer og brukerbehov.
- Tjenesten benytter løse koblinger mot andre systemer. Alle integrasjoner kan byttes ut uten å omskrive hele applikasjonen.
- Tjenesten tilbyr et åpent API som kan benyttes av ulike front-ends for passordbytte, og fordrer et åpent API i Cerebrum for passordfunksjonalitet
- Tjenesten er skalerbar. Den kan tilpasses og tilbys andre interessenter, og den kan skaleres vertikalt i perioder med høy pågang.
2.2 Sikkerhet
2.2.1 Lekkasje av personinformasjon
Personinformasjon benyttes i den delen av tjenesten hvor man benytter sitt fødselsnummer eller studentnummer for å liste ut brukernavn, samt for å få tilsendt SMS med engangskode. Dette steget lekker personinformasjon: En hvilken som helst bruker kan gå inn i tjenesten og prøve et fødselsnummer eller studentnummer for å se om det finnes brukere ved universitetet tilknyttet denne informasjonen.
For å redusere problemet, vil man kunne reservere seg mot treff i denne tjenesten. Dersom man er reservert mot visning på nett i Cerebrum, vil man få samme feilmelding fra tjenesten som om man ikke var tilknyttet universitetet. Merk at dette også forhinderer disse brukerene fra å bruke denne delen av tjenesten.
Reservasjon mot visning på nett er funksjonalitet knyttet direkte til Cerebrum. Denne funksjonaliteten er derfor implementert i modulen som kommuniserer med Cerebrum.
2.2.2 Misbruk av SMS-utsending
For å hindre misbruk av SMS-utsendingen, krever vi at brukeren kjenner til sitt eget mobilnummer. For å kunne sende en engangskode på SMS må brukeren altså kjenne til et av mobilnummerene som er registrert på brukeren i IGA-systemet (Cerebrum).
2.2.3 Tillit til kildedata
For å hindre at engangskoder kommer på avveie, stiller vi en del krav til mobilnummeret som det sendes til.
- Mobilnummeret må finnes i Cerebrum, og komme fra et kildesystem (SAP eller FS), slik at vi vet at det vedlikeholdes.
- Mobilnummeret må enten:
- være eldre en N dager
- tilhøre en ny person
Hvilke kildesystemer man benytter telefonnummer fra, og hva som er minimal alder på telefonnummer, kan konfigureres i tjenesten. Denne funksjonaliteten er implementert i modulen som kommuniserer med Cerebrum.
2.3 Passordregler
Siden det finnes eksisterende løsninger for bytte av passord, beholdes kontroll av passordstyrke i Cerebrum. Backend-applikasjon er derfor ukjent med passordregler, og overlater dette til IGA-systemet.
Nye passordregler
For å imøtekomme kritikk av passordregler, har INT gjort en gjennomgang av de eksisterende krav til passord ved universitetet. Denne gjennomgangen viste at eksisterende krav hverken bidrar til å styrke passord, eller hjelper sluttbruker å lage gode passord. Dette resulterte i et forslag til nye, enklere krav.
Den nye passordtjenesten utvikles primært for å støtte disse nye kravene. Frontend-applikasjonen presenterer eksisterende krav og gjør sanntidsvalidering av krav den kan validere selv. Resten av kravene (passordhistorikk, brukernavn og navn) valideres i backend-applikasjonen og eventuelle feil videreformidles til frontend-applikasjonen.
3 Detaljebeskrivelse
Passord lever i Cerebrum, som passord-hasher og GPG-kryptert data, og distribueres herfra til andre systemer. Løsningen består av:- Grensesnitt mot Cerebrum: Funksjonalitet for bytte av passord i API
- En backend-applikasjon som kommuniserer med Cerebrum, SMS-gateway og / eller ID-porten
- En frontend-applikasjon som presenterer brukergrensesnitt til sluttbrukeren
For å benytte tjenesten, går brukeren til nettadressen https://passord.uio.no, som viser frontend-applikasjonen. Frontend-applikasjonen presenterer følgende valg:
- Logg inn med brukernavn og passord
- Glemt eller utgått passord
- Glemt brukernavn
- Ny bruker
3.1 Teknisk formål
Tjenesten gir sluttbrukere to hovedfunksjoner: listing av brukernavn, og bytte av passord.
Liste brukernavn
Dette er en støttefunksjon som kan hjelpe brukere som typisk har glemt sitt brukernavn og trenger å bytte passord (eller, som av en eller annen grunn har glemt sitt brukernavn, men husker sitt passord).
- Applikasjonen ber bruker om å fylle inn person-identifikasjon (fødselsnummer eller studentnummer)
- Dersom informasjonen finnes i Cerebrum (med forbehold), viser applikasjonen en liste med brukernavnene
Studenter som har reservert seg mot publisering av personinformasjon på nett er unntatt denne funksjonen. Disse personene vil ikke kunne liste sine brukernavn.
Bytte av passord
Brukere som har fått autorisasjon, kan bytte sitt passord. For å få autorisasjon til dette, må brukeren gjøre en av en av følgende:
- logge inn med sitt nåværende brukernavn og passord
- bekrefte sin identitet med en engangskode som sendes per SMS
- logge seg inn via ID-porten
Brukernavn og passord
- Brukeren logger inn med sitt vanlige brukernavn og passord.
- Dersom innlogging lykkes, får brukeren tilgang til å bytte passord, og passordbytte-applikasjonen vises
Engangskode på SMS
- Applikasjonen ber bruker om å fylle inn person-id (fødselsnummer eller studentnummer), samt tilhørende brukernavn og mobilnummer
- Dersom informasjonen finnes i Cerebrum, og brukeren kan benytte SMS-tjenesten, vil det sendes en SMS med engangskode til mobilnummeret. Applikasjonen vil vise et felt for utfylling av engangskode.
- Dersom brukeren taster inn en gyldig engangskode, får brukeren tilgang til å endre passord, og passord-applikasjonen vises.
Studenter som har reservert seg mot publisering av personinformasjon på nett er unntatt denne funksjonen. Disse personene vil ikke kunne motta SMS-kode. I tillegg stilles det en del krav til mobilnummeret og brukernavnet som tastes inn:
- Brukernavnet må tilhøre personen
- Brukernavnet må ikke være reservert fra tjenesten
- Mobilnummeret må tilhøre personen
- Mobilnummeret må være pålitelig
- Det må komme fra et kildesystem (typisk SAP eller FS)
- Det må ikke være endret nylig (med mindre personen er en helt ny ansatt/student)
Innlogging via ID-porten
Applikasjonen videresender brukeren til ID-porten der vedkommende har mulighet til å benytte seg av flere typer elektronisk id som "Bankid", "Bankid på mobil", osv.
Dersom fødselsnummeret som blir sendt fra ID-porten etter en vellykket autentisering finnes i Cerebrum, vil en liste av brukere som tilhører denne personen presenteres.
En vil da kunne velge hvilken bruker en vil bytte passordet til.
3.2 Høynivådesign (Overordnet design)
Tjenesten er skrudd sammen av tre hovedkomponenter: Cerebrum, backend-applikasjon og frontend-applikasjon. En vil også bli vederesendt til ID-porten dersom en velger å autentisere seg via ID-porten (glemt eller utgått passord, ny bruker).
Passord lever i Cerebrum, og endring av passord skjer derfor i Cerebrum. For å gjennomføre passordbytte i Cerebrum, blir det eksponert et API for oppdatering av passord, som lar eksterne systemer endre passord på brukere. Dette endepunktet låses ned til passordbytte-tjenesten, og eventuelt andre systemer som skal gjennomføre passordbytte.
Backend består av et API som lar frontend gjennomføre autentisering og passordbytte. Det meste av forretningslogikk i applikasjonen hører hjemme her. Applikasjonen kommuniserer med Cerebrum for uthenting av person- og brukerinformasjon, samt gjennomføre passordbytte.
Frontend består av statiske nettsider og en Javascript-applikasjon. Applikasjonen utfører sanntidsvalidering av passord, samt kommunikasjon med backend-applikasjon.
3.3 Lavnivådesign (Design av enkeltkomponenter)
3.3.1 Cerebrum
For å gjøre det mulig for eksterne systemer å gjennomføre passordbytte, har Cerebrum fått utvidet API med noe funksjonalitet:
- Eksport av tidspunkter for endring av persondata. Dette kan benyttes av passordtjenesten for å regulere om persondata er pålitelig nok for å tillatte passordbytte vha. SMS-tjenesten.
- Funksjonalitet for å kontrollere nåværende passord, for å tillatte passordbytte dersom brukeren kjenner sitt nåværende passord.
- Funksjonalitet for å kontrollere at nytt passord er "godt nok". Dette gjør at applikasjonen kan gi tilbakemeldinger om passordregler som kun Cerebrum kan kontrollere (sammenligne med tidligere passord-hasher, brukernavn og navn).
- Funksjonalitet for å sette et nytt passord
3.3.2 Backend
Backend-tjenesten er en web-service som videre kommuniserer med de ulike andre tjenestene (Cerebrum, SMS-gateway og ID-porten), og implementerer business-logikken i passordbytte-tjenesten.
Selve passord-tjenesten er en Flask-applikasjon, tilrettelagt for å kjøre med applikasjonstjeneren Gunicorn. I tillegg benyttes blinker i utstrakt grad for å tilby hooks i applikasjonen for videre utvidelse og løse koblinger mellom komponenter.
Autentisering og autorisasjon
Tjenesten benytter sesjoner. Sesjonsdata oppbevares på server siden (Redis). Flask-applikasjonen finner sesjonsdata som er tilknyttet en tidligere autentisering ved hjelp av informasjonskapsler (cookies) som inneholder sesjon-id. Disse er utstedt og kryptografisk signert av Flask-applikasjonen ved en tidligere vellykket autentisering.
Brukerens nettleser må derfor kunne ta vare på informasjonskapsler.
Informasjonskapsler har begrenset levetid og inneholder ikke selve sesjonsdataen.
"Rate limiting"
ReCAPTCHA 2 er blitt erstattet av "rate limiting". Ved feil innlogging (feil brukernavn og / eller passord) eller feil SMS-kode, vil systemet introdusere forsinkelse. Det vil si at en klient må vente x - antall sekunder (forsinkelsesperioden) til den kan forsøke med ny innlogging. Forsinkelsen vil øke ved flere mislykkede innloggingsforsøk / SMS-koder.
SMS-dispatcher
Applikasjonen har en modul for utsending av SMS (pofh.sms).
Modulen benytter seg tungt av Python-modulen phonenumbers for å parse og validere mobilnummer. Dette gir oss mulighet for å:
- Fange opp tilfeller hvor IGA-systemet inneholder ugyldige mobilnummer
- Filtrere telefonnummer etter landkode (f.eks. kun tilby tjenesten for nordiske telefonnummer)
- Tilpasse formatering av telefonnummer for SMS-gateway
I tillegg benytter modulen hooks for å signalisere følgende hendelser:
- SMS blir forsøkt sendt
- SMS-utsending blir ikke gjennomført fordi modulen ikke kan sende til det oppgitte telefonnummeret
- SMS-utsending feilet (problem i ekstern SMS-tjeneste)
- SMS-utsending var vellykket
Selve utsendingen er todelt, en felles komponent som verifiserer og filtrerer telefonnummer, samt en klient-spesifikk implementasjon som kommuniserer med SMS-gateway. Følgende implementasjoner finnes:
- mock/debug: Implementasjoner for testing, som simpelthen ikke sender SMS
- uio-gateway: Implementasjon som sender SMS vha. USIT sin SMS-tjeneste
Modulen kan enkelt utvides til å støtte andre SMS-tjenester for utsending av SMS.
Tjenesten benytter denne modulen for utsending av engangskoder.
Språk og templates
Applikasjonen har grunnleggende støtte for språk (pofh.language) og templates (pofh.templates).
Språk-komponenten leter etter språkinnstillinger som frontend-applikasjonen sender (Accept-Language), og gjør dette tilgjengelig for resten av applikasjonen. Videre finnes det en egen template-komponent som benytter dette, samt Flask sin innebygde støtte for Jinja2-templates, til å lete opp drop-in templates (template-filer som enkelt kan endres eller byttes ut).
Språkvalg og templates benyttes kun til å formattere selve SMS-meldingen som sendes til sluttbruker.
Redis
Applikasjonen har en simpel Redis-komponent (pofh.redis), som kan benyttes til å lagre persistent informasjon i en Redis-database.
Komponenten er en enkel innpakning av redis-py og flask_redis. Komponenten kan også konfigureres til å benytte mockredispy, slik at man ikke trenger en kjørende redis-database i test og utvikling. Redis benyttes til å lagre engangskodene som blir sendt med SMS, slik at disse kan verifiseres. Engangskodene benytter Redis sin TTL-funksjonalitet, slik at ubrukte engangskoder automatisk ryddes bort. Redis brukes også til å lagre sesjon-data på server-siden.
Statsd
Applikasjonen har en statsd-komponent (pofh.stats) som kan benyttes til å logge bruksstatistikk. Komponenten benytter en klient fra statsd for kommunikasjon med statsd, samt en mock-implementasjon av denne klienten.
Applikasjonen fører statistikk over:
- Antall påbegynte, gjennomførte og ufullførte passordskifter
- Tidsbruk for gjennomføring av passordbytte
- Antall utsendte, verifiserte og ubrukte engangskoder
- Tidsbruk fra utsending til verifisering av engangskode
- Antall utlistinger av brukernavn
I tillegg kan applikasjonstjeneren Gunicorn konfigureres opp til å føre statistikk på requests mot applikasjonen.
IGA-klient
Selve kommunikasjonen med Cerebrum er implementert som en generisk IGA-komponent (pofh.idm).
IGA-komponenten består av konfigurasjon, mock-klienter og en klient for Cerebrum-APIet.
3.3.3 Frontend
Kjernerammeverk
Frontenden består av statiske nettsider, med HTML, CSS og en Javascript-applikasjon. Javascript-applikasjonen bygger på rammeverket Redux for tilstand og workflow, mens React benyttes for brukergrensesnitt.
En Redux-applikasjon bygger på tilstander, hendelser, og et pub-sub-mønster som kan endre i tilstand og reagere på hendelser. Nært knyttet tilstand organiseres i gjerne i mellomvare-komponenter. Nettstedene til Redux og React kan gi en bedre forståelse av hvordan en applikasjon bygget på disse rammeverkene fungerer.
Auth-middleware
Applikasjonen er utstyrt med en autentiseringsmellomvare, som ved hver brukerinteraksjon verifiserer at brukeren har gyldig autentiseringsinformasjon for handlingen som skal utføres. Dersom tilstandsmaskinen i applikasjonen på noe tidspunkt mangler autentiseringsinformasjon for å gå videre, vil brukeren sendes tilbake til den relevante startsiden for å sette i gang autentisering på nytt. Mellomvaren vil også sørge for å hente ett nytt token fra backend-applikasjonen dersom dette er i ferd med å gå ut på tid.
Api-middleware
For å kommunisere med backend-applikasjonenen, benyttes en egen mellomvare-komponent, som abstraherer denne kommunikasjonen. Alle hendelser i applikasjonen som krever informasjon fra, eller interaksjon med backend, vil automatisk omsettes til en REST-ful operasjon. Når backend svarer, vil dette endre tilstanden til informasjonen som kreves.
For resten av applikasjonen er kommunikasjon med backend helt transparent, og foregår på akkurat samme måte som all annen oppdatering av applikasjonens tilstand.
Skjemaer
Redux-Form brukes for å håndtere innsending, validering og visning av tilbakemeldinger av de ulike skjemaene som finnes i applikasjonen.
Validering i den grad det er mulig, blir gjort på klientsiden for momentante tilbakemeldinger til sluttbruker. Informasjon som må valideres i backend, vil først bli gjort når alle sjekker i applikasjonen passerer.
Slike sjekker inkluderer sjekk av nye passord mot tidligere brukte passord, og sjekk om person har reservert seg fra publisering på nett (og dermed også sms-tjenesten).
I18n
For å håndtere språkvalg, brukes biblioteket "react-redux-i18n" og oversettelsesfiler.
Themes
React-komponentene som styrer brukerinteraksjon har ingen (direkte) stilisering med CSS. Alle slike tilpasninger av stilisering skreddesys i egne CSS-regler som ligger i themes. Dette gjør at utseende i applikasjonen kan tilpasses og skreddersys etter ønske.
Applikasjonen bruker postcss-cssnext og css-modules, for å legge på stilinformasjon som defineres i themes. Dette gjør av man unngår globalt definerte css-regler, og det er enklere å skrive stilisering for enkeltkomponenter uten å forårsake uønskede bivirkninger andre steder i applikasjonen.
Bygging
Byggeverktøyet Webpack benyttes til å generere statiske filer for nettstedet. Ved bygging vil komponentene i applikasjonen slåes sammen til følgende filer:
- En Javascript-fil med alle tredjepartsbiblioteker, i minimert form.
- En Javascript-fil med selve applikasjonen, i minimert form.
- En CSS-fil med tilpasninger.
- En HTML-fil (index.html) som laster inn disse tre andre filene, og bootstrapper applikasjonen.
Webpack kan også benyttes under utvikling, slik at endringer fortløpende kan bygges og applikasjonen oppdateres.
3.3.4 Videre forbedringer:
- Svartliste brukte tokens: Etter at token har blitt benyttet, kan tokenets unike ID legges inn i en svartliste i Redis-databasen, for å forhindre at tokenet blir benyttet på nytt dersom dette skulle komme på avveie.
- IP-block: Dersom en IP skulle gjøre unormalt mange forespursler mot tjenesten, kan IP midlertidig legges inn i en svartliste i Redis-databasen, med stadig økende backoff.
- Autentiseringstjeneste: Det kan tenkes at autentiseringstjenesten i denne backenden kan generaliseres og benyttes i andre tjenester. Hvis SMS-engangskode er "godt nok" for autentisering, kan det tenkes at denne formen for autentisering kan benyttes i andre tjenester også.
- Fase ut komponenter for bruk i andre tjenester. En del av komponentene i backenden er generiske Flask-komponenter som kan gjenbrukes i andre tjenester.
4 Avhengigheter
Cerebrum
For at passordtjenesten skal kunne benyttes, må Cerebrum være tilgjengelig. Dette inkluderer:
- Cerebrum-API
- Cerebrum-database (postgres)
- API-Gateway (når denne settes i produksjon)
Dersom tjenesten videreutvikles til å støtte flere IGA-systemer, vil det samme gjelde for disse.
SMS-gateway
For å kunne sende ut SMS, må SMS-gateway være tilgjengelig.
ELK
Applikasjonen benytter Filebeat til å sende applikasjonslogger til Logstash. Dersom Logstash er utilgjengelig over lang tid, kan dette føre til at loggmeldinger går tapt.
Statsd
Applikasjonen sender statistikk til statsd. Dersom denne tjenesten er utilgjengelig, vil statistikk gå tapt.
ACE
Tjenesten benytter en reverse proxy for å fordele trafikk. Dersom denne proxyen er nede, vil ikke tjenesten kunne nås.
Redis
Tjenesten benytter en Redis-database for å lagre engangskoder. Dersom databasen er utilgjengelig, vil ikke engangskoder kunne lages eller verifiseres. Dersom data mistes fra Redis-databasen, så vil brukere som er i gang med passordbytte via SMS miste muligheten til å benytte engangskoden de har fått tilsendt. Brukeren vil måtte starte prosessen på nytt.
5 Relaterte systemer
Det finnes allerede flere applikasjoner for passordbytte. Disse benytter seg i hovedsak av to Cerebrum-tjenester, bofhd og CerebrumWS.
bofhd
Bofhd er en Cerebrum-tjeneste som kommuniserer med klienter over XMLRPC, og tilbyr en rekke proprietære funksjoner. Av disse er noen få relatert til passord:
- login <username> <password>: Verifiserer brukernavn og passord, og starter en ny sesjon
- user_password <username> [password]: Bytter passord for en gitt bruker
- misc_list_passwords: Lister passord som er blitt satt i inneværende sesjon
- misc_print_passwords <template> <printer> <username>: Genererer et passord-ark og sende til skriver
- misc_verify_password <username> <password>: Sjekker om passord er korrekt for en bruker
Passordfunksjonalitet er tilgjengelig i følgende klienter:
- cli-klienter (pybofh, jbofh)
CerebrumWS
CerebrumWS er Cerebrum-tjeneste som kommuniserer med en klient-applikasjon ved hjelp av REST, og tilbyr grensesnitt (API) mot Cerebrum.
6 Lenker og referanser
Kildekode
- Cerebrum
- pofh (backend-applikasjon)
- Frontend-applikasjon
Tjenester
- Passordtjenester (UiO)
- https://www.usit.uio.no/om/tjenestegrupper/cerebrum/aktiviteter/old/passordtjenesten/passordteneste.html