Anmeldung und Passwörter

Authentifizierungsroutine

Prinzipiell verläuft die Authentifizierungsroutine am CURSOR-CRM und am Betriebssystem (und an der Domäne) unabhängig. Jedes System verfügt über eigene Benutzer und Passwörter. Mit der Auto-Login-Funktionalität ist es trotzdem möglich, sich einmal gegen ein zentrales System (lokal, Windows-Domäne) zu authentifizieren und transparent von anderen Systemen (CURSOR-CRM) als authentifizierter Benutzer erkannt zu werden. Alternativ ist auch die Kerberos-Authentifizierung möglich.

Anmeldung mit Passworteingabe

Nachdem Sie die Anwendung gestartet haben, erscheint eine Anmeldemaske, über welche Sie sich authentifizieren können. Das vergebene Passwort muss nicht mit dem Ihres Betriebssystems identisch sein. Es ist aber erlaubt, beide gleich zu setzen. Voraussetzung ist, dass die Funktionalität Auto-Login auf der Konfigurationslasche des Anwenders deaktiviert ist.

In Fällen, bei welchen Sie sich als anderer Benutzer an demselben Rechner anmelden möchten (z. B. als Administrator auf einem Anwenderrechner, um ein Problem zu beheben oder eine Einstellung vorzunehmen), können Sie das über das Hauptmenü Datei / Abmelden und Anmelden tun.

Abbildung: Ab- und Anmelden ohne Applikationsneustart

Auswahl der Identität beim Login (Anmelden als)

Im Rahmen der Anmeldung wird geprüft, ob der aktuelle Benutzer mindestens einmal als Stellvertreter eingetragen ist. Ist dies der Fall, erscheint ein Dialog, in dem Sie auswählen müssen, mit welchen Berechtigungen Sie arbeiten möchten. Der erste Eintrag repräsentiert Sie selbst, danach werden alle Mitarbeiter aufgelistet, für die Sie als Stellvertreter definiert sind.

Liegt keine Stellvertreterregelung für Sie vor, wird der Dialog nicht angezeigt und Sie werden mit Ihren Berechtigungen angemeldet.

Anmerkungen

• Für den Fall, dass viele Stellvertreterregelungen existieren, müssen Sie die Liste scrollen, um die gewünschte Stellvertretung zu wählen.

• Der Text für die Visualisierung der möglichen Stellvertreteridentitäten wird nach dem Schema Stellvertretung von <Vorname> <Nachname> gebildet.

• Bei der Neuanlage bzw. der Änderung von Daten wird in die Felder Anlageuser / Updateuser immer das Kürzel des eigentlichen Nutzers eingetragen und explizit nicht das Kürzel des Stellvertretenen. Meldet sich z. B. Herr Baumann als Stellvertretung von Herrn Müller an und ändert einen Datensatz, steht im Feld Updateuser das Kürzel von Herr Baumann und nicht das Kürzel von Herrn Müller.

• Zur Aufhebung der Stellvertreterregelung müssen Sie die Zuordnung des entsprechenden Mitarbeiter-Datensatzes (analog zur Auswahl) entfernen.

• Jeder Mitarbeiter darf nur für sich selbst Stellvertreter hinzufügen bzw. entfernen, d. h. es ist explizit nicht möglich, dass ein Stellvertreter weitere Stellvertreter für den von ihm vertretenen Nutzer definieren darf. Eine Ausnahme bilden Mitarbeiter, die über bestimmte Funktionsrechte verfügen. Diese dürfen für alle Mitarbeiter Stellvertreterregelungen hinzufügen bzw. aufheben. In der Standardauslieferung werden nur Administratoren mit dieser Berechtigung ausgestattet.

Konfiguration der Anmeldung

Die Konfiguration wird beim Mitarbeiter auf der Lasche Konfiguration vorgenommen.

Abbildung: Konfiguration der Anmeldung

Autologin

