Zopebuch: Inhaltsverzeichnis

Kapitel 7: Benutzer und Sicherheit

Übersetzung von zopa (V 1.0)

Alle Web-Applikationen müssen mit Sicherheitsaspekten umgehen. Mit Sicherheitsaspekten umzugehen, bedeutet, zu kontrollieren, wer Zugang zu ihrer Applikation hat und festzulegen, was derjenige dort tun kann. Sicherheit ist kein Nachzügler, der einem laufenden System hinzugefügt werden kann. Stattdessen sollte Sicherheit ein wichtiges Design-Element sein, daß Sie bedenken, während Sie ihre Zope-Anwendungen aufbauen.

In diesem Kapitel werden Sie herausfinden, wie Sie Benutzer-Accounts einrichten und verwalten und wie die Weise zu kontrollieren ist, auf die Benutzer Zugriff auf ihre Anwendung haben, indem Sie Sicherheitsregeln aufstellen.

Sicherheit vorstellen

Sicherheit kontrolliert, was die Benutzer ihrer Website tun können und wie Sie und andere ihre Site pflegen können. Mit sorgfältigen Sicherheitsüberlegungen können Sie ihren Benutzern umfangreiche Möglichkeiten bieten und großen Gruppen von Menschen erlauben, auf sichere Weise zusammenzuarbeiten, um ihre Site zu pflegen. Wenn Sie sich um Sicherheit nicht kümmern, wird es schwierig sein, ihren -Benutzern sichere Kontrolle zu bieten und der Umgang mit ihrer Site wird ein lästiges Durcheinander werden. Ihre Site wird nicht nur unter Leuten leiden, die schädliche Dinge tun, zu denen sie gar nicht fähig sein sollten, sondern es wird auch schwer für Sie werden, ihren Benutzern irgendeinen Wert zu vermitteln und die zu kontrollieren, die ihre Site verwalten.

Zope flicht Sicherheit in fast jeden Aspekt der Web-Anwendungsaufbaus. Zope benutzt dasselbe Sicherheitssystem zur Kontrolle des Zope-Managements wie das, was Sie benutzen, um Benutzer für ihre Anwendung anzulegen. Zope macht keinen Unterschied zwischen dem Gebrauch und der Verwaltung einer Applikation. Zope mag verwirrend erscheinen, aber tatsächlich ermöglicht es Ihnen, Zopes Sicherheits-Framework für die Erfodernisse ihrer Anwendung einzustielen.

Bei Zope ein- und ausloggen

Wie wir in Kapitel 2 ("Zope benutzen") gesehen haben, loggen Sie sich bei Zope ein, indem Sie mit ihrem Web-Browser den Management-URL aufrufen und Benutzernamen und Paßwort eingeben. Wir haben in Kapitel 2 ("Zope benutzen") auch darauf hingewiesen, daß aufgrund der verbreiteten Browser-Arbeitsweise der Browser beendet werden muß, um sich aus Zope auszuloggen.

Wenn Sie versuchen, eine geschützte Ressource aufzurufen, für die Sie keine Zugangsrechte haben, wird Zope Sie auffordern, sich einzuloggen. Das kann auch geschehen, wenn Sie schon eingeloggt sind. Generell ist es nicht nötig, sich in Zope einzuloggen, wenn Sie nur öffentliche Ressourcen benutzen wollen.

Authentifizierung und Autorisierung

Sicherheit im weitesten Sinn kontrolliert zwei Funktionen, Authentifizierung und Autorisierung. Authentifizierung bedeutet, herauszufinden, wer Sie sind und Autorisierung bedeutet, festzulegen, was Sie tun können. Zope bietet getrennte Einrichtungen zur Verwaltung der Identifizierungsprozesse von Benutzern und Zugang zu kontrollierten Aktionen zu gewähren.

Wenn Sie eine geschützte Ressource aufrufen (wenn Sie sich beispielsweise eine private Website ansehen), wird Zope Sie auffordern, sich einzuloggen und nach ihrem Benutzer-Account suchen. Das ist der Authentifizierungsprozeß. Beachten Sie, daß Zope Sie nur authentifizieren wird, wenn Sie eine geschützte Ressource aufrufen; wenn Sie nur öffentliche Ressourcen aufrufen, wird Zope weiterhin annehmen, Sie seien anonym.

Sobald Sie authentifiziert sind, stellt Zope fest, ob Sie Zugang zu der geschützten Ressource haben oder nicht. Dieser Prozeß bezieht zwei vermittelnde Schichten zwischen Ihnen und der geschützten Ressource ein, nämlich Rollen und Erlaubnisse. Benutzer haben Rollen, die beschreiben, was sie tun dürfen, wie etwa "Autor", "Manager" oder "Redakteur". Zope-Objekte haben Erlaubnisse, die beschreiben, was mit ihnen getan werden kann, wie etwa "Ansehen", "Objekte löschen" oder "Eigenschaften verwalten".

Sicherheitsregeln teilen Rollen Erlaubnisse zu; in anderen Worten: Sie sagen, wer was tun darf. Zum Beispiel mag eine Sicherheitsregel die "Manager"-Rolle mit der Erlaubnis "Objekte löschen" assoziieren. Das erlaubt Managern, Objekte zu löschen. Auf diese Weise authorisiert Zope Benutzer, geschützte Aktionen durchzuführen.

In den folgenden Abschnitten werden wir einen genaueren Blick auf Authentifizierung und Autorisierung werfen und darauf, wie Sicherheitsregeln effektiv gesetzt werden können. Zuerst werden Sie etwas über Authentifizierung mit Hilfe von Benutzern und Benutzerverzeichnissen lernen, dann werden Sie etwas über die Kontrolle von Autorisierung mit Hilfe von Sicherheitsregeln herausfinden.

Authentifizierung und Verwaltung von Benutzern

Ein Zope-Benutzer definiert einen Benutzer-Account. Ein Zope-Benutzer hat einen Namen, ein Paßwort und optional zusätzliche Daten über jemenden, der Zope benutzt. Um sich in Zope einzuloggen, müssen Sie einen Benutzer-Account haben. Lassen Sie uns untersuchen, wie Benutzer-Accounts angelegt und verwaltet werden.

Benutzer in Benutzer-Verzeichnissen anlegen

Um Benutzer-Accounts in Zope anzulegen, fügen Sie Benutzer zu Benutzer-Verzeichnissen hinzu. In Kapitel 2 ("Zope benutzen") sollten Sie ihrem obersten Ordner bereits einen "Manager"-Benutzer hinzugefügt haben.

Lassen Sie uns einen neuen Benutzer anlegen, damiot ihr Mitarbeiter ihnen bei der Verwaltung der Zope-Site helfen kann. Gehen Sie zum Root-Ordner von Zope. Klicken Sie auf den Benutzer-Ordner namens acl_users. Der Benutzer-Ordner enthält Objekte, die Zope-Benutzer-Accounts definieren. Klicken Sie auf den Add-Button, um einen neuen Benutzer anzulegen.

Bild 6.1 Einen Benutzer zu einem Benutzer-Ordner hinzufügen.

Das Formular in Bild 6.1 läßt Sie den Benutzer definieren. Geben Sie im Feld Name den Namen ihres Mitarbeiters ein, zum Beispiel "michel". Der Benutzername kann Buchstaben, Leerzeichen und Zahlen enthalten. Er ist fallempfindlich.

Wählen Sie ein Paßwort für ihren Mitarbeiter und geben sie es in das Password- und das (Confirm)-Feld ein. Wir werden die Dinge so aufbauen, daß ihr Mitarbeiter sein Paßwort später ändern kann, wenn er sich einloggt. Sie können ein Paßwort wie "change me" benutzen, um ihm zu helfen, sich an die Änderung des Paßworts zu erinnern.

