Diese Website verwendet nur erforderliche Cookies, um sicherzustellen, dass unsere Website optimal genutzt werden kann. Wir verwenden keine Cookies, die personenbezogene Daten ohne Ihre vorherige Zustimmung verarbeiten. Cookie Richtlinien

Verbinden Sie sich mit unserer QR Code Plattform mit SSO über SAML 2.0

book reader icon
9 Minuten
facebook logo gray
linkedin logo gray
mail logo gray
Verbinden Sie sich mit unserer QR Code Plattform mit SSO über SAML 2.0

Dieser Artikel zeigt Ihnen, wie Sie Ihre Benutzer mit SSO über SAML 2.0 mit unserer Plattform verbinden können. Diese Funktion ist nur für Enterprise-Kunden verfügbar.

Dieser Beitrag enthält technische Details für IAM-Admins oder Ihre IT-Abteilung, die den Identity Provider (IDP) verwaltet. Bitte wenden Sie sich an einen IT-Experten in Ihrem Haus, der Sie bei der Einrichtung der SSO-Verbindung unterstützt.

Was ist SSO?

SSO steht für Single Sign-On. Dabei handelt es sich um einen Authentifizierungsprozess, der es einem Benutzer ermöglicht, mit einem einzigen Satz von Anmeldedaten (z. B. Benutzername und Passwort) auf mehrere Dienste wie unsere QR Code-Plattform zuzugreifen. Mit SSO müssen sich die Benutzer nicht für jede Anwendung, die sie nutzen, ein anderes Passwort merken, was den Anmeldeprozess vereinfacht und die Sicherheit erhöht, da nicht mehr so viele Anmeldedaten benötigt werden. Nach der Authentifizierung kann der Benutzer zwischen verschiedenen Anwendungen oder Diensten navigieren, ohne sich erneut anmelden zu müssen.

Was ist SAML 2.0?

SAML steht für Security Assertion Markup Language. Es ist ein XML-basiertes Framework, das für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Parteien verwendet wird, insbesondere zwischen einem Identitätsanbieter = Identity Provider (IDP) und einem Dienstanbieter = Service Provider (SP).

Wie funktioniert die Integration?

In diesem SSO-Setup agiert Ihr Unternehmen als Identity Provider (IDP), der uns Benutzerdaten zur Verfügung stellt. Unsere White Label-Plattform fungiert als Service Provider (SP), der die Benutzerdaten entgegennimmt und den Benutzern Zugang zu unserem System gewährt.

Vereinfachte SSO-Integrationsübersicht
Vereinfachte SSO-Integrationsübersicht

In Ihrem IDP-System fügen Sie unsere White Label Plattform als sogenannten Client ein.

Grundlegende Informationen über Ihren IDP und unseren SP werden über sogenannte Descriptor URLs ausgetauscht. Hinter diesen URLs stehen Dateien, die den IDP oder den SP mit Details beschreiben, die die jeweils andere Seite automatisch verarbeiten kann und die bei der Konfiguration helfen.

Die Benutzerinformationen werden über eine SAML 2.0 Nachricht gesendet. In dieser Nachricht sind die Daten in Attributen kodiert. Beim Versenden der Informationen aus Ihrem IDP bildet ein Outbound Mapper Ihre internen IDP-Felder, wie Vorname, Nachname, E-Mail, etc. auf SAML 2.0 Attribute ab.

Wenn wir Ihre SAML 2.0-Nachricht erhalten, wandelt unser Inbound Mapper das SAML 2.0-Attribut zurück in unser internes Format und wir melden den Benutzer bei unserer Plattform an.

Wie verbinde ich mich mit der QR Code Plattform über SSO?

1. Loggen Sie sich in Ihr Konto ein

Besuchen Sie unsere Website und melden Sie sich bei Ihrem White-Label-Konto an. Sobald Sie eingeloggt sind, gehen Sie zu Ihren Konto Einstellungen und wählen die SSO Registerkarte.

Login

Login
Login Maske

2. Wählen Sie den SSO-Typ

Wenn Sie sich mit einem Benutzer aus Ihrem Unternehmen auf unserer Plattform anmelden, können Sie wählen, wie dieser Benutzer auf die Plattform zugreifen kann. Es sind 2 verschiedene Szenarien möglich:

  • Benutzer meldet sich als White-Label-Benutzer 1:1 an
  • Benutzer kann sich unter verschiedenen White-Label-Benutzern 1:n anmelden
SSO-Typen: 1 zu 1 versus 1 zu vielen
SSO-Typen: 1 bis 1 versus 1 bis vielen

