Tim Jansen's Blog (deutsch)


2003/06/17
Wie geht es weiter mit Knot nach SLP?


Bin mir nicht mehr ganz so sicher, ob ich nach dem SLP Teil fuer Knot wirlich mit SIP weitermachen soll. Ich habe ein paar nette Ideen fuer ein Authentifizierungssystem auf Kerberos-Basis mit Offline-Authentifizierung. Es würde aus zwei Teilen basieren, die im Knot-Framework laufen, allerdings aus Sicherheitsgründen in eigenen Prozessen. Zum einen der Kerberos Server (KDC & TGS), der mittels wie Heimdal und andere die Passwörter verwaltet, die ich in OpenLDAP speichern würde. Teil 2 beinhaltet den Kerberos-Client (der sonst als Library implementiert ist) und die Offline-Funktionalitäten.


Ein Notebook würde, solange es seinen Server erreichen kann, ganz normal alle User per Kerberos authentifizieren. Der Spass aber fängt an, wenn der User sein Notebook mitnimmt und der Kerberos-Server nicht mehr erreichbar ist. Für diesen Fall würde der Client Kerberos-Daten cachen, so dass der Besitzer sich ohne Administrationsaufwand (wie das Anlegen lokaler Benutzer) jederzeit einloggen kann.


Der zweite Offline-Anwendungsfall ist, wenn zwei Benutzer verschiedener Notebooks unterwegs Daten austauschen wollen. Dazu würde der Knot auf Notebook A eine Anfrage zum Knot B schicken, dass Benutzer X sich gerne einloggen wuerde. Auf B muss der dortige Benutzer Y diesem zustimmen. Daraufhin erzeugt B einen Public Key fuer X und schickt A den Private Key. Solange A/X diesen hat (und das Zertifikat nicht auslaeuft oder Y ihn sperrt), kann Benutzer X auf Notebook B mit seinem normalen Account zugreifen. Hoffentlich lässt sich das per GSSAPI abbilden... Wenn A und B normalerweise mit demselben Kerberos Server kommunizieren, kann die Identität von X zusätzlich noch durch eine Signatur bewiesen werden.


Von den beiden Offline-Fällen abgesehen gäb es noch ein paar andere netter Sachen, zB das Finden von Kerberos-Servern per SLP (was flexibler ist als DNS).


Zusammen mit den nötigen Administrationstools wäre ich damit problemlos deutlich über 6 Monate beschäftigt... dazu kaemen noch Kleinigkeiten, wie ein sicherer Abgleich der Zeit (vielleicht die groesste Schwäche derzeitiger Kerberos-Installationen).


Dafür waere die Kombination SLP+(Offline-)Kerberos+LDAP eine Kombination, mit dem man ActiveDirectory nicht nur Konkurrenz machen könnte, sondern es noch übertreffen.




2003/06/12
Die Zukunft der KDE APIs


Ein Problem, das ich mit dem Schreiben von KDE Bibliotheken derzeit habe, ist das ich nicht weiss, wie zukunftssicher diese sind. Die Chancen stehen recht gut, dass ich meine Software in 5 Jahren bedenkenlos in C# (mittels DotGnu und Mono) oder Python schreiben kann. Nur brauche ich auch dafür einen Desktop und diverse andere Bibliotheken. Es kann weder erstrebenswert sein, bis zum Ende der Zeit auf C++ festgelegt zu sein, noch für jede Programmiersprache einen neuen Desktop zu schreiben. Das halb-manuelle Schreiben von Wrappern ist viel Arbeit und schon allein deswegen sind die Wrapper praktisch nie komplett. Was benötigt wird, und das möglichst schon für KDE 4, ist die Möglichkeit mit anderen Sprachen ohne manuelle Arbeit auf C++ Bibliotheken zuzugreifen. Es gibt verschiedene bestehende Ansätze, beispielsweise XPCOM und die Benutzung von QObject Slots, wie QSA es macht. Alle bestehenden Möglichkeiten haben aber genug Nachteile, um sich in der KDE Welt nicht für alle APIs durchzusetzen. Meine derzeitige Hoffnung liegt auf TrollTech, denen es wohl kaum entgehen kann, dass der C++ Markt schrumpfen wird (wenn er es nicht bereits tut) und hoffentlich so etwas dagegen tun.


Mit der Sprachenunabhängigkeit kommt auch die Notwendigkeit, die kdelibs und Qt besser zu unterteilen und strukturieren. Klassen wie KSharedPtr, QRegExp und QValueList werden von anderen Sprachen nicht gebraucht, mal davon abgesehen, dass man Templates nicht in sprachenunabhängigen APIs benutzen kann. Viele Dinge wie Netzwerkzugriffe erledigt man besser mit der Standardbibliothek der jeweiligen Sprache. Andere könnte man zwar mittels einer gemeinsamen API benutzen, sind aber besser nativ zu implementieren, zB kann DCOP in die Remoting-Architektur der C# CLR eingebaut werden.


Dazu kommt bereits jetzt, dass es für Qt-basierte Server wie Knot mehr als nützlich wäre, wenn die GUI vom Rest getrennt wäre. Bevorzugen würde ich eine Lösung, wie ich sie jetzt für die GStreamer-Bindings und Knot benutze, mit C++ Namespaces unterhalb von KDE (zB KDE::UI, KDE::Core etc). Das würde hoffentlich die Navigation durch die APIs vereinfachen und Konflikte vermeiden, wenn man die nativen Bibliotheken der jeweiligen Sprachen mit KDE APis zusammen benutzt.




2003/06/11
Ok, die Registrierung uebersteht er nun auch...



krfb laeuft mit knot, aber nur bis zur ersten Registrierung. Zumindest bin ich wieder dran...




2003/06/01
Habe einen Bug in der OpenSLP kompatiblen API vom Knot gefixt und die Dokumentation erweitert. Es gibt noch einen weiteren Bug, weswegen krfb sich nicht richtig registriert. Hoffe diesen auch noch loszuwerden, bevor ich die Woche in Mainz verbringe und vor Freitag nicht weitermachen kann.

Von der NX Library ist noch nichts zu sehen.



This page is powered by Blogger. Isn't yours? Creative Commons License
All text in this blog is licensed under a Creative Commons License.
(Images containing screenshots etc are excluded)