SSO (Einmalige Anmeldung)

Prev Next

Siehe auch: Authentifizierung, Benutzer, Site-Konfigurationen

Hintergrund

SSO (Single Sign-On) zielt darauf ab, beim Anmelden an der Lobster Data Platform die interaktive Eingabe von Zugangsdaten (Benutzername und Passwort) durch eine Referenz auf eine bestehende Anmeldung bei einem “Externen Identitätsanbieter” zu ersetzen. Bei Bedarf wird eine entsprechende Anmeldung bei diesem in einem eigenen Browserfenster eingeleitet.

Für die Anmeldung einer Sitzung an einer geeignet eingerichteten Lobster Data Platform kann der Benutzer per Klick auf einen im Login-Dialog angezeigten Button für den “Externen Identitätsanbieter” seiner Wahl (im Bild rechts “Microsoft” oder ein fiktiver Anbieter “B²B”) verweisen anstatt Eingaben vorzunehmen.

Sofern die “angebotene” Identität mit einem aktiven Benutzerkonto verknüpft ist, wird dieses dann für die Anmeldung herangezogen.

Was passiert beim Klick auf ( Microsoft )?

  1. Prüfung: Azure-Anmeldung im Kontext vorhanden?

    1. Wenn NEIN: Einleiten der Azure-Identifizierung
      (s. unten: Autorisierungs-URL).

    2. Rückgabe der Azure-Benutzerkennung
      (z. B. registrierte  E-Mail-Adresse)

  2. Prüfung: Existiert ein Benutzerkonto für die Lobster Data Platform, das sich im Feld “Benutzerkennung” (userterm) für ein “Externe Benutzeranmeldeinformation” (ExternalUserLoginInfo)-Attribut mit dem passenden Eintrag für den “Alias des Anbieters” (providerAlias) — hier: azure — auf die oben ermittelte Azure-Benutzerkennung bezieht?

    1. Wenn NEIN: Fehlermeldung / Abbruch des Logins

    2. Wenn JA: Login mit dem Benutzerkonto (sofern aktiv)

 WICHTIG  Falls mehrere Benutzerkonten für die Lobster Data Platform mit der “passenden” providerAlias/userterm Kombination existieren, wird eine Anmeldung ausschließlich mit dem ersten Treffer versucht, auch wenn dieses Konto nicht aktiv sein sollte.

 HINWEIS  Benutzer, denen unterschiedliche Firmen/Mandanten und/oder Rollen zugeordnet sind, können und müssen im Verlauf der Anmeldung eine Auswahl aus den den verfügbaren Alternativen treffen. Wenn in diesem zweiten Schritt der Anmeldung der Button “Abbrechen” gewählt wird, erscheint wieder der oben abgebildete Login-Dialog. Aus technischen Gründen wird dabei die im abgebrochenen SSO-Login verwendete “Benutzerkennung” (userterm) im “Benutzername”-Feld vorbelegt. Diese muss absolut nicht mit dem “Benutzernamen” (username) des korrespondierenden Benutzerkontos für die Lobster Data Platform übereinstimmen. Nur dann hat es aber einen Sinn, nach dem Abbruch ausgehend von der Vorbelegung ein konventionelles Login mit dem ggf. bekannten Passwort für dieses Konto auszuführen.

Beispiel:

  • Für einen via Microsoft-Azure über seine geschäftliche E-Mail-Adresse (jack.tonic@doma.in) identifizierten Benutzer (nennen wir ihn Jack), ist auf der Lobster Data Platform ein Benutzerkonto mit dem “Benutzernamen” jtonic eingerichtet, für das unter “Externe Benutzeranmeldeinformationen” ein Verweis auf die “Benutzerkennung” (jack.tonic@doma.in) vermerkt ist. Eine SSO-Anmeldung mit Jacks azure-”Benutzerkennung” (userterm) jack.tonic@doma.in bezieht die Lobster Data Platform dann auf das Konto mit dem “Benutzernamen” (username) jtonic.

  • Das Listenfeld “Rolle” (roles) in Jacks Lobster Data Platform-Benutzerkonto sieht zwei unterschiedliche Rollen zur Auswahl vor. Bei jedem SSO-Login wird Jack daraufhin aufgefordert, die Rolle der Session auszuwählen.

    • Er kann diese Auswahl allerdings auch per “Abbrechen” verweigern. Dann gilt das Login insgesamt als abgebrochen.

    • Danach erscheint wieder der Login-Dialog — vorbelegt mit jack.tonic@doma.in im Benuztername-Eingabefeld, obwohl der “Benutzername” (username) für das im abgebrochenen Login-Prozess herangezogene Benutzerkonto jtonic lautet.

    • Selbst wenn Jack über ein Passwort für das ihm zugeordnete Benutzerkonto (jtonic) verfügt, wäre eine Anmeldung als jack.tonic@doma.in mit diesem Passwort sinnlos.

