Version: GSB 7Website

Sobald ein Benutzer versucht, einen geschützten Zugriffsbereich zu betreten (durch Zugriff auf eine geschützte URL), muss sich dieser entsprechend anmelden oder ggf. eine Registrierung für die benötigte Benutzerrolle durchführen. In den folgenden Abschnitten werden diese beiden Alternativen vorgestellt.

Hinweis: Der Zugriffsschutz und Prüfung des Zugriffsschutzes erfolgt auf Basis von URL-Präfixen. D.h. alle URLs unterhalb eines geschützten Bereiches erfordern eine erfolgreiche Autorisierung und Authentisierung. Werden Dokumente, die unterhalb eines geschützten Bereichs abgelegt sind, in allgemein verfügbare Seiten eingebettet so werden diese Dokumente als Bestanteil der allgemein verfügbaren Seite dargestellt. Ein Dokument basierter Zugriffsschutz, der auch Seitenbestandteile berücksichtigt muss mit anderen Mechanismen (CoreMedia-Livegruppen) realisiert werden.

Konfiguration

Die Registrierung / Anmeldung zu geschützten Bereichen erfolgt nach durchgeführter Konfiguration innerhalb des Mandanten GSBAdmin durch entsprechend konfigurierte Formulare innerhalb des Mandanten, in dem die geschützten Bereiche vorgesehen sind.

Im Content der ausgelieferten Standardlösung sind entsprechend vorkonfigurierte Formulare inkl. sämtlicher erforderlicher Komponenten enthalten und können nach wenigen Konfigurationsarbeiten eingesetzt werden.

Die erforderlichen Dokumente liegen unterhalb von /standardlsg/Login und bilden einen weitgehend abgeschlossenen Bereich, der somit bei Bedarf auch in andere Mandanten kopiert werden kann. Dieses Kopieren wird idealerweise über den CoreMedia-Editor durchgeführt, der seit CMS2005 auch sämtliche Verlinkungen innerhalb des zu kopierenden Ordners beibehält.

Um die Formulare für einen Mandanten zu aktivieren, sind innerhalb des Ordners //_config folgende Registrierungen vorzunehmen:

Eintrag in /Mandant/_config/LoginPage

• Text-Classifier: Sprachkürzel (optional)
• Link-Classifier: ViewVariante „/Mandant/SiteGlobals/Layout/Views/main“
• Dokumentenlink: /Login/Login/Login_node

Eintrag in /Mandant/_config /LoginErrorPage ergänzen für Mandant

• Text-Classifier: Sprachkürzel (optional)
• Link-Classifier: ViewVariante „/Mandant/SiteGlobals/Layout/Views/main“
• Dokumentenlink: /Login/Login/LoginError_node

Eintrag in /Mandant/_config/ErrorPage403 ergänzen für Mandant

• Text-Classifier: Sprachkürzel (optional)
• Link-Classifier: ViewVariante „/Mandant/SiteGlobals/Layout/Views/main“
• Dokumentenlink: /Login/Login/Error403

Textfelder unterhalb von Login/Forms/_components/Textfelder/Hidden anpassen:

• In Registrierung_Mandanten_Name im Feld Default-Value den Mandantenbezeichner eintragen
• In Registrierung_Rolle_Name den Default-Value auf den im GSBAdmin-Mandanten angelegten Rollennamen setzen (z.B. admins @standardlsg).

Anmeldung

Sobald ein Nutzer auf einen geschützten Bereich zugreift, jedoch noch nicht eingeloggt ist, so erfolgt eine Aufforderung zur Authentifizierung. Die Aufforderung mit dem Anmelde-Bildschirm ist in Abbildung 16 dargestellt. Wie zu erkennen ist, benötigt die Authentifizierung die Eingabe von Benutzername und Passwort des jeweiligen Benutzers.

Registrierung

Sollte der jeweilige Benutzer die benötigte Berechtigung noch nicht besitzen, so kann er innerhalb des Anmeldefensters den Link mit der Beschriftung „hier“ betätigen, um den Registrierungsvorgang zu starten.

