Erfassen Sie Ihre Fortschritte
Trailhead-Startseite
Trailhead-Startseite

Grundlagen der Sicherheit und Authentifizierung

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:

  • Erklären der Sicherheits- und Authentifizierungsmethoden, die in Salesforce-Anwendungen verwendet werden.
  • Erläutern der Verwendung von verbundenen Anwendungen für die Integration von mobilen Anwendungen und Salesforce-Server.
  • Erläutern der grundlegenden OAuth-Terminologie.
  • Erklären des Ereignis-Flows bei OAuth-Authentifizierung und PIN-Sicherheit.

Informationen zu Sicherheit und Authentifizierung

Für Unternehmensanwendungen, die auf mobilen Geräten ausgeführt werden, ist eine sichere Authentifizierung unabdingbar. Das Branchenstandardprotokoll OAuth 2.0 ermöglicht eine sichere Authentifizierung für den Zugriff auf die Daten eines Verbrauchers, ohne dass Benutzername und Kennwort des Benutzers herausgegeben werden. Es wird häufig als der "Werkstattschlüssel" für den Softwarezugriff beschrieben. Ein Werkstattschlüssel bietet nur Zugriff auf bestimmte Funktionen Ihres Autos. Der Kofferraum oder das Handschuhfach lassen sich beispielsweise mit einem solchen Schlüssel nicht öffnen.

Entwickler von mobilen Anwendungen können die OAuth 2.0-Implementierung von Salesforce schnell und einfach einbetten. Die Implementierung verwendet eine HTML-Ansicht, um Benutzername und Kennwort zu erfassen, die danach an den Server gesendet werden. Der Server gibt ein Sitzungstoken und ein persistentes Aktualisierungstoken zurück, die für weitere Aktionen im Gerät gespeichert werden.

Für die Verbindung zwischen einer mobilen Anwendung und Salesforce wird hauptsächlich eine verbundene Salesforce-Anwendung verwendet. Eine verbundene Anwendung bietet dem Entwickler und dem Administrator Steuerungsmöglichkeiten für die Art der Verbindung der Anwendung sowie die zugriffsberechtigten Benutzer. Eine verbundene Anwendung kann den Zugriff beispielsweise auf eine bestimmte Gruppe von Kunden festlegen, einen IP-Adressbereich festlegen oder einschränken usw.

OAuth-Terminologie

Wenn Ihren Orientierung fehlt, können Sie mit dieser Liste wieder in die Spur finden. Diese Bezeichnungen führen bei gemeinsamer Betrachtung direkt ins OAuth-Nirvana.
Hinweis

Hinweis

Der Begriff "Verbraucher" in dieser Liste bezieht sich auf eine Mobile SDK-Anwendung. Ein menschlicher Verbraucher wird dagegen als "Benutzer" oder "Endbenutzer" bezeichnet.

Verbraucherschlüssel
Ein Wert, der vom Verbraucher (in diesem Fall von der Mobile SDK-Anwendung) für die Identifikation der Anwendung bei Salesforce verwendet wird. Wird als client_id bezeichnet.
Zugriffstoken
Ein vom Verbraucher verwendeter Wert, mit dem im Namen des Benutzers Zugriff auf geschützte Ressourcen erlangt werden kann, ohne dass die Salesforce-Anmeldeinformationen des Benutzers verwendet werden müssen. Das Zugriffstoken ist eine Sitzungs-ID und kann unmittelbar verwendet werden.
Aktualisierungstoken
Ein Token, das vom Verbraucher verwendet wird, um ein neues Zugriffstoken abzurufen, ohne dass der Endbenutzer den Zugriff erneut genehmigen muss.
Autorisierungscode
Ein kurzlebiges Token, das den durch den Endbenutzer gewährten Zugriff darstellt. Der Autorisierungscode dient zum Abrufen eines Zugriffstokens und eines Aktualisierungstokens.
Verbundene Anwendung
Eine Anwendung außerhalb von Salesforce, bei der das OAuth-Protokoll verwendet wird, um sowohl den Salesforce-Benutzer als auch die externe Anwendung zu verifizieren.

