Authentifizierung

Für easydb sind mehrere Authentifizierungsysteme verfügbar. Als Standard werden Konten in einer Tabelle der easydb angelegt: "user" (oder "User" bei älteren Installationen).

Per Konfiguration kann auch Zugriff gewährt werden über ein Gast-Konto oder ganz ohne Authentifizierung; oder mit mit zusätzlichen Modulen.

Die Module LDAP, Kerberos, Shibboleth und Stud.IP können Sie dafür zusätzlich lizensieren.

LOGIN_METHODS

Die Variable LOGIN_METHODS legt fest, welche Methode in welcher Reihenfolge probiert wird, wenn easydb eine Authentifizierungs-Anfrage erhält.

Für das Standard-Verhalten können Sie diese Variable unkonfiguriert lassen. Der Default-Wert ist easydb.

Es stehen zur Verfügung (je nach Ausbaustufe):

Beispiel 1:

LOGIN_METHODS=guest,easydb

Dieses Beispiel authentifiziert immer den Benutzer "guest" (falls er als Benutzer mit dem Passwort "guest" angelegt wurde).
Sollte ein Modul ( z.B. der Creator ) eine Authentifizierung verlangen, wird die easydb-Methode benutzt.

Beispiel 2:

LOGIN_METHODS=ldap,easydb

In diesem Bespiel versucht easydb zuerst über ldap zu authentifizieren und, wenn die login/passwort-Kombination nicht zum Erfolg führt, über easydb.

Administrativer Zugriff:

Bitte beachten Sie, dass in LOGIN_METHODS immer easydb enthalten sein sollte. Falls nicht, kann es sein, dass Sie keinen administrativen Zugriff mehr auf z.B. http://<easydb-url>/ezadmin bekommen, weil der "admin"-Benutzer ein easydb-Benutzer ist.

guest und unauthenticated:

Die Methode unauthenticated authentifiziert immer. Der Benutzer wird als "nicht angemeldet" im Rechtemanagement geführt.
Der angezeigte Benutzer-Name ist in diesem Fall der Inhalt von l10n.login.unauthenticated.displayname aus String-Tool (und keys.csv).

Bitte beachten Sie, dass sich mit Version 4.0.199 die Funktionsweise der Methode guest geändert hat.
Die Methode die ohne Benutzernamen authentifiziert heisst jetzt unauthenticated und hieß vorher guest.
Die Methode guest authentifiziert jetzt mit dem Modul easydb den Login-Namen "guest" mit Passwort "guest".

Die Methode guest authentifiziert mit der easydb-Methode den Login-Namen "guest" mit Passwort "guest".
Der Benutzer "guest" ist ein normaler Benutzer, also im Sinne des easydb-Rechtemanagements auch "angemeldet".
Falls Sie die Rechte dieses Kontos ändern wollen, dann richten Sie dazu einen Benutzer mit dem Login-Namen "guest" ein.

Der Benutzer "guest" wird auch benutzt, wenn im Frontend ein Button "Guest" eingerichtet ist.

Login-Maske:

easydb und ldap können mit httpbasic kombiniert werden. In diesem Fall wird easydb nicht die Login-Maske zeigen (die Sie im Creator in INDEX_LOGIN_GRID angegeben können),
sondern eine HTTP-Authentifizierungs-Anfrage zum Browser schicken. Die empfangenen Credentials werden dann an die Methode weitergegeben, die in LOGIN_METHODS konfiguriert ist.

LOGIN_ADDITIONAL_GROUP_METHODS

Wenn es gewünscht ist, die Gruppenzuordnung einer anderen Authentifizierungsmethode zusätzlich zu übernehmen, dann hilft diese Variable.

Das ist vor allem hilfreich, wenn Ihre Nutzer per LDAP oder Shibboleth angemeldet sind, trotzdem aber auf easydb-Gruppen zugreifen können sollen.
Dazu muss ein easydb-Benutzer mit dem gleichen Login-Namen existieren, welcher den gewünschten Gruppen zugeordnet ist;
außerdem muss die Variable wie folgt gesetzt sein:

LOGIN_ADDITIONAL_GROUP_METHODS=easydb

Die Variable unterstützt nicht alle Authentifizierungsmethoden. Neben easydb ist das im Moment nur ldap und studip als kundenspezifische Lösung.

Falls LDAP nur als Quelle für Gruppen genutzt wird (z.B. mit Kerberos), also nicht in LOGIN_METHODS, dann ist nur eine LDAP_GROUPS_URL verwendbar, also nur LDAP_GROUPS_URL_1, siehe LDAP.

LOGIN_EASYDB_LDAP_AUTH_COLUMN