In Abbildung 17 „Registrierung“ ist die Bildschirm-Maske für den Registrierungsvorgang abgebildet. Wie an den durch „*“ gekennzeichneten Feldern zu erkennen ist, handelt es sich bei den Eingaben von Name, Passwort und Email-Adresse um Pflichtfelder. Die Email-Adresse gehört zu den Pflichtfeldern, da aufgrund des Double-Opt-In Verfahrens eine Email an den jeweiligen Benutzer gesendet wird. Technisch gesehen sind die Felder Vor- und Nachname optional, können jedoch bei Interesse auch als Pflichtfelder konfiguriert werden.

Wie bereits geschildert wurde, erfolgt die Registrierung unter Einsatz des Double-Opt-In-Verfahrens. Der Benutzer ist zwar unmittelbar nach dem Abschicken seiner Daten registriert, kann sich jedoch noch nicht am System anmelden. Stattdessen erhält er eine Email mit einer URL, die zur Freischaltung besucht werden muss. Sobald der neue Benutzer diese URL besucht hat, wird das Status-Attribut der Rollenzuordnung entweder auf "bestätigt" oder direkt auf "aktiv" gesetzt. Dies hängt letztendlich davon ab, ob es sich bei der benötigten Rolle um eine automatische oder administrative handelt (vgl. Kapitel 3.1.1 „Erstellung von Benutzerrollen“).

Ist der Status des Benutzers „aktiv“, so kann sich dieser am System anmelden. Andernfalls muss er erst noch von einem Administrator freigeschaltet werden.

Passwort vergessen

Hat ein Nutzer sein Passwort vergessen, so kann er sich auf der Seite "Passwort vergessen" sein Passwort neu setzen. Nach Angabe seiner Benutzerkennung wird an die im jeweiligen Profil hinterlegte Email-Adresse eine Email geschickt. Nutzer bei denen die Email-Adresse nicht bekannt/im Profil gespeichert ist, können diese Funktion nicht nutzen.

Nach Klick auf den Link in der Email werden die im Link enthaltenen Parameter validiert, nach erfolgreicher Validierung wird der Nutzer auf eine Formular weitergeleitet auf dem er sein Passwort neu setzen kann. Anschließend kann sich der Nutzer wie gewohnt mit dem neu gesetzten Passwort anmelden, um auf Zugriffsgeschützte Inhalte zuzugreifen.

Konfiguration

Die für die "Passwort vergessen"-Funktionalität benötigten Dokumente finden sich in der Standardlösung unterhalb des Ordners /standardlsg/Login/PasswortVergessen. Der Email-Versand der "Passwort vergessen"-Email erfordert eine Anpassung der entsprechenden Mailaction (Dokument /standardlsg/Login/Forms/_components/Actions/PasswordForgottenMail_Action). Relevante Action-Properties sind:

• lookForEmail (true/false) definiert, ob neben der Benutzerkennung auch die Angabe von Email-Adressen imn "Passwort vergessen"-Formular akzeptiert werden.
• userNameIsEmail (true/false) definiert, ob die Benutzerkennung die Email-Adresse enthält.
• defaultSender enthält die Email-Adresse mit dem die "Passwort vergessen"-Emails geschickt werden
• defaultSubject enthält das Subject der "Passwort vergessen"-Email

die klassifizierte LInkliste Parameter enthält darüber hinaus einige weitere Definitionen:

• UserNameTextInput verlinkt auf das Formularfeld, aus dem die Benutzerkennung gelesen wird
• TargetPage verlinkt auf die Zielseite des "Passwort vergessen"-Links in der Email
• EmailTemplate verlinkt auf das Mail-Template der "Passwort vergessen"-Email

Die Prüfung des Links in der "Passwort vergessen"-Email wir durch die Generische-JSP passwortvergessen_checkpassword_jsp (/standardlsg/Login/PasswortVergessen/passwortvergessen_checkpassword_jsp) durchgeführt. Der Konfigurationsparameter validForMinutes definiert die Gültigkeit des Links in Minuten und ist Standardmäßig auf 240 Minuten konfiguriert. Dieser Wert kann bei Bedarf im Mandanten angepasst werden.

Passwort ändern

