Informationen zur Sprache im Bereich Identität

Lernziele

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

• Erkennen der Branchenstandards für die Identitäts- und Zugriffsverwaltung
  
• Erläutern des Zusammenhangs zwischen SAML und XML
  
• Erklären des Unterschieds zwischen Identitätsanbieter und Serviceanbieter
  

Identitätsstandards und -protokolle

Können Sie sich nur schwer vorstellen, die Sicherheit der Identitäten Ihrer Benutzer aufrecht zu erhalten, wenn diese sich nicht bei externen Websites oder Anwendungen anmelden müssen? Wie können die Produkte so vieler Unternehmen, ja sogar konkurrierende Produkte, zusammenarbeiten?

Die Antwort sind Branchenstandards und -protokolle für die Identitäts- und Zugriffsverwaltung. Das klingt jetzt vielleicht ein wenig einschüchternd, muss es aber gar nicht sein. Ein Standard ist nichts anderes als ein Satz allgemein vereinbarter Methoden, an die sich die Branche hält. Ein Standard kann ein Protokoll beinhalten, das festlegt, wie Systeme Informationen austauschen.

Dies sind die drei Protokolle, die die sich Salesforce und andere Anbieter bei der Implementierung von Identitätslösungen halten.

• SAML
  
• OAuth 2.0
  
• OpenID Connect
  

SAML-Protokoll

Wenn Benutzer ohne wiederholte Anmeldung nahtlos zwischen Salesforce-Organisationen und -Anwendungen wechseln können sollen, richten Sie Single Sign-On (SSO) ein. Dazu verwenden Sie das Protokoll SAML (Security Assertion Markup Language).

Die folgenden Beispiele zeigen, wann SAML am Werk ist:

• Wenn Sie sich bei Salesforce angemeldet haben und dann auf den App Launcher klicken, um direkt zu Ihrem Gmail-Posteingang zu gelangen, dann ist SAML am Werk.
  
• Wenn Benutzer, die sich bereits bei einer anderen Anwendung angemeldet haben, ohne erneute Anmeldung auf ihre Salesforce-Organisation zugreifen können, ist auch hier SAML am Werk.
  

SAML-Bestätigung

So funktioniert SAML: Ein Benutzer versucht, auf einen Service zuzugreifen. Der Serviceanbieter sendet eine Anfrage an den Identitätsanbieter, in der er im Prinzip fragt: "Ist es in Ordnung, wenn dieser Benutzer auf meinen Service zugreift?" Der Identitätsanbieter stellt sicher, dass Benutzer wirklich die sind, die sie zu sein behaupten, indem er seine Datenbank prüft und eine Antwort (also eine Bestätigung) zurückgibt, die etwa wie folgt lautet: "Ja, dieser Benutzer ist autorisiert, und hier sind einige Informationen über ihn."

Moment mal. Was ist der Unterschied zwischen einem Identitätsanbieter und einem Serviceanbieter? Einfach gesagt ist der Identitätsanbieter derjenige, der den Benutzer authentifiziert. Der Serviceanbieter fragt nach der authentifizierten Identität. Wir befassen uns später in dieser Lektion noch eingehender mit Identitäts- und Serviceanbietern.

Als Bestätigung bezeichnet man die übertragenen Informationen. Eine Bestätigung kann detaillierte Informationen über einen Benutzer enthalten. Sie kann auch Attribute über den Benutzer beinhalten, wie Vor- und Nachname, Kontaktinformationen und eventuell sogar seine Position.

Die SAML-Vorgänge passieren im Hintergrund. Ihre Benutzer bekommen davon nichts zu sehen. Sie klicken nur auf ein Symbol oder einen Link und öffnen eine andere Anwendung, ohne weitere Informationen angeben oder sich erneut anmelden zu müssen. Manchmal liegen am Zielort bereits Informationen über den Benutzer vor (eben jene Attribute), wenn dieser dort ankommt.

SAML und XML

SAML ist ein XML-basiertes Protokoll. Das bedeutet, die Informationspakete, die ausgetauscht werden, sind in XML geschrieben. XML ist für Menschen (mehr oder weniger) lesbar, sodass Sie sich eine ungefähre Vorstellung von den Abläufen machen können. Das ist sehr praktisch, wenn Sie sicherstellen möchten, ob alles richtig funktioniert.