Eine erfolgreiche SSO-Anmeldung setzt folgende Punkte voraus:

  • Im Ausführungskontext des Logins muss eine Anmeldung beim gewünschten Externen Identitätsanbieter etabliert sein oder werden.

  • In einem aktiven Benutzerkonto für die Lobster Data Platform muss eine gültige Referenz auf das Anbieter-Konto hinterlegt sein (s. Benutzer, “Externe Benutzeranmeldeinformationen”).

  • Geeignete “SSO-Systemeinstellungen” für die Kommunikation mit dem “SSO-Anbieter” müssen eingerichtet, aktiviert und ggf. für den konkreten Anmeldekontext (s. Site-Konfigurationen) unterstützt sein.

Die folgende Dokumentation betrifft ausschließlich den letzten Punkt dieser Liste.

Zugriff auf “SSO-Systemeinstellungen”

Die View Authentifizierung (s. Basis-Einstellungen) sieht einen eigenen Tab mit Einstellungen für SSO (Einmalige Anmeldung) vor.

Der SSO (Einmalige Anmeldung)-Tab beinhaltet eine Übersicht , die alle “SSO-Systemeinstellungen“ (SSOSystemPreferences) auflistet , für die im Kontext der aktuellen Sitzung Lesezugriff besteht.

Sofern für die Rolle der Session Besitzereinschränkungen zu berücksichtigen sind (s. Rollen), erscheinen nur “SSO-Systemeinstellungen“ (SSOSystemPreferences) in der Liste, die sich im Besitz der Firma der Session befinden oder für die Firmenfreigaben greifen.

Weiterführende Berechtigungen für aufgelistete “SSO-Systemeinstellungen“ (SSOSystemPreferences) - z. B. “Ändern”, “Erstellen”, “Löschen”, usw. - müssen für die Rolle der Session gewährt und für die jeweilige Instanz aufgrund der Besitzverhältnisse und ggf. Firmenfreigaben anwendbar sein, damit die zugehörigen Ribbon Buttons sichtbar sind bzw. abhängig von der Auswahl in der Liste aktiv erscheinen.

Mit ausreichenden Berechtigungen für einen per Einfachauswahl oder Doppelklick identifizierten Listeneintrag kann auf die zugehörigen Konfigurationsdetails in einer separaten View zugegriffen werden. Bei dieser handelt es sich um eine Erfassungsmaske (s. Erfassungsmasken), die nachfolgend auch als Detailansicht bezeichnet wird.

Konfiguration

Die systemseitig vordefinierte Detailansicht für “SSO-Systemeinstellungen” wird unter anderem benötigt, um über den Ribbon Button Neu (in der Übersicht oder der Detailansicht) eine neue “SSO-Systemeinstellungen”-Instanz anzulegen.

Dabei muss initial über ein Auswahlfeld/Combobox der Typ für den SSO-Anbieter (ssoType) festgelegt werden, damit weitere ggf. spezifisch ausgeprägte Formularelemente erscheinen.

 WARNUNG 

Wenn die Auswahl für den SSO-Anbieter geändert wird, nachdem bereits begonnen wurde Details in die daraufhin eingeblendeten Formularelemente einzupflegen, gehen für den abgewählten Anbieter bereits eingegebene Daten auch dann verloren, falls die Konfiguration für den ausgewählten Anbieter dieselben Eigenschaften unterstützt.

Hintergrund zum Datenmodell

Technisch weist die Auswahl für den SSO-Anbieter dem preferences-Feld der Klasse “SSO-Systemeinstellungen” (SSOSystemPreferences) ein Datenobjekt mit einer spezifischen Klasse ({Google|Azure|Auth0|Facebook|Amazon|Frontegg|Custom}SSOConfiguration) zu. Die übergeordnete Klasse “SSO (Einmalige Anmeldung)” (BaseSSOConfiguration) stellt die gemeinsamen Eigenschaften bereit. Die spezifischen Klassen können zusätzliche Eigenschaften enthalten.

Tatsächlich werden für alle SSO-Anbieter weitgehend dieselben Eigenschaften angeboten, wie der folgenden Tabelle zu entnehmen ist. Die wenigen spezifischen Eigenschaften sind in der Tabelle grau schattiert.

Betreff

Name

Datenfeld

Datentyp

Beschreibung

Allgemeine Eigenschaften

Alias

alias

String

systemweit eindeutige Kennung, die dem Benutzer beim Login direkt angezeigt wird, sofern keine Lokalisierung (s. Sprachverwaltung) definiert ist.

