Benutzerverwaltung

Sonstige Links

OpenID

Hintergrund

Benutzerverwaltung ist ein schwieriges Thema. Ich brauche das eigentlich seit Jahrzehnten, kam aber bisher nicht dazu, es vernüftig umzusetzen.

Hier notiere ich mir die Ideen / Requirements zu diesem Thema.

Notwendigkeiten

  1. Login: (login)
    Natürlich braucht man einen Login mit Passwort. Anders ist das ja nicht denkbar. Meistens geht es um einen Web-Login. Am Login hängt noch viel mehr als man so denkt:
    1. Benutzername:
      Username (mit oder ohne Leerzeichen)
      Ein vom System zugewiesener Text
      Ein URL (eMail, http: etc.)
    2. Passwort:
      Das klassische Passwort (mit / ohne Beschränkung)
      Ein vom System generierter String (Auth durch URL-Klick) Session-TANs
      Token
    3. Zusätzliche Informationen:
      Name, Adressen, Telefonnummern, das übliche.
      Passwort vergessen Informationen.
      Bemerkungen, sonstiges.
      Generell: Eine erweiterbare Tabelle.
    4. Dynamische Informationen:
      Hier werden dynamische Informationen, wie Sessions, temporäre Rechte etc. angegeben
  2. Rolle: (role)
    Die Rolle ist ein Konzept, das ich als absolut notwendig erachte.
    Ein Benutzer hat im täglichen Leben verschiedene Rollen. Für den Chef ist man ArbeitnehmerIn, für Teammitglieder der TeamleiterIn, am Abend Privatmensch.
    Die Teamleitung aber können mehr als eine Person innehaben.
    Und genau das ist das Rollenkonzept.
    Der Unterschied zum Gruppenkonzept ist, dass man eine Rolle übernimmt, währen man mitglied einer Gruppe ist.
    Es gibt immer mindestens so viele Rollen wie Benutzer.
    An der Rolle hängen folgende Informationen:
    1. Rollenname:
      In Foren ist man typischerweise als Benutzer unterwegs. Aber es gibt auch Administratoren, Moderatoren etc. Manchmal will man nicht als Individuum in Erscheinung treten, sondern muss eine Gruppenentscheidung durchführen. Dadurch wird man persönlich für Dinge angreifbar, die man nicht alleine zu vertreten hat. Das ist schlecht.
      Deshalb wäre es praktischm, in eine Rolle zu schlüpfen. Die anderen Rollenmitglieder können dann einsehen, wer diese Rolle innehatte. Aber niedriger priorisierte Leute können das nicht.
    2. Rollenavatar:
      Das Piktogramm sollte Teil der Rolle sein, nicht des Benutzers
    3. Die Benutzer die diese Rolle verwenden:
      Eine Rolle kann von mehreren Benutzern eingenommen werden.
    4. Zusätzliche Informationen:
      Wie beim Benutzer
  3. Gruppe: (group)
    Die Gruppe und die Rolle sind sehr nahe verwandt. Aber sie sind trotzdem verschieden. Und beide sind notwendig. Beispielsweise wieder in einem Forensystem:
    Man ist als normaler Benutzer unterwegs, kann aber gleichzeitig die Administratorrolle übernehmen. Wenn man nun in einem Forumsbereich, in dem man als Benutzer über keine Rechte verfügt etwas posten will, wechselt man automatisch die Rolle. Sprich, der Benutzer hat eine eine einfache Drop-Down-Liste, mit der er die Rolle wechseln kann die er im jeweiligen Bereich anhand der Rechte einnehmen kann. Ist keine Rolle vorhanden, kann er auch nicht zugreifen.
    Gruppen wechselt man hingegen nicht. Einer Gruppe ist man fest zugehörig oder nicht zugehörig. Eben über die Rolle.
    Das Gruppenkonzept unter Unix ist daher eher ein Rollenkonzept mit jeweils einer Gruppe. Ich kann nämlich die Gruppe wechseln, das entspricht dem Rollenkonzept, aber ich kann zugreifen, das entspricht dem Gruppenkonzept.
    An der Gruppe hängt das übliche:
    1. Gruppenname:
      Jede Gruppe sollte einen eindeutigen, einfach zu merkenden Namen haben.
    2. Gruppenrechte:
      Zugriffserlaubniss und Zugriffsverweigerungen.
      Es wird grundsätzlich "Deny" vor "Allow" ausgewertet. Einfachheit zählt hier.
    3. Rollen die in dieser Gruppe sind:
      Diese Tabelle ist aus Effizienzgründen notwendig (siehe Attribute).
    4. Art der Gruppe:
      Es gibt Gruppen, in die können sich Benutzer selber eintragen.
      Beispielsweise könnte ein Benutzer wünschen, dass er beim Schalten einer Nachricht grundsätzlich die Rolle wechselt. Das ist möglich, indem er sich selber in seiner Rolle die Post-Rechte entzieht.
    5. Gruppenfunktion:
      In der Regel ist die Gruppe statisch.
      Gruppen können funktional sein, also ihren Kontext dynamisch verändern.
      Eine derartige Gruppe ist z. B. "Vordermann auf der Autobahn". Vielleicht will ich ihm die Rechte einräumen, mit mir sprechen zu können.
    6. Attribute:
      Ein typisches Gruppenattribut wären die Rollen die in der Gruppe sind.
      Dies wird aber aus Effizienzgründen anders gehandhabt.
      Ein typisches Attribut einer Gruppe ist der Manager der Gruppe.
      Die Gruppenfunktionen benötigen in der Regel weitere Attribute.
  4. Zugangsrechte: (permissions)
    Dann gibt es eine ganze Hand voll Zugangsrechten. Das ist die Erlaubnis, zuzugreifen. Ein Zugangsrecht hat folgende Eigenschaften:
    1. Rechtename:
      Ein eindeutiger, leicht verständlicher Namen.
      Dieser kann automatisch generiert worden sein, z. B. Dokumentennummer, MD5-Hash etc.
    2. Rechtetyp:
      Leserecht, Schreibrecht, etc.
    3. Rechtefunktion:
      Die Rechte können sich dynamisch verändern. Nur mit statischen Rechten zu rechnen ist oft zu kompliziert.
      Ein typisches dynamisches Recht ist "Zugangsrecht läuft in 15 Minuten ab".
    4. Attribute:
      Wie bei Gruppenfunktionen benötigen die Rechtefunktionen Attribute.
  5. Klassenrechte: (classright)
    Eine Klasse kann in mehreren Zugangsrechten und ein Zugangsrecht in mehreren Klassen sein. Typisch ist die Klasse der Teil, der an einem Dokument hängt und dessen Zugang regelt.
    Dokumente gehören immer exakt einer Klasse an. Sollte die Standardklasse nicht ausreichen, dann muss diese abgeleitet werden.
    Folgende Eigenschaften haben Classrights:
    1. ID:
      Eine eindeutige ID, d. h. Nummer
    2. Name:
      Ggf. (optional!) einen leicht merkbaren Namen
    3. Baseclass:
      Eine Grundklasse von der sie abgeleitet wurden.
      Diese ist rein informationeller Natur.
      Wenn die Baseclass geändert wird kann man so alle abgeleiten Klassen erfahren.
    4. Zugangsrechte:
      Eine Liste von Zugangsrechten.
      Wer dieses hat darf auf das Objekt entsprechend des gegebenen Rechts zugreifen.
      Es gibt keine Negativrechte, sprich man kann hier nichts wieder entziehen.
      Das ist aus Einfachheitsgründen so.
    5. Attribute:
      Diese sind hauptsächlich für Rechtefunktionen da.
  6. Logging:
    Änderungen in den Rechten müssen geloggt werden können. Folgende Fälle sind wichtig:
    1. Zugriff auf ein Dokument (ändern, lesen, etc.):
      Dokument, Benutzer, Rolle, Gruppe, Zugangsrecht, Klassenrecht Es kann mehrere Pfade geben, es wird ein beliebiger Pfad geloggt.
    2. Änderung in den Erlaubnisstrukturen:
      • Änderung in Login, Rolle oder Gruppe
      • Änderung von permanenten Attributen
