Felmeddelanden för SAML-app

Om du stöter på felmeddelanden för SAML-appar (Security Assertion Markup Language) är här några felsökningssteg som vägleder dig.

Fel vid generering av SAML-app

När du skapar en SAML-app på administratörskonsolen kan följande 400-fel visas:

400 duplicerat enhets-id

Du ser detta om du försöker skapa ett program med ett redan befintligt enhets-id. Lös det här felet genom att använda en applikation som redan har konfigurerats eller ett annat enhets-id.

När du skapar en SAML-app på administratörskonsolen kan följande 500-fel visas:

  • I avsnittet Google IdP-information visas ett 500-fel överst på skärmen om att klienttjänstens server inte är tillgänglig om du klickar på knappen hämta certifikat eller hämta metadata.
  • När du hämtar scheman i mappningen Namn-id eller Attribut visas ett 500-fel överst på skärmen om tidsgränsen för schematjänsten nås eller visar ett serverundantag.
  • Om tjänsten spconfig inte är tillgänglig visas ett 500-fel överst på skärmen i det sista steget när du klickar på Slutför.

Lösningen på dessa 500-fel är att bara vänta och sedan testa flödet igen. Om det fortfarande inte fungerar kontaktar du support för Google Cloud. Om du åtgärdar detta och användarna fortfarande ser felmeddelandet kontaktar du support för Google Cloud.

SAML-körtidsfel

Följande felscenarier kan uppstå när du testar ett SAML SSO-flöde i flöden som initierats av IdP eller tjänstleverantörer:

403 appen har inte konfigurerats

Det här felet kan uppstå i följande fall:

  • I ett flöde som initieras av en tjänstleverantör har applikationen som motsvarar det enhets-id som nämns i begäran inte skapats på administratörskonsolen.

  • I ett flöde som initierats av en tjänstleverantör matchar enhets-id som angetts i SAML-begäran inte något enhets-id för de appar som är installerade för närvarande. Om någon ändrar applikations-id:t (tjänstleverantörens id) som nämns i den IdP-initierade webbadressen, ser du ett felmeddelande om att appen inte har konfigurerats.

Så här löser du ett 403-fel där appen inte har konfigurerats:

  1. Kontrollera att appen som motsvarar det enhets-id som nämns i begäran har installerats innan du initierar begäran.
  2. Kontrollera att det enhets-id som anges i SAML-begäran är korrekt och motsvarar det du angav när appen skapades.
  3. Kontrollera att tjänsteleverantörens id i webbadressen för begäran är detsamma som app-id:t för "app har inte aktiverats:".

403 appen har inte konfigurerats för användaren

Så här löser du ett 400-fel där appen har inte konfigurerats för användaren: 

Kontrollera att värdet i taggen saml:Issuer i SAMLRequest matchar värdet för enhets-id som konfigurerats i avsnittet SAML-avsnittet Uppgifter om tjänstleverantör i administratörskonsolen. Värdet är skiftlägeskänsligt.

400 appen med motsvarande enhets-id har inte aktiverats för användaren

Så här löser du 400-felet med motsvarande enhets-id för applikation:

  1. Öppna fler menyalternativ.
  2. Aktivera tjänsten för alla eller för användarens organisation.

400 ogiltig mappning av användar-id för saml

Om en tjänstleverantör skickar en NAMEID-parameter i SAML-begäran måste denna parameter måste vara densamma som den som konfigurerats på IdP-sidan. Annars misslyckas SAML-begäran med detta fel.

Så här löser du 400-felet med ogiltig mappning av användar-id för saml:

  1. Öppna Grundläggande information och kontrollera parametern NAMEID.
  2. Kontrollera att parametern NAMEID som överförs i SAML-begäran är densamma som den som konfigurerats på IdP-sidan.

400 ogiltigt tjänstleverantörs-id saml

När tjänstleverantörens id i webbadressen för IdP-flödet är felaktigt, på grund av felkonfiguration eller manipulering av webbadressen.

Så här löser du felet med ogiltigt tjänstleverantörs-id för saml:

  1. Öppna Grundläggande information och kontrollera fältet för app-id.

  2. Kontrollera att det tjänstleverantörs-id som överförts i webbadressen för begäran är detsamma som app-id:t.

SAML-svaret skickar tillbaka statusen AVVISAD för följande scenarier.

Du kan se något av följande felmeddelanden:

Ogiltig begäran om tjänstleverantörsinitierat flöde, ACS-webbadress i $parameter för begäran matchar inte konfigurerad $parameter för ACS-webbadress.


ACS-webbadress som anges i SAML-begäran och ACS-webbadress som konfigureras i administratörskonsolen för motsvarande applikation matchar inte.

Så här löser du felet med att ACS-webbadress i $parameter för begäran matchar inte konfigurerad $parameter för ACS-webbadress:

  1. Gå till detaljer om tjänstleverantör

  2. Kontrollera att ACS-webbadressen är densamma som i SAML-begäran

Ogiltigt idp-id anges i webbadressen

Detta betyder att det IdP-id (ett förvrängt kund-id) som anges i webbadressen har manipulerats och är felaktigt.

Så här löser du felet med ogiltigt IdP-id i webbadressen:

  1. Öppna informationssidan för Google IdP 

  2. Hämta IdP-id från slutet av webbadressen för enhets-id

  3. Kontrollera att IdP-id i webbadressen för begäran är detsamma som webadressen för enhets-id

IdP-initierat flöde Ogiltigt IdP-id har angetts i begäran.

Användaren som ringer upp har ändrat den IdP-initierade webbadressen för SSO och ändrat IdP-id till ett annat kund-id (förvrängt).

Så här löser du felet om ett ogiltigt IdP-id i begäran:

  1. Öppna informationssidan för Google IdP 

  2. Hämta IdP-id från slutet av webbadressen för enhets-id

  3. Kontrollera att IdP-id i webbadressen för begäran är detsamma som webadressen för enhets-id

När användarna testar ett SAML SSO-flöde i flöden som initierats av IdP eller tjänstleverantör kan de stöta på ett av flera 500-fel på grund av serverprocesser som blir otillgängliga.

Lösningen på dessa 500-fel är att bara vänta och sedan testa flödet igen. Om det fortfarande inte fungerar kontaktar du support för Google Cloud. Om du löser detta och dina användare fortfarande ser felmeddelandet kontaktar du support för Google Cloud.

Var det här till hjälp?
Hur kan vi förbättra den?