Um mit der Einrichtung der SSO-Verbindung fortzufahren, müssen Sie zunächst einen SSO-Typ auswählen.

Damit Sie die Konzepte so schnell wie möglich verstehen, verwenden wir in diesem Artikel ein Beispiel. Gehen wir von folgenden Annahmen aus:
  • Die Benutzer Adam, Eve und Steve arbeiten in Ihrem Unternehmen und benötigen Zugriff auf die White Label Plattform
  • Sie verwenden Okta als Identity Provider (IDP) in Ihrem Unternehmen. Wenn Sie nicht Okta, sondern einen anderen IDP haben, brauchen Sie sich keine Sorgen zu machen. Auch wenn die Schritte nicht vollständig identisch sind, sind sie doch recht ähnlich zu Ihrem IDP.

Benutzer anlegen (1:1)

1 IDP-Benutzer ist 1 White Label-Benutzer zugewiesen
1 IDP-Benutzer ist 1 White Label-Benutzer zugewiesen

Wählen Sie Benutzer, wenn Sie möchten, dass ein Benutzer in Ihrem Identity Provider (="IDP-User") genau einem (1:1) individuellen White Label-Benutzer zugeordnet wird.

Wenn sich ein IDP-Benutzer zum ersten Mal anmeldet, wird der entsprechende White Label-Benutzer erstellt. Im obigen Beispiel wird der IDP User Adam als White Label User Adam angelegt, wenn er sich zum ersten Mal anmeldet.

Subaccount anlegen (1:n)

In diesem Szenario nehmen wir als Beispiel an, dass die White Label Plattform einen Benutzer für die Abteilung Marketing und einen Benutzer für den CustomerService hat.
1 IDP-Benutzer ist 1 oder mehreren White Label-Benutzern zugewiesen
1 IDP-Benutzer ist 1 oder mehreren White Label-Benutzern zugewiesen

Wählen Sie Subaccount, wenn Sie möchten, dass ein Benutzer in Ihrem Identity Provider (="IDP-User") einem oder mehreren (1:n) White Label-Benutzern zugeordnet wird.

Im obigen Beispiel können die IDP-Benutzer Adam und Eve die White Label-Benutzer Marketing und CustomerService verwenden. Der IDP-Benutzer Steve kann hingegen nur den White Label-Benutzer CustomerService verwenden.

Ein IDP-Benutzer agiert dann wie ein Teamleiter und kann wählen, unter welchem White Label User er sich anmelden möchte. So können Adam und Eve wählen, ob sie sich als White Label User Marketing oder CustomerService anmelden wollen.

3. Legen Sie die SAML 2.0 IDP Descriptor URL fest

SAML 2.0 IDP Deskriptor URL Ihres Identity Providers eingeben
SAML 2.0 IDP Deskriptor URL Ihres Identity Providers eingeben

Nachdem Sie den SSO-Typ ausgewählt haben, müssen Sie die SSO IDP Descriptor URL Ihres Identity Providers eingeben. Diese wird benötigt, damit wir grundlegende Informationen darüber erhalten, wie wir Ihre Benutzer mit SAML 2.0 verbinden und authentifizieren können.

4. Setzen Sie die  Identity Provider Service URLs

SSO Signon Service URL und SSO Logout Service URL prüfen und ggf. ändern
SSO Signon Service URL und SSO Logout Service URL prüfen und ggf. ändern

Nachdem Sie die SSO IDP Descriptor URL eingegeben haben, werden die Service-URLs aus der Descriptor URL extrahiert und die Felder für die SSO Signon Service URL und die SSO Logout Service URL werden vorausgefüllt.

Wenn keine URLs angezeigt werden, geben Sie diese bitte manuell ein. Die SSO Logout Service URL ist optional. Wenn die URL festgelegt ist, wird der Benutzer zu dieser URL weitergeleitet, wenn er sich von der QR-Code-Plattform abmeldet. Anschließend kann er sich optional auch von seinem IDP abmelden.

5. Prüfen Sie das SSO IDP-Inbound Mapping

Nachdem die SSO IDP Descriptor URL und die SSO Provider Service URLs definiert sind, muss festgelegt werden, in welchem Format der IDP User in der SAML-Nachricht an uns übermittelt wird.

Wir stellen Ihnen bereits Standardwerte für die Attributnamen für Vorname, Nachname, E-Mail und Telefon zur Verfügung. Bitte überprüfen Sie jedoch, wie Ihr IDP die Felder exportiert (Outbound Mapping), da es möglicherweise notwendig ist, diese Werte zu ändern.

Lassen Sie uns anhand eines Beispiels prüfen, wie das Mapping in einem Okta IDP-System funktioniert.

