Single Sign-On bei der mobilen Salesforce-Anwendung – Übersicht

Erste Schritte

Für diesen Authentifizierungsprozess sollten Sie sich zunächst ein ausführliches Beispiel des erwarteten SAML-Prozess-Flows ansehen.

Organisationen mit Active Directory-Verbunddiensten (Active Directory Federation Services, ADFS) zum Authentifizieren mit SAML

• Stellen Sie sicher, dass Ihr Setup der Entwicklungsdokumentation zu ADFS folgt.

Implementieren mobiler Salesforce-Anwendungen mit SSO

Aktivieren von "Meine Domäne"

1. Aktivieren Sie die Funktion "Meine Domäne" in Ihrer Organisation, indem Sie die Schritte unter Meine Domäne – Übersicht ausführen.
2. Fügen Sie Ihre SAML-Konfiguration dem Authentifizierungsdienst im Abschnitt "Authentifizierungskonfiguration" von "Meine Domäne" mithilfe der Schritte unter Hinzufügen von Identitätsanbietern auf einer Anmeldeseite hinzu.
(Dieser Domänen-URL stellt den URL dar, den Sie als Verbindung mit mobilen Salesforce-Anwendungen hinzufügen, wenn Sie sich anmelden, um den vom Serviceanbieter initiierten Single Sign-On-Prozess zu starten.)

Hinweis: Benutzer werden diese Methode verwenden wollen, um den benutzerdefinierten URL für "Meine Domäne" in ihrer Anwendung als benutzerdefinierte Verbindung hinzuzufügen (stellen Sie sicher, dass Benutzer nicht den Link "Benutzerdefinierte Domäne verwenden" auf der Standardanmeldeseite verwenden). Siehe: Wechseln des Anmeldeservers in Salesforce Mobile Apps

Auf Formularen basierende Anmeldeseite

• Nachdem Sie Ihre Domäne für "Meine Domäne" eingegeben haben, sollten Sie zu einer Webseite mit einem Formular gelangen, in dem der Benutzer seinen Benutzernamen und sein Kennwort für das Netzwerk eingeben kann.
• Andere Methoden wie die integrierte Windows-Authentifizierung (NTLM) oder andere Aufforderungen zum Eingeben von Anmeldeinformationen werden von mobilen Salesforce-Anwendungen nicht verarbeitet und es wird wahrscheinlich eine Fehlermeldung (401-Fehler bei der Abfrage) oder einfach ein weißer Bildschirm angezeigt.
• Lesen Sie die folgende Microsoft-Dokumentation zum Einrichten dieses Anmeldeseitentyps für Organisationen mit ADFS 2.0.

RelayState

• Wenn Ihr SAML-Service den SAML-Prozess in mobilen Salesforce-Anwendungen initiiert, beinhaltet dieser einen RelayState für Ihren Identitätsanbieter, der ein Echo an uns zurücksendet, um das OAuth-Setup nach dem Authentifizieren zu starten (siehe Schritte 5 bis 8 im erwarteten SAML-Prozess-Flow).
• Informationen zur Unterstützung von RelayState für ADFS 2.0 nach dem Installieren aller Rollup-Patches auf dem Server finden Sie in der Dokumentation zum Unterstützen des vom Identitätsanbieter initiierten RelayState von Microsoft.

HTTP POST- oder HTTP Redirect-Bindungen

• Ihr Identitätsanbieter muss HTTP POST- oder HTTP Redirect-Bindungen unterstützen. Nutzen Sie die HTTP Redirect-Bindung, wenn Ihre Organisation ADFS als Identitätsanbieter verwendet. Weitere Einzelheiten finden Sie unten im Abschnitt zum Fehler 404.
• Hinweis: Wenn Sie ADFS verwenden, wird die Redirect-Bindung in den Einstellungen für Salesforce Single Sign-On konfiguriert, in Ihrer ADFS-Konfiguration wird jedoch POST beibehalten. Es soll sichergestellt werden, dass die SAML-Anforderung auf den Servern mithilfe von Redirect gesendet wird, aber POST für die Rückgabe von ADFS beibehalten wird.

Häufige Probleme

• Sie melden sich mit SAML und "Meine Domäne" an und auf der Oberfläche der mobilen Salesforce-Anwendung wird die Oberfläche der vollständigen Site angezeigt.
  • Der Authentifizierungsprozess nimmt keine Weiterleitung zum OAuth-Setup vor, da der RelayState nicht genauso lautet, wie er anfangs vom SAML-Service bereitgestellt wurde.
  • Überprüfen Sie Ihre RelayState-Einstellung bei Ihrem Identitätsanbieter, um sicherzustellen, dass der RelayState ordnungsgemäß abgerufen und dem SAML-Service wieder bereitgestellt wird.
  • Stellen Sie sicher, dass der Anmelde-URL des Identitätsanbieters im SAML-Abschnitt Ihrer Salesforce-Organisation keine zusätzlichen Parameter enthält, die beim Weiterleiten zu diesem URL übergeben werden müssen.
  • Siehe auch: OAuth mit SAML 2.0-Authentifizierung, relayState kann länger als 80 Zeichen sein.

