Nutzer und Gruppen in einer Datenbank

• » Home
• »Server-Daten
• »Menü-Hilfe
• » Nutzer und Gruppen

In einer Datenbank gibt es zwei vordefinierte Benutzer: <admin> ist der Nutzer, der zu allen Aktionen berechtigt ist. Im Hintergrund gibt es den Nutzer <server-daten>, dieser ist bsp. Besitzer des Nutzers 'admin' und taucht im Protokoll dann auf, falls das System Daten geändert hat. Ferner gibt es einige vordefinierte Gruppen mit zugeordneten Berechtigungssätzen sowie vordefinierte Gruppen, deren Mitglieder sich aus der Art der Anmeldung (anonym, anonym + Nick usw.) ergeben. Zusätzlich können weitere autorisierte Nutzer und sonstige Gruppen über das folgende Menü erstellt werden.

Suchen

Neuer Nutzer/Gruppe

Speichern

Abbruch

---

Hilfe

Übersicht  (1/5) ≪ < 1  > ≫  -    admin  -    Beispiel-Gruppe  -    M1  -    M2  -    M3  -     (N)

Id ↑↓ Nutzer/Gruppenname * ↑↓ Mailadresse ↑↓ Login erlauben * JaNein↑↓ interne Masken nutzen * JaNein↑↓ PM-Versand erlaubt JaNein↑↓ Nutzertyp * authorized Userother group↑↓ online seit ↑↓ letzte Anmeldung ↑↓ Mail gültig? ---JaNein↑↓ Urlaubssperre ↑↓ Owner adminserver-daten

Zur Erstellung eines neuen autorisierten Nutzers müssen Nutzername und Mailadresse bekannt sein. Ein Nutzer mit dem Recht, Nutzer hinzuzufügen, trägt beide Informationen hier ein. Ferner legt er fest, ob dem Nutzer das Login für die internen Masken sowie das Versenden von Private Messages (PM) erlaubt sein soll (näheres unter Private Message ). Eine Gruppe benötigt nur einen eindeutigen Namen sowie den Typ 'other Group'. Wird ein Datensatz später zum Lesen aufgerufen, so ist zusätzlich das Feld <Nutzertyp> deaktiviert. Die anderen Daten werden vom System bereitgestellt.

Nutzer vom Typ anonyme Nutzer, welche nur eine Mailadresse zur Anmeldung benötigen sowie vom Typ anonyme Nutzer mit Nick, für welche eine Mailadresse und ein Nickname notwendig ist, können sich nur selbst am System anmelden. Sie werden auch als Selbstanmelder bezeichnet. Hierfür sind mittels der Vorlagen Ausgabeseiten für beide Typen sowie eine Login-Maske zu erstellen. Ferner muß der not-registered-user-group, der Gruppe der nicht registrierten Nutzer ohne Authentifizierung, die Execute-Berechtigung für diese Ausgabeseiten zum Anmelden und zum Login erteilt werden, damit die Ausgabeseiten aufrufbar sind. Bei der Erstellung eines autorisierten Nutzers muß diesem das Login erlaubt werden. An alle drei Nutzertypen wird ein Passwort per Mail verschickt. Selbstanmelder müssen sich innerhalb von 24 Stunden einmal anmelden. Ansonsten wird der Account vom System gelöscht und die Anmeldung verweigert. Diese Nutzer können auch noch nicht Gruppen zugeordnet werden, falls sie ihre Anmeldung noch nicht bestätigt haben.

Autorisierte Nutzer müssen sich nicht innerhalb einer festgesetzten Frist anmelden. Sie können auch schon vor der Bestätigung ihrer Anmeldung Gruppen zugeordnet werden. Dies gestattet es, Listen von Nicknamen und Mailadressen einmalig einzugeben und sie in Gruppen zu gliedern, auch wenn sich die Nutzer erst in den folgenden Wochen anmelden.

Nach der erfolgreichen Erstanmeldung wird die Mailadresse auf den 'Mail gültig' - Status 'Ja' gesetzt. Hier zeigt das System 'Nein' an, falls der Nutzer seine Mailadresse geändert, seine neue Adresse jedoch noch nicht bestätigt hat. Für anonyme Nutzer wird intern die Mailadresse als Nick verwendet, diese ist für interne Nutzer immer sichtbar.

Zwei Besonderheiten der Konzeption

Es fällt auf, daß die obige Maske kein Feld zur Festlegung eines Passwortes kennt. Das Initialpasswort wird dem Nutzer per Mail zugesandt. Anschließend kann der Nutzer - und nur er - sein Passwort im Menü <Eigene Daten> - <Sicherheit> ändern. Es ist nicht möglich, daß der Administrator für einen Nutzer ein Passwort erstellt, ändert oder löscht. Dies mag zunächst als Einschränkung der Administratorrechte erscheinen. Tatsächlich jedoch vermindert es all jene Probleme, die mit dem Begriff Social Engineering bekannt sind. Dies meint Situationen, in welchen mittels sozialer Kontakte versucht wird, einen Berechtigten zur Herausgabe oder Änderung eines Passworts zu veranlassen. Ein Administrator kennt kein Passwort eines anderen Nutzers, also ist jeder Versuch, ihn zur Preisgabe oder Änderung eines Passwortes zu bewegen, unsinnig.