Das Feld Domains läßt Sie die Internet-Domains einschränken, von denen aus sich der Benutzer einloggen kann. Das ermöglicht Ihnen, dem Account eine weitere Sicherheitskontrolle hinzuzufügen. Wenn Sie beispielsweise möchten, daß sich ihr Mitarbeiter immer von seinem Arbeitsplatz aus einloggt, könnten Sie die Domain des Arbeitsplatzes im Domain-Feld eingeben, zum Beispiel "myjob.com". Sie können mehrere Domains - getrennt durch Leerzeichen - angeben, um dem Benutzer das Einloggen von mehreren Domains aus zu ermöglichen. Wenn Sie beispielsweise beschließen, daß ihr Mitarbeiter Zope auch von zuhause aus verwalten soll, könnten Sie die Domains auf "myjob.com myhome.net" setzen. Sie können auch IP-Nummern mit Sternchen verwenden, um Wildcards anstelle von Domain-Namen zu verwenden, um Domains zu spezifizieren. Beispielsweise würde "209.67.167.*" alle IP-Adressen definieren, die mit "209.67.167" beginnen.

Die Auswahlliste Roles zeigt an, welche Rollen der Benutzer haben soll. Im Allgemeinen sollten Benutzer mit Verwaltungsaufgaben die Manager-Rolle zugewiesen bekommen. Im Falle ihres Mitarbeiters wählen Sie die Manager-Rolle. Die Owner-Rolle ist in den meisten Fällen nicht angebracht, weil ein Benutzer normalerweise der Eigentümer ("Owner") bestimmter Objekte ist, nicht ein Eigentümer im Allgemeinen. Eigentümerschaft werden wir uns später im Kapitel genauer ansehen. Wir werden später auch sehen, wie Sie ihre eigenen Rollen definieren können wie etwa Redakteur oder Lektor.

Um einen neuen Benutzer anzulegen, klicken Sie auf den Add-Button. Sie sollten ein neues Benutzer-Objekt im Benutzer-Ordner sehen.

Benutzer bearbeiten

Sie können bestehende Benutzer bearbeiten, indem Sie sie anklicken. Das ruft ein Formular auf, das dem sehr ähnlich ist, daß Sie benutzt haben, um den Benutzer anzulegen. Tatsächlich können Sie hier alle Vorgaben kontrollieren, die wir gerade für dieses Formular diskutiert haben. Nachdem ihr Mitarbeiter sich bei dem für ihn Account eingeloggt hat, sollte er diesen Management-Bildschirm und sein Paßwort hier ändern.

Wie alle Verwaltungsfunktionen in Zope ist auch das Bearbeiten von Benutzer-Accountsvon den Sicherheitsregeln geschützt. Ein Benuitzer kann sein Paßwort nur ändern, wenn er die Erlaubnis Manage Users hat, die Manager als Voreinstellung besitzen.

Daher ist es nach Voreinstellung einem in einem bestimmten Benutzer-Ordner definierten Manager möglich, die Accounts anderer Manager zu ändern, wenn beide im selben Benutzerordner definiert sind. Das mag sein, was Sie wollen oder auch nicht. Später sehen wir uns Möglichkeiten an, dieses potentielle Problem zu vermeiden. Sie können allerdings beruhigt sein, denn es ist niemandem möglich, vom Management-Bildschirm aus ihr Paßwort herauszufinden. Ein anderer Manager mag Zugang zur änderung ihres Paßwortes haben, kann aber ihr gegenwärtiges Paßwort nicht herausfinden, ohne es zu ändern.

Im Allgemeinen funktionieren Benutzer-Ordner wie normale Zope-Ordner; Sie können darin Objekte anlegen, bearbeiten und löschen. Dennoch bieten Benutzer-Ordner nicht dieselben Möglichkeiten wie normale Ordner. Sie können in Benutzer-Ordnern nicht kopieren und einfügen und Sie können in einem Benutzer-Ordner nichts anderes anlegen als Benutzer.

Um einen existierenden Benutzer aus einem Benutzer-Ordner zu löschen, wählen sie einen Benutzer aus und klicken auf den Delete-Button. Denken Sie daran: Wie alle Zope-Aktionen kann das rückgängig gemacht werden, wenn Sie einen Fehler machen.

Benutzeranordnung festlegen

Zope kann mehrere Benutzer-Ordner an verschiedenen Stellen der Objekthierarchie enthalten. Ein Zope-Benutzer kann auf Ressourcen über dem Benutzer-Ordner, in dem er definiert ist, nicht zugreifen. Wo ihr Benutzer-Ordner definiert ist, entscheidet darüber, zu welchen Zope-Ressourcen Sie Zugang haben.

Wenn ihr Account in einem Benutzer-Ordner auf der Root-Ebene definiert ist, haben Sie Zugang zum Root-Ordner. Das ist wahrscheinlich der Ort, wo der Account, den Sie jetzt gerade benutzen, definiert ist. Sie können jedoch Benutzer in jedem Zope-Ordner definieren.

Betrachtenb Sie den Fall eines Benutzer-Ordners unter /WellnessSchule/Haar/acl_users. Nehmen Sie an, daß der Benutzer Edgar Scherenhand in diesem Benutzer-Ordner definiert ist. Edgar kann sich oberhalb des Ordners /WellnessSchule/Haar in Zope einloggen. Edgars Blick auf die Zope-Site ist praktisch begrenzt auf den Ordner /WellnessSchule/Haar und den darunterliegenden Bereich. Gelichgültig, welche Rollen Edgar zugeordnet sind, kann er nicht auf geschützte Ressourcen oberhalb dieses Ortes zugreifen.

Mit der Anwendung dieser Technik ist es leicht, einfache Sicherheitsregeln aufzubauen. Eins der verbreitetsten Zope-Verwaltungsmuster ist es, verwandte Objekte gemeinsam in einem Ordner zu plazieren und dann dort einen Benutzer-Ordner anzulegen, um die Leute zu definieren, die für diese Objekte verantwortlich sind.

Nehmen Sie beispielsweise an, daß die Leute in ihrer Organisation Uniformen tragen. Sie schaffen ein Intranet, das Informationen über ihre Organisation enthält, einschließlich Informationen über Uniformen. Sie mögen einen Ordner Uniformen irgendwo in der Intranet-Zope-Site anlegen. In diesem Ordner könnten sie Objekte ablegen wie Bilder von Uniformen und Beschreibungen, wie sie zu tragen und zu reinigen sind. Dann könnten Sie einen Benutzer-Ordner im Uniformen-Ordner anlegen und einen Account für die Chefschneiderin einrichten. Wenn ein neuer Uniform-Schnitt herauskommt, braucht die Schneiderin nicht den Webmaster zu bitten, die Site zu aktualisieren, sondern kann ihren eigenen Abschnitt das selbst tun, ohne irgendjemanden belästigen zu müssen. Außerdem hat die Chefschneiderin keinen Zugang zu Ordnern oberhalb von Uniformen, was bedeutet, daß sie keine Objeklte verwalten kann außer denen im Uniformen-Ordner.

Dieses Sicherheitsmuster wird Delegation genannt und ist in Zope-Anwendungen sehr verbreitet. Durch das Deligieren von verschiedenen Bereichen ihrer Zope-Site an verschiedene Benutzer können Sie die Last der Site-Administration von einer kleinen Gruppe von Managern nehmen und auf verschiedene spezifische Benutzergruppen verteilen. Später im Kapitel werden wir andere Sicherheitsmuster betrachten.

Mit alternativen Benutzer-Ordnern arbeiten

Es kann sein, daß Sie ihren Benutzer-Account nicht durch das Web verwalten wollen. Das mag daran liegen, daß Sie schon eine Benutzerdatenbank haben oder Sie wollen vielleicht andere Tools benutzen, um ihre Acoount-Informationen zu warten. Zope ermöglicht Ihnen, mit Hilfe von wechselnden Benutzer-Ordnern alle Arten von Autentifikationstechniken zu benutzen. Sie können auf der Zope-Website unter http://www.zope.org/Products/user_management viele wechselnde Benutzer-Ordner finden. Zur Zeit der Niederschrift gibt es 19 eingetragene wechselnde Benutzer-Ordner (Stand 08/2002: 55 Produkte; d.ü.). Hier steht eine Zusammenstellung einiger der populäreren alternativen Benutzer-Ordner zur Verfügung.

LoginManager