Beispiel IDP SAML Outbound Mappings in Okta
Beispiel IDP SAML Outbound Mappings in Okta

Wie Sie im Screenshot oben sehen können, werden die IDP-Felder auf der rechten Seite wie folgt auf die SAML-Nachrichtenattribute auf der linken Seite gemappt:

  • Vorname: Das IDP-Profilfeld user.firstName wird in der SAML-Nachricht gesendet als Attribut firstname
  • Nachname: das IDP-Profilfeld user.lastName wird in der SAML-Nachricht gesendet als Attribut lastname
  • E-Mail: das IDP-Profilfeld user.email wird in der SAML-Nachricht gesendet als Attribut email

Vergleichen wir nun diese Werte mit den Einstellungen im White-Label-Portal im SSO IDP Inbound Mapping Bereich.

Inbound Mapping Attributnamen
Inbound Mapping Attributnamen

Wie Sie in der folgenden Vergleichstabelle sehen können, haben alle Felder den gleichen Namen (firstname=firstname, lastname=lastname, email=email) und Sie müssen die Attributnamen im Bereich SSO IDP Inbound Mapping nicht ändern.

I IDP
Profil Feldname
II SAML Nachricht Attributname (Outbound Mapping)
III White Label SSO IDP Inbound Mapping
user.email
email
email
user.firstNamefirstnamefirstname
user.lastNamelastnamelastname

Wenn die Werte in Spalte II und III unterschiedlich sind, müssen Sie den Eintrag im Portal im Abschnitt SSO IDP Inbound Mapping auf den Wert in Spalte II ändern.

6. Initialisieren Sie die  Verbindung

Zu guter Letzt klicken Sie auf den Button Connect am unteren Ende des Formulars, um die Verbindung zu Ihrem IDP zu initialisieren.

Klicken Sie auf den Button Connect für die Initialisierung der IDP Verbindung
Klicken Sie auf den Button Connect für die Initialisierung der IDP Verbindung

Sie bekommen dann die Service Provider Descriptor URL angezeigt. Diese URL kann von Ihrem IAM-Admin/IT-Abteilung verwendet werden, um die Konfiguration auf ihrer Seite abzuschließen.

Kopieren Sie die SSO-Service Provier-Deskriptor-URL für die Verwendung in Ihrem IDP
Kopieren Sie die SSO-Service Provier-Deskriptor-URL für die Verwendung in Ihrem IDP

Sie können diese URL über das Kopiersymbol am rechten Ende des Feldes kopieren.

Gehen Sie in Okta zu Application > Your application > General > SAML settings > Edit und fügen Sie die Service Provider Descriptor URL in Single sign-on URL und Audience URI (SP Entity ID) auf der Registerkarte Configure SAML ein, wie im Screenshot unten gezeigt.

Kopieren Sie die Service Provider Descriptor URL in Okta
Kopieren Sie die Service Provider Descriptor URL in Okta

Klicken Sie nun auf Next und dann auf die Schaltfläche Finish.

7. Testen Sie die SSO-Anmeldung

Nachdem Sie die Verbindung hergestellt haben, sehen Sie auf dem Anmeldebildschirm einen neuen Button SSO Login. Klicken Sie auf den Button, um zu sehen, ob der Anmeldevorgang funktioniert.

SSO-Anmeldebutton
SSO-Anmeldebutton

Sie können auch ein Lesezeichen für den direkten SSO-Endpoint setzen, der unten in den SSO-Einstellungen angezeigt wird.

SSO-Anmelde-Endpoint
SSO-Anmelde-Endpoint

Mapping von Rollen im Identity Provider

Wenn Sie den SSO-Typ Subaccount (1:n) gewählt haben, müssen Sie angeben, welcher IDP-Benutzer auf welchen White Label-Benutzer Zugriff haben soll.

In der Regel werden die erlaubten White Label-Benutzernamen auf eine von zwei möglichen Arten im Identity Provider gespeichert:

A. Speichern der erlaubten White Label-Benutzernamen als reguläre Rolle im IDP

In diesem Fall erstellen Sie für jeden White Label User eine zusätzliche Rolle. Der Name der Rolle muss mit dem Namen des White Label-Benutzers identisch sein.

Um unserem Beispiel von oben zu folgen, müssen Sie im IDP die beiden Rollen Marketing und Kundenservice anlegen.

Nun weisen Sie die Rolle Marketing den IDP Usern Adam, Eve und Steve zu. Die Rolle CustomerService wird nur Adam und Eve zugewiesen, da Steve nicht auf den Benutzer CustomerService zugreifen können soll.