etc. pp. Hier muss ich noch konkret dran arbeiten.

Datenstruktur

  1. Login, Rolle und Gruppe werden zusammengefasst in einer einzigen Tabelle. Die Unterschiede zwischen den Einträgen wird über die zusätzlichen Informationen abgewickelt.
    1. Jede Zeile hat eine eindeutige Nummer (ID).
    2. Jede Zeile hat einen eindeutigen Namen.
      Das hört sich nachteilig an, ist es aber bei weitem nicht. Denken wir an den Berühmten Administrator unter Windows. In meinem Konzept von mir kann ich ihm den Login entziehen. Damit verschwindet das Passwort und er kann nur noch als Rolle verwendet werden.
      In einem Forensystem kann man dem Administrator z. B. fest die ID 1 geben und muss sich programmtechnisch nichts weiter überlegen, was z. B. passiert, wenn ich den Administrator-Login löschen oder umbenennen will. Ich setze lediglich die Spalte mit dem "c_is_login" auf 0 und lösche ggf. das Passwort aus den zusätzlichen Informationen.
    3. Login ist gleichzeitig Rolle und Rolle ist gleichzeitig Gruppe.
    4. Es gibt dazu ein Feld, das die Werte 3 bis 0 annehmen kann:
      • 3 oder darüber: Login+Rolle+Gruppe
      • 2: Rolle+Gruppe
      • 1: Nur Gruppe
      • 0 oder darunter, bzw. NULL: Deaktivierter Eintrag
    5. Dazu kommt die Gruppenfunktion
  2. Es gibt (NxM) Beziegungen zwischen Login und Rolle und eine zweite zwischen Rolle und Gruppe.
    Die idid-Verbindung (jede Zeile ist in sich enthalten) wird nicht in der jeweiligen Tabelle erfasst, sie ist immer da.
  3. Es gibt mehrere Tabellen mit zusätzlichen Informationen bzw. Attributen.
    • ID der Tabelle auf die sich die Daten beziehen.
      Zusammen mit den nächsten drei Feldern ist es der Primärschlüssel.
    • Herkunft (Tabelle auf die sich die ID bezieht)
    • Attributstyp (siehe andere Tabelle)
    • Folgenummer des Attributs
      Das ist ein Zähler, so kann man die Informationen indizieren oder mehrere Zeilen erfassen oder mehrere Alternativen.
      Beim Passwort kann es z. B. die Passworthistorie sein.
    • Textfeld bzw. Integerfeld bzw. Fliesskommafeld mit dem Inhalt.
      Einige Datenbanken können mit NULL Werten nicht ordentlich umgehen, diese machen indizierte Zugriffe oft zu Tablescans. Insbesondere beim Sortieren bereitet das Schwierigkeiten. Deshalb gibt es 3 oder mehr Tabellen, je nach Datentyp des Attributs.
  4. Tabelle mit den Attributstypen:
    • ID, Name des Attributs, Datentyp des Attributs (ascii), evtl. Grenzwerte etc. (Applikationsabhängig)
    • Der Datentyp benennt die Attributstabelle direkt, d. h. wenn die Attributstabelle "t_attr_" heisst und der Datentyp "asc" ist, dann wird auf das Attribut als "t_attr_asc" zugegriffen.
  5. Zugangsrechte sind eine einfache Tabelle:
    ID, Rechtename, Rechtetyp, Rechtefunktion
  6. Dazu kommt die NxM-Tabelle von Gruppe und Recht
    Zusätzlich ist ein Allow/Deny-Flag enthalten.
    Man kann nicht Allow und Deny gleichzeitig in einer Gruppe setzen.
  7. Zusätzlich kommen die Klassenrechte hinzu:
    ID, Name, Basisklasse
  8. Dazu kommt die NxM-Tabelle zwischen Zugangsrecht und Klassenrecht.
  9. Dynamische Informationen werden so verarbeitet wie es sein muss. Dafür kann es beliebig viele weitere Tabellen geben.
    Dynamische Informationen enthalten immer die ID der Login/Rollen/Gruppen-Tabelle, nicht den Namen.