Die folgende Abbildung zeigt einen Teil einer SAML-Bestätigung. Verstehen Sie auf den ersten Blick nur "Bahnhof"? Riskieren Sie einen zweiten Blick, dann sieht das alles gar nicht mehr so schlimm aus. Dieser Auszug enthält Informationen über den Benutzernamen, die Telefonnummer und den Vornamen eines Benutzers.

In diesem Beispiel übergibt die Salesforce-Organisation die Informationen über den Benutzer an eine andere Anwendung. Die Anwendung kann diese Informationen zum Autorisieren des Benutzers und zur persönlichen Anpassung der Oberfläche nutzen. Das Wichtigste ist jedoch, dass sich der Benutzer für den Zugriff auf die Anwendung nicht erneut anmelden muss.

OAuth 2.0-Protokoll

Bei OAuth (Open Authorization) 2.0 handelt es sich um ein offenes Protokoll, das die sichere Datenfreigabe zwischen Anwendungen ermöglicht. Der Benutzer arbeitet dabei in einer Anwendung, bekommt jedoch Daten aus einer anderen angezeigt. Beispiel: Sie sind bei Ihrer mobilen Salesforce-Anwendung angemeldet und zeigen Daten aus Ihrer Salesforce-Organisation an.

Hinter den Kulissen führen die Anwendungen eine Art Handshake durch und fordern den Benutzer dann auf, die Datenfreigabe zu autorisieren. Wenn Entwickler Ihre Anwendung in Salesforce integrieren möchten, verwenden sie OAuth-APIs.

Hier sind einige Beispiele dazu:

• Eine mobile Anwendung, die Kontakte aus einer Salesforce-Organisation abruft, verwendet OAuth.
  
• Eine Salesforce-Organisation, die Kontakte aus einem anderen Service abruft, verwendet ebenfalls OAuth.
  

Das folgende Beispiel zeigt die Anfrage einer Anwendung an den Benutzer, ob er den Informationszugriff mit OAuth 2.0 genehmigt.

OpenID Connect-Protokoll

Dieses Protokoll fügt oberhalb von OAuth 2.0 eine Authentifizierungsschicht hinzu, um einen sicheren Austausch von Benutzerinformationen zu ermöglichen. Wie SAML sendet OpenID Connect Identitätsinformationen von einem Service zu einem anderen. Im Gegensatz zu SAML ist OpenID Connect auf die modernen sozialen Netze ausgelegt. Sind Sie beim Installieren einer neuen Anwendung schon einmal gefragt worden "Möchten Sie sich mit Ihrem Google-Account anmelden?"? Falls ja, verwendet diese Anwendung das OpenID Connect-Protokoll. Bei der Anmeldung mit Google erstellen Sie weder ein Account noch ein weiteres Kennwort. Nur Google ist im Besitz dieser Informationen.

Der Anwendungsentwickler verwendete das OpenID Connect-Protokoll, um Social Sign-On zu ermöglichen.

Wenn Google beispielsweise die Identität eines Benutzers im Namen eines anderen Service überprüft, dann authentifiziert es den Benutzer. In dieser Hinsicht ist Google also ein Identitätsanbieter.

Salesforce bietet integrierte Unterstützung für mehrere große soziale Identitätsanbieter wie etwa Google, Facebook und LinkedIn. Wenn ein Anbieter nicht standardmäßig unterstützt wird, können Sie ihn dennoch verwenden, sofern er das OpenID Connect-Protokoll implementiert, wie beispielsweise Amazon und PayPal.

Das Protokoll OpenID Connect hat für Benutzer den Vorteil, dass sie weniger separate Accounts, Benutzernamen und Kennwörter verwalten müssen. Außerdem können Entwickler ihre Benutzer damit über Websites und Anwendungen hinweg authentifizieren, ohne Kennwortdateien anlegen und verwalten zu müssen. Diese Vorgehensweise macht es Hackern viel schwerer, Benutzer-Accounts zu "knacken".

Serviceanbieter und Identitätsanbieter

Bei der Authentifizierung von Benutzern tauscht SAML Identitätsinformationen zwischen dem Inhaber der Informationen, dem sogenannten Identitätsanbieter, und dem gewünschten Service, den Serviceanbieter genannt wird, aus.

