oberon index <- ^ -> mail ?
Weiter: Namensräume, davor: Realisierung, darüber: Autorisierungsprotokolle.

Weitere Implementierungen von Shards

Standardlösung

Die trivialen Implementierungen, die das Basismodul anbietet, nützen offensichtlich keineswegs alle Möglichkeiten aus, die im Protokoll vorgesehen sind. Für eine sinnvolle -- d.h. in erster Linie überhaupt stattfindende -- Überprüfung der Zusammengehörigkeit bedarf es eines Topf- und Deckeltyps mit einem gewissen Maß an Individualität. Shards-Objekte mit dieser Eigenschaft implementiert das kleine Modul PrivateShards.

Ideal wäre eine unerschöpfliche Quelle immer neuer Topf-Individuen, von denen keine zwei denselben Deckel akzeptierten, und von Deckeln, die jeweils auf genau einen dieser Töpfe paßten. Ein auf einem Computer ablaufendes Programm, das selbst keine Identität und zudem nur eine begrenzte Menge von Unterscheidungsmerkmalen zur Verfügung hat, kann diese Idee natürlich nur ansatzweise verwirklichen. Immerhin läßt sich die Wahrscheinlichkeit ungewollter Übereinstimmungen mit etwas Heuristik auf einen für praktische Belange vertretbar kleinen Wert drücken: Eine Sequenz von Pseudozufallszahlen, die unter Einbeziehung von Variablen wie Datum und Uhrzeit, Prozeßnummer, Netzwerkadresse, Hardware-Seriennummern usw. initialisiert wird, hat nur ein geringes Risiko, systematisch in verschiedenen Programmläufen übereinzustimmen; eine ebenso "zufällig" initialisierte, dann aber fortlaufende Nummer für Objektinstanzen sorgt zudem dafür, daß jedenfalls innerhalb eines Prozesses so rasch keine Wiederholung möglich ist.

Dieses Codefragment zeigt, wie einfach die Methode Fits für Töpfe und Deckel mit einem "genetischen Code" auf dieser Basis zu implementieren ist.

Bemerkung: Ob jemand in Australien den gleichen Hausschlüssel wie Herr X aus Ulm benutzt, ist nicht wichtig; daß die beiden verschiedene Kreditkartennummern haben, dagegen schon. -- In Fällen, in denen es wirklich auf absolute Eindeutigkeit ankommt, bedarf es zusätzlicher Maßnahmen. Letztlich kann nur durch irgendeine Form der Koordination die theoretisch geforderte Sicherheit erreicht werden. (Diese muß nicht unbedingt zur Laufzeit erfolgen. Beispielsweise profitieren Netzwerke, in denen jeder Teilnehmer eine konstante eindeutige Identifikation besitzt, von einer vorher erzielten Einigung auf administrativer Ebene). Ein geeigneter Koordinationsmechanismus wird im nächsten Kapitel im Zusammenhang mit dem Modul UniqueNames vorgestellt.

Zusätzliche Anforderungen

Mit der bisher besprochenen Funktionalität werden schon sehr viele Anwendungsmöglichkeiten abgedeckt. Ein typisches Objekt, das in das Autorisierungsschema eingebunden ist, wird eine oder mehrere private Pot-Komponenten besitzen und seine sensiblen Methoden mit je einem Lid-Argument versehen, das zu Beginn jeder Methode am entsprechenden Gegenstück geprüft wird. Folgende Optionen stehen ihm nun offen:

Ein nützliches Autorisierungssystem sollte jedoch noch weiteren Ansprüchen gerecht werden. Neben der bereits angesprochenen Zuverlässigkeit des Prüfkriteriums ist hier vor allem die Sicherheit gegenüber verschiedenen Arten des Mißbrauchs zu nennen. (Die folgenden Überlegungen beschränken sich grundsätzlich auf Angriffe von außen, d.h. aus einem anderen Prozeß. Auf Programme, die sich selbst attackieren wollen, erstreckt sich das hier vorausgesetzte Verständnis des Begriffs "Mißbrauch" nicht).

Objekte werden dann für die Außenwelt sichtbar, wenn sie Kommunikationskanäle benutzen. Persistente Objekte können dabei auch im ganzen zu einer neuen Lokation kopiert werden, und wer auch immer diese Daten empfängt, kann dadurch funktionsfähige Kopien der betreffenden Objekte erhalten. Insofern ist es einleuchtend, daß gerade Objekte, die gewisse Berechtigungen repräsentieren, tunlichst nur die richtigen Adressaten erreichen sollten.

Zu diesem Zweck empfiehlt sich der Einsatz kryptographischer Methoden: Die zu übertragenden Daten können so verschlüsselt werden, daß nur ein bestimmter Empfänger sie entschlüsseln kann, der wiederum in der Lage ist, den Absender und die Unversehrtheit der Nachricht eindeutig zu verifizieren. Ein public-key-Verfahren ist besonders zweckmäßig, wenn zu keinem Zeitpunkt ein "sicherer" Übertragungsweg für Klartext zur Verfügung steht. Ferner können durch die Verwendung sogenannter Falltürfunktionen Töpfe und Deckel so konstruiert werden, daß es praktisch unmöglich ist, bei Kenntnis nur eines der beiden Teile den anderen zu rekonstruieren. Zum dritten kann nicht nur beim Versenden der Objekte, sondern gerade auch in dem Moment, wo sie kommunizieren (d.h. beim Prüfvorgang), ein gegen Abhören und Stören gesicherter Dialog verwendet werden. Eine Implementierung dieser Techniken in Oberon behandelt [Szczuka95].