Das war's schon.

Zusammenfassung

Die Idee hinter dem ganzen, ist es einfach verständlich zu machen, und ausserdem leicht für den Computer umsetzbar zu gestalten.

Ich logge mich irgendwo ein, bekomme eine oder mehrere Rollen zugeteilt, befinde mich so mehr oder weniger Automatisch in bestimmten Gruppen die bestimmte Rechte haben. Diesen Rechten ordne ich die Dokumente zu und ich kann zugreifen.

Dabei ist das Zugangsrecht das entscheidende Recht. Ein Administrator der alle Rechte besitzen darf, kann beispielsweise ein Zugangsrecht haben, das keine Klassenrechte beachtet.

Es kann Rollen geben die keine Gruppe haben und Gruppen, die keine Rollen haben.

Technisch ist das ganze so einfach aufgebaut, wie es geht. Einige Tabellen sind da, werden aber gar nicht benötigt (z. B. Tabelle der Klassenrechte). Viele Tabellen können fest verdrahtet sein, typischerweise die der Attributstypen. Allerdings müssen sie zur Kompatibilität vorhanden sein, damit man eine generelle Benutzerverwaltung implementieren kann.

Mein Ziel ist es, generelle Adapter zu schaffen, so dass man andere Benutzerverwaltungsschemata auf dieses anpassen kann. In der einfachsten Form bedeutet das Synchronisation, d. h. es werden die Daten nicht integriert, sondern die vorhandenen Tabellen mit dem Benutzer-Schema der anderen Anwendung synchronisiert.