OAuth2-Authentifizierungs-Flow

Der Flow der Ereignisse bei der OAuth-Autorisierung hängt vom Status der Authentifizierung auf dem Gerät ab.

Flow bei der erstmaligen Autorisierung

  1. Der Kunde öffnet eine Mobile SDK-Anwendung.
  2. Eine Authentifizierungsaufforderung wird angezeigt.
  3. Der Kunde gibt Benutzername und Kennwort ein.
  4. Die Anwendung sendet die Anmeldeinformationen des Kunden an Salesforce und erhält anschließend eine Sitzungs-ID als Bestätigung einer erfolgreichen Authentifizierung.
  5. Der Kunde genehmigt die Anforderung der Anwendung, um Zugriff auf die Anwendung zu gewähren.
  6. Die Anwendung wird gestartet.

Laufende Autorisierung

  1. Der Kunde öffnet eine mobile Anwendung.
  2. Die Anwendung wird sofort gestartet, wenn die Sitzungs-ID aktiv ist. Die Anwendung verwendet das Aktualisierungstoken der ersten Autorisierung, um eine aktualisierte Sitzungs-ID zu erhalten, wenn die Sitzungs-ID veraltet ist.
  3. Die Anwendung wird gestartet.

PIN-Sicherheit

Verbundene Salesforce-Anwendungen verfügen durch den PIN-Schutz in der Anwendung über eine zusätzliche Sicherheitsebene. Dieser PIN-Schutz gilt für die mobile Anwendung und darf nicht mit dem PIN-Schutz des Geräts oder der Anmeldesicherheit durch die Salesforce-Organisation verwechselt werden.

Um den PIN-Schutz zu verwenden, muss der Entwickler beim Erstellen der verbundenen Anwendung das Kontrollkästchen Implementiert Bildschirmsperre & PIN-Schutz aktivieren. Die Administratoren von mobilen Anwendungen haben dann die Möglichkeit, den PIN-Schutz zu aktivieren, die Dauer des Zeitlimits anzupassen und die PIN-Länge festzulegen.

Hinweis

Hinweis

Da die PIN-Sicherheit im Betriebssystem des mobilen Geräts implementiert ist, steht diese Funktion in HTML5-Webanwendungen nicht zur Verfügung.

In der Praxis kann der PIN-Schutz verwendet werden, um die mobile Anwendung zu sperren, wenn Sie für einen bestimmten Zeitraum (in Minuten) nicht genutzt wird. Wenn eine mobile Anwendung in den Hintergrund verschoben wird, läuft die Uhr weiter.

Der PIN-Schutz funktioniert folgendermaßen:
  1. Der Kunde schaltet ein Telefon ein und gibt die PIN für das Gerät ein.
  2. Der Kunde startet eine Mobile SDK-Anwendung.
  3. Der Kunde gibt die Anmeldeinformationen für die Salesforce-Organisation ein.
  4. Der Kunde gibt den PIN-Code für die Mobile SDK-Anwendung ein.
  5. Der Kunde arbeitet mit der Anwendung und verschiebt sie in den Hintergrund, indem er eine andere Anwendung öffnet (oder einen Anruf entgegen nimmt usw.).
  6. Das Zeitlimit der Anwendung wird überschritten.
  7. Der Kunde öffnet die Anwendung erneut, und der PIN-Eingabebildschirm der Anwendung wird angezeigt (für die Mobile SDK-Anwendung, nicht für das Gerät).
  8. Der Kunde gibt die PIN der Anwendung ein und kann die Arbeit fortsetzen.

Flow für OAuth2-Benutzeragenten

