/blog/wvk

Soo, nach der Einführung in die oberflächliche Funkionsweise des Loginprozesses unter Consolvix kann nun erst der richtige Spaß anfangen, denn: Ob der Benutzer sich einloggen darf, hängt von einer ganzen Reihe an Faktoren ab, nicht nur ob er sein Kennwort richtig eingegeben hat!

Beispiele:

• ist das Benutzerkonto an sich gesperrt?
• ist das Benutzerkennwort abgelaufen?
• verfügt der Benutzer über ausreichende Rechte, um das verlangte Consolvix-Modul zu verwenden?
• verfügt der Benutzer über ausreichende Rechte, um diese Aktion aufzurufen?
• befindet sich das System im Wartunsgmodus? (dann sind nur Administratorlogins erlaubt)
• ...

Mein Ziel ist es, nämtliche Zugriffsberechtigungsfragen an ein austauschbares Authoriser-Modul zu binden. Beispielsweise existieren bislang Auth::Authoriser sowie AuthPam::Authoriser. Ersteres Modul verwendet direkt die auch vom System verwendeten MySQL-Tabellen, und ist gleichzeitig fester Bestandteil des Kernmoduls con Consolvix. Das davon abgeleitete Modul AuthPam::Authoriser verwendet die Ruby/PAM Bibliothek um direkt auf die PAM-Schnittstelle des Betriebssystems zugreifen zu können. Da mein System ja aber die gleichen MySQL-Tabellen verwendet wie sie Consolvix verwalten soll (was ja überhaupt erst die Sinnhaftigkeit meiner Diplomarbeit ausmacht ;-)), ist damit noch nichts gewonnen. Doch wer weiß, wie sich Consolvix noch entwickeln wird...

Das Authoriser-Modul gibt auf die allgemeine Frage "Darf dieser Benutzer das?" eine Ja/Nein-Antwort. Momentan lautet sie genau dann "Ja", wenn das Kenwort richtig, das Konto aktiv und das Kennwort nicht abgelaufen ist. Ich arbeite an einer ausgefeilteren Authentifizierung und Autorisierung, die nach dem gleichen Muster wie PAM aufgebaut ist (es soll ja auch später PAM als Autorisierungsquelle verwendet werden können). Die PAM-API liefert hier eine schöne Referenz für ein mächtiges Zugriffsgegelwerk, bestehend aus folgenden Methoden:

1. authenticate: Authentifizierung -- hier: Stimmt das Kennwort (aus HTTP, POST oder Session)?
2. set_credentials: laden von Gruppenzugehörigkeiten, Zugriffsrechten etc.
3. account_management: Überprüfung, ob das Konto verfügbar ist -- Je nach dem, was diese Methode zurück liefert, können verschiedene Aktionen nötig sein. Ein Beispiel wäre eine Auffurderung, ein neues Kennwort zu setzen. Ein anderes, den Login-Vorgang komplett abzubrechen (z.B. weil Login derzeit nicht möglich/erlaubt). Momentan wird bei "active" fortgefahren, ansonsten einfach eine entsprechende Fehlermeldung ausgegeben und zum Login redirected.
4. open_session: Hier kommt alles rein, was zu Beginn der autorisierten Sitzung abgefackelt werden sollte. Ein Beispiel wäre das Setzen des Benutzerobjektes und seiner Gruppen in den Kontext des Controllers (vorher existiert dieses nur im Kontext des Authorisers)
5. close_session: alles, was am Ende einer Sitzung (hier vermutlich eher im Sinne einer Aktion/eines Seitenaufrufs als im Sinne der Cookie-basierten Session, aber das muss ich noch evaluieren) bereinigt und gespeichert werden soll. Momentan wird einfach das Benutzerobjekt auf nil gesetzt
6. change_authentication_token: vereinfacht ausgedrückt: Setze neues Kennwort. Mit Iris-Scans und Smartcards werde ich wohl nicht sooo viel zu tun haben :)

Der Standard-Authoriser kann bislang alle Benutzer aus der users-Tabelle authentifizieren, wobei es keine Rolle spielt ob das Kennwort mit UNIX-crypt (also DES), MD5-crypt, Blowfish-crypt oder Plaintext gespeichert ist. Beim Login wird an Hand von RegExps versucht, festzustellen wie das Kennwort gehashed wurde und ggfs das Salt extrahiert. Anschließend wird damit das eingegebene Kennwort gehashed und mit dem wert aus der Tabelle verglichen. Beim Setzen neuer Kennwörter (set_credentials) wird auf die Applikationseinstellung core::passwordhashmethod zurückgegriffen um die hash/crypt-Methode zu bestimmen.

Wenn mein Umbrello nun mitspielt werde ich ein kleines Klassendiagrämmchen von dem ganzen Auth*-System basteln, ansonsten wird's langsam Zeit, schlafen zu gehen.

Tatsache, es hat geklappt :)