Håndtering av brukere kan bli en tung prosess dersom du har flere websider i drift. Ofte må brukere logge inn flere ganger for å benytte seg av disse tjenestene, og kanskje har du tjenestene dine spredt ut over flere domener, noe som gjør det umulig å bruke cookies for å verifisere at brukeren faktisk er logge inn. Her beskriverer jeg en single-sign-on-løsning (SSO) som vil på tvers av alle webløsningene du måtte ha, gjøre at din bedrift vil få et sømløst ansikt utad. I tillegg skal vi tillate autentisering av brukere med OpenID.
Vi ønsker at alle brukere av våre tjenester skal registreres i en sentral brukerdatabase. Vi ønsker derimot ikke å lage store endringer i eksisterende løsninger, spesielt ikke “hyllevare”-produkter. Mange hyllevareprodukter har allerede støtte for OpenID, men det kan vi ikke bruke uten endringer. Da mister vi oversikt over hvor mange brukere vi har, brukerne får ingen sentral profil på tvers av systemene og de må skrive inn sin OpenID-adresse og trykke “Logg inn med OpenID” på alle systemene våres. Derfor har vi behov for en tilpasset utgave av OpenID som fungerer innenfor vårt domene av webløsninger.
Først er det viktig å skille mellom vår løsning for SSO mellom egne tjenester og OpenID for SSO mellom eksterne tjenester. Vi trenger begge til å fungere sammen. I vår SSO-løsning ønsker vi ikke at brukeren skal måtte skrive inn sitt brukernavn på alle systemene. Fordi noen av systemene ligger på separate domener og ikke kan dele cookies blir vi nødt til å ha “Logg inn”-knapper på alle systemene, selv om brukeren allerede er logget inn.
Eksempelet
Vi gjør et eksempel ved at en bruker skal logge inn på et forum. Ved å trykke på “Logg inn” blir man sendt til en sentral side hvor man kan registrere seg eller logge inn. Vi kaller denne for profiltjenesten. Med denne linken sendes også en URL som viser hvor brukeren kom fra. Når brukeren er registrert, verifisert (med enten e-post eller SMS) og logget inn blir brukeren sendt tilbake til foumet, der han klikket “Logg inn”. URL-en som brukeren sendes tilbake til inneholder nå også en parameter med brukernavnet sitt samt et token som vi skal bruke for å kontrollere at brukeren faktisk er innlogget. Det som skjer så er at forumet henter profildata fra profiltjenesten for å fylle ut navn, e-post og andre profildata som forumet har behov for. Dette er en funksjonalitet som finnes i OpenID-løsninger.
Dette gir oss en tre-veis autentisering. Brukeren stoler på oss (ja, ikke sant…) eller sin OpenID-tilbyder, profilsiden vår vet at det er riktig bruker som har logget inn og forumet stoler på profilsiden vår og kan verifisere at brukerens token er korrekt.
To samspillende løsninger
Så, hva gjør vår SSO-løsning forskjellig fra OpenID? Ikke så mye, men ganske forskjellig for det, fra brukerens ståsted. For det første er det intet felt for å skrive inn sitt OpenID-navn i våre systemer, heller ikke noe brukernavn- og passord-felter. Det er bare en “Logg inn”-knapp. Denne knappen fører til vår profil- og innloggingsside, ikke til brukerens OpenID-tilbyder. Her logger brukeren inn, enten med en OpenID-konto fra et eller annet sted i verden eller et brukernavn og passord mot vår egen brukerdatabase. Dette betyr at forumet som brukeren opprinnelig prøvde å logge inn på ikke vet brukernavnet til brukeren, faktisk ingenting om brukeren. Derfor må profilsiden vår fortelle forumet hvilken bruker som faktisk har logget inn, når brukeren sendes tilbake.
Da jeg sa at vår SSO-løsning og OpenID må holdes klart adskilt så mente jeg det. Våre systemer har ikke OpenID, da de ikke godtar innlogging fra OpenID-tilbydere. De godtar kun innlogging via vår profilside. Allikevel er det en OpenID-løsning, men en tilpasset OpenID-løsning, og alt som minner om OpenID for sluttbrukere er strippet bort. Det er egentlig ikke lenger OpenID lenger.
OpenID
Så hva med OpenID? Profilsiden støtter OpenID. Brukere trenger ikke å lagre noe passord i vår brukerdatabase. De logger inn via sin OpenID-tilbyder, og oppretter så en profilkonto hos oss med navn, telefonnummer, epost og what-not som vi kan ha behov for. Vi kan godt kreve aktivering av profilen ved å sende dem en kode på SMS eller epost, slik at vi får en viss kontroll over brukerne våre og vite at det er levende personer som står bak profilene. Når brukerne er logget inn på profilsiden vår har de logget inn som på en hvilken som helst annen OpenID-støttet nettside på Internett. Når brukerne så går til de andre systemene våre vil de autentiseres mot vår profilside, på samme måte som OpenID fungerer.