Dies ist ein flexibler und mächtiger Benutzer-Ordner, der Ihnen erlaubt, ihre eigenen Authorisierungsmethoden einzubinden. Zum Beispiel können Sie LoginManager benutzen, um sich aus einer Datenbank heraus zu authentifizieren.

etcUserFolder

Dieser Benutzer-Ordner authentifiziert über Standard-UNIX /etc/password style files.

LDAPAdapter

Dieser Benutzer-Ordner läßt Authetifizierung über einen LDAP-Server zu.

NTUserFolder

Dieser Benutzer-Ordner authetifiziert aus NT-Benutzer-Accounts heraus. Er funktioniert nur, wenn Sie Zope unter Windows NT oder Windows 2000 betreiben.

Manche Benutzer-Ordner bieten wechselnde Kontrollen für Login und Logout wie etwa Login-Webformulare, eher als browserbasierte HTTP-Autorisierungskontrollen. Abgesehen von diesem Unterschied nutzen alle Benutzer-Ordner dieselbe Login-Prozedur des Abfragens ihrer Angaben, sobald Sie eine geschützte Ressource aufrufen.

Währedn die meisten Benutzer über Benutzer-Ordner der einen oder anderen Art verwaltet werden, hat Zope einige besondere Benutzer-Accounts, die nicht üpber den Benutzer-Ordner verwaltet werden.

Besondere Benutzer-Accounts

Zope bietet drei besondere Benutzer-Accounts, die nicht in Benutzer-Ordnern definiert sind, den anonymen Benutzer, den Notfall-Benutzer (emergency user) und den Ursprungs-Manager (initial manager). Der anonyme Benutzer wird gelegentlich benutzt, während die Accounts von Notfall-Benutzer und Ursprungs-Manager selten benutzt werden, es aber wichtig ist, über sie bescheid zu wissen.

Anonymer Zope-Benutzer

Zope hat einen eingebauten Benutzer-Account für Gäste, den anonymen Benutzer. Wenn Sie keinen Benutzer-Account auf Zope haben, werden Sie für den anonymen Benutzer gehalten.

Der anonyme Benutzer hat Sicherheitskontrollen wie jeder andere auch, er hat die Rolle Anonymous. Als Voreinstellung kann die Rolle Anonymous nur auf öffentliche Ressourcen zugreifen und keine Zope-Objekte ändern. Sie können diese Regel ändern, aber meistens werden Sie die voreingestellten Sicherheitseinstellungen angemessen finden.

Wie wir bereits oben im Kapitel erwähnt haben, müssen sie versuchen, auf eine geschützte Ressource zuzugreifen, um Zope zu einer Authentifizierung zu bringen. Schließlich hält Zope Sie auch dann für anonym, wenn Sie einen Benutzer-Account haben, solange Sie noch nicht eingeloggt sind.

Zope-Notfall-Benutzer

Zope hat einen besonderen Benutzer-Account für den Notfall-Gebrauch, bekannt als Notfall-Benutzer (emergency user). Wir haben den Notfall-Benutzer bereits in Kapitel 2 ("Zope benutzen") kurz besprochen. Der Notfall-Benutzer ist nicht durch normale Sicherheitseinstellungen beschränkt. Dennoch kann der Notfall-Benutzer keinerlei neue Objekte anlegen, ausgenommen neue Benutzer-Objekte.

Der Notfall-Benutzer ist nur für zwei Dinge wirklich geeignet: das Reparieren durcheinandergebrachter Berechtigungen und das Anlegen von Manager-Accounts. Wie wir in Kapitel 2 ("Zope benutzen") gesehen haben, können Sie sich als Notfall-Benutzer einloggen und einen Manager-Account anlegen, wenn keiner existiert. Nach dem Anlegen eines Manager-Accounts sollten sie sich als Notfall-Benutzer ausloggen und als Manager wieder einloggen.

Ein anderer Grund, den Notfall-Benutzer-Account zu nutzen, besteht, wenn Sie sich selbst aus Zope ausgesperrt haben, indem Sie Berechtigungen entfernt haben, die Sie brauchen, um Zope zu verwalten. In diesem Fall loggen Sie sich als Notfall-Benutzer ein und stellen sicher, daß ihr Manager-Account die Berechtigungen View management screens und Change permissions hat. Dann loggen sie sich aus, loggen sich mit ihrem Manager-Account wieder ein und sollten genug Zugriffsmöglichkeiten haben, alles andere zu reparieren, was beschädigt ist.

Ein verbreitetes Problem mit dem Notfall-Benutzer ist der Versuch, ein neues Objekt anzulegen.

Bild 6.2 Error ausgelöst durch den Versuch, während des Logins als Notfall-Benutzer ein neues Objekt anzulegen.

Der Error in Bild 6.2 läßt Sie wissen, daß der Notfall-Benutzer keine neuen Objekte anlegen kann. Die Ursache dafüpr ist ein wenig komplex, wird aber später im Kapitel klarer werden, wenn wir Besitzerschaft behandeln. Die Kurzversion der Geschichte ist, daß es unsicher wäre, den Notfall-Benutzer Objekte anlegen zu lassen, da sie nicht Gegenstand derselben Sicherheitszwänge wären wie andere Objekte.

Einen Notfall-Benutzer anlegen

Anders als normale Benutzer-Accounts, die durch das Web definiert werden, wird der Notfall-Benutzer im Datei-System definiert. Sie können den Notfall-Benutzer-Account durch Bearbeitung der access-Datei im Zope-Verzeichnis ändern. Zope enthält eine Kommandozeilen-Anwendung, zpasswd.py, um den Notfall-Benutzer zu verwalten. Starten Sie zpasswd.py, indem Sie ihm den Pfad der Zugangsdatei übergeben:

      $ python zpasswd.py access

      Username: superuser
      Password:
      Verify password:

      Please choose a format from:

      SHA - SHA-1 hashed password
      CRYPT - UNIX-style crypt password
      CLEARTEXT - no protection.

      Encoding: SHA
      Domain restrictions:

Das zpasswd.py-Skript leitet Sie durch den Prozeß des Anlegens eines Notfall-Benutzer-Accounts. Beachten Sie, daß das von Ihnen eingegebene Paßwort nicht auf dem Bildschirm dargestellt wird. Sie können zpasswd.py auch ohne Argumente aufrufen, um eine Liste von Kommandozeiolen-Optionen zu erhalten.

Zope-Ursprungs-Manager

Der Ursprungs-Manager-Account wird vom Zope-Installer angelegt, damit Sie sich das erste Mal bei Zope einloggen können. Wenn Sie Zope das erste Mal installieren, sollten Sie eine Nachricht wie diese sehen:

      creating default inituser file

      Note:
      The initial user name and password are 'admin' and 'IVX3kAwU'.

      You can change the name and password through the web interface or using the 'zpasswd.py' script.

Das teilt Ihnen den Namen das Paßwort des Ursprungs-Managers mit. Sie können diese Informationen benutzen, um sich zum ersten Mal als Manager bei Zope einzuloggen. Anschließend können Sie zusätzliche Benutzer-Accounts anlegen.

Ursprungs-Benutzer werden auf ähnliche Weise definiert wie der Notfall-Benutzer; sie sind in einer Datei im Dateisystem definiert, die inituser heißt. Das zpasswd.py-Programm kann benutzt werden, um diese Datei auf dieselbe Weise zu bearbeiten, wie sie benutzt wird, um die Notfall-Benutzer-Datei access zu editieren

      $ python zpasswd.py inituser

      Username: bob
      Password:
      Verify password:

      Please choose a format from:

      SHA - SHA-1 hashed password
      CRYPT - UNIX-style crypt password
      CLEARTEXT - no protection.

      Encoding: SHA
      Domain restrictions:

Das wird einen neuen Ursprungs-Benutzer namens "bob" einrichten und sein Paßwort setzen (das Paßwort wird nicht auf dem Bildschirm dargestellt, während Soie es eintippen). Wenn Zope startet, untersucht es diese Datei nach Benutzern und stellt sicher, daß sie sich in Zope einloggen können. Normalerweise werden Ursprungs-Benutzer vom Zope-Installer für Sie angelegt und Sie sollten sich nicht darum kümmern müssen, sie zu ändern. Wenn Sie zusätzliche Benutzer anlegen wollen, werden Sie das mit der Zope-Web-Management-Schnittstelle tun.