Angemeldete Benutzer können ihr Passwort über das "Passwort ändern"-Formular welches Bestandteil der Standardlösung ist ändern. Der Aufruf erfolgt über die Seite (Navigationsknoten) /Restricted/DE/MeinProfil/PasswortAendern/passwort-aendern_node. Es sollte bei der Konfiguration der Seite darauf geachtet weden, dass der Link nur für angemeldete User sichtbar ist und somit vorzugsweise innerhalb eines geschützten Bereichs liegt.

Passwortrichtlinien

Passwortrichtlinien können über Validatoren geprüft und deren Einhaltung sichergestellt werden. Hierfür stehen die folgenden Validatoren zur Verfügung, die in der Stzur Sicherung der Passwort-Qualität im Eingabefeld /SiteGlobals/Forms/_components/Textfelder/PasswortAendern_Passwort eingesetzt werden können:

• PasswordValidator - prüft die grundsätzliche Qualität des Passwortes anhand eines regulären Ausdrucks. In der Standardlösung findet sich dieser Validator im Dokument /SiteGlobals/Forms/_components/Validatoren/Password
• PasswordReusedValidator - prüft, ob das Passwort identisch mit einem der zuletzt verwendeten Passwörtern des Nutzers ist. Die Anzahl der zu prüfenden Passwörter muss in der Validator-Property numberOfPasswordsToCheck konfiguriert werden. Ein Wert von 0 deaktiviert diese Prüfung. In der Standardlösung findet sich der Validator im Dokument /SiteGlobals/Forms/_components/Validatoren/PasswordReused
• SimilarityBasedPasswordValidator - prüft, ob das angegebene Passwort dem bisherigen Passwort zu ähnlich ist. Dazu wird die Levenshtein-Distanz berechnet.
  Das Texteingabefeld mit dem alten Passwort muss in der Validator-CLL-Property unter dem Text-Classifier oldPassword verlinkt sein. Da in der Datenbank nur Passwort-Hashes gespeichert werden, kann dieses Verfahren nicht genutzt werden, um die Ähnlichkeit zu früher verwendeten Passwörtern zu prüfen.
  Die Mindestdistanz zum alten Passwort wird in der Property minDifference angegeben werden. Um zusätzlich case-insensitiv zu prüfen, kann in der Property caseInsensitiveBonus ein Wert größer oder gleich 0 angegeben werden. Der angegebene Wert wird bei der case-insensitiven Prüfung als Bonus berücksichtigt. Der Default ist -1, d.h. die Prüfung wird nicht durchgeführt. Der kleinere gefundene Wert (case-sensitiv bzw. case-insensitiv mit Bonus) wird als Endergebnis verwendet.
  Um zusätzlich das rückwärts geschriebene Passwort zu prüfen, kann in der Property reverseBonus ein Wert größer oder gleich 0 angegeben werden. Der angegebene Wert wird bei der Rückwärts-Prüfung als Bonus berücksichtigt. Der Default ist -1, d.h. die Prüfung wird nicht durchgeführt. Der kleinere gefundene Wert (vorwärts bzw. rückwärts mit Bonus) wird als Endergebnis verwendet. Der Fehlercode kann in der Property errorCode festgelegt werden. Der Default ist passwordTooSimilar.

Hinweis für Hosting-Plattform-Betreiber

Passwörter werden mit einem zufällig gewählten Salt-Wert in der Datenbank gespeichert. D.h. bei Änderungen des Passworts (im Mandanten oder über die GSBAdmin-Oberfläche) wird der bisher verwendete Passwort-Hash zusammen mit seinem Salt in der Tabelle BKCMS_TOMCAT_USERS gespeichert. Der Hash- und Salt-Wert der verwendeten Passwörter der Nutzer werden in der neuen Datenbank-Tabelle BKCMS_OLD_PASSWORDS gespeichert, um diese im PasswordReused-Validator für die Prüfung des neuen Passwortes gegen das alte damit beim Passwort-Ändern geprüft werden kann, ob das neue Passwort bereits verwendet wurde.

Password Aging

