Benutzer
Siehe auch: Gastbenutzer
Der Menüeintrag Benutzer ist im Hauptmenü über den Menüknoten "Verwaltung/Konten" zu finden, sofern ausreichende Berechtigungen vorliegen.
Er öffnet per Standard (s. Eigene Übersichten) eine Übersicht für den Entitätstyp "Benutzer" (User), der auch als "Benutzerkonto" bezeichnet wird.
View-Name: de.lobster.scm.base.security.user::User|listDetailsWindow
Menüknotenname: admin/accounts/userOverview
Den Zugriff auf Benutzer regeln die Berechtigungen für den Knoten "Verwaltung/Konten/Benutzer" (administration/accounts/user).
Menüeinträge für Benutzer erscheinen nur, wenn die Berechtigung "Anzeigen" (show) für Benutzer vorliegt.
Für den Zugriff auf Benutzer sind im Allgemeinen Besitzereinschränkungen für die Firma der Session zu berücksichtigen.
Die Berechtigungen der Rolle der Session sind daher nur in Bezug auf Benutzer anwendbar, für die die Firma der Session als "Besitzer" gilt oder Empfänger von entsprechenden Firmenfreigaben ist.
Bedeutung von Benutzerkonten für die Zugriffskontrolle
Typischerweise bilden Benutzer die Basis für die Anmeldung einer Lobster Data Platform-Sitzung (s. a. Benutzer Login).
Jedes Benutzerkonto muss mit mindestens einer Firma (s. Firmen/Mandanten) und mit mindestens einer Rolle (s. Rollen) verknüpft sein.
Benutzer, deren Konto mit mehreren Firmen/Mandanten und/oder Rollen verknüpft ist, müssen beim Anmelden einer Sitzung eine Auswahl für die Firma der Session und/oder die Rolle der Session treffen.
Die Rolle der Session bestimmt dabei die kategorische Verfügbarkeit von Berechtigungen (s. Rollen).
Die Firma der Session wirkt sich auf die Anwendbarkeit von Berechtigungen auf konkrete Entitäten aus, sofern für diese Besitzereinschränkungen zu berücksichtigen sind.
Die Zugriffkontrolle über Berechtigungen und Besitzereinschränkungen stützt sich nie unmittelbar auf Benutzer. Der "Aktionsradius" für Benutzer ergibt sich überwiegend durch deren Zugriff auf Rollen und Firmen/Mandanten bei der Anmeldung
Als "Besitzer" von Entitäten kommen nur Firmen/Mandanten in Frage. Entsprechend können auch nur Firmenfreigaben und keine persönlichen Freigaben für Benutzer erteilt werden.
Allerdings beziehen sich Entitäten über die automatisch befüllten Felder "Ersteller" (creatorId) und "Zuletzt geändert von" (lastModifierId) auf Benutzer (bzw. Gastbenutzer) mit besonderer Bedeutung für die Entität. Relevant für den Zugriff auf die Entität sind diese Referenzen ohne ausdrückliche Berücksichtigung in Konfigurationen nicht.
Bei Bedarf können allerdings wirklich persönliche Restriktionen für Benutzer konfiguriert werden, etwa per Benutzerregel (z. B. in Zuordnungskriterien oder einer Fallunterscheidung per Wenn Dann Sonst) oder im Kontext von Einschränkungen (z. B. für Eigene Übersichten oder Auswahlfeld/Combobox-Elemente), die sich auf Benutzer beziehen.
►WICHTIG◄ Es existieren dedizierte Wertauflöser, mit denen Referenzen auf eine Firmenwert oder eine Rolle in Konfigurationen mit Blick auf einen Meta Exchange "sicher" gehandhabt werden können. Für Benutzer (und Gastbenutzer) ist dies nicht vorgesehen. Konfigurationen, die sich explizit und direkt auf eine als Festwert definierte ID (id) eines individuellen Benutzerkontos beziehen, sind damit potenziell problematisch.
Die interaktive Verwaltung für Benutzer stützt sich per Standard auf eine kombinierte Ansicht (listDetailsWindow), die über den Menüeintrag Benutzer im Hauptmenü geöffnet werden kann.
Der folgende Screenshot zeigt das Standard-Ribbon (für eine Rolle mit allen relevanten Berechtigungen), darunter die Standard-Erfassungsmaske mit den Details des im Listenbereich (ganz unten) ausgewählten Benutzers.
Besonderheiten im Ribbon
Neben den generischen Ribbon Buttons (Neu, Löschen, usw.) enthält die im Screenshot sichtbare Hauptkategorie ("Allgemein") auch einen spezifischen Ribbon Button für Firmen/Mandanten:
Unterkategorie |
Ribbon Button |
Beschreibung |
Anmeldungen |
|
Der Ribbon Button Anzeigen ist an die Berechtigung "Anmeldeverlauf anzeigen" (administration/accounts/user/showLoginLog) gebunden. Er öffnet ein modales Vollbild-Fenster (s. Anmeldungsverlauf) innerhalb der aktuellen View, das die Historie der Anmeldungen eines im Listenbereich ausgewählten Benutzers auflistet. |
Inhalte der Standarderfassungsmaske
Die per Standard für Benutzer angebotene Erfassungsmaske bildet nur eine Auswahl der insgesamt verfügbaren Inhalte der Datenstruktur für Benutzer über Formularelemente ab.
Tab-Reiter "Benutzer"
Objekt |
Feld |
Datenfeldpfad |
Beispielwerte |
Inhalt |
"Benutzer" |
Aktiv |
active |
$true (Boolean) |
Das Kennzeichen Aktiv muss gesetzt sein, damit ein Benutzerkonto für ein Benutzer Login genutzt werden kann. |
Benutzername |
username |
"don.duck@doma.in" |
Als Benutzername muss eine systemweit eindeutige Zeichenfolge (unter Beachtung der Groß-/Kleinschreibung) angegeben werden. ►HINWEIS◄ Die Eindeutigkeit für den Benutzernamen wird erst beim Speichern geprüft. Das Speichern wird mit einer Fehlermeldung abgebrochen, wenn der angegebene Benutzername bereits vergeben ist. Da jedes Benutzerkonto als Entität über eine eindeutige "ID" (id) identifizierbar ist, kann der Benutzername für bereits erstellte Benutzer wieder geändert werden. Allerdings ist das bedingt empfehlenswert, da der Benutzername auch als Referenz im Kontext der Orchestration-Integration (z. B. per Integration Login bzw. Create Login Request (Integration-Funktion)) genutzt werden kann. Solche Referenzen sind nach einer Umbenennung ggf. verwaist. |
|
Passwort Passwortbestätigung |
(passwordHash) |
"69f50cde6DD6" Siehe auch: Passwort ändern |
Beim Erstellen eines Benutzers muss ein Passwort angegeben und im Feld für die Passwortbestätigung fehlerfrei wiederholt werden.
|
|
Passwort Ablaufdatum
|
passwordExpiryDate |
22.05.2025 22:00(UTC)(DateTime) |
Ein Passwort Ablaufdatum kann optional angegeben werden, um einen Dialog zum Ändern des Passworts auszulösen, wenn das Ablaufdatum bei dem Versuch einer Anmeldung (mit dem bisher gültigen Passwort) bereits überschritten ist. |
|
►WICHTIG◄ Wird in diesem Dialog ein neues Passwort eingegeben und korrekt wiederholt, löst das das Ereignis "Ändern" (s. Allgemein (Ereignisse)) für das Benutzerkonto aus. Ereignisbehandlungen, die auf das "Ändern"-Ereignis für Benutzer (s. Typprüfung) reagieren, können in diesem Fall zwei Boolean-Variablen auswerten:
Das Passwort Ablaufdatum für den Benutzer ist dann bereits bereits gelöscht. Falls auch für das neue Passwort ein Passwort Ablaufdatum gelten soll, muss dieses explizit ermittelt und dem passwordExpiryDate-Feld zugewiesen werden. Mit dem Relatives Datum mit Zeit-Wertauflöser gelingt das entweder ausgehend von der aktuellen Systemzeit oder ggf. relativ zum vorherigen Ablaufdatum, das im Kontext des "Ändern"-Ereignisses über den Original-Objekt-Wertauflöser gelesen werden kann. |
||||
Sprache |
locale |
"Englisch" (en) |
Einfachauswahl, die eine bestimmte Sprache mit der Firma verknüpft. |
|
Max. gleichzeitige Sitzungen |
maxConcurrentSessions |
1 |
Diese Einstellung legt fest, wie viele Lobster Data Platform-Sitzungen ein Benutzer gleichzeitig nutzen darf. Beim jedem Anmeldeversuch wird diese Beschränkung überprüft. Überschreitet ein Benutzer mit einer zusätzlichen Sitzung das persönliche Limit, dann wird die Anmeldung der neuen Sitzung nur vollzogen, wenn der Benutzer zustimmt, dafür eine bestehende Sitzung abzumelden:
|
|
Firmen |
companies |
"SL UK", "SL Germany", |
Mehrfachauswahl von Firmen/Mandanten, aus denen der Benutzer beim Login die Firma der Session auswählen darf. Ist hier genau eine Firma ausgewählt, dann entfällt die Firmenauswahl beim Login. |
|
►HINWEIS◄ Die Beschriftung "Versteckte Firma" erscheint für Firmen, die bereits zugewiesen sind und deshalb im Kontext der aktuellen Sitzung zwar entfernt aber danach nicht wieder ausgewählt werden könnten. ►WICHTIG◄ Ein Benutzerkonto, das sich auf eine "Versteckte Firma" bezieht, kann zwar geändert aber nicht erstellt werden. Dies ist vor allem beim Kopieren eines bestehenden Benutzerkontos relevant. Ggf. müssen alle versteckten Firmen entfernt werden, damit das kopierte Benutzerkonto gespeichert werden kann. Für den Zugriff auf Firmen/Mandanten für eine Firmen-Auswahl für Benutzer sind per Standard folgende Szenarien zu unterscheiden:
In benutzerdefinierten Erfassungsmasken für Benutzer kann der Zugriff in diesen beiden Fällen durch gezielte Sucheinschränkungen für das Auswahlfeld/Combobox-Element eingeschränkt werden. |
||||
Rollen |
roles |
"Guest", "Admin (accounts)", |
Mehrfachauswahl für Rollen, aus denen der Benutzer beim Login die Rolle der Session auswählen darf. Ist hier genau eine Rolle ausgewählt, dann entfällt die Rollenauswahl beim Login. |
|
►HINWEIS◄ die Beschriftung "Versteckte Rolle" erscheint für Rollen, die bereits zugewiesen sind und deshalb im Kontext der aktuellen Sitzung zwar entfernt aber danach nicht wieder ausgewählt werden könnten. Dies betrifft alle Rollen, auf die mit der Rolle der Session kein Zugriff besteht. ►WICHTIG◄ Ein Benutzerkonto, das sich auf eine "Versteckte Rolle" bezieht, kann zwar geändert aber nicht erstellt werden. Dies ist vor allem beim Kopieren eines bestehenden Benutzerkontos relevant. Ggf. müssen alle versteckten Rollen entfernt werden, damit das kopierte Benutzerkonto gespeichert werden kann. |
||||
"Adresse" |
Anrede |
address.salutation |
"Herr" (MR) |
Einfachauswahl für die Anrede in der Benutzeradresse. |
Name |
address.name1 |
"Don" |
Freitext der zusammen mit weiteren Feldern für Beschriftungen herangezogen wird. |
|
Name 2 |
address.name2 |
"Duck" |
Freitext der zusammen mit weiteren Feldern für Beschriftungen herangezogen wird. |
|
Straße |
address.street1 |
"Entenwerder Stieg" |
Freitext für die Straße in der Postadresse |
|
Hausnummer |
address.streetNo |
"66" |
Freitext für Hausnummer(n) in der Postadresse |
|
Kontonummer |
address.accNumber |
"1901" |
Freitext, der z. B. genutzt werden kann, um eine Kennung für das Benutzerkonto in anderen Systemen anzugeben. |
|
Land* |
address.countryCode |
"Deutschland" (DE) |
Einfachauswahl für das Land in der Postadresse |
|
Postleitzahl* |
address.zipcode |
"20359" |
Freitext für die Postleitzahl in der Postadresse |
|
Stadt* |
address.city |
"Hamburg" |
Freitext für den Namen der Stadt in der Postadresse |
*) Interaktive Änderungen an den Feldern Land, Postleitzahl und Stadt lösen ggf. ein Nachschlagen von Daten für Orte aus. Beim Übernehmen eines Treffers im automatisch eingeblendeten Dropdown werden ggf. auch Adressfelder mit für Orte hinterlegten Daten befüllt bzw. überschrieben, die die Standard-Erfassungsmaske für Benutzer nicht anzeigt.
Tab-Reiter "Kommunikationsinformationen"
Der Screenshot zeigt das in der Standard-Erfassungsmaske für Benutzer verwendete Format für die Eingabe von Kommunikationsinformationen.
Kommunikationsinformationen werden als Plurale Attribute des Typs "Kommunikationsinformation" (AddressCommunicationInfo) für die Benutzeradresse gespeichert.
Im Feld Typ kann eine Kommunikationstyp ausgewählt werden. Einer Adresse können mehrere Einträge für denselben Typ zugeordnet werden.
Im Feld Kontext kann ein Textschlüssel angegeben werden, der den Verwendungszweck für die betreffende Kommunikationsinformation charakterisiert.
Im Feld Wert sollte die Schlüsselinformation für die Kommunikationsinformation (z. B. eine E-Mail-Adresse oder eine Telefonnummer) eingetragen werden.
ACHTUNG
Für Plurale Attribute gilt die Restriktion, dass es beim Speichern keine komplette Redundanz zwischen zwei Instanzen des Attributs geben darf. Enthält die Liste der Kommunikationsinformationen mindestens zwei Einträge, die in Typ, Kontext und Wert komplett übereinstimmen, tritt beim Speichern ein Fehler auf.
►HINWEIS◄ Besonders häufig werden Kommunikationsinformationen mit dem Typ "E-Mail" (EMAIL) genutzt, um Daten für die Adressierung bei einem automatischen E-Mail-Versand zu hinterlegen. Für Benutzer kann z. B. der Mailadresse Benutzer-Wertauflöser genutzt werden, um hinterlegte E-Mail-Adressen für einen bestimmten Kontext direkt nachzuschlagen, ohne diesen Lesezugriff auf die Attributstruktur der Adresse ausführlich konfigurieren zu müssen. Allerdings setzt der vereinfachte Zugriff über Mailversand (Wertauflöser) voraus, dass im Attribut ein Kontext hinterlegt ist.
►ANMERKUNG◄ Auch wenn sich Kommunikationsinformationen auf einen Kommunikationstyp beziehen, handelt es sich formal nicht etwa um Typisierte Attribute sondern um Plurale Attribute (s. a. Geschäftsobjekte und Attribute). Dies muss beim Konfigurieren von Zugriffen (s. Attribut (Wertauflöser) bzw. Projektionen) berücksichtigt werden.
Tab-Reiter "Externe Benutzeranmeldeinformationen"
Der Tab-Reiter "Externe Benutzeranmeldeinformationen" enthält Einstellungen, die eine Authentifizierung des Benutzers über andere Systeme (via LDAP, SSO) ermöglichen.
Im Screenshot wird die Zeichenfolge, die im konkreten Beispiel auch als "Benutzername" (username) verwendet wird, explizit als Benutzerkennung für die SSO-Anmeldung über Microsoft Azure (s. Alias des Anbieters) angegeben.