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 Artikel behandelt die SSO-Integration mit unserer Plattform anhand eines Beispiels mit Okta.

• Wenn Sie MS Azure Entra ID verwenden, lesen Sie unseren Beitrag über SSO für Microsoft Azure Active Directory.
• Wenn Sie im Unternehmen Keycloak verwenden lesen Sie unseren SSO Artikel für Keycloak.

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.

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.

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).

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.

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.

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.

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 (Achtung: es gelten die monatlichen Kosten pro Benutzer)
  
• Benutzer kann sich unter verschiedenen White-Label-Benutzern 1:n anmelden

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.

Achtung: Im Falle von 1:1 fällt eine monatliche Gebühr für jeden Nutzer an.

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.

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.

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.

Nach der Anlage sollten die Benutzer wie folgt aussehen:

Inspiration: Die White-Label-Benutzer müssen nicht zwangsläufig basierend auf der Abteilung wie Marketing oder CustomerService angelegt werden. Wir verwenden dies hier nur als Beispiel.

Es ist auch durchaus üblich, verschiedene White Label User für jedes

1. Land (Österreich, Deutschland, Schweiz, Spanien, Italien, Brasilien, etc.) und/oder
2. Marke (MarkeA, MarkeB, MarkeC, etc.) und/oder
3. Produktlinie (Schuhe, Hemden, Jacken, etc.)

... anzulegen.

Der Anwendungsfall kann für jedes Unternehmen anders sein. Überlegen Sie also, wie es für Ihr Unternehmen am sinnvollsten wäre.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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

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:

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.

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.

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.

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.

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.

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.

In unserem Beispiel haben wir "AllowedWhiteLabelUsers" verwendet.

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

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.

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.

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

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.

• Firefox
• Chrome

Nachdem Sie das SAML-Tracer-Popup geöffnet haben,...

1. beginnen Sie mit einem SSO-Anmeldeprozess
2. Sie werden sehen, dass sich die Liste am oberen Rand des Popups mit HTTP-Anfragen füllt.
3. Klicken Sie auf die Anfrage, die als SAML-Anfrage in oranger Farbe markiert ist.
4. Wählen Sie die Registerkarte Summary (oder SAML für alle Details im XML-Format). Sie können überprüfen, ob die Daten (z. B. Rolle) korrekt übertragen wurden. In diesem Fall wurde die Rolle whitelabel_admin übertragen. Das ist genau das, was wir brauchen, damit sich dieser Benutzer als Whitelabel-Portal-Admin anmelden kann.