User-Login Absicherung: Unterschied zwischen den Versionen

Aus Physik
Zur Navigation springen Zur Suche springen
Zeile 60: Zeile 60:
 
* Im Formular musste das Wiki als aktiv deklariert werden, obwohl eigenlich nicht das ganze Wiki läuft => Hackalarm!
 
* Im Formular musste das Wiki als aktiv deklariert werden, obwohl eigenlich nicht das ganze Wiki läuft => Hackalarm!
 
* User hat nach wie vor extra Registrierungsdaten für das Wiki
 
* User hat nach wie vor extra Registrierungsdaten für das Wiki
  +
  +
  +
== Externes Formular auf Kerberos-geschützter Seite mit Childklasse von AuthPlugin.php ==
  +
  +
Man kann eine Childklasse von AuthPlugin.php auch extern verwenden, siehe [http://wiki.case.edu/CaseWiki:External_Authentication diese Anleitung]
  +
  +
Dies wäre im Prinzip wie die oben geschilderte Variante, nur eleganter und die Sache mit dem Passwort dürfte funktionieren.
  +
   
 
== Authentifizierung über gssapi/kerberos ==
 
== Authentifizierung über gssapi/kerberos ==
   
 
Childklasse von AuthPlugin.php, bei der sich der Benutzer über gssapi od. direkt über kerberos authentifiziert.
 
Childklasse von AuthPlugin.php, bei der sich der Benutzer über gssapi od. direkt über kerberos authentifiziert.
 
Siehe auch [http://wiki.case.edu/CaseWiki:External_Authentication eine ganz nette Anleitung]
 
   
 
'''Vorteile'''
 
'''Vorteile'''
Zeile 80: Zeile 86:
 
* (Vielleicht) eigenes php-Paket notwendig, dass am Server installiert werden muss, um die Lösung sauber zu halten.
 
* (Vielleicht) eigenes php-Paket notwendig, dass am Server installiert werden muss, um die Lösung sauber zu halten.
   
  +
== Authentifizierung über IMAP ==
 
  +
== Authentifizierung über IMAP (AuthPlugin) ==
 
Childklasse von AuthPlugin.php, bei der sich der Benutzer über IMAP authentifiziert.
 
Childklasse von AuthPlugin.php, bei der sich der Benutzer über IMAP authentifiziert.
  +
 
'''Vorteile'''
 
'''Vorteile'''
 
* siehe oben, nur muss man sich immer authentifizieren, auch wenn mann schon ein Ticket hat
 
* siehe oben, nur muss man sich immer authentifizieren, auch wenn mann schon ein Ticket hat
Zeile 87: Zeile 95:
 
'''Nachteile'''
 
'''Nachteile'''
 
* wechselseitige Abhängigkeiten ;-)
 
* wechselseitige Abhängigkeiten ;-)
  +
   
 
== Anbindung ans PHPBB ==
 
== Anbindung ans PHPBB ==
Zeile 100: Zeile 109:
   
   
== Authentifizierung über IMAP ==
+
== Authentifizierung über IMAP (PHPBB-Extension) ==
   
 
Gleiches Prinzip wie bei der PHPBB-Extension, allerdings wird am IMAP Server des ITP nach dem User gesucht.
 
Gleiches Prinzip wie bei der PHPBB-Extension, allerdings wird am IMAP Server des ITP nach dem User gesucht.

Version vom 16. Oktober 2005, 13:10 Uhr

Problem

Als jeder Seiten editieren konnte wurden Wiki-Seiten durch Linksammlungen ersetzt.

Als Zwischenlösung dürfen nur angemeldete User editieren und das Registrieren neuer User ist derzeit nicht möglich.


Ziel

Auf jeden Fall soll das Lesen weiterhin für alle möglich sein.

Minimal:

Das automatisierte Erstellen von User-Accounts soll unterbunden werden

Optimal:

  • Nur angemeldete User dürfen editieren.
  • User-Authentifizierung mit Kerberos.
  • (Möglichst) Keine Änderung im Wiki-Code

Das bedeutet

  • Wer ein Kerberos-Ticket erhält, darf sich auch im Wiki anmelden
    • => Nur wer ein Computerraum Account hat kann sich anmelden
  • Benutzer brauchen sich kein weiteres Passwort zu merken


Lösungsansätze