Bisher haben wir uns damit beschäftigt, wie Benutzer und Benutzer-Ordner Authentifizierung kontrollieren. Als Nächstes werden wir betrachten, wie Autorisierung mit Sicherheitsregeln kontrolliert wird

Autorisierung und Verwaltung von Sicherheit

Zope-Sicherheitsregeln kontrollieren Autorisierung; sie definieren, wer was tun kann. Sicherheitsregeln beschreiben, welche Rollen welche Berechtigungen haben. Rollen bezeichnen Klassen von Benutzern und Berechtigungen schützen Objekte. Daher definieren Sicherheitsregeln, welche Benutzer-Klassen (Rollen) welche Art von Aktionen (Berechtigungen) in einem bestimmten Teil der Site durchführen können.

Anstatt festlegen zu müssen, welcher bestimmte Benutzer welche bestimmten Aktionen mit welchem bestimmten Objekt durchführen darf, erlaubt Ihnen Zope, zu definieren, welche Art von Benutzern welche verschiedenen Aktionen in welchen Bereichen der Site durchführen können. Diese Art der Generalisierung macht ihre Sicherheitsregheln einfach und mächtig. Natürlich können Sie für bestimmte Benutzer, Aktionen und Objekte Ausnahmen von diesen Regeln machen.

In den folgenden Abschnitten werden wir Rollen, Berechtigungen und Sicherheitsregeln etwaxs näher untersuchen und einen Blick auf den Aufbau einfacher und effektiver Sicherheitsregeln werfen.

Mit Rollen arbeiten

Zope-Benutzer haben Rollen, die bestimmten, welche Arten von Aktionen sie durchführewn können. Rollen legen Benutzer-Klassen wie Manager, Anonym (Anonymous) und Authentifiziert (Authenticated) fest.

Rollen sind darin UNIX-Gruppen ähnlich, daß sie Gruppen von Benutzern abstrahieren. Und wie UNIX-Gruppen können Zope-Benutzer mehr als eine Rolle haben.

Rollen machen es leichter für Sie, Sicherheitsaspekte zu verwalten. Anstatt zu definieren, was jeder einzelne Benutzer tun kann, können Sie einfach ein paar verschiedene Sicherheitsregeln für verschiedene Benutzerrollen festlegen.

Zope hat vier eingebaute Rollen:

Manager

Diese Rollen wird an Benutzer vergeben, die Standard-Verwaltungsfunktionen von Zope durchführen wie etwa anlegen und bearbeiten von Zope-Ordern und Dokumenten.

Anonym (Anonymous)

Der anonyme Zope-Benutzer hat diese Rolle. Sie sollte die öffentlichen Ressourcen sehen ("view") dürfen. Generell sollte dieser Rolle nicht gestattet sein, Zope-Objekte zu ändern.

Besitzer (Owner)

Diese Rolle wird automatisch Benutzern in dem Kontext zugeordnet, wo sie Objekte anlegen. Besitzerschaft werden wir später in diesem Kapitel behandeln.

Authentifiziert (Authenticated)

Diese Rolle wird automatisch Benutzern zugeordnet, die gültige Authentifizierungsdaten übermittelt haben. Diese Rolle bedeutet, daß Zope "weiß", wer der bestimmte Benutzer ist.

Für einfache Zope-Sites kommen Sie mit Manager und Anonym klar. Für komplexere Sites mögen Sie ihre eigenen Rollen anlegen wollen, um ihre Benutzer in verschiedene Gruppen zu ordnen.

Rollen definieren

Um eine neue Rolle festzulegen, gehen Sie zur Registerkarte Security und scrollen bis zum Fuß des Bildschirms. Tippen Sie den Namen der neuen Rolle in das Feld User defined role und klicken Sie Add Role. Rollennamen sollten kurze, ein- oder zweiwortige Beschreibungen eines Benutzertyps sein wie etwa "Autor", "Site-Architekt" oder "Designer". Sie sollten Rollennamen aussuchen, die für ihre Anwendung relevant sind.

Sie sehen, daß ihre Rolle angelegt worden ist, wenn Sie beachten, daß es nun eine Rollen-Spalte für ihre neue Rolle am Kopf des Bildschirms gibt. Sie können auch eine Rolle löschen, indem sie die Rolle in der Auswahlliste am Fuß der Sicherheits-Seite markieren und dann den Delete Role-Button anklicken. Sie können nur ihre zusätzlich angelegten Rollen löschen und nicht die "Stamm"-Rollen, die Zope mitbringt.

Sie sollten beachten, daß Rollen auf der Ebene benutzt werden können, wo sie definiert sind und in der Objekthierarchie darunter. Wenn Sie also eine Rolle anlegen wollen, die auf ihrer gesamten Site verwendet werden soll, legen Sie sie im Root-Ordner an.

Im Allgemeinen sollten Rollen für große Abschnitte ihrer Site anwendbar sein. Wenn Sie dabei sind, Rollen anzulegen, um den Zugang zu Teilen ihrer Site zu begrenzen, gibt es möglicherweise bessere Wege, dasselbe Ziel zu erreichen. Zum Beispiel könnten Sie einfach die Sicherheitseinstellungen für die existierenden Rollen in dem Ordner ändern, den Sie schützen wollen oder Sie könnten Benutzer tiefer in der Objekthierarchie definieren, um ihren Zugang zu beschränken. Später im Kapitel werden wir mehr Beispiele dazu betrachten, wie Sicherheitsregeln definiert werden.

Lokale Rollen (local roles) verstehen

Lokale Rollen (lokal roles) sind eine fortgeschrittene Eigenschaft der Zope-Sicherheit. Benutzer können Extra-Rollen zugeordnet bekommen, wenn sie an einem bestimmten Objekt arbeiten. Wenn ein Objekt lokale Rollen mit einem Benutzer assoziiert hat, bekommt dieser Benutzer jene zusätzlichen Rollenm während er an dem Objekt arbeitet.

Wenn zum Beispiel ein Benutzer ein Objekt besitzt, ist ihm gewöhnlich auch die zusätzliche lokale Rolle des Besitzers (Owner) zugeordnet, während er mit dem Objekt arbeitet. Ein Benutzer mag generell nicht die Fähigkeit haben, DTML-Skripte zu bearbeiten, aber für DTML-Skripte, die er besitzt, könnte der Benutzer Zugang zum Bearbeiten des DTML-Skripts über die lokale Rolle des Besitzers haben.

Lokale Rollen sind ziemlich fortgeschrittene Sicherheitsmechanismen und werden nicht sehr oft gebraucht. Zopes automatische Kontrolle der lokalen Rolle Besitzer ist wahrscheinlich die einzige Stelle, wo sie lokalen Rollen begegnen.

Der Hauptgrund, aus dem Sie möglicherweise lokale Rollen manuell kontrollieren möchten, ist der Wunsch, einem bestimmten Benutzer besonderen Zugang zu einem Objekt zu gewähren. Sie sollten es nach Möglichkeit generell vermeiden, besondere Sicherheitseinstellungen für einzelne Benutzer vorzunehmen. Es ist einfacher, Sicherheitseinstellungen zu verwalten, die Gruppen von Benutzern betreffen als einzelne.

Berechtigungen verstehen

Berechtigungen definieren, welche Aktionen mit Zope-Objekten durchgeführt werden können. Genau wie Benutzer durch Rollen abstrahiert werden, werden Objekte durch Berechtigungen abstrahiert. Viele Zope-Objekte - einschließlich DTML-Skripten und DTML-Dokumenten - können beispielsweise betrachtet werden. Diese Aktion ist durch die Berechtigung View geschützt.

Manche Berechtigungen sind nur für einen Objekt-Typ relevant, wie zum Beispiel die Berechtigung zum ändern von DTML-Skripten, Change DTML Methods, die ausschließlich DTML-Skripte schützt. Andere Berechtigungen schützen viele Objekt-Typen wie etwa die Berechtigungen FTP access und WebDAV access, die kontrollieren, welche Objekte per FTP oder WebDAV zugänglich sind.