Beim Ändern des Passworts auf der Website des Mandanten oder über die GSBAdmin-Oberfläche wird das Datum der Passwortänderung im jeweiligen Benutzer-Datensatz gespeichert. Bei bereits existierenden Benutzerdatensätzen wird dieses Datum, sofern noch nicht vorhanden, bei der nächsten Anmeldung gesetzt.

Nachdem sich ein Benutzer erflogreich an einem geschützten Bereich angemeldet hat, wird das Alter seiner letzten Passwortänderung geprüft. Liegt diese bereits mehr als X-Tage zurück, so muss der Benutzer zunächst ein neues Passwort setzen. Erst nach erfolgreicher Änderung des Passwortes kann der Benutzer auf den geschützten Bereich zugreifen. Nach Änderung des Passworts wird das Datum der Passwortänderung aktualisiert. Das maximale Passwortalter von X-Tagen wird innerhalb des Mandanten konfiguriert.

Weiterhin besteht die Möglichkeit pro Nutzer das Password-Aging zu deaktivieren oder einen anderen Aging-Zeitraum zu wählen. Hierfür gibt es ein neues Attribut im Benutzer-Datensatz, welches die Konfiguration des Mandanten überschreibt. Es kann im GSBAdmin-Mandanten gesetzt werden.

Für die Konfiguration des Password Agings sind die folgende Dokumente im GSB-Mandanten zuständig:

• MaxPasswordAge (SiteGlobals-Reader, Dokumenttyp ConfigInt) definiert das maximal erlaubte Alter des Passwortes in Tagen. Bei einem Wert von 0 ist das Aging deaktiviert. Die Standardlösung enthält eine exemplarische Konfiguration im Dokument /standardlsg/SiteGlobals/_config/MaxPasswordAge.
• ChangePasswordPage (Rekursiver-ConfigReader, Dokumenttyp ConfigLinkList)verlinkt auf die Seite mit dem "Passwort ändern"-Formular. Die Standardlösung verlinkt im Dokument /standardlsg/_config/ChangePasswordPage auf die "Passwort ändern"-Seite

Account Deaktivierung bei fehlerhafter Anmeldung

Fehlgeschlagene Benutzeranmeldungen aufgrund eines falschen Passworts (aber gültigem Benutzernamen) führen im jeweiligen Benutzer-Datensatz zu einer Erhöhung des Failed-Login-Zählers und setzten das Failed-Login-Datum. Bei einer nachfolgenden erfolgreichen Anmeldung werden Zähler und Datum wieder gelöscht.

Mehrere aufeinanderfolgende fehlgeschlagene Logins können zu einer Sperrung des betreffenden Benutzer-Accounts führen. Die Anzahl der maximal erlaubten Fehlanmeldungen kann innerhalb des Mandanten definiert werden. Bei einer Sperrung des Accounts wird optional eine E-Mail an die im Account hinterlegte Emailadresse sowie eine Liste von zuständigen Administratoren geschickt.

Für die Konfiguration sind die folgenden Dokumente zuständig, die bei Bedarf angepasst werden müssen:

• MaxFailedLogins (SiteGlobals-Reader, Dokumenttyp ConfigInt) definiert die maximale Anzahl aufeinanderfolgender fehlerhafter Benutzeranmeldungen. Bei einem Wert von 0 ist die Account Deaktivierung ausgeschaltet. Die Standardlösung enthält eine exemplarische Konfiguration im Dokument /standardlsg/SiteGlobals/_config/MaxFailedLogins.
• AccountDeactivatedEMailSender (SiteGlobals-Reader, Dokumenttyp ConfigString) definiert den Email-Absender der Deaktivierungs-Email
• AccountDeactivatedEMailRecipients (SiteGlobals-Reader, Dokumenttyp ConfigString) enthält die optionale Liste der Email-Empfänger der Deaktivierungs-Email. Ist dieses Dokument leer so wird keine Email-Benachrichtigung an die Mandanten-Administratoren durchgeführt.
• AccountDeactivatedEMailToUser (SiteGlobals-Reader, Dokumenttyp ConfigBool) definiert, ob eine Email-Benachrichtigung des gesperrten Benutzers durchgeführt wird
• AccountDeactivatedUserEMailSubject (Label) enthält das Subject der Deaktivierungs-Email für den Benutzer
• AccountDeactivatedAdminEMailSubject (Label) enthält das Subject der Deaktivierungs-Email für die Administratoren
• AccountDeactivatedUserEmailTemplate (Email-Template) enthält das Email-Template der Deaktivierungs-Email für den Benutzer
• AccountDeactivatedAdminEmailTemplate (Email-Template) enthält das Email-Templates der Deaktivierungs-Email für die Administratoren