Dies ist eine Kombination aus easydb-Authentifizierung und LDAP. Der Benutzer wird in easydb angelegt und geführt. Der Passwort-Check wird gegen einen LDAP-Server durchgeführt ( mit LDAP-bind ).

LOGIN_EASYDB_LDAPAUTH_COLUMN=use_ldap_auth

In diesem Beispiel schaut easydb in der Spalte use_ldap_auth nach, ob für den zu authentifizierenden Benutzer ein "true" oder ein "Y" gesetzt ist. Falls ja, wird der LDAP-Server angefragt, ob die eingegebene Login/Passwort-Kombination korrekt ist.

Für diese Methode muss aus dem LDAP-Modul die Variable LDAP_USER_URL gesetzt sein. Mehr zu LDAP finden Sie hier.

LOGIN_EASYDB_DISPLAYNAME_FORMAT=<formatstring>

Diese Variable beeinflusst wie der Username zur Darstellung formatiert wird.

Als Variablen stehen alle Spalten des gefundenen Users bereit. Formatstrings sind in einem eigenen Kapitel beschrieben.

LOGIN_EASYDB_DISPLAYNAME_FORMAT=Easydb User: %(email:html)s

Es ist wichtig mittels :html escaping anzuschalten wenn das Attribut HTML enthalten und vom user geändert werden kann.

LOGIN_EASYDB_BY_REQUEST

Wenn diese Variable gesetzt ist, kann ein Nutzer direkt angemeldet werden, indem zusätzliche Request-Variablen gesetzt werden. Format der Variable ist folgendes:

LOGIN_EASYDB_BY_REQUEST=<sql mit platzhaltern>,<request-variable>[,<request-variable> *]

Vorstellbar ist z.B. die Angabe des Nutzernamens:

LOGIN_EASYDB_BY_REQUEST=login = ?,easydb-login

Um sich mit dieser Konfiguration als Nutzer tester anzumelden, ruft man die easydb mit http://easydb/?easydb-login=tester auf.