Es ist möglich das Automatische Login für Benutzer nach dem Single Sign-On Prinzip (kurz SSO, "Einmalanmeldung") einzuschalten. Das bedeutet, dass ein Benutzer nach einer einmaligen Authentifizierung auf alle Rechner und Dienste, für die er berechtigt ist, zugreifen kann, ohne sich jedes Mal neu anmelden zu müssen. Jeder Mitarbeiter (Anwender) kann individuell entscheiden, ob er diese Methode nutzt. Die Checkbox Autom. Einloggen muss auf der Lasche Konfiguration aktiviert sein.

Ablauf

Das Hauptproblem stellt der Zugriff auf die Datenbank dar. In der Tabelle 'Mitarbeiter' werden die Information zum Autologin in den Feldern 'Autologin' und 'Autologinname' gespeichert. Da aber nur dem Server ein Zugriff auf diese Informationen möglich ist, diese aber für das Login benötigt werden, um sich am (JBoss)Server anzumelden, mussten Wege gefunden werden, diese Information ohne Serverzugriff bereitzustellen. Das Problem wurde gelöst, indem eine Property-Datei (autologin.properties) vom Server erstellt wird, die die benötigten Informationen (die Zuordnung des Windows-Loginnames und des CURSOR-CRM/EVI-Benutzerkürzels) enthält. Beispiel 'XYZ=XYZ' bedeutet, dass der in der ersten Spalte definierte Windows(Domäne)-Client mit dem Kürzel 'XYZ' mit dem CURSOR-CRM/EVI Benutzer (hier: ebenfalls Kürzel 'XYZ') gemappt ist. Die Namen sind frei wählbar, sie müssen nur entsprechend gemappt werden (z.B.: Xz7ugH=HM).

Tipp

Vergeben Sie im CURSOR-CRM/EVI den selben Benutzernamen (Kürzel) wie im Windows System, damit sich die Anwender diese besser merken können.

Richtlinien für die Kürzel im CURSOR-CRM/EVI:

• nur GROSSBUCHSTABEN sind zulässig

• maximal 35 Zeichen lang * Leerzeichen sind zulässig

• Umlaute sind zulässig

Vermeiden Sie allzu lange Kürzel, damit sie in die Felder auf den Masken passen.

Abbildung: Zugriff auf die Konfigurationsdatei

Um die Aktualität der Informationen zu gewährleisten, wird diese Datei bei jeder Änderung bei den Mitarbeitern aktualisiert, ebenso wenn in der Adminkonsole die Passwort-Verschlüsselung oder die Systeminitialisierung gestartet wird.

Beim Autologin wird der Passwortschutz der Applikation umgegangen. Es wird vorausgesetzt, dass die Authentifizierung am Betriebssystem (an der Domäne) für die Sicherheit ausreichend ist.

• Konfiguration Serverseite

Damit die Informationen für das Autologin dem Client zur Verfügung stehen, muss für den Server der komplette Pfad der Property-Datei in der Tabelle Propertymapper unter dem Eintrag AUTOLOGIN.PROPERTY angegeben werden. Bsp.: c:\\temp\\autologin.properties ('\\' beachten).

• Konfiguration Clientseite

Der Client muss auf diese Property-Datei lesend zugreifen können. Es empfiehlt sich also ein schreibgeschützter Platz im Netz, wo diese Datei abgelegt ist. In der Datei checkAutologin.bat muss dazu der Pfad zur autologin.properties-Datei aus Sicht des Clients eingetragen werden. Passen Sie dazu unterhalb des Bereichs ":localAutologinPath" die Variable "-DAutologin" entsprechend an. für den Client muss dazu die Variable Autologin auf den kompletten Pfad der Property-Datei gesetzt werden. z.B. -DAutologin=c:\temp\autologin.properties.

Anmeldesicherheit

In der Entität Mitarbeiter gibt es das Feld gesperrt. Standardmäßig befindet sich das Feld in der Maske auf der Lasche Konfiguration.

• Die Anmeldesicherheit ist aktiviert

Wird nach den konfigurierten Grenzen zu häufig ein falsches Passwort eingegeben, so wird der Account gesperrt (nicht mehr deaktiviert). Das Kontrollkästchen kann auch manuell vom Administrator gesetzt und so der Account gesperrt werden. Der Anwender kann sich dann nicht mehr am System anmelden, er erhält die Meldung, dass sein Passwort fehlerhaft ist. Die Anwendung wird anschließend beendet.