(Status)

 HINWEIS  In der Erfassungsmaske zeigt die zugehörige Checkbox ihren Wert (“aktiv”, “nicht aktiv”) anstelle einer Beschriftung an.

active

Boolean

Kennzeichen, das gesetzt (true) sein muss, damit die betreffende “SSO-Systemeinstellungen”-Instanz beim Anmelden angeboten werden kann

 HINWEIS  Ob aktive “SSO-Systemeinstellungen” im Login-Dialog erscheinen, kann zusätzlich von Einstellungen in anwendbaren Site-Konfigurationen abhängen. Dort kann eine Whitelist (per Multi-Combobox “Externe Identitätsanbieter”) als Filter definiert sein.

Client-ID

clientId

String

öffentliche Kennung für Ihre Anwendung, die vom Identitätsanbieter (z. B. Google, Amazon) ausgestellt wurde

Client-Secret

clientSecret

String

privater Schlüssel zur Authentifizierung Ihrer Anwendung beim Identitätsanbieter

 WICHTIG  Halten Sie diesen vertraulich!

Autorisierungs-URL

authorizationUrl

String

URL, zu der Benutzer weitergeleitet werden, um sich über den Identitätsanbieter anzumelden

Callback-URL

callbackUrl

String

URL, zu der der Identitätsanbieter Benutzer nach erfolgreicher Anmeldung weiterleiten soll

 HINWEIS  Der Textwert wird ausgehend vom Alias automatisch für das aktuelle System zugewiesen. Das zugehörige Textfeld ist deshalb schreibgeschützt. Der rechts davon bereitgestellte Button überträgt den berechneten Wert in die Zwischenablage des Clients, damit er von dort aus weiterverwendet werden kann.

Kommentar

comment

String

Freitext für Kommentare zur Konfiguration

└► nur Azure SSO

Mandant

tenant

String

spezifische Mandanten- oder Organisations-ID innerhalb des Identitätsanbieters
(wird in Mehr-Mandanten-Setups wie Azure AD verwendet)

└► nur Auth0 SSO
und Frontegg SSO

Domain

domain

String

erwartete Domäne der E-Mail oder Organisation des Benutzers
(wird verwendet, um den Anmeldezugriff zu leiten oder einzuschränken)

Erweiterte Einstellungen

Token-URL

tokenUrl

String

Endpunkt zum Austausch des Autorisierungscodes gegen ein Zugriffstoken

Benutzerinfo-URL

userInfoUrl

String

Endpunkt zum Abrufen von Benutzerprofilinformationen (wie E-Mail und Name) nach der Anmeldung

Scope

scope

String

Schlüsselwörter für angeforderte Berechtigungen (z. B. openid email profile)

State-Feld

stateField

String

Parameter zur Aufrechterhaltung des Zustands zwischen Anfrage und Rückruf; hilft, CSRF-Angriffe zu verhindern

Feld-Zuordnungen

fieldMappings

String

Zeichenfolge, die eine Zuordnung für Identitätsanbieter-Felder (wie E-Mail oder Name) zu den Benutzerattributen Ihrer Anwendung definiert

Zusätzliche Autorisierungsparameter

additionalParameters

String

Optionale Abfrageparameter, die in die Autorisierungsanfrage aufgenommen werden sollen
(z. B. prompt=consent)

Symbol

iconUri

String

Referenz für das Symbol, das zusammen mit dem Alias (oder der zugeordneten Lokalisierung) im Login-Dialog angezeigt werden soll (s. a. Arbeiten mit Bildressourcen (Icons))

 HINWEIS  Falls nicht ausdrücklich ein Symbol zugewiesen wird, erscheint als Standard-Symbol ein “Schlüssel”:

Lokalisierung (Alias)

ein Textfeld für jede unterstützte Sprache

n/a

String

Lokalisierungswert für den Alias (s. o.) in der jeweiligen Sprache
(Bundle ExternalIdentityProvider Resource {alias}.login)

 HINWEIS  Lokalisierungen erscheinen anstelle des Alias im Login-Dialog und ggf. im Multi-Combobox-Element für “Externe Identitätsanbieter” für Site-Konfigurationen.

 ANMERKUNG  Aus historischen Gründen enthält das Bundle ExternalIdentityProvider eventuell Resource-Einträge mit dem Schema {alias}.icon. Aktuelle Versionen der Lobster Data Platform beziehen sich ausschließlich auf die Eigenschaft Symbol (iconUri), um einer “SSO-Systemeinstellungen”-Instanz ein Icon zuzuordnen.

 WICHTIG  Platzhaltertexte beschreiben Standardwerte