Eine weitere Möglichkeit wäre die Angabe des Klartextpassworts (http://easydb/?easydb-login=tester&easydb-password=12345):

LOGIN_EASYDB_BY_REQUEST=login = ? AND password = MD5(?),easydb-login,easydb-password

Sollte die Spalte mit dem Login-Namen von der Vorgabe login abweichen, so muss im Stringtool USER_LOGIN_COLUMN auf den richtigen Wert gesetzt werden.

LOGIN_CHECK_BROWSER (seit Version 4.0.287)

Seit Version 4.0.287

Durch Setzen dieser Variable wird die aktuelle Benutzer-Session an den Browser gebunden, d.h. man kann eine easydb-URL nicht mehr in einen anderen Browser kopieren und dort weiterverwenden. easydb verwendet dazu einen Session-Cookie der für die Dauer einer Browsr-Sitzung aktiv bleibt.

LOGIN_CHECK_BROWSER=0  # Standard: 1

easydb enthält seit Version 4.0.287 einen erweiterten Schutz vor Session-Hijacking, d.h. dem Kopieren und Weiter-Verwenden aktiver Session-ID von anderen Computern oder Browsern.

LOGIN_CHECK_EXCLUDE_IP_V4 (seit Version 4.0.287.6)

Seit Version 4.0.287.6

In Einzelfällen kann es nötig sein einzelne IP-Adressen oder Netwerke vom Login-Check auszunehmen. Beispielweise wenn Sie extrem langläufige ezadmin-Aufgaben per wget mit einer Browser-Session-ID ausführen können möchten.

IP-Adressen und Netzwerke können Sie kommasepariert angeben.

# Standard: <leer>
#
LOGIN_CHECK_EXCLUDE_IP_V4=127.0.0.1,122.0.8.0/8

Im Beispiel werden 127.0.0.1 und das Netz 122.0.8.0/8 vom Security-Check ausgenommen.

Die IP oder Netzwerke können in dem selben Format eingegeben werden wie die IP-Filter bei Gruppen.

Cookie-Authenifizierung (seit Version 4.0.125)

Enthält LOGIN_METHODS die cookie-Methode, ist auch eine Authentifizierung möglich, ohne jedes Mal ein Passwort eingeben zu müssen. Dabei wird nach der erfolgreichen Anmeldung mit einer der anderen Login-Methoden ein Cookie im Browser gesetzt, der alle nötigen Angaben zur Anmeldung enthält. Beim Klick auf den logout-Link in der easydb wird dieser Cookie wieder gelöscht. Die folgenden zwei Konfigurationsoptionen sind zur Verwendung der cookie-Methode zwingend notwendig:

LOGIN_COOKIE_LIFETIME

Diese Option gibt die Lebensdauer des gesetzten Cookies in Tagen an. Nach Ablauf dieser Zeit ist eine erneute Anmeldung mit Nutzernamen und Passwort erforderlich.

LOGIN_COOKIE_SECRET

Bei dieser Option handelt es sich um ein frei wählbares Passwort, dass zur Absicherung des Cookies benutzt wird. Es sollte nicht erratbar sein und muss auch keinem anderen Passwort innerhalb der easydb oder der angeschlossenen Datenbank entsprechen.

Überprüfung der User-ID im Rechtemanager (seit Version 4.0.199)

Im Rechtemanager können manuell User-IDs eingegeben werden. Für die User-IDs kann eine Prüfung festgelegt werden. Die Prüfung kann auch erwartete Zusätze an die User-ID automatisch anfügen.

Die Prüfung erfolgt immer zuerst in dem von easydb angelegten Benutzer-Cache. Wenn sich die User-ID schon einmal angemeldet hat, ist sie automatisch valide. Danach überprüfen die in LOGIN_METHODS konfigurierten Login-Methoden (derzeit nur für easydb), ob eine User-ID valide ist. Danach kann per Config-Variablen die User-ID syntaktisch geprüft und ggfs. auch verändert werden.

Eine Überprüfung erfolgt nur, wenn LOGIN_VALID_USER_ID_ERROR[.<language>] gesetzt ist und nur für neu eingegebene User-IDs.

LOGIN_VALID_USER_ID_ERROR[.<language>]

Die Überprüfung wird aktiviert, wenn LOGIN_VALID_USER_ID_ERROR auf einen Fehlertext gesetzt ist. Mit Angabe von <language> kann der Fehlertext für verschiedene Sprachen hinterlegt werden (z.B. de, en). In dem Fehlertext können Sie Angaben zum notwendigen Format hinterlegen.

Der Fehler wird in den allgemeinen Fehlertext l10n.rightsmanager.Error.INVALID USER ID in der Variable %1 eingebettet.

LOGIN_VALID_USER_ID_<n>

LOGIN_VALID_USER_ID_<n> wird als regulärer Ausdruck angegeben und in der easydb an preg_match als $pattern übergeben. n ist eine Zahl von 1-9 zur Definition von bis zu 9 Regeln. Die Regeln werden in der Reihenfolge 1-9 durchlaufen. Wenn eine Regel zutrifft, gilt die eingegeben User-ID als valide und es wird nicht weiter geprüft. Im Falle einer validen Prüfung wird bei Bedarf noch eine Ersetzung durchgeführt.

LOGIN_VALID_USER_ID_<n>.replace

In LOGIN_VALID_USER_ID_<n>.replace wird ein Ausdruck übergeben, der zum Ersetzen dient. easydb übergibt den Ausdruck als $replacement an preg_replace. Damit ist es möglich automatisch an eine User-ID noch eine Domain o.ä. anzufügen (siehe Beispiel).

Beispiel

LOGIN_VALID_USER_ID_1=/.{3,}@domain/
LOGIN_VALID_USER_ID_2=/(.{3,})/
LOGIN_VALID_USER_ID_2.replace=\1@domain
LOGIN_VALID_USER_ID_ERROR.de=Mindestens 3 Buchstaben
LOGIN_VALID_USER_ID_ERROR=At least 3 chars

Im Beispiel wird für die User-ID mindestens 3 Zeichen verlangt und ein deutscher und ein allgemeiner Fehlertext (für andere Sprachen) definiert. Es wird automatisch ein @domain angehängt.

Creator-Konfiguration

Für die easydb-Authentifizierung werden folgende Variablen über das Stringtool konfiguriert. In Klammern ist jeweils die Standardeinstellung angegeben.

  • USER_TABLE_NAME ("User")
  • USER_LOGIN_COLUMN ("login"), wird momentan nur für LOGIN_EASYDB_BY_REQUEST benutzt
  • GROUP_TABLE_NAME ("Usergruppe")
  • GROUP_TABLE_DISPLAY_COLUMN_NAME ("name")
  • GROUP_TABLE_FILTER_IPV4_COLUMN ("ip_v4_filter")
  • USER_AUTH (password=MD5(%p) AND login=%u), %p und %u werden jeweils durch Login + Passwort ersetzt (als SQL-String in einfachen Anführungszeichen).
  • USER_ACL_SELECT (<leer>), wenn gesetzt werden beim Rechtemanager diese Benutzer zur Auswahl ausgegeben. Beispiel: ‘SELECT login, name FROM "user" ORDER BY login’. Die erste Spalte muss den Login (user_id) enthalten, die zweite Spalte den Wert für die Anzeige. Seit Version 4.0.265

Passwort-Richtlinien

Mit Creator-Mitteln kann auch die Überprüfung von Passwort-Richtlinien eingebunden werden.