Ein Nutzer kann sich im Menü <Eigene Daten> - <Sicherheit> jederzeit selbst sperren, indem er ein in der Zukunft liegendes Datum eingibt und dieses mit seinem Passwort bestätigt. Er erhält anschließend eine Mail mit zwei Schlüsseln. Der erste Schlüssel aktiviert die Sperre endgültig. Der zweite Schlüssel kann die Sperre vorzeitig aufheben. Da diese Sperre genutzt werden kann, damit sich ein Nutzer während seines Urlaubs selbst blockiert, wird sie als Urlaubssperre bezeichnet. Der Zeitpunkt der Urlaubssperre ist für andere Nutzer im aktuellen Menü sichtbar. Die Urlaubssperre wird automatisch aufgehoben, wenn der Nutzer sich anschließend das erste Mal wieder anmeldet. Nur ein Nutzer kann für sich selbst eine Urlaubssperre festlegen. Kein Nutzer, auch kein Administrator, kann dies für einen anderen Nutzer erzeugen.

Vordefinierte Gruppen

In jeder Datenbank stehen einige Gruppen von vornherein zur Verfügung. Es gibt zwei Typen: Gruppen, für welche die Berechtigung fixiert ist, die Mitglieder jedoch geändert werden können sowie Gruppen, für welche die Berechtigungen definierbar, die Mitglieder jedoch fixiert sind.

Gruppen mit vordefinierten Berechtigungen

Zu diesen Gruppen können neue Mitglieder hinzugefügt werden. Es können keine Berechtigungssätze für diese Gruppen erstellt oder bestehende Berechtigungssätze geändert bzw. gelöscht werden.

• admin-group: Mitglieder haben globale Administratorrechte für alle Objekte. Der <admin> ist zunächst einzigstes Mitglied.
• dataReader-group: Nutzer können alle Daten in benutzerdefinierten Tabellen zu lesen.
• dataWriter-group: Nutzer sind berechtigt, alle Daten in benutzerdefinierten Tabellen zu ändern.
• execObjects-group: Nutzer sind zur Ausführung berechtigt. Dies betrifft Uploads/Downloads, Abfragen und Ausgabeseiten.
• ownAdmin-group: Nutzer dieser Gruppe sind dazu berechtigt, Objekte, deren Besitzer sie sind, zu verwalten.

Mit Ausnahme der admin-group sind alle anderen Gruppen zunächst leer.

Vordefinierte Gruppen, deren Mitglieder nicht geändert werden können

Die folgenden fünf Gruppen fassen Benutzer nach ihrem Typ zusammen. Der Typ eines Nutzers (anon-user, anon-nick, auth-user) ergibt sich aus seiner Anmeldung. Jeder Nutzer gehört immer zu zwei dieser vordefinierten Gruppen - zur Gruppe aller registrierten Nutzer sowie zu der Gruppe, die für seinen Typ charakteristisch ist. Diesen Gruppen sind keine vordefinierten Berechtigungen zugeordnet. Zu diesen Gruppen können keine Mitglieder, jedoch Berechtigungssätze erzeugt werden.

• anon-nick-group: Diese Gruppe faßt alle anonymen Nutzer mit Nick zusammen.
• anon-user-group: Gruppe aller anonymen Nutzer (ohne Nick).
• auth-user-group: Gruppe aller autorisierten Nutzer, welche über das oben gezeigte Menü erstellt wurden.
• registered-user-group: Diese vordefinierte Gruppe umfaßt alle registrierten Nutzer, die sich mit einem eigenen Passwort anmelden können. Dies ist die gemeinsame Gruppe aus anon-nick-group, anon-user-group und auth-user-group. Erteilt man dieser Gruppe bsp. das Execute-Recht für eine Ausgabeseite, dann kann diese Ausgabeseite nur von registrierten Nutzern aufgerufen werden. Diese Gruppe wurde eingeführt, um in einem solchen Fall nicht für alle drei Standardgruppen einen Berechtigungssatz erstellen zu müssen.
• not-registered-user-group: Zugriffe vor einem Login für unbekannte Leser können gestattet werden, falls dieser Gruppe eine entsprechende Ausführungsberechtigung für eine Ausgabeseite, die Leseberechtigung für eine Tabelle oder die Ausführungsberechtigung für eine Abfrage erhält. Schreibberechtigungen können für nicht registrierte Nutzer nicht erteilt werden.

  Ausgabeseiten für das Login und für die Anmeldung von anonymen Nutzern oder anonymen Nutzern mit Nick müssen immer das Execute-Recht für diese Gruppe gewähren, damit die Seite überhaupt aufgerufen werden kann.

Sicherheit

Leseberechtigung: Für das Lesen der Daten anderer Nutzer ist die 'Nutzer und Gruppen' - Leseberechtigung notwendig. Hierbei sollte berücksichtigt werden, daß die Mailadressen sichtbar sind. Zusätzlich kann jeder interne Nutzer immer seine eigenen Daten in diesem Menü lesen.

Zur Erstellung neuer Nutzer wird wird das Recht 'Nutzer und Gruppen' mit 'Add' benötigt. Das Editierrecht umfaßt nur die Möglichkeit, dem Nutzer eine neue Mailadresse zuzuweisen oder ihn für die internen Masken bzw. global zu sperren. Da der <admin> ein Objekt im Besitz von <server-daten> ist, kann die admin-Mailadresse nicht über dieses Menü geändert werden. Dies ist unter <Eigene Daten> - <Sicherheit> möglich.