- Welke versie van SAML ondersteunt de SSO API?
- Werkt SAML SSO met POP3 of IMAP?
- Werkt SAML SSO met de Gmail Atom-feed?
- Werkt SAML SSO met AuthSub?
- Kunnen we RSA in plaats van DSA gebruiken voor de implementatie van single sign-on?
- Hoe kan ik het verificatiecertificaat genereren dat nodig is voor SSO?
- Als ons domein SSO ondersteunt, kunnen we dan nog steeds rechtstreeks inloggen bij Google?
- Hoe kan de niet-permanente sessiecookie die een gebruiker tijdens een browsersessie identificeert, worden verwijderd (bijvoorbeeld bij het uitloggen)?
- Waarom werkt de URL voor het wijzigen van het wachtwoord niet?
- Waarom werkt het SAMLResponse HTML-formulier wel in Firefox, maar niet in Internet Explorer?
- Hoe kan ik gebruikers toegang geven tot de partnerstartpagina zonder dat ze zich hoeven te authenticeren?
- Wat is het Recipient-attribuut dat vereist is in het SAML-antwoord?
- Hoe zorg ik ervoor dat mijn externe identiteitsaanbieder het juiste 'Recipient'-kenmerk specificeert?
Kunnen mijn gebruikers zich met SSO authenticeren via de inlog-URL van het beheerderspaneel?
Welke versie van SAML ondersteunt de SSO API?
We ondersteunen momenteel SAML v2.0. Ga naar http://www.oasis-open.org/specs/index.php#samlv2.0 voor meer informatie over de SAML v2.0-standaard.
Werkt SAML SSO met POP3 of IMAP?
Nee, SAML werkt alleen met de webapplicaties van Google Workspace.
Werkt SAML SSO met de Gmail Atom-feed?
Nee, de Gmail Atom-feed maakt gebruik van HTTP-basisauthenticatie.
Werkt SAML SSO met AuthSub?
Ja, SAML werkt wel met AuthSub.
Kunnen we RSA in plaats van DSA gebruiken voor de implementatie van single sign-on?
Ja, u kunt kiezen tussen het RSA- of DSA-coderingsalgoritme. Wij accepteren beide.
Hoe kan ik het verificatiecertificaat genereren dat nodig is voor SSO?
Je kunt X509-certificaten genereren met het openssl commando. Zie Sleutels en certificaten genereren voor SSO voor meer informatie.
Als ons domein SSO ondersteunt, kunnen we dan nog steeds rechtstreeks inloggen bij Google?
Nee, met SSO geïmplementeerd kunnen eindgebruikers van een domein niet rechtstreeks inloggen bij Google. Superbeheerders kunnen nog steeds inloggen op het Google-configuratiescherm (bijv. http://www.google.com/a/example.com ).
Hoe kan de niet-permanente sessiecookie die een gebruiker tijdens een browsersessie identificeert, worden verwijderd (bijvoorbeeld bij het uitloggen)?
Na een succesvolle authenticatie via SAML plaatst Google een sessiecookie om de sessie van een gebruiker te identificeren. Wanneer de gebruiker zich expliciet afmeldt (bijvoorbeeld door op de afmeldknop te klikken), moet deze cookie worden verwijderd. Als uw implementatie gebruikmaakt van persistent sessiebeheer ("onthoud mij op deze computer"), moet u mogelijk bepalen hoe en wanneer deze cookie wordt verwijderd. Na het afmelden stuurt Google de gebruiker door naar uw afmeldservlet. In uw afmeldservlet kunt u de gebruiker opties presenteren die bepalen of de sessiecookie wel of niet moet worden verwijderd.
Waarom werkt de URL voor het wijzigen van het wachtwoord niet?
Wijzigingen in de URL voor het wijzigen van het wachtwoord in de SSO-instellingen worden pas na ongeveer een uur van kracht.
Waarom werkt het SAMLResponse HTML-formulier wel in Firefox, maar niet in Internet Explorer?
Het probleem kan te wijten zijn aan een verkeerde interpretatie van de RelayState door Internet Explorer. Internet Explorer interpreteert "<mpl" als "<mpl". Om dit te voorkomen, moeten speciale XML-tekens in de RelayState worden ontsnapt. Wijzig { &, <, >, ', " } in { &, <, >, ', " }.
Hoe kan ik gebruikers toegang geven tot de partnerstartpagina zonder dat ze zich hoeven te authenticeren?
Zie dit onderwerp in de discussiegroep voor een voorbeeld van een SAMLResponse.
Wat is het Recipient-attribuut dat vereist is in het SAML-antwoord?
Volgens paragraaf 4.1.4.2 van de SAML 2.0-profielspecificatie moet het Recipient-attribuut gelijk zijn aan de URL van de Assertion Consumer Service (ACS). Deze bevindt zich hier:
<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>
Zie de onderstaande vragen voor meer informatie over het toevoegen van de ontvanger aan het SAML-antwoord.
Hoe zorg ik ervoor dat mijn externe identiteitsaanbieder het juiste 'Recipient'-kenmerk specificeert?
Als uw commerciële of open-source identiteitsprovider SAML 2.0 ondersteunt, zou deze al het juiste Recipient-attribuut moeten specificeren. Als u een van de bovenstaande foutmeldingen krijgt, betekent dit dat het Recipient-attribuut onjuist is. Neem in dat geval contact op met de leverancier of de beheerder van de software en stuur hen de link naar deze pagina.
Kunnen mijn gebruikers zich met SSO authenticeren via de inlog-URL van het beheerderspaneel?
Ja. Met SAML-gebaseerde Single Sign-On (SSO) kunt u de inlogbevoegdheid voor Google Workspace overdragen aan uw eigen identiteitsprovidersoftware (bijvoorbeeld een bestaand inlogportaal). Uw software beheert de authenticatie van uw gebruikersaccounts en Google Workspace stuurt een inlogpoging door naar uw SSO-portaal. Het is echter belangrijk om te onthouden dat uw beheerders deze services nog steeds kunnen beheren via de beheerders-URL van de Google Admin-console ( https://www.google.com/a/example.com ). Dit biedt u flexibiliteit als uw SSO-portaal een probleem heeft of moet worden bijgewerkt.
Wat betekent deze foutmelding: "Deze service is niet toegankelijk omdat uw inlogverzoek geen ontvangersinformatie bevatte"?
Dit betekent dat het SAML-antwoord een verplicht 'Recipient'- attribuut mist.
Wat betekent deze foutmelding: "Deze service is niet toegankelijk omdat uw aanmeldingsverzoek ongeldige ontvangersinformatie bevatte"?
Dit betekent dat het Recipient- attribuut in het SAML-antwoord niet overeenkomt met de Assertion Consumer Service (ACS)-URL.
Wat betekent deze foutmelding: "Toegang tot dit account is niet mogelijk omdat de inloggegevens niet konden worden geverifieerd"?
Dit betekent meestal dat de privésleutel die is gebruikt om de SAMLResponse te ondertekenen niet overeenkomt met het openbare sleutelcertificaat dat Google Workspace heeft opgeslagen. Upload het certificaat in de SSO-instellingen in het configuratiescherm en probeer het opnieuw.