Wenn sich ein Benutzer bei Salesforce anmeldet und dann auf Gmail zugreift, ist Salesforce der Identitätsanbieter und Google der Serviceanbieter. Salesforce kann sowohl als Service- als auch als Identitätsanbieter fungieren.

Salesforce als Serviceanbieter

Authentifizierte Benutzer können von einem externen Identitätsanbieter zu Salesforce wechseln. In diesem Fall ist Salesforce Serviceanbieter: Benutzer möchten auf diesen Service zugreifen, und ihr Identitätsanbieter gestattet dies. Diese Salesforce-Konfiguration ist häufig anzutreffen, da Unternehmen oftmals bereits einen Identitätsanbieter nutzen. Der Identitätsanbieter kann einer von mehreren verfügbaren Anbietern sein, wie etwa die Active Directory Federation Services (ADFS) von Microsoft, PingFederate von Ping Identity, das Open-Source-Produkt Shibboleth oder OpenAM von ForgeRock.

Benutzer melden sich über einen Identitätsanbieter an und werden dann zu Salesforce (dem Serviceanbieter) weitergeleitet. In einem anderen Modul werden wir Single Sign-On mit Salesforce als Serviceanbieter einrichten und eine Drittanbieteranwendung als externen Identitätsanbieter konfigurieren.

Salesforce als Identitätsanbieter

Authentifizierte Benutzer können auch von Salesforce zu anderen Cloud-Umgebungen und Anwendungen wechseln. In diesem Fall fungiert Salesforce als Identitätsanbieter und bietet SSO für Benutzer, die sich mit anderen Serviceanbietern verbinden möchten.

SAML-Flow für SSO

Für die ganz Neugierigen zeigt die folgende Abbildung den SAML-Kommunikationsfluss beim SSO-Prozess. Das geschieht alles hinter den Kulissen. Das muss Sie nicht unbedingt interessieren. Und es wird auch nicht abgeprüft.

Der gesamte SSO-Prozess läuft mit blitzartiger Geschwindigkeit ab, besteht aber trotzdem aus einigen Schritten.

1. Der Benutzer versucht, auf Salesforce zuzugreifen.
   
2. Salesforce erkennt die SSO-Anforderung und erstellt eine SAML-Anforderung.
   
3. Salesforce leitet die SAML-Anforderung wieder zum Browser weiter.
   
4. Der Browser leitet die SAML-Anforderung zum externen Identitätsanbieter weiter.
   
5. Der Identitätsanbieter überprüft die Identität des Benutzers und erstellt ein Datenpaket mit der SAML-Bestätigung, die die Benutzerauthentifizierung beinhaltet.
   
6. Der Identitätsanbieter sendet die SAML-Bestätigung an den Browser.
   
7. Der Browser leitet die Bestätigung an Salesforce weiter.
   
8. Salesforce prüft die Bestätigung.
   
9. Der Benutzer wird angemeldet und darf auf Salesforce zugreifen.
   

Übersicht über die Identitätsterminologie

Na, wie fanden Sie diesen Schnellkurs zum Thema Identitätsprotokolle? Wenn Begriffe ähnlich klingen und nur kleine, aber feine Unterschiede bestehen, dann ist es oft schwer, Verwechslungen zu vermeiden. Wir haben Ihnen deshalb hier eine Übersicht zusammengestellt. Das hilft Ihnen bestimmt weiter!

Was kommt jetzt?

Sie haben jetzt im Schnelldurchlauf die Branchenstandards für die Identitäts- und Zugriffsverwaltung kennen gelernt. Machen Sie sich keine Gedanken, wenn es Ihnen schwerfällt, sie alle auseinander zu halten. Sie sollten sich vorerst nur merken, dass Salesforce Identity Protokolle für die Implementierung seiner Funktionen einsetzt.

So, und jetzt kommt der vergnügliche Teil! Haben Sie genug von Konzepten und Definitionen? Dann lassen Sie uns das Gelernte zum Teil in die Praxis umsetzen. Später in diesem Trail werden Sie Sicherheitsfunktionen in Ihrer Salesforce Dev-Organisation einrichten.

Ressourcen

• Salesforce-Hilfe: SAML-SSO-Flow
  
• Salesforce-Hilfe: Identifizieren der Benutzer und Verwalten des Zugriffs