Attributname für White Label-Benutzernamen
Attributname für White Label-Benutzernamen

In den SSO IDP Inbound Mappings müssen Sie im Feld White Label User Names den korrekten Attributnamen einstellen, der diese Information enthält. In diesem Fall geben Sie üblicherweise "Role" ein. Je nach IDP-System oder Konfiguration kann der Name anders lauten.

B. Speicherung der erlaubten White Label-Benutzernamen in einem benutzerdefinierten Feld des Benutzerprofils im IDP

In diesem Fall erstellen Sie ein benutzerdefiniertes Feld, z. B. AllowedWhiteLabelUsers, im Benutzerprofil im Identity Provider.

Auch hier verwenden wir den IDP von Okta als Beispiel. Gehen Sie zu Directory > Profile Editor > User (default) und klicken Sie auf Add Attribute.

Beispiel für die Speicherung der erlaubten White Label-Benutzer in einem Profilfeld im IDP (Okta)
Beispiel für die Speicherung der erlaubten White Label-Benutzer in einem Profilfeld im IDP (Okta)

Als Feldtyp wählen Sie "Dropdown", "String-Array" oder einen anderen
Typ, der eine Liste möglicher Werte zur Auswahl für den User bietet. Jeder Wert muss mit einem Benutzernamen übereinstimmen, den Sie auf der White-Label-Plattform erstellt haben.

In unserem Beispiel würde das bedeuten, dass Sie die möglichen Werte Marketing und CustomerService für das benutzerdefinierte Feld AllowedWhiteLabelUsers erstellen.

Wählen Sie nun für jeden IDP User, der auf die White Label Plattform zugreifen können soll, den entsprechenden Namen des White Label Users aus dem AllowedWhiteLabelUsers Dropdown aus.

White Label-Benutzer für den IDP-Benutzer wählen (Beispiel auf Okta)
White Label-Benutzer für den IDP-Benutzer wählen (Beispiel auf Okta)

In unserem Beispiel würden wir also für die IDP-Benutzer Adam und Eve die Werte Marketing und CustomerService wählen. Für den IDP-Benutzer Steve würden wir nur den Wert CustomerService wählen.

Die Tatsache, dass die White Label Benutzernamen nun über ein eigenes Feld AllowedWhiteLabelUsers aus dem IDP übertragen werden, muss unserem System natürlich auch bekannt gegeben werden. Dies wird dadurch erreicht, dass wir den SAML Attributnamen für White Label User Names im SSO IDP Mapping setzen auf unser neues IDP Profil-Feld AllowedWhiteLabelUsers.

Benutzerdefinierter Wert "AllowedWhiteLabelUsers" für SAML Attributnamen für White Label User Names
Benutzerdefinierter Wert "AllowedWhiteLabelUsers" für SAML Attributnamen für White Label User Names

In unserem Beispiel haben wir "AllowedWhiteLabelUsers" verwendet.

Erste Anmeldung eines SSO-Benutzers

In diesem Abschnitt sehen Sie, wie das White-Label-Konto nach der ersten Anmeldung der Benutzer für die 2 verschiedenen SSO-Typen aussieht.

SSO Typ Benutzer (1:1)

Wenn sich ein IDP-Benutzer zum ersten Mal über SSO anmeldet, wird ein White Label-Benutzer mit demselben Namen erstellt. Im folgenden Beispiel sehen Sie die 3 IDP-Benutzer Adam, Eve und Steve, die als White Label-Benutzer im Benutzer-Abschnitt erstellt wurden.

Ein IDP-Benutzer ist einem White-Label-Benutzer zugeordnet
Ein IDP-Benutzer ist einem White-Label-Benutzer zugeordnet

SSO Typ Subaccount (1:n)

Wenn sich ein IDP-Benutzer zum ersten Mal auf unserer Plattform anmeldet, wird ein Subaccount mit der Rolle SSO erstellt und die passenden White Label-Benutzer werden diesem Subaccount zugewiesen. Sie können die Subaccounts im Abschnitt Konto unter der Registerkarte Subaccounts sehen.

Subaccounts für IDP-Benutzer
Subaccounts für IDP-Benutzer

Der folgende Screenshot zeigt den IDP-Benutzer Adam, der den White-Label-Benutzern Marketing und CustomerService zugeordnet ist.

Subaccount mit zugewiesenen Benutzern
Subaccount mit zugewiesenen Benutzern

Fehlersuche

Um die SAML 2.0 Kommunikation zwischen Ihrem Identity Provider (IDP) und unserem Service Provider (SP) zu debuggen, können Sie das Browser Plugin SAML-tracer installieren.

Letzte Aktualisierung vor einer Woche