Med enkel inloggning (SSO) kan dina användare komma åt många appar utan att behöva ange användarnamnet och lösenordet för varje app. SAML (Security Assertion Markup Language) gör att säkra webbdomäner kan utbyta användarautentisering och data för användarauktorisering.
Rollerna för tjänsteleverantörer och identitetsleverantörer
Google erbjuder en SAML-baserad SSO-tjänst som gör det möjligt för partnerföretag att auktorisera och autentisera värdanvändare som försöker komma åt säkert innehåll. Google fungerar som onlineleverantör och tillhandahåller tjänster, som Google Kalender och Gmail. Googles partner fungerar som identitetsleverantörer online och kontrollerar användarnamn, lösenord och annan information som används för att identifiera, autentisera och auktorisera användare för webbapplikationer som Google är värd för.
Många identitetsleverantörer med öppen källkod och kommersiella alternativ kan hjälpa dig att implementera SSO med Google.
Skrivbordsklienter kräver fortfarande inloggning
Det är viktigt att notera att SSO-lösningen enbart gäller webbappar. Du kan låta användarna få åtkomst till Googles tjänster med skrivbordsklienter. Om du till exempel vill ge POP-åtkomst till Gmail med Outlook måste du ge användarna användbara lösenord och synkronisera dessa lösenord med din interna databas med hjälp av Admin SDK:s Directory API. När du synkroniserar lösenord bör du förstå hur användarna autentiseras med inloggningswebbadressen för administratörskontrollpanelen.
Så här fungerar partnerdriven SAML-baserad SSO
Bild 1 visar processen genom vilken en användare loggar in på en Google-app, som Gmail, via en SAML-baserad SSO-tjänst som drivs av partner. Den numrerade listan som följer bildinformationen varje steg.
Obs! Innan detta görs måste partnern tillhandahålla Google webbadressen till sin SSO-tjänst samt den offentliga nyckel som Google ska använda för att verifiera SAML-svar.
Bild 1: Detta visar inloggningsprocessen på Google med en SAML-baserad SSO-tjänst.
Den här bilden illustrerar stegen nedan.
- Användaren försöker att nå en app som Google är värd för, exempelvis Gmail, Google Kalender eller en annan Google-tjänst.
- Google genererar en begäran om SAML-autentisering som kodas och bäddas in i webbadressen för partnerns SSO-tjänst. Den RelayState-parameter som innehåller den kodade webbadressen till Google-applikationen som användaren försöker nå är också inbäddad i SSO-webbadressen. Denna RelayState-parameter är en ogenomskinlig identifierare som skickas tillbaka utan ändringar eller inspektion.
- Google skickar en omdirigering till användarens webbläsare. Webbadressen för omdirigering inkluderar den kodade begäran om SAML-autentisering som ska skickas till partnerns SSO-tjänst.
- Webbläsaren omdirigerar till SSO-webbadressen.
- Partnern avkodar SAML-begäran och extraherar webbadressen för både Googles ACS (Assertion Consumer Service) och användarens måladress (RelayState-parameter).
- Partnern autentiserar sedan användaren. Partner kan autentisera användare genom att antingen be om giltiga inloggningsuppgifter eller genom att söka efter giltiga sessionscookies.
- Partnern genererar ett SAML-svar som innehåller den autentiserade användarens användarnamn. I enlighet med SAML v2.0-specifikationen signeras detta svar digitalt med partnerns offentliga och privata DSA/RSA-nycklar.
- Partnern kodar SAML-svaret och RelayState-parametern och returnerar denna information till användarens webbläsare. Partnern tillhandahåller en mekanism så att webbläsaren kan vidarebefordra denna information till Googles ACS. Till exempel kan partnern bädda in SAML-svar och målwebbadress i ett formulär och tillhandahålla en knapp som användaren kan klicka på för att skicka formuläret till Google. Partnern kan också inkludera JavaScript på sidan som skickar formuläret till Google.
- Webbläsaren skickar ett svar på ACS-webbadressen. Googles ACS verifierar SAML-svaret med hjälp av partnerns offentliga nyckel. Om svaret verifieras omdirigerar ACS användaren till måladressen.
- Användaren är inloggad i Google-appen.