• Benutzern wird beim Eingeben des URL für "Meine Domäne" eine 401-Fehlermeldung oder ein weißer Bildschirm angezeigt.
  • Dies tritt auf, wenn Ihr ADFS für die Verwendung der integrierten Windows-Authentifizierung (NTLM-Aufforderung) konfiguriert ist. Diese Methode wird von mobilen Salesforce-Anwendungen nicht unterstützt.
  • Ihr ADFS-Administrator muss eine auf Formularen basierende Anmeldeseite einrichten.
  • Microsoft gibt hier eine Übergangslösung zum Konfigurieren einer auf Formularen basierenden Intranet-Authentifizierung an.

• Bei SAML-Behauptungen tritt folgender Fehler auf: "InResponseTo: Invalid." (InResponseTo: Ungültig).

• Benutzern werden in mobilen Salesforce-Anwendungen oft auf Zertifikate bezogene Fehler angezeigt.
  • In den meisten Fällen kann dieses Problem vom Salesforce-Support nicht behoben werden. 
  • Interne SSO-Teams oder IT-Teams müssen ein neues Zertifikat hochladen oder sicherstellen, dass ihr aktuelles Zertifikat nicht auf dem nativen Gerät installiert oder geladen werden muss.

• 404-Fehler. "File or directory not found. The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable." (Datei oder Verzeichnis wurde nicht gefunden. Die gesuchte Ressource wurde möglicherweise entfernt oder umbenannt, oder sie steht vorübergehend nicht zur Verfügung.)
  • Dieser Fehler tritt meist bei der Verwendung der HTTP Redirect-Bindung auf, da sie die Anforderung innerhalb des URL sendet. Dies kann die Anforderung über die normale Obergrenze für die Microsoft IIS-Sicherheit von 2048 hinaus erweitern und als Ergebnis wird der Fehler 404 zurückgegeben.
  • Als Übergangslösung können Sie die Obergrenze auf dem Server erhöhen, der den Fehler ausgibt. Sehen Sie sich dazu hier das Beispiel von Microsoft an.
  • Alternativ können Sie die Anforderungsbindung auf POST anpassen und sicherstellen, dass Ihr Identitätsanbieter so konfiguriert ist, dass stattdessen diese Bindung akzeptiert wird.

• "An SSL error has occurred and a secure connection to the server cannot be made." (Es ist ein SSL-Fehler aufgetreten und es kann keine sichere Verbindung mit dem Server hergestellt werden)
  • Wenn Benutzern dieser Fehler angezeigt wird, besteht die bewährte Vorgehensweise darin, für iOS und die Anwendungsversion ein Upgrade auf die neuesten verfügbaren Versionen vorzunehmen. Siehe auch: Anforderungen für die Salesforce-Anwendung
  • Salesforce empfiehlt IT-Teams/Sicherheitsteams ein Upgrade ihrer Single Sign-On-Server, damit TLS 1.2 unterstützt wird.
  • In iOS 9.0 wurde ATS (App Transport Security) eingeführt, um den Sicherheitsprotokollen von Apple gerecht zu werden. In iOS 11 hat Apple detailliertere Optionen hinzugefügt, um es für Localhost und Webinhalte zu deaktivieren.
  • Wenn ATS deaktiviert ist, verwendet iOS eine Datensatzebene der Version TLS 1.0 (obwohl letztendlich TLS 1.2 ausgehandelt wird). Wenn es aktiviert ist, lautet die Datensatzebene TLS 1.2. Für einen RFC-konformen Server sollte dies keine Rolle spielen.
  • Dieser Fehler kann auftreten, wenn die Websitezertifikate des Identitätsanbieters Ihrer Organisation kein gültiges Zertifikat oder keine vollständige Zertifikatskette enthalten. Es wird empfohlen, dass Sie lokale Tools oder Drittanbieter-Websites für die SSL-Überprüfung verwenden, um Ihre Zertifikate zu überprüfen und sicherzustellen, dass Sie über vollständige Zertifikatsketten verfügen.
  • Siehe auch: Salesforce deaktiviert TLS 1.1

• OAuth-Fehler. 1800. 
  • Beim Festlegen Ihres Remote-Zugriffs ist ein Problem aufgetreten. Dieser Fehler tritt auf, wenn der Identitätsanbieter den RelayState-Wert in der SAML-Anforderung falsch codiert oder abschneidet, was dazu führt, dass der Quellwert verloren geht.
  • Dieser Quellwert identifiziert, mit welchen mobilen Anwendungen Sie eine Verbindung herstellen und ein OAuth-Zugriffstoken erhalten. Stellen Sie sicher, dass die SAML-Antwort zurück an Salesforce genau mit der übereinstimmt, die in der ursprünglichen Anforderung von Salesforce bereitgestellt wurde.

Erweiterte Authentifizierung

• Zusätzliche Formen der Authentifizierung für iOS und Android:
  • Diese können mithilfe der Einstellung "Für die Benutzerauthentifizierung unter iOS den systemeigenen Browser verwenden" oder "Für die Benutzerauthentifizierung auf Android-Geräten den systemeigenen Browser verwenden" von "Meine Domäne" umgesetzt werden.
  • Dies beinhaltet Funktionen wie die Google-Authentifizierung mithilfe von Open ID auf iOS-Geräten oder Richtlinien für Azure oder den bedingten Zugriff mit Intune, die in den standardmäßigen Webansichten der Anwendungen nicht verwendet werden können.
  • Siehe: Anpassen Ihrer Anmeldeseite "Meine Domäne" für Authentifizierungsmethoden für Mobilbenutzer
• Möchten Sie MDM-Steuerelemente und eine zertifikatbasierte Authentifizierung implementieren? Siehe: MDM- und EMM-Unterstützung von Salesforce für Android und iOS