Spezialfälle

Eine Reihe verschiedener Aufgaben läßt sich sehr gut mit geeigneten speziellen Implementierungen der Abstraktion Shards lösen. Das soll zum Abschluß dieses Kapitels durch einige Beispiele illustriert werden.

Eine erste Gruppe der Spezialisierungen zeichnet sich durch Variationen hinsichtlich dessen aus, was genau getestet werden soll. Das kann zum Beispiel die einfache Frage sein, ob die Funktion Fits in demselben Prozeß aufgerufen wird, in dem auch der kontrollierende Topf lebt. Diese Frage stellt sich in Situationen, wo bestimmte Dinge zwar von außen sichtbar sind, etwa weil sie in prozeßübergreifend vernetzten Datenstrukturen erscheinen, aber nur intern manipuliert werden können sollen. Eine zuverlässige Antwort hierauf liefert das Modul VolatileShards mit Hilfe eines kleinen Tricks, der gleichzeitig den Namen erklärt: Ein Deckel, der als (vermeintlich) persistentes Objekt auf die Reise geschickt wird, kommt stets in leicht veränderter Form auf der anderen Seite an.

Dieses Codefragment zeigt alles Wesentliche der Realisierung des Moduls VolatileShards. Typspezifische Schreib- und Leseprozeduren werden hier nicht gebraucht. Zu beachten ist, daß in keinem der Konstruktoren die Funktion NEW verwendet wird, da sich die relevante Information problemlos in einer konstanten Zahl von Objekten unterbringen läßt.

Als weitere Vertreter auf bestimmte Tests spezialisierter Implementierungen seien noch genannt: TransientShards, ein Modul, das es erlaubt, Töpfe oder Deckel mit einem definierten Verfallsdatum auszustatten; SemaphoreShards -- hier berücksichtigt jeder Topf den Zustand eines ihm zugeordneten Semaphors; und CompositeShards, ein Modul, mit dem man vorhandene Töpfe mit verschiedenen logischen Verknüpfungen zu neuen zusammensetzen kann.

Eine andere Gruppe bilden Implementierungen, deren Objekte auf eine besondere Art der Handhabung ausgelegt sind. So zeichnen sich z.B. PasswordShards dadurch aus, daß Töpfe und Deckel völlig unabhängig voneinander, parametrisiert nach einer Zeichenkette hergestellt werden können. Sie passen dann zusammen, wenn ihre Zeichenketten übereinstimmen. RemoteShards schließlich machen Töpfe und mithin Autorisierungskontrollen fernsteuerbar.

Ausblick

Mit diesen Beispielen sind die denkbaren Konkretisierungen der vorgestellten Abstraktion Shards durchaus noch nicht ausgeschöpft. Jeder neue Anwendungsfall kann eine neue Sichtweise auf die Verwendungsmöglichkeiten eines Protokolls auslösen und auch neue konkrete Ausprägungen motivieren. Der Abstraktion selbst fällt die wichtige Rolle als gemeinsame Basis und Verständigungsgrundlage für unterschiedlichste Weiterentwicklungen einerseits und zahlreiche sich ebenfalls ausdifferenzierende Einsatzbereiche andererseits zu. Um eine solche Rolle angemessen erfüllen zu können, muß sie gut gewählt sein: so einfach wie irgend möglich -- primitiv in des Wortes bester Bedeutung -- und dennoch den Kern einer Sache treffend, eine brauchbare Ausdrucksmöglichkeit schaffend. James White, der in den siebziger Jahren neue Protokolle für das ARPANET [White76] entwickelte, bemerkt:

The choice of model also constrains the kind and range of protocol extensions that are likely to occur to the systems programmer; one model may suggest a rich set of useful extensions, another lead nowhere (or worse still, in the wrong direction).

Autorisierung ist ein wichtiger Aspekt in Systemen, die heute entwickelt werden -- von der Wegfahrsperre bis zum elektronischen Bargeld, von der Versicherungskarte bis zum Anrufbeantworter. Sie soll ohne unnötigen Aufwand, aber bei Bedarf mit ausreichender Sicherheit und Zuverlässigkeit funktionieren. Um diesem Ziel nahe zu kommen, muß mit großer Sorgfalt vorgegangen werden; vor allem sollte security (Sicherheit) nicht mit obscurity (Unübersichtlichkeit) verwechselt werden, will man nicht den Gebrauch einer Sache stärker behindern als ihren Mißbrauch.

Anwendungsbeispiele für das Protokoll finden sich in den folgenden Kapiteln.


oberon index <- ^ -> mail ?
Weiter: Namensräume, davor: Realisierung, darüber: Autorisierungsprotokolle.
Martin Hasch, Oct 1996