Formular mit Absicherung gegen automatische Eingaben

Ein Formular für die Registrierung neuer User wird mit irgendeinem Mechanismus vor automatischen Eingaben geschützt. Siehe Anmeldung bei PHPBB!

Vorteile:

  • (vermeindlich) schnelle Lösung
    • Vielleicht Code aus PHPBB verwendbar

Nachteile

  • Nur Absicherung gegen automatische Eingaben


Externes Formular auf Kerberos-geschützter Seite

Formular für die Registrierung neuer Benutzer auf einer externen Seite, auf welcher man sich über Kerberos authentifizieren muss.

Der erste, schnelle Versuch; beinahe ausprogrammiert.

Die Technologie zur Absicherung einer Seite gibt es bereits, das Formular wurde so programmiert, dass jene Klassen, die im Wiki verwendet werden, auch hier benutzt werden. Mit dem Formular ist es möglich einen neuen User in die DB einzutragen, allerdings gibt es ein Problem mit dem eingegebenen Passwort, so dass sich der neue User damit nicht anmelden kann. Jedoch kann er sich bei der Wiki-Anmeldeseite ein neues Passwort zusenden lassen, mit dem die Anmeldung dann möglich ist.

Mögliche Fehlerursache: Variable für die Codierung des Passwortes nicht korrekt, da das Wiki ja nicht wirklich läuft?

Ein Verzicht auf die Wiki-Klassen dürfte recht umständlich werden. Der direkte Zugriff auf die DB funktioniert zwar, (wurde getestet) jedoch müsste trotzdem eine Variable aus dem Wiki geholt werden um das Passwort korrekt zu verschlüsseln. Außerdem dürfte es recht kompliziert werden z.B. die User-Einstellungen richtig einzutragen, da diese in einem Blob stecken, welcher erst richtig zusammengebaut werden müsste.

Vorteile:

  • (vermeindlich) schnelle Lösung
  • keine Änderung im Wiki

Nachteile

  • Passwort in die DB eintragen funktioniert nicht so ganz => etwas umständlichere Handhabung für den User
    • dies wäre aber auch ein zusätzlicher Sicherheitsaspekt, der aber unnötig sein sollte, da die Seite bereits über Kerberos abgesichert ist
  • Zugriff auf die Wiki-DB von außen
  • Im Formular musste das Wiki als aktiv deklariert werden, obwohl eigenlich nicht das ganze Wiki läuft => Hackalarm!
  • User hat nach wie vor extra Registrierungsdaten für das Wiki


Externes Formular auf Kerberos-geschützter Seite mit Childklasse von AuthPlugin.php

Man kann eine Childklasse von AuthPlugin.php auch extern verwenden, siehe diese Anleitung

Dies wäre im Prinzip wie die oben geschilderte Variante, nur eleganter und die Sache mit dem Passwort dürfte funktionieren.


Authentifizierung über gssapi/kerberos

Childklasse von AuthPlugin.php, bei der sich der Benutzer über gssapi od. direkt über kerberos authentifiziert.

Vorteile

  • Am einfachsten für den Benutzer, gleiche Logindaten wie itp-account
  • Sicherheit über SSL genügt
  • Konsistente Lösung
  • Keine Änderungen am Wiki
  • Keine zweite Benutzerdatenbank
  • Keine Eingriffe in die WikiDB - Auf neue mediawiki-Versionen sollte nicht reagiert werden müssen
  • Beim Einsatz eines "kerberosfähigen"-Browsers (z.B. Firefox, Mozilla) kein Einloggen des Benutzers nötig, wenn die Klasse schön programmiert wird

Nachteile

  • gssapi php Anbindung muss teilweise selber geschrieben werden bzw. aus dem Source der IMAP-php Klassen geholt werden.
  • (Vielleicht) eigenes php-Paket notwendig, dass am Server installiert werden muss, um die Lösung sauber zu halten.


Authentifizierung über IMAP (AuthPlugin)

Childklasse von AuthPlugin.php, bei der sich der Benutzer über IMAP authentifiziert.

Vorteile

  • siehe oben, nur muss man sich immer authentifizieren, auch wenn mann schon ein Ticket hat
  • sehr einfach zu schreiben, da php schon alles mitbringt (Ein 10-Zeiler)

Nachteile

  • wechselseitige Abhängigkeiten ;-)