Ist Autom. Einloggen aktiviert, so kommt der Anwender in den Anmeldedialog. Versucht er sich hier mit dem gleichen Kürzel manuell anzumelden, erhält er die gleiche Meldung und die Anwendung wird beendet.

•   Die Anmeldesicherheit ist nicht aktiviert

Das Kontrollkästchen kann nur manuell vom Administrator gesetzt und so der Account gesperrt werden. Er bleibt im Anmeldedialog stehen. Eine detailliertere Beschreibung ist nicht möglich, da hierzu Funktionalitäten aus der Anmeldesicherheit benötigt werden.

Passwort-Einstellungen

Konfiguration in Systemeinstellungen

Als Administrator können Sie die Passwortrichtlinien vorgeben. Diese konfigurieren Sie in der Dialogmaske Passwort Einstellungen, zu der Sie über Menü Optionen / Systemeinstellungen gelangen. Alternativ können Sie sie über Administration / Adminkonsole / Sonstige Bereiche/ Systemeinstellungen öffnen.

Unabhängig von den administrativen Vorgaben, kann der Anwender sein Passwort über das Menü Optionen / Passwort ändern jederzeit ändern.

Passwortrichtlinien

Für das Arbeiten mit dem CRM bedarf es einer vorherigen System-Authentifizierung mittels Benutzername sowie dazugehörigem Passwort. Die Passwörter der einzelnen User-Accounts werden innerhalb der Datenbank der CRM-Applikation verschlüsselt abgelegt. Die Vergabe von Passwörtern unterliegt hierbei folgenden Richtlinien, welche vom System-Administrator der CRM-Applikation einzeln vorgebbar sind:

• Sicherstellung folgender Kennwort-Kriterien:

  • Mindest-Zeichenlänge (z. B. >= 8 Zeichen)

  • Verwendung von Groß- und Kleinbuchstaben notwendig

  • In neu eingegebenen Passwörtern ist mindestens eine Zahl enthalten

  • Es ist mindestens ein Sonderzeichen enthalten

• Kennwortwechselzwang: Ablauf des Kennworts nach X Tagen, mit einstellbarer Warnmeldung Y Tage vor dem Zeitpunkt des Ablaufs

• Speicherung einer Kennworthistorie, aufgrund welcher die letzten N Kennwörter nicht wieder verwendet werden können. Bei der Passwortänderung wird geprüft, ob das neue Passwort nicht dem aktuellen Passwort gleicht und nicht in der Historie vorhanden ist. Deshalb sind für den Benutzer das aktuelle Passwort plus die letzten N Kennwörter nicht benutzbar.

• Sperrung eines Accounts bei Überschreitung einer maximalen Anzahl an Anmeldefehlversuchen (z. B. nach drei gescheiterten Versuchen)

Ein leeres Passwort ist nicht zulässig.

Im Auslieferungszustand (leerer Datenbank-Dump der Entwicklung) wird die interne Passwortsicherheit aktiviert.
Hierbei werden die folgenden Einstellungen gesetzt:

• Erweiterte Passwortsicherheit: An

• Groß- und Kleinbuchstaben: An

• Mindestens eine Zahl: Aus

• Mindestens ein Sonderzeichen: Aus

• Zeichenlänge mindestens: 12

• Ablauf des Kennworts (Tage): 90

• Warnung vor dem Ablauf des Kennworts (Tage): 7

• Kennworthistorie: 10

• Anzahl Fehlversuche: 5

Passwortänderung erzwingen 

Der Administrator hat auch die Möglichkeit, neue Passwortrichtlinien bei Benutzern durchzusetzen. Ist die Checkbox Passwort bei Anmeldung ändern aktiv, muss der Benutzer bei der Neuanmeldung sein Passwort richtlinienkonform anpassen.

Falls das Passwort den Richtlinien nicht entspricht, wird der Benutzer informiert.

Feld 'Passwort läuft nie ab'