Im Benutzeragenten-Flow empfängt die verbundene Anwendung, die die Clientanwendung in die Salesforce-API integriert, das Zugriffstoken als HTTP-Umleitung. Die verbundene Anwendung fordert, dass der Autorisierungsserver den Benutzeragenten zu einem Webserver oder zu einer lokal zugänglichen Ressource umleitet. Der Webserver kann das Zugriffstoken aus der Antwort extrahieren und an die verbundene Anwendung weiterleiten. Aus Sicherheitsgründen wird die Tokenantwort als Hash-Tag-Fragment (#) im URL bereitgestellt. Dieses Format verhindert, dass das Token an den Server sowie an andere Server in Verweis-Headern weitergeleitet wird.

Warnung

Warnung

Da das Zugriffstoken im Umleitungs-URL codiert ist, kann es für den Benutzer und andere Anwendungen auf dem Gerät verfügbar gemacht werden.

Hinweis

Hinweis

Verbundene Anwendungen für diese Typen von Clients können benutzerspezifische Geheimnisse schützen. Das Client-Geheimnis ist jedoch zugänglich und auswertbar, da sich die ausführbaren Clientdateien auf dem Gerät des Benutzers befinden. Aus diesem Grund wird bei diesem Benutzeragenten-Flow das Client-Geheimnis nicht verwendet. Die Autorisierung beruht auf der Same-Origin-Policy des Benutzeragenten. Der Benutzeragenten-Flow unterstützt auch keine "Out-of-Band"-Posts.

Benutzeragenten-Flow
Angenommen, Sie nutzen das Salesforce Mobile SDK, um eine mobile Anwendung zu entwickeln, die Kundenkontaktdaten aus Ihrer Salesforce-Organisation abruft. Das Mobile SDK implementiert den OAuth 2.0-Benutzeragenten-Flow für Ihre verbundene Anwendung, integriert die mobile Anwendung in Ihre Salesforce-API und gewährt ihr autorisierten Zugriff auf die festgelegten Daten. Der Flow umfasst die folgenden Schritte.
  1. Der Endbenutzer öffnet die mobile Anwendung.
  2. Die verbundene Anwendung leitet den Benutzer an Salesforce weiter, um die mobile Anwendung zu authentifizieren und zu autorisieren.
  3. Der Benutzer genehmigt den Zugriff für diesen Autorisierungs-Flow.
  4. Die verbundene Anwendung empfängt den Rückruf von Salesforce an den Umleitungs-URL, der die Zugriffs- und Aktualisierungs-Token extrahiert.
  5. Die verbundene Anwendung verwendet das Zugriffstoken, um im Namen des Endbenutzers auf Daten zuzugreifen.

Verbundene Anwendungen

Eine verbundene Anwendung integriert eine Anwendung mithilfe von APIs mit Salesforce. Verbundene Anwendungen verwenden die Standardprotokolle SAML und OAuth für die Authentifizierung, ermöglichen Single Sign-On und bieten Zugriffstoken für die Verwendung mit Salesforce-APIs. Zusätzlich zu den OAuth-Standardfunktionen bieten verbundene Anwendungen dem Salesforce-Administrator die Möglichkeit, verschiedene Sicherheitsrichtlinien festzulegen, und explizite Kontrolle darüber, welche Personen die entsprechenden Anwendungen verwenden können.

Es folgt eine allgemeine Liste mit Informationen, die Sie angeben, wenn Sie eine verbundene Anwendung erstellen.
  • Name, Beschreibung, Logo und Kontaktinformationen
  • URL, unter dem Salesforce die Anwendung für die Autorisierung oder Identifikation finden kann
  • Autorisierungsprotokoll: OAuth, SAML oder beides
  • IP-Bereiche von Benutzeranmeldungen bis zu verbundenen Anwendungen (optional)
  • Informationen zu mobilen Richtlinien, die die verbundene Anwendung erzwingen kann (optional)

Salesforce Mobile SDK-Anwendungen verwenden verbundene Anwendungen, um auf Salesforce OAuth-Services zuzugreifen und Salesforce-REST-APIs aufzurufen.

Werte des Umfangsparameters

OAuth erfordert eine Konfiguration des Umfangs sowohl im Server als auch im Client. Die Vereinbarung zwischen beiden Seiten definiert den Vertrag für den Umfang.

  • Serverseite: Definieren Sie die Umfangsberechtigungen in einer verbundenen Anwendung im Salesforce-Server. Diese Einstellungen bestimmen, welche Zugriffsebenen Clientanwendungen, z. B. Mobile SDK-Anwendungen, anfordern können. Konfigurieren Sie die OAuth-Einstellungen Ihrer verbundenen Anwendung zumindest den Angaben in Ihrem Code entsprechend. Bei den meisten Anwendungen genügen refresh_token, web und api.
  • Clientseite: Geben Sie Umfangsanforderungen in Ihrer Mobile SDK-Anwendung an. Client-Umfangsanforderungen müssen eine Teilmenge der Umfangsberechtigungen der verbundenen Anwendungen sein.

Serverseitige Konfiguration

Sie können die folgenden Werte des Umfangsparameters festlegen.
Value (Wert) Beschreibung
api Gestattet den Zugriff auf den Account des aktuellen angemeldeten Benutzers über die APIs, beispielsweise REST-API oder Bulk-API. Dieser Wert enthält auch chatter_api, wodurch Zugriff auf Chatter-REST-API-Ressourcen gewährt wird.
chatter_api Ermöglicht nur den Zugriff auf Chatter-REST-API-Ressourcen.
custom_permissions Ermöglicht den Zugriff auf die benutzerdefinierten Berechtigungen in einer Organisation, die der verbundenen Anwendung zugeordnet ist, und gibt an, ob die einzelnen Berechtigungen für den aktuellen Benutzer aktiviert wurden.
full Ermöglicht Zugriff auf alle für angemeldete Benutzer zugänglichen Daten und schließt alle anderen Umfänge ein. full gibt kein Aktualisierungstoken zurück. Sie müssen explizit den refresh_token-Umfang anfordern, um ein Aktualisierungstoken zu erhalten.
id Gestattet Zugriff auf den Identitäts-URL-Service. Wenn Sie profile, email, address oder phone einzeln anfordern, erhalten Sie dasselbe Ergebnis wie bei der Verwendung von id; sie können alle synonym verwendet werden.
openid Ermöglicht den Zugriff auf die eindeutige ID des angemeldeten Benutzers für verbundene OpenID Connect-Anwendungen.

Verwenden Sie den openid-Umfang im OAuth 2.0-Benutzeragenten-Flow und im OAuth 2.0-Authentifizierungs-Flow für Webserver, um neben dem Zugriffstoken auch ein signiertes ID-Token abzurufen, das den OpenID Connect-Spezifikationen entspricht.

refresh_token Ermöglicht die Rückgabe eines Aktualisierungs-Tokens, wenn Sie zum Bezug eines solchen Tokens berechtigt sind. Die Anwendung kann dann mit den Daten des Benutzers interagieren, während der Benutzer offline ist. Dies kann synonym mit der Anforderung offline_access verwendet werden.
visualforce Gestattet den Zugriff auf vom Kunden erstellte Visualforce-Seiten. Gewährt keinen Zugriff auf standardmäßige Salesforce-Benutzeroberflächen.
web Ermöglicht die Verwendung von access_token im Web und enthält visualforce, wodurch der Zugriff auf vom Kunden erstellte Visualforce-Seiten gewährt wird.
Hinweis

Hinweis

Für Mobile SDK-Anwendungen müssen Sie immer zwingend refresh_token als serverseitige Einstellung für verbundene Anwendungen auswählen. Auch dann, wenn Sie den Bereich full auswählen, müssen Sie dennoch explizit refresh_token auswählen.

Clientseitige Konfiguration

Die folgenden Regeln decken die Bereichskonfiguration für Mobile SDK-Anwendungen ab.

Umfang

Mobile SDK – Anwendungskonfiguration

refresh_token

Wird implizit von Mobile SDK für Ihre Anwendung angefordert und muss nicht in die Umfangsliste Ihre Anwendung eingeschlossen werden.

api

Sollte einbezogen werden, wenn Sie Aufrufe der Salesforce REST-API verwenden (gilt für die meisten Anwendungen.)

web

Sollte einbezogen werden, wenn Ihre Anwendung auf Seiten zugreift, die in einer Salesforce-Organisation definiert wurden (gilt für Anwendungen, die Salesforce-basierte Webseiten laden.)

full

Sollte einbezogen werden, wenn Sie alle Berechtigungen anfordern möchten. (Mobile SDK fordert refresh_token implizit für Sie an.)

chatter_api

Sollte einbezogen werden, wenn Ihre Anwendung Chatter-REST-APIs aufruft.

id

(nicht erforderlich)

visualforce

Verwenden Sie stattdessen web.

Erstellen von verbundenen Anwendungen

Das Erstellen einer verbundenen Anwendung ist einfach, erfordert allerdings Administratorrechte. In Ihrer eigenen Developer Edition- oder Trailhead Playground-Organisation werden Ihnen diese Berechtigungen automatisch erteilt.

  1. Wechseln Sie in Ihrer Trailhead Playground- oder Developer Edition-Organisation zu Setup.
  2. Führen Sie einen der folgenden Schritte aus:
    • Wenn Sie Salesforce Classic verwenden, wählen Sie Erstellen | Anwendungen aus, blättern zum Abschnitt "Verbundene Anwendungen" und klicken auf Neu.
    • Bei Verwendung von Lightning Experience wählen Sie Anwendungen | Anwendungsmanager aus und klicken auf Neue verbundene Anwendung.
  3. Füllen Sie das Formular unter Grundlegende Informationen wie folgt aus:
    • Name der verbundenen Anwendung: <beliebiger Name, der Leerzeichen enthalten darf>
    • API-Name: Übernehmen Sie den vorgeschlagenen Wert.
    • Kontakt-E-Mail: Geben Sie Ihre E-Mail-Adresse ein.
  4. Aktivieren Sie unter "API (OAuth-Einstellungen aktivieren)" OAuth-Einstellungen aktivieren.
  5. Legen Sie Rückruf-URL auf Folgendes fest:<beliebige URL-Zeichenfolge, real oder ausgedacht, z. B. mysampleapp://auth/success>. Falls ein automatischer Vorschlag für den Rückruf-URL angegeben wird, akzeptieren Sie diesen nicht. Geben Sie stattdessen den Rückruf-URL an.
  6. Wählen Sie unter Verfügbare OAuth-Umfänge Folgendes aus:
    • Zugriff auf Ihre Daten und Datenverwaltung (api)
    • Gewähren von Zugriff auf Ihre Daten über das Web (web)
    • Durchführen von Anforderungen in Ihrem Namen zu jedem beliebigen Zeitpunkt (refresh_token, offline_access)
    Dieser minimale Umfangbereich funktioniert bei den meisten Mobile SDK-Anwendungen gut.
  7. Klicken Sie auf Hinzufügen.
  8. Wenn Ihre Organisation die browserbasierte Authentifizierung verwendet, auch bekannt als "Erweiterte Authentifizierung", aktivieren Sie das Kontrollkästchen Geheimnis für Webserver-Flow erforderlich.
  9. Klicken Sie auf Save (Speichern).
Beachten Sie nach dem Speichern der Konfiguration die Details Ihrer neuen verbundenen Anwendung.
  • Notieren Sie sich die Werte Rückruf-URL und Verbraucherschlüssel. Sie kopieren diese Werte in die Konfiguration Ihrer Mobile SDK-Anwendung, ehe Sie diese verteilen.
  • Das Verbrauchergeheimnis wird von Mobile SDK-Anwendungen nicht verwendet. Sie können diesen Wert daher ignorieren.

Nachdem Sie sich ein wenig mit der Architektur und Sicherheit von Mobile SDK vertraut gemacht haben, ist es Zeit, praktisch mit dem Mobile SDK zu üben. Sie können beginnen, indem Sie sich der folgenden Aufgabe stellen, für die nur eine Developer Edition- oder Trailhead Playground-Organisation erforderlich ist. Danach empfehlen wir, dass Sie das Projekt Einrichten Ihrer Mobile SDK-Entwicklertools durcharbeiten.