Anbindung ans PHPBB

Hier gibt es eine Mediawiki Extension, mit welcher in der Userdatenbank des Forums nach dem User gesucht wird. Ist ein User, der sich anmelden will, nicht in der Wiki-DB, wird jedoch in der PHPBB-DB gefunden, so wird er auch in die Wiki-DB eingetragen und angemeldet

Vorteile:

  • Extension ist bereits programmiert

Nachteile

  • Kopplung ans PHPBB
  • Nicht jeder Computerraum-Nutzer hat auch ein PHPBB-Account


Authentifizierung über IMAP (PHPBB-Extension)

Gleiches Prinzip wie bei der PHPBB-Extension, allerdings wird am IMAP Server des ITP nach dem User gesucht.

Vorteile:

  • Einfache Programmierung
    • PHPBB-Extension kann als Basis verwendet werden
    • In PHP ist die IMAP - Unterstützung bereits vorhanden
  • Jeder User mit Computerraum-Account kommt ins Wiki

Nachteile

  • Kopplung an den IMAP Server


Authentifizierung über Kerberos 1 - Ticket anfordern

Das Wunschziel!

Auch hier kann die PHPBB-Extension als Ausgangspunkt verwendet werden. Das Problem bei dieser Methode ist, dass noch kein Weg gefunden wurde, wie man aus PHP heraus ein Kerberos-Ticket anfordert.

Vorteile:

  • Authentifizierung direkt über Kerberos
  • PHPBB-Extension kann als Basis verwendet werden

Nachteile

  • keine schnelle, leichte Lösung in Sicht.


Authentifizierung über Kerberos 2 - Kontaktaufnahme mit dem Server

Das Wunschziel?

Auch hier kann die PHPBB-Extension als Ausgangspunkt verwendet werden. Die Idee ist, das PHP-Modul KADM5 zu verwenden. Dieses stellt Funktionalitäten zur Verwaltung eines Kerberos Servers zur Verfügung. Damit kann u.A. nach Principals gesucht werden:

 kadm5_get_principal  -- Gets the principal's entries from the Kerberos database
 kadm5_get_principals -- Gets all principals from the Kerberos database

Allerdings kann man damit keine Passwortüberprüfung vornehmen.

Mit

 kadm5_init_with_password -- Opens a connection to the KADM5 library and initializes any neccessary state information

könnte man vielleicht tricksen: Man versucht mit Principal und Passwort eine Verbindung zum Kerberos-Server herzustellen, stimmen die Daten nicht, liefert die Funktion FALSE. Allerdings muss erst versucht werden, ob das für alle Kerberos-User geht oder nur für Admins.

Die Verbindung kann dann sofort wieder geschlossen werden.

Vorteile:

  • Kerberos wird verwendet
  • Einfache Programmierung
  • PHPBB-Extension kann als Basis verwendet werden

Nachteile

  • Keine weiteren Userdaten abrufbar
    • User muss Emailadresse und Realname selbst eintragen (kann ja höflich darauf hingewiesen bis dazu gezwungen werden)
  • Sicherheit??


Stand der Dinge

Externes Formular auf Kerberos-geschützter Seite ist teilweise implementiert. Das Formular liegt noch nicht auf einer geschützten Seite, außerdem funktioniert das Speichern des Passwortes nicht.

Die schnellste Möglichkeit dies fertigzustellen wäre, die Passworteingabe aus dem Formular zu nehmen und den User zu bitten sich ein neues Passwort schicken zu lassen.

Ein wenig aufwändiger wäre es, dem User ein zufällig generiertes Passwort automatisch zu schicken.

Alle weiteren Varianten sind noch in der Planungsphase.


Allgemeines

Vorgangsweise beim Einloggen:

Zuerst in der Wiki-DB oder "auswärts" nach dem User suchen?

Problem: (bei zuerst Wiki-DB)

  • User können ihr Wiki-Passwort ändern. Er/Sie ist dann zwar selbst schuld, hat aber erst wieder mehrere Passwörter
  • Werden Computerraum-Accounts gelöscht, so ist die Wiki-DB davon nicht betroffen

Abhilfe: Beides überprüfen, nur wer ein Computerraum-Account hat darf rein.

"Ungültige" Wiki-User automatisch löschen lassen (Überprüfung auf Computerraum-Account reicht nicht - z.B. Admins)?