Ist das Feld aktiviert, so werden für den so konfigurierten Mitarbeiter die Einstellungen zum Ablauf des Kennworts und der Warnung vor dem Ablauf des Kennworts umgangen. Das Feld ist standardmäßig für den Mitarbeiter TECH_USER auf true gesetzt. Wird das Feld auf die Maske aufgenommen, so verhält es sich wie das Feld Passwort bei Anmeldung ändern. Diese Felder werden nur dann sichtbar, wenn die erweiterte Passwortsicherheit aktiviert wird.

Konfiguration der Login-Seite im Web Client

Die neue Login-Seite ist ab der Version 24.3 im Standard aktiv.

Sie kann aber bereits ab der Version 24.1 explizit aktiviert werden, um beispielsweise die dort zur Verfügung stehenden Authentifizierungsverfahren (Open-ID und SAML) zu nutzen.

Aktivierung der Login-Seite

Im Anmeldedialog des Web Clients stehen mehrere Optionen und Anmeldedienste zur Verfügung. Die neue Maske kann optional über ein Feature-Flag aktiviert werden.

Hierfür müssen folgende Statements ausgeführt werden:

Aktivieren der modernen Login-Page

MSSQL

INSERT INTO PropertyMapper( Pk, id, property, propertyValue, propertyType, principal, isCustomizing, CustLayer, Active, CreateDate, CreateUser, UpdateDate, UpdateUser, Status, WFInstanceId, RightPk, ClientNo, MassData, OfflineData)
VALUES ( 'LoginPage.ModernLoginPageEnabled', 'LoginPage.ModernLoginPageEnabled', '', 'true', 'SYSTEM', '', 'false', 'CN', 'true', getDate(), 'TECH_USER', getDate(), 'TECH_USER', null, '#EMPTY-KEY#', null, null, 'false', 'false')

ORACLE

INSERT INTO PropertyMapper( Pk, id, property, propertyValue, propertyType, principal, isCustomizing, CustLayer, Active, CreateDate, CreateUser, UpdateDate, UpdateUser, Status, WFInstanceId, RightPk, ClientNo, MassData, OfflineData) 
VALUES ( 'LoginPage.ModernLoginPageEnabled', 'LoginPage.ModernLoginPageEnabled', '', 'true', 'SYSTEM', '', 0, 'CN', 1, SYSDATE, 'TECH_USER', SYSDATE, 'TECH_USER', null, '#EMPTY-KEY#', null, null, 0, 0);

Deaktivieren der legacy Login-Page (greift nur, wenn man die moderne Anmeldung auch aktiviert hat)

INSERT INTO PropertyMapper( Pk, id, property, propertyValue, propertyType, principal, isCustomizing, CustLayer, Active, CreateDate, CreateUser, UpdateDate, UpdateUser, Status, WFInstanceId, RightPk, ClientNo, MassData, OfflineData)
VALUES ( 'LoginPage.LegacyLoginPageEnabled', 'LoginPage.LegacyLoginPageEnabled', '', 'false', 'SYSTEM', '', 'false', 'CN', 'true', getDate(), 'TECH_USER', getDate(), 'TECH_USER', null, '#EMPTY-KEY#', null, null, 'false', 'false')

Je nachdem, ob bzw. welcher SSO-Anmeldedienst verwendet wird, steht auf der neuen Login-Maske neben der Anmeldung mit Account und Passwort ein zusätzlicher Button für das Single-Sign-On zur Verfügung.

Konfiguration der Anmeldedienste

Mit der neuen Login-Seite hat eine Erweiterung der möglichen Anmeldedienste stattgefunden. Die jeweiligen Konfigurationen sind den unten aufgeführten Links zu entnehmen.

Ein Auto-Login ist damit nicht mehr möglich! Der Anwender muss sich durch die Eingabe der Anmeldeinformationen oder den Klick auf den Single-Sign-On-Button am CRM-System anmelden.

Symbol	Beschreibung des Anmeldedienstes
	Direkte Anmeldung am System des Betreibers
	SAML → Single Sign-on mit SAML 2.0
	OpenID → Single Sign-on mit OpenID Connect
	Kerberos → Kerberos-Login
	Microsoft → SAML 2.0 mit Microsoft Active Directory Federation Services (ADFS) → SAML 2.0 mit Microsoft Azure Active Directory

