- Vilken version av SAML stöder SSO API:et?
- Fungerar SAML SSO med POP3 eller IMAP?
- Fungerar SAML SSO med Gmail Atom-flödet?
- Fungerar SAML SSO med AuthSub?
- Kan vi använda RSA istället för DSA för implementeringen av enkel inloggning?
- Hur kan jag generera verifieringscertifikatet som krävs för SSO?
- Om vår domän implementerar SSO, kan vi fortfarande logga in direkt på Google?
- Hur kan den icke-persistenta sessionscookien som identifierar en användare under en webbläsarsession raderas (t.ex. vid utloggning)?
- Varför fungerar inte URL:en för att ändra lösenord?
- Varför fungerar SAMLResponse HTML-formuläret i Firefox men inte i Internet Explorer?
- Hur kan jag tillåta användare att se partnerns startsida utan att autentisera?
- Vilket är Recipient-attributet som krävs i SAML-svaret?
- Hur säkerställer jag att min tredjepartsidentitetsleverantör anger rätt Recipient-attribut?
Vilken version av SAML stöder SSO API:et?
Vi stöder för närvarande SAML v2.0. Besök http://www.oasis-open.org/specs/index.php#samlv2.0 för att hitta information om SAML v2.0-standarden.
Fungerar SAML SSO med POP3 eller IMAP?
Nej, SAML fungerar bara med Google Workspace-webbapparna.
Fungerar SAML SSO med Gmail Atom-flödet?
Nej, Gmail Atom-flödet använder HTTP-baserad autentisering.
Fungerar SAML SSO med AuthSub?
Ja, SAML fungerar med AuthSub.
Kan vi använda RSA istället för DSA för implementeringen av enkel inloggning?
Ja, du kan välja att använda RSA- eller DSA-krypteringsalgoritmen. Vi accepterar båda.
Hur kan jag generera verifieringscertifikatet som krävs för SSO?
Du kan generera X509-certifikat med kommandot openssl . Mer information finns i Generera nycklar och certifikat för SSO .
Om vår domän implementerar SSO, kan vi fortfarande logga in direkt på Google?
Nej, med SSO implementerad kan domänens slutanvändare inte logga in direkt på Google. Superadministratörer kan fortfarande logga in på Googles kontrollpanel (t.ex. http://www.google.com/a/example.com).
Hur kan den icke-persistenta sessionscookien som identifierar en användare under en webbläsarsession raderas (t.ex. vid utloggning)?
Efter lyckad autentisering via SAML ställer Google in en sessionscookie för att identifiera en användares session. När användaren uttryckligen loggar ut (t.ex. genom att klicka på utloggningsknappen) måste denna cookie förstöras. Om din implementering innebär permanent sessionshantering ("kom ihåg mig på den här datorn") kan du behöva kontrollera hur och när denna cookie förstörs. Vid utloggning omdirigerar Google till din utloggningsservlet. I din utloggningsservlet kan du presentera användaren med några alternativ som kan avgöra om sessionscookien ska raderas eller inte.
Varför fungerar inte URL:en för att ändra lösenord?
Det tar ungefär en timme innan ändringar av URL:en för att ändra lösenord i SSO-inställningarna träder i kraft.
Varför fungerar SAMLResponse HTML-formuläret i Firefox men inte i Internet Explorer?
Det kan bero på att Internet Explorer misstolkar RelayState. Internet Explorer tolkar "<mpl" som "<mpl". För att förhindra att detta händer bör XML-specialtecken användas som escape-tecken i RelayState. Ändra { &, <, >, ', " } till { &, <, >, ', ' }.
Hur kan jag tillåta användare att se partnerns startsida utan att autentisera?
Se det här ämnet i diskussionsgruppen för ett exempel på SAMLResponse.
Vilket är Recipient-attributet som krävs i SAML-svaret?
Enligt avsnitt 4.1.4.2 i SAML 2.0-profilspecifikationen ska attributet Recipient vara lika med URL:en för Assertion Consumer Service (ACS). Den finns här:
<samlp:Response ...>
<saml:Assertion ...>
<saml:Subject>
<saml:NameID ...>user@domain.com</saml:NameID>
<saml:SubjectConfirmation ...>
<saml:SubjectConfirmationData Recipient="https://www.google.com/a/domain.com/acs" .../>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:Assertion>
</samlp:Response>
Se frågorna nedan för hur du kan lägga till mottagaren i SAML-svaret.
Hur säkerställer jag att min tredjepartsidentitetsleverantör anger rätt Recipient-attribut?
Om din kommersiella eller öppen källkods-identitetsleverantör stöder SAML 2.0, bör den redan ange rätt Recipient-attribut. Om du får ett av felmeddelandena ovan betyder det att Recipient-attributet är felaktigt. Om så är fallet, kontakta leverantören eller underhållaren av programvaran och skicka dem länken till den här sidan.
Kan mina användare autentisera sig själva med hjälp av inloggnings-URL:en på administratörens kontrollpanel med SSO?
Ja. SAML-baserad enkel inloggning (SSO) låter dig överföra inloggningsbehörighet för Google Workspace till din egen identitetsleverantörsprogramvara (till exempel en befintlig inloggningsportal). Din programvara styr och hanterar autentiseringen av dina användarkonton, och Google Workspace omdirigerar ett inloggningsförsök till din SSO-portal. Men det är viktigt att komma ihåg att dina administratörer fortfarande kommer att kunna hantera dessa tjänster med hjälp av Googles administratörskonsols administratörsinloggnings-URL ( https://www.google.com/a/example.com ). Detta ger dig flexibilitet om din SSO-portal har ett problem eller behöver uppdateras.
Vad betyder detta felmeddelande: "Den här tjänsten kan inte nås eftersom din inloggningsförfrågan inte innehöll någon mottagarinformation"?
Det betyder att SAML-svaret saknar ett obligatoriskt mottagarattribut .
Vad betyder detta felmeddelande: "Den här tjänsten kan inte nås eftersom din inloggningsförfrågan innehöll ogiltig mottagarinformation"?
Det betyder att Recipient- attributet i SAML-svaret inte matchar ACS-URL:en (Assertion Consumer Service).
Vad betyder detta felmeddelande: "Det går inte att komma åt det här kontot eftersom inloggningsuppgifterna inte kunde verifieras"?
Detta innebär vanligtvis att den privata nyckeln som används för att signera SAMLResponse inte matchar det publika nyckelcertifikat som Google Workspace har registrerat. Ladda upp certifikatet i SSO-inställningarna i kontrollpanelen och försök igen.