Sie können herausfinden, welche Berechtigungen bei einem bestimmten Objeklt zur Verfügung stehen, indem Sie zur Registerkarte Security gehen.

Bild 6.3 Sicherheitseinstellungen für ein Mail Host-Objekt.

Wie Sie in Bild 6.3 sehen können, verfügt ein Mail Host über eine eingeschränkte Berechtigungspalette. Vergleichen Sie das mit den vielen Berechtigungen, die Sie beim Festlegen der Sicherheitseinstellungen für einen Oredner sehen.

Sicherheitsregeln definieren

Sicherheitsregeln sind die Stelle, an der Rollen auf Berechtigungen treffen. Sicherheitsregeln definieren, wer was in einem bestimmten Teil der Site tun kann.

Sie können Sicherheitsregeln für fast jedes Zope-Objekt festlegen. Um eine Sicherheitsregel festzulegen, gehen Sie zur Registerkarte Security. Klicken Sie zum Beispiel auf die Sicherheits-Registerkarte des Root-Ordners.

Bild 6.4 Sicherheitsregeln für den Root-Ordner.

Es geschieht eine Menge in Bild 6.4. Im Zentrum des Bildschirms befindet sich ein Gitter von Kontrollkästchen. Die vertikale Spalte des Gitters steht für Rollen, die horizontalen Reihen des Gitters für Berechtigungen. Das Anklicken des Kästchens an der Kreuzung zwischen einer Berechtigung und einer Rolle ordnet dem Benutzer mit dieser Rolle die Fähigkeit zu, Aktionen vorzunehmen, die von dieser Berechtigung geschützt werden.

Sie werden bemerken, daß Zope voreingestellte Sicherheitsregeln hat, die dem Manager erlauben, die meisten Aufgaben auszuführen und anonymen Benutzern nur erlauben, ein paar auszuführen. Sie können diese Regeln bearbeiten, um sie ihren Anforderungen anzupassen, indem Sie die Sicherheitseinstaellungen im Root-Ordner ändern.

Sie können beispielsweise ihre Site "privatisieren", indem Sie anonymen Benutzern verbieten, irgendwelche Webseiten zu sehen. Um das zu tun, verweigern Sie allen anonymen Benutzern den "View"-Zugang, indem Sie die View-Berechtigung abschalten, wo sie die Rolle Anonymous trifft. Sie können ihre gesamte Site privatisieren, indem Sie diese änderung der Sicherheitsregeln im Root-Ordner durchführen. Wenn Sie einen Teil ihrer Site privatisieren wollen, können Sie diese änderung in dem Ordner vornehmen, den Sie privatisieren wollen.

Dieses Beispiel weist auf einen sehr wichtigen Punkt von Sicherheitsregeln hin: Sie kontrollieren Sicherheit nur für einen bestimmten Teil der Site. Die einzige generelle Sicherheitsregel ist die des Root-Ordners.

Erwerben von Sicherheitsregeln

Wie interagieren verschiedene Sicherheitsregeln? Wir haben gesehen, daß man Sicherheitsregeln für verschiedene Objekte einrichten kann, aber was betsimmt, welche Regeln welches Objekt kontrollieren? Die Antwort ist, daß Objekte ihre eigenen Regeln beutzen, wenn sie welche haben, zusätzlich erwerben sie die Sicherheitsregeln von ihren Haupt-Dokumenten durch einen Prozeß, der Erwerben

Erwerben ist in Zope ein Menschanismus zum Teilen von Informationen zwischen Objekten, die in einem Ordner und seinen Unterordnern enthalten sind. Das Zope-Sicherheitssystem benutzt Erwerben, um Sicherheitsregeln zu teilen, damit der Zugang von Ordnern höherer Ebene aus kontrolliert werden kann.

Sie können das Erwerben von Sicherheitsregeln über die Registerkarte Security kontrollieren. Beachten Sie, daß es dort eine Spalte von Auswahlkästchen auf der linken Seite des Bildschirms gibt, die mit Acquire permission settings beschriftet ist. Jedes Auswahlfeld in dieser Spalte ist als Voreinstellung markiert. Das bedeutet, daß die Sicherheitsregel ergänzend zu allen Einstellungen in diesem Bildschirm die Einstellungen des Hauptdokuments für jede Berechtigung zu den Rollen-Einstellungen erwerben wird. Behalten Sie im Kopf, daß es im Root-Ordner (der kein übergeordnetes Hauptdokument hat) die äußerste, linke Spalte nicht gibt.

Nehmen Sie beispielsweise an, Sie würden diesen Ordner privat machen wollen. Wie wir schon gesehen haben, erfordert das bloß, der Rolle Anonymous die Berechtigung View zu verweigern. Wie Sie aber auf diesem Bildschirm sehen, hat die Rolle Anonymous hier keine View-Berechtigung und dennoch ist der Ordner nicht privat. Wie kommt das? Die Antwort ist, daß die Einstellung Acquire permission settings für die Berechtigung View aktiviert ist. Das bedeutet, daß die gegenwärtigen Einstellungen von den Sicherheitseinstellungen der übergeordneten Dokumente dieses Ordners übernommen worden sind. Irgendwo oberhalb dieses Ordners muß also der Rolle Anonymous die Berechtigung View zugewiesen sein. Siue können das überprüfen, indem Sie die Sicherheitsregeln der Haupt-Dokumente dieses Ordners untersuchen. Um den Ordner zu privatisieren, müssen wir die Markierung der Berechtigung Acquire permission settings aufheben. Das wird sicherstellen, daß ausschließlich die Einstellungen wirksam sind, die in dieser expliziten Sicherheitsregel gelten.

Im Allgmeinen sollten Sie immer Sicherheitseinstellungen übernehmen, wenn Sie nicht gerade einen besonderen Grund haben, das nicht zu tun. Das wird die Verwaltung ihrer Sicherheitseinstellungen viel einfacher machen, weil vieles vom Root-Ordner aus getan werden kann.

Als nächstes beschäftigen wir uns mit ein paar Beispielen, wie wirkungsvolle Sicherheitsregeln mit den Werkzeugen aufgestellt werden können, die Sie in diesem Kapitel bisher kennengelernt haben.

Anwendungsmuster Sicherheit

Die grundlegeneden Konzepte von Zope sind simpel: Rollen und Berechtigungen werden kombiniert, um Sicherheitsregeln zu schaffen und das Verhalten der Benutzer wird von diesen Regeln kontrolliert. Diese einfachen Werkzeuge können dennoch auf viele verschiedene Weise zusammengestellt werden. Das kann die Verwaltung von Sicherheitsaspekten komplex machen. Lassen Sie uns ein paar grundsätzliche Muster für die Verwaltung von Sicherheitsaspekten betrachten, die gute Beispiele für das Anlegen einer wirksamen und leicht zu verwaltenden Sicherheitsarchitektur liefern

Sicherheit: Faustregeln

Hier sind ein paar schlichte Leitlinien für die Sicherheitsverwaltung unter Zope. Die folgenden Sicherheitsmuster bieten spezifischere Rezepte, aber diese Leitlinien geben Ihnen etwas Orientierung, wenn Sie vor unerforschtem Gelände stehen.

1. Definieren Sie Benutzer auf iher höchsten Kontrollebene, aber nicht höher.
2. Gruppieren Sie Objekte, die von denselben Leuten verwaltet werden sollen, gemeinsam in denselben Ordnern.
3. Halten Sie die Dinge schlicht.

Die Regeln Eins und Zwei sind eng verwandt. Beide sind Teil einer eher generellen Regel für die Site-Architektur von Zope. Im Allgemeinen sollten Sie ihre Site überarbeiten, um verwandte Ressourcen und Benutzer nah beieinander anzuordnen. Natürlich ist es nie möglich, Ressourcen und Benutzer in eine strikte Hierarchie zu zwingen. Dennoch hilft eine wohlüberlegte Anordnung von Ressourcen und Benutzern in Ordnern und Unterordnern erheblich.