Design und Branding

Kunden, welche die Anwendung entsprechend der Unternehmens-CI gestalten möchten, können folgende Elemente anpassen:

• Farbschema der Login-Komponenten (z.B. Buttons)

• Logo-Bild über der Anmeldemaske

• das Bild auf der rechten Seite des Login-Screens (Hintergrundbild)

• Fav-Icon im Browser-Tab

 Im ersten Schritt ist die Übersteuerung noch an zwei verschiedenen Stellen zu tätigen. Dies wird im Zuge der Neugestaltung der Adminkonsole geändert, sodass eine zentrale Stelle zur Anpassung der Login-Page vorhanden sein wird.

Anpassung des Farbschemas

Das Farbschema der Login-Page besteht aus fünf übersteuerbaren Farben. Um die Farben zu übersteuern muss die Anwendungsvariable "LoginPage.UiBranding" gesetzt werden. Diese kann über die "Adminkonsole > Customizing > Anwendungsvariable > Neu" aus der Vorschlagsliste gewählt werden.

Als Wert der Variable muss ein JSON-Objekt hinterlegt werden, in dem die Farben im Hex-Code definiert sind. Beispielwert mit den Standard-Farbcodes:

{
	"colors" : {
		"login-bg"          : "#ffffff",
		"marina-main"       : "#2f4898",
		"marina-black"      : "#020a24",
		"marina-white"      : "#fdfdfd",
		"marina-silver"     : "#e1e1e1"
	}
}

Soll nur ein Wert angepasst werden, muss auch nur dieser aufgeführt werden:

{
	"colors" : {
		"marina-main"       : "#2f4898"
	}
}

Die Zuordnung der jeweiligen Farbkategorien ist in der folgenden Darstellung aufgeführt.

Nach dem Hinzufügen bzw. Ändern der Anwendungsvariable greifen die Anpassungen an den Farbcodes der Login-Page sofort. Beim erneuten Aufruf der Login-Seite sind die aktuell definierten Farben ersichtlich.

Anpassung des Hintergrundbildes

Um das Standard-Hintergrundbild zu übersteuern, muss ein Dokumentenobjekt-Eintrag angelegt werden. Dieser kann unter "Adminkonsole > Dokumentenintegration > Verwaltung Dokumentenobjekte > Neu" erstellt werden. Bei der Anlage muss als Name  "LoginPage.backdrop" und als Typ "Grafiken" gewählt werden. Die Beschreibung kann beliebig hinterlegt werden.

Nach der Anlage des Eintrages sollte der Server-Cache geleert werden. Zudem sollte der Cache des Browsers ebenfalls geleert werden, damit das Ergebnis nicht erst vor dem Ablauf eines zuvor gefüllten Cache-Eintrags geladen wird.

Nach der Anlage des Eintrages sollte der Server-Cache geleert werden. Zudem muss der Cache des Browsers bei den Anwendern ebenfalls geleert werden, damit das neue Hintergrundbild auch für den Anwender sichtbar ist, da die Grafiken im Browser-Cache zwischengespeichert werden.

Diese Hinweis gilt auch für die Anpassung des Logos sowie des Fav-Icons!

Anpassung des Logos

 Für die Übersteuerung des Logos kann das gleiche Vorgehen wie beim Anpassen des Hintergrundbildes genutzt werden. Als Name muss lediglich "LoginPage.logo" gewählt werden. Das Logo wird auf 72x72px skaliert angezeigt. Daher sollte man aus Effizienzgründen bei der Wahl des Logos im Vorfeld auf eine passende Größe achten.

Anpassung des Fav-Icons

Für die Übersteuerung des Fav-Icons kann das gleiche Vorgehen wie beim Anpassen des Hintergrundbildes genutzt werden. Als Name muss lediglich "LoginPage.favicon" gewählt werden. Das Icon sollte im Format "ico" vorliegen und eine Größe von 16x16px aufweisen.