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.
Hinweis
Lernen Sie auf Deutsch? In diesem Badge ist für die praktischen Trailhead-Aufgaben Englisch als Bearbeitungssprache festgelegt. Übersetzungen werden zur Referenz in Klammern angegeben. Vergewissern Sie sich, dass Sie in Ihrem Trailhead-Playground (1) das Gebietsschema auf USA und (2) die Sprache auf Englisch festgelegt haben. (3) Verwenden Sie zum Kopieren und Einfügen nur die englischen Werte. Die zugehörigen Anweisungen finden Sie hier.
Weitere Details dazu, wie Sie die übersetzte Trailhead-Umgebung optimal nutzen können, finden Sie unter dem Badge "Trailhead in Ihrer Sprache".
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
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
- Der Kunde öffnet eine Mobile SDK-Anwendung.
- Eine Authentifizierungsaufforderung wird angezeigt.
- Der Kunde gibt Benutzername und Kennwort ein.
- Die Anwendung sendet die Anmeldeinformationen des Kunden an Salesforce und erhält anschließend eine Sitzungs-ID als Bestätigung einer erfolgreichen Authentifizierung.
- Der Kunde genehmigt die Anforderung der Anwendung, um Zugriff auf die Anwendung zu gewähren.
- Die Anwendung wird gestartet.
Laufende Autorisierung
- Der Kunde öffnet eine mobile Anwendung.
- 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.
- 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
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 Kunde schaltet ein Telefon ein und gibt die PIN für das Gerät ein.
- Der Kunde startet eine Mobile SDK-Anwendung.
- Der Kunde gibt die Anmeldeinformationen für die Salesforce-Organisation ein.
- Der Kunde gibt den PIN-Code für die Mobile SDK-Anwendung ein.
- Der Kunde arbeitet mit der Anwendung und verschiebt sie in den Hintergrund, indem er eine andere Anwendung öffnet (oder einen Anruf entgegen nimmt usw.).
- Das Zeitlimit der Anwendung wird überschritten.
- 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).
- 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
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
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.
- Der Endbenutzer öffnet die mobile Anwendung.
- Die verbundene Anwendung leitet den Benutzer an Salesforce weiter, um die mobile Anwendung zu authentifizieren und zu autorisieren.
- Der Benutzer genehmigt den Zugriff für diesen Autorisierungs-Flow.
- Die verbundene Anwendung empfängt den Rückruf von Salesforce an den Umleitungs-URL, der die Zugriffs- und Aktualisierungs-Token extrahiert.
- 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.
- 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
| 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
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.
- Wechseln Sie in Ihrer Trailhead Playground- oder Developer Edition-Organisation zu Setup.
- 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.
- 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.
- Aktivieren Sie unter "API (OAuth-Einstellungen aktivieren)" OAuth-Einstellungen aktivieren.
- 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.
- Wählen Sie unter Verfügbare OAuth-Umfänge Folgendes aus:
- Verwalten von Benutzerdaten über APIs (api)
- Verwalten von Benutzerdaten über Webbrowser (web)
- Durchführen von Anforderungen zu einem beliebigen Zeitpunkt (refresh_token, offline_access)
- Klicken Sie auf Hinzufügen. Dieser minimale Umfangbereich funktioniert bei den meisten Mobile SDK-Anwendungen gut.
- Aktivieren Sie das Kontrollkästchen Require Secret for Web Server Flow (Geheimnis für Webserver-Flow erforderlich).
- Klicken Sie auf Speichern.
- Notieren Sie sich die Werte für 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.
