Ibland är det viktigt att ett forum eller en kunskapsbank bara går att komma åt av en viss grupp av användare. Vanligtvis så har ni som kund redan sen tidigare ett system kan som göra den urskiljningen, vilka som ska ha tillgång och vilka som inte har det.

För de fallet kan vi göra en inloggningsintegration mot er. Den typen av specialinloggningar görs vanligtvis som konsultprojekt enligt den timkostnad som står i vårt gemensamma avtal. Kontakta oss alltid innan ni gör en integration så kan vi diskutera detaljer och upplägg tillsammans.

Denna artikel beskriver en vanlig lösning för SSO, se också övriga alternativ för anpassad accesskontroll. Vi föreslår denna lösning för kunder då den ger en bra användarupplevelse, är relativt lätt att implementera tekniskt och redan har bra stöd i Kundo. 

Tekniska detaljer

Vår vanligaste lösning för SSO bygger på JWT för att skicka betrodd användardata från er till oss. Vår lösning kontrollerar behörighet genom att skicka användaren vidare till er, där ni kan autentisera användaren och skicka hen vidare till oss. Vanligen sker allt detta i några få redirects som användaren inte märker (om den redan är inloggad hos er) för att användarupplevelsen för era användare ska blir så bra som möjligt.

För att få en introduktion till JWT rekommenderar vi JWT.io, som också har exempelkod i en mänga olika programmeringsspråk.

Huvudflödet:

1. Användaren surfar in på ert forum eller kunskapsbank
2. Vi upptäcker att den inte är inloggad och skickar den vidare till er autentiseringsendpoint. Vi skickar med den adress som användaren försökte surfa till.
3. Ni verifierar att användaren har rätt rättigheter på valfritt sätt, och om det stämmer så skapar ni en token (JWT) och skickar den till oss. Den innehåller adressen som användaren försökte gå till.
4. Vi läser JWTs, verifierar att den är korrekt, och loggar in användaren.
5. Eftersom användaren nu är inloggad så behöver vi inte skicka några fler requests till er förrän inloggningen går ut. Då börjar processen om igen.

Vi behöver veta från er:

• URL:en för er autentiseringsendpoint. I URL:en kan ni också lägga in uppgifter ni behöver för att identifiera att det är från just forumet eller kunskapsbanken som inloggningsförsöket kommer, t.ex. som queryparameter.
• Det lösenord som ni signerar JWT-tokens med.

Vi kommer vidarebefordra okända användare till den URL:en, med ursprungs-URL:en under query-parametern 'next'.

På er sida implementerar ni autentisering, med följande detaljer:

• Den ska verifiera att kunden har access till det forum eller kunskapsbank som det gäller. Adressen till det forum eller kunskapsbank det gäller skickas med som parameter om ni vill ha olika rättigheter i olika kanaler.
• Om access tillåts ska ni redirecta klienten till https://[adressen till ert forum]/auth/custom_auth2
• Redirecten ska innehålla er JWT-token under query-parametern 'jwt'
• Redirecten ska behålla det värde vi skickade med under query-parametern 'next', med samma namn på parametern. Tänk där på att värdet vi skickar redan är URL-encodat, så ni behöver inte URL-encoda igen. Om den parametern saknas hamnar kunden på forumets eller kunskapsbankens startsida.

För att vi ska acceptera er token gäller följande:

• Den ska vara signerad med en algoritm vi har kommit överens om i förväg. Vi föreslår RS512, RS384, RS256 för asymmetrisk signering eller HS256, HS384, HS512 för signering med delad nyckel.
• Fälten 'exp' och 'iat' måste finnas som claims. Sätt gärna 'exp' till bara kort in i framtiden (förslagsvis en minut). Vi kommer inte att återanvända tokens.
• Fälten 'email' och 'name' måste finnas som claims, och kommer användas i vårt system för att identifiera användaren. I forum-fallet kommer det namn ni anger där är det namn som kommer visas när de skriver inlägg.

När vi verifierat användarens token minns vi inloggningen i ett dygn. När tiden gått ut upprepas processen. För en bra användarupplevelse bör ni alltså se till att redirecta användare baserat på existerande inloggning hos er i första hand, snarare än att alltid kräva manuell inloggning varje gång.

Om vi kommit överens om en signering med delad nyckel behövs en hemlig sträng som vi båda känner till. Kontakta oss på support@kundo.se så ser vi till att skapa en sån och dela den med er på ett säkert sätt. Om den ska ske med asymmetrisk signering behöv ni informera oss om er publika nyckel (vi ska då inte känna till er privata nyckel).