Ich habe darauf geachtet, dass man das Unix- und Windows-Schema relativ leicht abbilden kann. Allerdings ist hier die Vererbung im Filesystem nicht enthalten. Dies wäre in einer Applikations-Logik abzubilden, d. h. die übergeordneten Zugriffsrechte in einer geeignet abgeleiteten Klasse unterzubringen.

Umsetzung

  1. User loggt sich mit Passwort ein:
    • Zugriff auf die Haupttabelle, ermitteln des Passwort-Attributs, Passwort prüfen.
    • Dynamisches Attribut (Session) hinzufügen.
    • Standard-Rolle des Benutzers aktivieren (Attribut).
  2. User greift zu:
    Diese Auswertung lässt sich dank MIN/MAX über ein einziges SQL abwickeln.
    • Klassenrecht des Zugriffs ermitteln.
    • Rollen vom User ermitteln.
    • Gruppen der Rollen ermitteln.
    • Gruppenweise durcharbeiten:
      • Idealerweise fängt man mit der Gruppe der aktiven Rolle an.
      • Zugangsrechte der Gruppe ermitteln
      • Dabei die Typen des Zugangsrecht verwerfen, die dem gewünschten Zugang nicht entsprechen
      • Ist ein Recht mit Deny dabei, diese Gruppe verwerfen.
      • Ist ein Recht mit Allow dabei, dann die Gruppe (und evtl. die Rechte) merken.
    • Bleibt keine Gruppe mehr übrig, Zugang verweigern.
    • Blieb eine Gruppe übrig die der aktiven Rolle gehört, Zugang in aktiver Rolle gewähren.
    • Anderenfalls den Benutzer informieren, dass die Rolle gewechselt wurde. (Evtl. Rolle automatisch gemäß preferenzen des Users wechseln.)
    • Zugang gewähren.
  3. Veränderung der Rechte
    Hieran muss ich noch arbeiten, ist diffizil.