Versuchen Sie die Dinge schlicht zu halten, unabhängig von ihrer Site-Architektur. Je mehr Sie ihre Sicherheitseinstellungen komplizieren, umso schwieriger wird es, sie zu verstehen, zu verwalten und sicherzustellen, daß sie wirksam sind. Begrenzen Sie zum Beispiel die Zahl der neuen Rollen, die Sie anlegen und versuchen Sie, durch Erwerben von Sicherheitsregeln die Zahl der Orte zu begrenzen, wo Sie konkret Sicherheitseinstellungen definieren müssen. Wenn Sie bemerken, daß ihre Sicherheitsregeln, Benutzer und Rollen zu einem komplexen Dickicht verwachsen, sollten Sie überdenken, was Sie tun; es gibt vielleicht einen einfacheren Weg.

Allgemeine und lokale Regeln

Das grundlegende Sicherheitsmuster von Zope besteht darin, eine allgemeine Sicherheitsregel im Root-Ordner festzuilegen und diese Regel überall erwerben zu lassen. Dann können Sie - wo es nötig ist - zusätzliche Regeln tiefer in der Objekthierarchie festlegen, um die allgemeinen Regeln zu erweitern. Bemühen Sie sich, die Zahl der Orte zu begrenzen, an denen Sie die allgemeinen Sicherheitsregeln außer kraft setzen. Wenn Sie feststellen, daß Sie an vielen Stellen änderungen vornehmen müssen, bedenken Sie die Möglichkeit, die betreffenden Objekte aus den verschiedenen Ablageorten in einem Ordner zusammenzufassen, damit Sie die Sicherheitsregeln nur einmal bearbeiten müssen.

Sie sollten das Erwerben von Berechtigungsregeln in den Unter-Regeln übernehmen, es sei denn, ihre Unter-Regeln wären restriktiver als die allgemeinen Regeln. In diesem Fall sollten Sie die Markierung dieser Option für die Berechtigung aufheben, die nicht übernommen werden soll.

Dieses einfache Muster wird viele ihrer Sicherheitsbedürfnisse erfüllen. Sein Vorteil ist, daß es einfach zu verwalten und zu verstehen ist. Es sind extrem wichtige Charakteristika für jede Sicherheitsarchitektur.

Kontrolle an lokale Manager deligieren

Dieses Sicherheitsmuster ist für Zope sehr zentral und Teil dessen, was Zope seinen einzigartigen Geschmack gibt. Zope unterstützt Sie dabei, etwa Ressourcen in Ordnern zusammenzufassen und und dann Benutzer-Accounts in diesen Ordnern anzulegen, um ihren Inhalt zu verwalten.

Sagen wir, Sie wollen die Verwaltung des Ordners Verkauf auf ihrer Zope-Site dem neuen Web-Verkaufsmanager Stefan überlassen. Als erstes wollen Sie nicht, daß Stefan irgendwoanders dran herumfummelt als am Ordner Verkauf, also brauchen Sie ihn auch nicht dem acl-user-Ordner im Root-Verzeichnis hinzuzufügen. Stattdessen legen Sie einen neuen Benutzer-Ordner im Ordner Verkauf an.

Nun können Sie Steve zum Benutzer-Ordner im Ordner Verkauf hinzufügen und ihm die Rolle Manager zuweisen. Stefan kann sich nun direkt im Ordner Verkauf einloggen, um seinen Bereich zu verwalten, indem er mit seinem Browser http://www.zopezoo.org/Verkauf/manage aufruft.

Figure 6-5 Den Ordner "Verkauf" verwalten.

Beachten Sie, daß in Bild 6.5 der Navigationsbaum auf der linken Seite den Ordner Verkauf als Root-Ordner anzeigt. Der lokale Manager, der für diesen Ordner defiiniert ist, wird niemals die Fähigkeit haben, sich in einen Ordner über Verkauf einzuloggen, daher wird er als oberster Ordner angezeigt.

Dieses Muster ist sehr mächtig, denn es kann rekursiv angewandt werden. Stefan kann beispielsweise einen Unterordner für Multi-Level-Marketing-Verkäufe anlegen. Dann kann er einen Benutzer-Ordner anlegen und in diesem Unterordner anlegen, um die Kontrolle über diesen Ordner an den Multi-Level-Marketing-Manager zu delgieren. Und so weiter.as ist ein Rezept für große Websites, die von tausenden von Menschen verwaltet werden.

Die Schönheit dioeses Musters besteht darin, daß Manager in höheren Ebenen sich nicht so sehr damit beschäftigen müssen, was ihre Unterlinge tun. Wenn sie wollen, können sie von Nahem aufmerksam zusehen, aber sie können problemlos Einzelheiten ignorieren, denn sie wissen, daß die Untergebenen keinerlei änderungen außerhalb ihres Kontrollbereichs vornehmen können und sie wissen, daß ihre Sicherheitseinstellungen übernommen werden.

Verschiedene Zugangsebenen durch Rollen

Das Muster der lokalen Manager ist mächtig und skalierbar, aber es bietet einen eher groben Blick auf die Sicherheit. Entweder Sie haben Zugang oder eben nicht. Manchmal brauchen Sie eher feinere Kontrollmechanismen. Oft werden Sie Ressourcen haben, die von mehr als einem Benutzer-Typus benötigt werden. Rollen verschaffen Ihnen eine nLösung für dieses Problem. Rollen erlauben Ihnen, Benutzerklassen zu definieren und Sicherheitsregeln für sie festzulegen.

Bevor Sie neue Rollen anlegen, stellen Sie sicher, daß Sie sie wirklich brauchen. Angenommen, Sie haben eine Website, auf der Artikel veröffentlicht werden. Die öffentlichkeit liest Artikel und Manager bearbeiten und veröffentlichen Artikel, aber es gibt mit Autoren eine dritte Klasse von Benutzern, die Artikel schreiben, aber sie nicht bearbeiten oder veröffentlichen können.

Eine Lösung wäre, einen Autoren-Ordner anzulegen, wo Autoren-Accounts angelegt und ihnen Manager-Rollen zugewiesen werden. Dieser Ordner wäre privat, könnte also nur von Managern gesehen werden. Die Artikel könnten in diesem Ordner geschrieben werden und dann könnten Manager diese Artikel aus diesem Ordner herausbewegen, um sie zu veröffentlichen. Das ist eine angemessene Lösung, aber sie verlangt, daß Autoren nur in einem Teil der Site aus dem Autoren-Ordner heraus arbeiten und sie verlangt Extra-Arbeit von Managern, um die Artikel der Autoren aus dem Autoren-Ordner hinauszubewegen. Bedenken Sie auch die Schwierigkeiten, die es macht, wenn ein Autor einen Artikel überarbeiten will, der aus dem Autoren-Ordner entfernt wurde.

Eine bessere Lösung ist es, eine Rolle Autor hinzuzufügen. Eine Rolle hinzuzufügen, hilft uns, weil darüber ortsungebundene Zugangskontrollen möglich werden. Daher ermöglichen wir in unserem Beispiel mit dem Hinzufügen einer Autoren-Rolle das Schreiben, bearbeiten und Veröffentlichen von Artikeln überall auf der Site. Wir können eine allgemeine Sicherheitsregel anlegen, die Autoren die Berechtigung gibt, Artikel anzulegen und zu schreiben, aber ihnen die Berechtigung verweigert, sie zu veröffentlichen oder zu bearbeiten.

Rollen erlauben Ihnen, Zugang aufgrund dessen zu kontrollieren, wer ein Benutzer ist, nicht nur, wo er definiert ist.

Zugang zu Orten über Rollen kontrollieren

Rollen können helfen, mit einem subtilen Problem des Musters der lokalen Manager fertigzuwerden. Das Problem bestehtr darin, daß das Lokale-Manager-Muster eine strenge Kontrollhierarchie verlangt. Es gibt keine Möglichkeit, zwei verschiedenen Gruppen von Leuten den Zugang zu denselben Ressourcen zu gewähren, ohne daß die eine Gruppe Manager der anderen Gruppe ist. Anders gesagt, gibt es keinen Weg für Benutzer, die im einen Teil der Site definiert sind, im anderen Teil Ressourcen zu verwalten.

