SSO (Einmalige Anmeldung)

Siehe auch Authentifizierung, Benutzer, Site-Konfigurationen

Dieser Artikel beschreibt die SSO-Systemeinstellungen der Lobster Data Platform. Er erklärt den Anmeldeablauf per externem Identitätsanbieter und zeigt, wie Sie SSO-Konfigurationen anlegen und testen.

Hintergrund

SSO (Single Sign-On) ersetzt die manuelle Eingabe von Zugangsdaten durch eine bestehende Anmeldung bei einem „Externen Identitätsanbieter". Ist noch keine solche Anmeldung vorhanden, öffnet die Lobster Data Platform ein eigenes Browserfenster zur Identifizierung.

Im Login-Dialog klicken Sie auf den Button des gewünschten „Externen Identitätsanbieters". Eine manuelle Eingabe von Zugangsdaten entfällt damit.

Ist die übermittelte Identität mit einem aktiven Benutzerkonto verknüpft, meldet das System Sie mit diesem Konto an.

Was passiert beim Klick auf ( Microsoft )?

Prüfung: Azure-Anmeldung im Kontext vorhanden?
1. Wenn NEIN: Einleiten der Azure-Identifizierung (s. unten: Autorisierungs-URL).
Rückgabe der Azure-Benutzerkennung (z. B. registrierte E-Mail-Adresse)
Prüfung: Existiert ein Benutzerkonto für die Lobster Data Platform, das auf die ermittelte Azure-Benutzerkennung verweist? Das Konto muss im Feld „Benutzerkennung" (userterm) eines „Externe Benutzeranmeldeinformation"-Attributs (ExternalUserLoginInfo) eingetragen sein. Der „Alias des Anbieters" (providerAlias) muss dabei den Wert azure haben.
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, verwendet das System ausschließlich den ersten Treffer. Das gilt auch dann, wenn dieses Konto nicht aktiv ist.

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 befüllt das System das Feld „Benutzername" mit der zuletzt verwendeten „Benutzerkennung" (userterm). 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. Unter „Externe Benutzeranmeldeinformationen" ist ein Verweis auf die „Benutzerkennung" (jack.tonic@doma.in) vermerkt. 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 Benutzerkonto sieht zwei unterschiedliche Rollen zur Auswahl vor. Bei jedem SSO-Login wird Jack aufgefordert, die Rolle der Session auszuwählen. Er kann diese Auswahl per „Abbrechen" verweigern. Dann gilt das Login insgesamt als abgebrochen.

Danach erscheint wieder der Login-Dialog. Das Feld „Benutzername" ist mit jack.tonic@doma.in vorbelegt. Der tatsächliche „Benutzername" (username) des Kontos lautet aber jtonic.

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" — 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 oder 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.

Ändern Sie den SSO-Anbieter, nachdem Sie bereits Formularelemente ausgefüllt haben, gehen alle eingegebenen Daten verloren. Das gilt auch dann, wenn der neue 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 die Lobster Data Platform Sie weiterleitet, damit Sie sich beim Identitätsanbieter anmelden.
Callback-URL	`callbackUrl`	String	URL, zu der der Identitätsanbieter Sie nach erfolgreicher Anmeldung weiterleitet. 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.
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 für die Autorisierungsanfrage (z. B. `prompt=consent`).
Symbol	`iconUri`	String	Referenz für das Symbol, das zusammen mit dem Alias im Login-Dialog angezeigt wird (s. a. Arbeiten mit Bildressourcen (Icons)). HINWEIS Falls kein Symbol zugewiesen wird, erscheint als Standard ein „Schlüssel"-Symbol.
Lokalisierung (Alias)	Ein Textfeld für jede unterstützte Sprache	n/a	String	Lokalisierungswert für den Alias in der jeweiligen Sprache (Bundle `ExternalIdentityProvider`, Resource `{alias}.login`). HINWEIS Lokalisierungen erscheinen anstelle des Alias im Login-Dialog und ggf. im Multi-Combobox-Element „Externe Identitätsanbieter" in 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 „Azure SSO" lautet der Platzhalter für die Autorisierungs-URL (authorizationUrl): https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. Dieser Platzhalter beschreibt den Standardwert, der zur Laufzeit gilt, solange kein eigener Wert eingetragen ist. Der als Platzhalter angezeigte Text kann eine Referenz auf ein Datenfeld enthalten (z. B. {tenant}, {domain}). Dann verwendet das System zur Laufzeit den Wert der betreffenden Eigenschaft. Das gilt nur für Standardwerte. In benutzerdefinierten Textwerten sind solche Referenzen nicht vorgesehen. Hartcodierte Standardwerte werden beim Speichern nicht in der Datenbank persistiert. Betreffende Felder bleiben leer. Das 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 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 „SSO-Systemeinstellungen"-Instanz aus. Das System zeigt eine Erfolgs- oder Fehler-Notification an. Für den Test wird vorübergehend ein eigenes Browserfenster geöffnet. 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 aktuellen Bearbeitungsstand. Vor dem Test wird das Formular validiert. Bei Validierungsfehlern (z. B. leere Pflichtfelder) erscheint eine Fehlermeldung. Mit ungültigen Daten wird kein Test ausgeführt.
De-/Aktivieren	`deActivate`	Übersicht. Invertiert den Booleschen Wert der Eigenschaft „Status" (`active`) für ausgewählte Instanzen. Aktive Instanzen werden deaktiviert. Inaktive Instanzen werden aktiviert. Ein Statuswechsel speichert die ausgewählten Instanzen und löst das Ereignis „Ändern" aus (s. Allgemein (Ereignisse)). WICHTIG Ein Statuswechsel erfordert die Berechtigung „Ändern" für die betreffende Instanz. Fehlt diese Berechtigung, erscheint beim Klick eine Fehlermeldung.