Für viele der gemeinsam genutzten Eigenschaften zeigt das leere Textfeld einen Platzhalter an, der je SSO-Anbieter (ssoType) spezifisch ausgeprägt sein kann.

  • Beispiel: Für den SSO-Anbieter (ssoType) “Azure SSO” lautet der Platzhalter für die Eigenschaft Autorisierungs-URL (authorizationUrl):
    https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

Der Platzhalter beschreibt den Standardwert, der zur Laufzeit für die Eigenschaft gilt, solange keine Eingabe für die Eigenschaft vorliegt.

Die als Standardwert vom System vordefinierten Textwerte sind ausschließlich in der Benutzeroberfläche in leeren Textfeldern ersichtlich, sobald eine Auswahl für den SSO-Anbieter (ssoType) getätigt wird.

  • Für alle konkreten SSO-Anbieter stellt das System typische Standardwerte bereit. Für die Option “Benutzerdefiniertes SSO” sind Standardwerte natürlich nur bedingt anwendbar.

  • Der als Platzhalter angezeigte Text kann (wie im Beispiel oben) eine Referenz auf ein Datenfeld einer spezifischen Eigenschaft ({tenant}, {domain}) enthalten. Dann wird zur Laufzeit stattdessen der für die betreffende Eigenschaft (Mandant, Domain) zugewiesene Text verwendet. Dies gilt allerdings nur für Standardwerte. Es ist nicht vorgesehen, entsprechende Referenzen in benutzerdefinierten Textwerten für Eigenschaften einer SSO-Konfiguration einzusetzen.

Die hartcodierten Standardwerte werden beim Speichern einer “SSO-Systemeinstellungen”-Instanz ausdrücklich nicht explizit in der Datenbank persistiert. Stattdessen bleiben betreffende Felder leer.

Auch das zugehörige Datenobjekt liefert bei einem Lesezugriff auf eine unbestimmte Eigenschaft nicht den effektiv wirksamen Standardwert.

Spezifische Menüfunktionen

Sobald innerhalb der “Authentifizierung”-View der Tab “SSO (Einmalige Anmeldung)” ausgewählt ist, erscheinen die im Kontext anwendbaren Ribbon Buttons.

Neben den generischen Funktionen, die wie üblich abhängig von Berechtigungen für die betreffende “SSO-Systemeinstellungen”-Instanz erscheinen und aktiviert werden, sind auch zwei spezifische Ribbon Buttons verfügbar:

Ribbon Button

Kontext

Funktionsbeschreibung


Test SSO

testSSO

Übersicht
und Erfassungsmaske

Führt einen Test für die ausgewählte/angezeigte “SSO-Systemeinstellungen”-Instanz und zeigt abhängig vom Verlauf eine Erfolgs- oder Fehler-Notification an. Für des Test wird vorübergehend ein eigenes Browserfenster geöffnet, in dem ggf. eine Fehlermeldung mit Details erscheint.

  • Die Auswahl für die Eigenschaft “Status” (active) wird für den Test ignoriert. Auch inaktive Konfigurationen können getestet werden.

  • Im Kontext einer Erfassungsmaske berücksichtigt der Test den ggf. vorliegenden volatilen Bearbeitungsstand für die angezeigte “SSO-Systemeinstellungen”-Instanz. Vor dem eigentlichen Test wird das Formular validiert. Auf Validierungsfehler (z. B. leere Pflichtfelder) wird per Fehlermeldung hingewiesen. Mit ungültigen Daten wird kein Test ausgeführt.


De-/Aktivieren

deActivate

Übersicht

Invertiert den Booleschen Wert für die Eigenschaft “Status” (active) für ausgewählte “SSO-Systemeinstellungen”-Instanzen:

  • Aktive “SSO-Systemeinstellungen”-Instanzen werden deaktiviert.

  • Inaktive “SSO-Systemeinstellungen”-Instanzen werden aktiviert.

Ein Statuswechsel impliziert das Speichern der ausgewählten Instanzen, sodass für diese das Ereignis “Ändern” (s. Allgemein (Ereignisse)) ausgelöst wird.

 WICHTIG  Ein Statuswechsel kann nur ausgeführt werden, wenn die Berechtigung zum “Ändern” für die ausgewählte “SSO-Systemeinstellungen”-Instanz vorliegt. Anderenfalls erscheint beim Klick auf den Ribbon Button eine Fehlermeldung.

 HINWEIS  Im Kontext einer Erfassungsmaske steht der Ribbon Button “De-/Aktivieren” nicht zur Verfügung. Dort kann der “Status” (active) direkt über das zugehörige Checkbox-Element angepasst werden. Ein Statuswechsel impliziert dann allerdings nicht das Speichern der Instanz.