Lassen Sie uns ein Beispiel nehmen, um die zweite Begrenzung des Lokal-Manager-Musters zu illustrieren. Stellen Sie sich vor, Sie unterhalten eine große Site für eine pharmazeutische Gesellschaft. Sie haben zwei Klassen von Benutzern: Wissenschatfler und Verkäufer. In der Hauptsache haben Wissenschaftler und Verkäufer verschiedene Web-Ressourcen. Nehmen Sie dennoch an, daß es einige Dinge gibt, die beide Sorten von Menschen verwalten müssen, wie etwa Anzeigen, die komplexe, wissenschaftliche Warnungen enthalten müssen. Wenn wir unsere Wissenschaftler im Ordner Wissenschaft definieren und die Verkäufer im Ordner Verkauf, wohin soll.en wir dann den Ordner AnzeigenmitkomplexenWarnungen stellen? Wenn nicht der Ordner Wissenschaft im Ordner Verkauf liegt oder umgekehrt, gint es keinen Ort, wo wir den Ordner AnzeigenmitkomplexenWarnungen anlegen können, und sowohl Wissenschaftler als auch Verkäufer ihn verwalten können. Es ist weder theoretisch noch praktisch eine gute Lösung, die Verkäufer von den Wissenschaftlern verwalten zu lassen oder umgekehrt; was ist möglich?

Die Lösung ist, Rollen zu verwenden. Sie wollten zwei Rollen auf einer Ebene über den Ordner von Wissenschaft und Verkauf anlegen, vielleicht Wissenschaftler und Verkäufer. Dann definieren Sie die Wissenschaftler und Verkäufer nicht innerhalb ihrer eigenen Ordner, sondern höher in der Objekthierarchie, sodaß beide Zugang zum Ordner AnzeigenmitkomplexenWarnungen haben.

Wenn Sie Benutzer auf dieser höheren Ebene anlegen, sollten Sie ihnen keine Manager-Rolle zuweisen, sondern ordnen Sie ihnen "Wissenschaftler" oder "Verkäufer" zuordnen. Dann sollten Sie die Sicherheitsregeln festlegen. Im Ordner Wissenschaft sollte die Wissenschaftler-Rolle das äquivalent der Manager-Kontrolle haben. Im Ordner Verkauf sollte die Verkäufer-Rolle dieselben Berechtigungen haben wie der Manager. Schließlich sollten Sie sowohl Wissenschaftler als auch Verkäufer im Ordner AnzeigenmitkomplexenWarnungen adäquate Berechtigungen geben. Auf diese Weise werden Rollen nicht benutzt, um verschiedenme Zugangsebenen zu schaffen, sondern Zugang zu verschiedenen Orten, indem sie darauf beruhen, wer Sie sind.

Eine andere häufige Situation beim Verwenden dieses Musters kann entstehen, wenn Sie ihre Benutzer nicht lokal definieren können. Sie mögen beispielsweise einen alternativen Benutzerordner verwenden, der die Definition aller Benutzer im Root-Ordner erzwingt. In diesem Fall würden Sie umfassenden Gebrauch von Rollen machen wollen, um den Zugang zu verschiedenen Orten auf Grundlage der Rollen zu beschränken.

Das schließt unsere Diskussion von Sicherheits-Mustern ab. Inzwischen sollten Sie eine angemessene Vorstellung davon haben, wie Benutzer-Ordner, Rollen und Sicherheitsregeln angewendet werden, um eine angemessene Sicherheitsarchitektur für ihre Anwendung anzulegen. Als nächstes werden wir zwei fortgeschrittene Sicherheitsaspekte behandeln, nämlich: Wie Sicherheitstests durchgeführt und ausführbare Inmhalte gesichert werden.

Sicherheitstests durchführen

Während der meisten Zeit brauchen Sie überhaupt keine Sicherheitstests durchzuführen. Wenn ein Benutzer versucht, eine gesicherte Operation durchzuführen, wird Zope ihn auffordern, sich einzuloggen. Wenn der Benutzer keine angemessenen Berechtigungen zum Zugang auf die geschützte Ressource besutzt, wird Zope ihm den Zugang verweigern. Dennoch mögen Sie gelegentlich manuelle Sicherheitstests durchführen wollen. Der Hauptgrund, das zu tun, liegt darin, die Auswahl zu begrenzen, die einem Benutzer angeboten wird, wenn er sich authentifizieren soll. Das hindert einen raffinierten Benutzer nicht daran, auf geschützte Aktionen zugreifen zu wollen, aber es reduziert die Frustration von Benutzern, ihnen etwas, das nicht funktioniert, auch nicht anzubieten.

Die meistverbreitete Sicherheitsanfrage klärt, ob der gegenwärtige Benutzer eine bestimmte Berechtigung hat. Nehmen Sie zum Beispiel an, ihre Anwendung erlaubt Benutzern, Dateien hochzuladen. Diese Aktion wird durch die Zope-Standard-Berechtigung "Add Documents, Images, and Files" kontrolliert. Sie können mit DTML prüfen, ob der gegenwärtige Benutzer diese Berechtigung hat:

      

        

        ...
        

      

Die Funktion SecurityCheckPermission braucht zwei Argumente, nämlich einen Berechtigungsnamen und ein Objekt. In diesem Fall übergeben wir this() als das Objekt, was eine Refernz auf das gegenwärtige Objekt darstellt. Durch übergeben des gegenwärtigen Objekts stellen wir sicher, daß lokale Rollen einbezogen werden, wenn wir prüfen, ob der gegenwärtige Benutzer eine bestimmte Berechtigung hat.

Sie können etwas über den aktuellen Benutzer herausfinden, wenn Sie in DTML auf den Benutzer zugreifen. Der aktuelle Benutzer ist ein Zope-Objekt wie jedes andere und Sie können Aktionen mit ihm durchführen, indem Sie Skripte aus der API-Dokumentation benutzen.

Nehmen Sie an, Sie wollen den gegenwärtigen Benutzernamen auf einer Web-Seite darstellen, um die Seite zu personalisieren. Das können Sie ganz leicht in DTML:

Sie können den aktuell eingeloggten Benutzer über die DTML-Funktion SecurityGetUser auslesen. Dieses DTML-Fragment prüft den gegenwärtigen Benutzer, indem das Skript getUserName über das gegenwärtige Benutzer-Objekt aufgerufen wird. Wenn der Benutzer nicht eingeloggt ist, werden Sie den Namen des anonymen Benutzers bekommen, der Anonymous User lautet.

Als Nächstes sehen wir uns einen anderen fortgeschrittenen Aspekt ansehen, der die Sicherheit von DTML- und Skripten betrifft.

Fortgeschrittene Sicherheitsaspekte: Besitzerschaft und ausführbare Inhalte

Sie haben nun alle Grundlagen der Zope-Sicherheit behandelt. Was bleibt, sind die fortgeschrittenen Konzepte von Besitzerschaft (ownership) und ausführbaren Inhalten. Zope benutzt Besitzerschaft, um Objekte mit den Benutzern zu assoziieren, die sie anlegen und ausführbare Inhalte verweist auf auf Objekte wie Skripte und Dokumente, die Benutzer-Code ausführen.

Für kleine Sites mit vertrauenswürdigen Benutzern können Sie diese fortgeschrittenen Aspekte ignorieren. Wo Sie allerdings auf großen Sites nicht als vertrauenswürdig bekannten Benutzern erlauben, Zope-Objekte anzulegen oder zu bearbeiten, ist es wichtig, Besitzerschaft zu verstehen und ausführbare Inhalte abzusichern.

Das Problem: Angriffe mit Trojanern

Das grundlegende Szenario, daß ebenso Besitzerschaft wie ausführbare Inhalte interessant macht, ist ein Trojaner-Angriff. Ein Trojaner ist ein Angriff auf ein System, der einen Benutzer dergestalt austrickst, daß er eine potentiell schädliche Aktion durchführt. Ein typischer Trojaner maskiert sich als freundliches Programm, das Schaden anrichtet, wenn Sie es unbeabsichtigt ausführen.

