Enkla inloggningsgrunder för Single Sign On.
Uppdaterad
av
Victor Jespersen
Innan du ställer in SSO i Quinyx är det viktigt att gå igenom grunderna för att förenkla uppsättningen. SSO står för Single Sign On, och i Quinyx används det för att flytta autentisering från de inbyggda sätten att autentisera användare via, till exempel, ett användarnamn och lösenord till ett kundkontrollerat sätt.
SSO ger många fördelar såsom säkerhet, överensstämmelse och enkelhet jämfört med användarnamn och lösenord, men framför allt ger det kunden kontroll över inloggning och autentisering till Quinyx.
Teknologier och protokoll
Eftersom SSO har utvecklats under åren har ett antal protokoll och standarder etablerats för att förenkla SSO mellan olika system. Två vanliga protokoll som stöds av Quinyx är SAML 2.0 för webben och OpenID Connect (OAuth2) för mobila appar.
Protokollen finns till för att förenkla implementering och kompatibilitet mellan olika system så att varje leverantör, Quinyx i detta fall, inte behöver bygga specifikt stöd för varje typ av leverantör (Azure ADFS, Onelogin, Okta, Google, etc.) - vi talar alla samma språk. Gemensamt för alla protokoll är att de har en lista med inställningar såsom certifikat, URL:er och potentiella hemligheter som behöver delas för att etablera förtroendet mellan de två.
Medan URL:er kan se olika ut mellan olika leverantörer, erbjuder de alla samma funktionalitet eftersom de är kompatibla med det angivna protokollet.
Quinyx SSO grundläggande steg
Konfigurering och användning av SSO kan delas upp i olika steg:
- Tekniskt förtroende mellan två system
- Datamappning
- Logga in på Quinyx med SSO för anställda.
Tekniskt förtroende mellan två system
En förutsättning för att SSO ska fungera mellan Quinyx och kundens IT miljö är att etablera det tekniska förtroendet mellan de två parterna. Detta görs en gång och oftast av IT avdelningen ansvarig för systemet hos kunden. Quinyx UI erbjuder en självbetjäningsväg för att ange alla inställningar som krävs för att etablera förtroendet mellan Quinyx och det system som kunden valt.
Här används alla URL:er, hemligheter och certifikat för att konfigurera och etablera detta förtroende. För att förenkla denna process i SAML 2.0, lagras all nödvändig information i en "metadata"-fil som delas mellan parterna. Denna fil minimerar risken för felaktigheter och felkonfiguration, eftersom den innehåller all information som behövs för att konfigurera förtroendet. OpenID Connect har liknande instruktioner som kallas "Well Known URIs" vilket är en webblänk som innehåller alla URL:er som behövs för att konfigurera OpenID (slutar ofta med /.well-known/openid-configuration).
Datamappning
När det tekniska förtroendet är etablerat, kommunicerar de två systemen under inloggningen. Det finns dock fortfarande en sak kvar att konfigurera och det är datamappningen. Kundsystemet, här kallat IDP (IDentity Provider), tillhandahåller en databas över de anställda som ska logga in på Quinyx. IDP kan bestå av många olika system internt hos kunden med hög komplexitet. Eller så kan det vara ett enda system i sin enklaste form, som en kalkylblad som innehåller all anställningsinformation.
När en anställd använder SSO för att logga in på Quinyx, skickas olika användaregenskaper från IDP-databasen till Quinyx som en del av det använda protokollet.
Medan protokoll som används för att etablera förtroende har vissa specifika detaljer och rekommendationer, bestämmer de inte exakt vad alla fält ska innehålla. Detta kräver konfiguration i datamappningen. Många leverantörer av OpenID Connect har vissa gemensamma påståenden som till exempel innehåller en e-postadress i ett visst påstående (fält). Ett specifikt påstående kanske inte passar varje Quinyx-kund så vi tillåter kunden att välja vilken som ska användas.
Konfigurera datamappning
Målet med datamappning är att koppla informationen om en anställd i kundens IDP-databas till informationen om den anställda i Quinyx, så att Quinyx kan identifiera vem som loggar in.
Detta kräver att vi väljer ett fält/egenskap från Quinyx och ett fält/egenskap i kundens IDP-databas för att matcha varandra och unikt identifiera den användaren. De valda fälten matas in på konfigurationssidan i Quinyx för SSO.
Exempeldata
Exempeldata i Quinyx (vänster) och på kundsidan (höger).
Konfigurera med e-post och användarnamn
Första försöket att göra datamappning; egenskapen e-post väljs från Quinyx, och användarnamnet väljs från kundens data.
Inloggningen misslyckas eftersom informationen inte matchar exakt på båda sidor.
Konfigurera med e-post och UPN
Andra försöket att göra datamappning; omkonfigurering för att använda e-post från Quinyx och UPN från kundens data. Detta ger ett annat resultat.
Inloggningen lyckas nu eftersom Quinyx unikt identifierar användaren som rätt John Doe från kunden.
Hur man bestämmer vilka data som ska användas
Eftersom protokollet inte specificerar exakt vilka data som ska användas under SSO rekommenderas det att identifiera data som är tillgängliga i båda systemen. Hitta sedan ett lämpligt fält att kartlägga användare innan du konfigurerar SSO. Eftersom kund-IDP:er ofta är mycket konfigurerbara är det möjligt att ändra vilka data som skickas i vilka fält till Quinyx för att underlätta i datakartläggningsprocessen - den viktiga delen är att bestämma vilket fält som ska användas och säkerställa att datan är konsekvent.
Om inga data hittas för att kartlägga varje användare behöver ny information skapas i något av systemen. Det kan vara vilken typ av unikt nummer eller sträng som helst, unik för varje anställd. Genom att använda integrationer mot Quinyx och uppdatera varje anställd med automation förenklas denna process för att undvika manuell konfiguration av nödvändiga data för inloggning.