Anzeige des Benutzerstatus nach Anmeldung

Bei der Anmeldung werden einige neue Session-Attribute gesetzt, die den Status des angemeldeten Benutzers enthalten. Folgende Attribute stehen für die Ausgabe des Status zur Verfügung:

Name	Typ	Funktion
Security_UserNotLoggedOut	Boolean	Der User hatte sich vor der Anmeldung nicht abgemeldet
Security_LastLoginDate	Date	Datum des letzten erfolgreichen Logins
Security_FailedLoginDate	Date	Datum des letzten fehlgeschlagenen Logins
Security_FailedLoginCount	Integer	Anzahl der fehlgeschlagenen Login-Versuche

Die Ausgabe des Benutzerstatus erfolgt in einem JSP-Template oder Velocity-Skript. In der Standardlösung findet sich eine exemplarisch Umsetzung im Dokument /Restricted/DE/MeinProfil/Functions/profil_informationen_html. Das folgende Velocity-Code-Schnipsel gibt bspw. die Anzahl fehlgeschlageneer Logins aus:

#set($nrFailedLogin= $!CMUtil.Request.Session.getAttribute("Security_FailedLoginCount"))$cms.message("NrFailedLogin", $nrFailedLogin)

Email-Benachrichtigung bei Freischaltung

Wenn über die GSBAdmin-Oberfläche der Status einer Benutzer-Rolle auf aktiv gesetzt wird, kann bei Bedarf automatisch eine E-Mail an den betroffenen User gesendet werden.Dazu wird die neue von der FormMailAction abgeleitete UserRoleActivatedNotificationMailAction genutzt, die im GSBAdmin-Mandanten genutzt werden kann.Eine E-Mail wird nur dann gesendet, wenn im Benutzer-Datensatz eine E-Mail-Adresse im Feld email oder (wenn so konfiguriert) im Feld userName gespeichert ist und wenn das Feature für die Rolle explizit für den GSBAdmin-Mandanten aktiviert wurde.

Für die Verwendung im GSBAdmin-Mandanten muss für jede Rolle, deren Benutzer bei Aktivierung benachrichtigt werden sollen ein Dokument vom Typ HFAction (Formular-Action) im Folder /GSBAdmin/Customers/${CUSTOMER}/_config/UserRoleActivatedNotification_${FULLROLENAME} angelegt werden. Die Konfiguration erfolgt dann rollenspezifisch in dieser Action, die nicht weiter verlinkt zu werden braucht, sondern anhand der Namenskonvention gefunden wird. Bei Verwendung direkt im Zielmandanten erfolgt die Konfiguration in der im Formular verlinkten Action selbst.

Action-Properties:

Name	Funktion	Beispiel
defaultSender	E-Mail-Adresse des Absenders	admin@domain.example
defaultSenderName	Klartext-Name des Absenders	GSB-Administration
defaultSubject	E-Mail-Subject	Rolle aktiviert
userNameIsEmail	Gibt an, ob die E-Mail-Adresse im Login-Namen des Users gespeichert ist. Der Default ist false	true

Im klassifizierten Action-Parameter mit dem Text-Classifier EmailTemplate muss in den Dokumenten-Links zusätzlich das Velocity-Template für den E-Mail-Text verlinkt werden. Es ist sicherzustellen, dass dieses Dokument im aktuellen ResourceBundle gefunden wird. In diesem Template können zusätzlich zu den Standard-Variablen der FormMailAction die folgenden Velocity-Variablen genutzt werden:

Name	Typ	Funktion
customer	String	Name des Mandanten
user	BkcmsTomcatUser	Benutzer-Datensatz
userName	String	Login-Name des Users
role	BkcmsTomcatRole	Datensatz der aktivierten Rolle
roleName	String	Name der aktivierten Rolle