Alle Web-basierten Plattformen - eingeschlossen Zope und viele andere - sind Gegenstand dieser Art von Angriff. Dazu ist es nur nötig, jemanden dazu zu bringen, einen URL aufzurufen, der eine schädliche Aktion durchführt.

Es ist sehr schwierig, sich gegen diese Art von Angriff zu schützen. Sie können sehr leicht jemanden dazu bringen, auf einen Link zu klicken oder Sie können fortgeschrittene Techniken wie JavaScript nutzen, um einen Benutzer auf einen schädlichen URL zu leiten.

Zope bietet einigen Schutz vor dieser Art von Trojanern. Zope hilft, ihre Site von der Server-Seite aus gegen Trojaner zu schützen, indem die Macht der Web-Ressourcen darauf gründet, wer ihr Autor ist. Wenn ein nicht-vertrauter Benutzer eine Web-Seite anlegt, ist die Macht, vertrauensseelige Benutzer zu schädigen, beschränkt. Nehmen Sie beispielsweise an, ein nicht-vertrauter Benutzer schreibt ein DTML-Dokument oder Python-Skript, das alle Seiten auf ihrer Site löschen soll. Wenn er versucht, die Seite aufzurufen, wird das scheitern, denn er hat die entsprechenden Berechtigungen nicht. Wenn ein Manager diese Seite aufruft, wird es auch scheitern, obwohl der Manager die entsprechenden Berechtigungen zur Durchführung der gefährlichen Aktion hat.

Zope benutzt die Besitzer-Informationen und die Kontrollen über ausführbare Inhalte, um diesen begrenzten Schutz zu gewähren.

Besitzerschaft verwalten

Wenn ein Benutzer ein Zope-Objekt anlegt, besitzt (own) er das Objekt. Ein Objekt, daß keinen Besitzer hat, wird als unbesessen (unowned) bezeichnet. Informationen zur Besitzerschaft werden im Objekt selbst gespeichert. Das ist so ähnlich, wie UNIX den Besitzer einer Datei behält.

Sie können herausfinden, wem ein Objekt gehört, indem Sie die Rewgisterkarte Ownership aufrufen, wie in Bild 6.6 zu sehen.

Bild 6.6 Besitzereinstellungen verwalten.

Dieser Bildschirm sagt Ihnen, ob das Objekt besessen wird und wenn ja, von wem. Wenn das Objekt von jemand anderem besessen wird und Sie haben die Berechtigung zur Besitzübernahme (Take ownership), können Sie die Besitzerschaft an einem Objekt übernehmen. Sie haben auch die Option, alle Unter-Objekte zu übernehmen, wenn Sie die Box Take ownership of all sub-objects anklicken. Besitzerschaft zu übernehmen ist meist nützlich, wenn der Besitzer-Account gelöscht worden ist oder wenn Objekte zur Bearbeitung an Sie weitergeleitet worden sind.

Wie wir oben erwähnt haben, hat Besitzerschaft Auswirkungen auf Sicherheitsregeln, weil ein Benutzer die lokale Rolle Besitzer (Owner) bei besessenen Objekten hat. Dennoch betrifft Besitzerschaft die Sicherheit, weil sie den ausführbaren Inhalt der Rolle kontrolliert.

Rollen ausführbarer Inhalte

Sie können manche Skripte in mancher Art Zope-Objekte durch das Web bearbeiten. Diese Objekte beinhalten DTML-Dokumente, DTML-Skripte, SQL-Skripte, Python-basierte Skripte und Perl-basierte Skripte. Diese Objekte werden als ausführbar bezeichnet, weil sie Skripte aufrufen, die durch das Web bearbeitet werden können.

Wenn Sie ein ausführbares Objekt besuchen, indem Sie zu seinem URL gehen oder es über DTML oder ein Skript aufrufen, führt Zope das Skript des Objekts aus. Dieses Skript wird beschränkt durch die Rollen des Besitzers dieses Objektes und ihren eigenen Rollen. Mit anderen Worten: Ein ausführbares Objekt kann nur Aktionen durchführen, für die sowohl der Besitzer als auch der Betrachter berechtigt sind. Das hält einen unprivilegierten Benutzer davon ab, ein schädliches Skript zu schreiben und dann einen mächtigen Benutzer dazu zu bringen, es auszuführen. Sie können niemand anders dazu bringen, etwas zu tun, wozu Sie selbst nicht berechtigt sind. So nutzt Zope serverseitig Besitzerschaft als Schutz gegen Trojaner-Angriffe.

Proxy Roles

Manchmal ist Zopes System von begrenztem Zugang zu ausführbaren Objekten nicht genau das, was Sie wollen. Manchmal mögen Sie Sicherheit an einem Objekt festklammern wollen, egal wer auch immer es besitzt oder ausführt, als eine Form von Extra-Sicherheit. Zu anderen Zeiten werden Sie ein ausführbares Objekt mit besonderem Zugang bereitstellen wollen, um einem unprivilegierten Betrachter zu erlauben, geschützte Aktionen durchzuführen. Proxy-Rollen (Proxy roles) ermöglichen Ihnen, die Rollen eines ausführbarenm Objektes zu bearbeiten.

Nehmen wir an, Sie wollen eine Mail-Form anlegen, die es anonymen Benutzern erlaubt, dem Webmaster ihrer Site eMails zu schicken. Das Senden von eMails wird durch die Berechtigung Use mailhost services geschützt. Anonyme Benutzer dürfen diese Berechtigung normalerweise aus gutem Grund nicht haben. Sie wollen nicht, daß absolut jeder anonyme eMails über ihren Zope-Server versenden darf.

Das Problem mit dieser Einstellung ist, daß ihr DTML-Skript zum Senden von eMails für anonyme Benutzer nicht funktionieren wird. Wie können sie dieses Problem umgehen? Die Antwort ist, die Proxy-Rollen für ihr DTML-Skript zum Senden von eMails so zu setzen werden, daß es bei der Ausführung die "Manager"-Rolle hat. Gehen Sie zur Registerkarte Proxy Management ihres DTML-Skripts wie in Bild 6.7 gezeigt.

Figure 6.7 Verwaltung von Proxy-Rollen.

Wählen Sie Manager und klicken auf den Change-Button. Das wird die Proxy-Rollen des eMail-sendenden Skripts auf Manager setzen. Beachten Sie, daß Sie selbst die Manager-Rolle haben müssen, um sie als Proxy-Rolle festzulegen. Wenn nun irgendjemand - anonym oder nicht - ihr eMail-sendendes Skript aufruft, wird es mit der Manager-Rolle ausgeführt und daher autorisiert sein, eMails zu senden.

Proxy-Rollen definieren ein festgelegtes Set von Berechtigungen für ausführbare Inhalte. Daher können Sie sie genausogut benutzen, um Sicherheit einzuschränken. Wenn Sie zum Beispiel die Proxy-Rollen eines Skripts auf Anonymous setzen, wird das Skript nie irgendeine andere Rolle ausführen als Anonymous, ungeachtet der Rollen don Besitzer oder Betrachter.

Benutzen Sie Proxy-Rollen vorsichtig, da sie an den voreingestellten Sicherheitseinschränkungen vorbei benutzt werden können.

Zusammenfassung

Sicherheit besteht aus zwei Prozessen: Authentifizierung und Autorisierung. Benutzer-Ordner kontrollieren Authentifizierung, Sicherheitsregeln kontrollieren Autorisierung. Zope-Sicherheit ist eng an das Konzept des Ortes gebunden; Benutzer haben einen Ort, Sicherheitsregeln haben einen Ort, sogar Rollen können einen Ort haben. Der Aufbau einer wirksamen Sicherheitsarchitektur verlangt Aufmerksamkeit für den Ort. Im Zweifel halten Sie sich an die Anmwendungsmuster für Sicherheit, die in diesem Kapitel diskutiert worden sind.

Im nächsten Kapitel werden wird hochschalten und fortgeschrittene DTML untersuchen. DTML kann ein sehr mächtiges Werkzeug für Präsentation und Scripting sein. Sie werden etwas über viele neue Tags herausfinden und einen Blick auf einige DTML-spezifische Sicherheitskontrollen herausfinden, die in diesem Kapitel nicht behandelt worden sind.