-
HINTERGRUND
-
Webhosting-Organisationen handhaben oft komplexe Operationen, wobei sie tausende, zehntausende und hunderttausend oder mehr Website-Kunden auf einem einzelnen Server oder einem Serverpark hosten. Performance- und Sicherheitsanforderungen erfordern genaue Aufmerksamkeit, so dass der breitest verfügbare Zugriff auf Inhalt angeboten wird, während angemessene Sicherheit von Daten jedes Kunden aufrecht erhalten ist.
-
Das Niveau und der Typ von Sicherheit, welche erforderlich ist, wenn nur statischer Inhalt (z. B..html, jpeg) geliefert wird, ist ziemlich verschieden von der Sicherheit, welche angewendet werden muss, wenn dynamischer Inhalt (z. B. ausführbare Daten, Skripte) geliefert werden. Um zusätzlich zu verhindern, dass Website-Besucher Inhalt betrachten, auf welchen Zugriff beschränkt ist (z. B. Passwort-geschützte Seiten), ist es notwendig, dynamischen Inhalt weiter zu beschränken, so dass Skripte (oder anderer ausführbarer Inhalt, welcher innerhalb einer geteilten Serverumgebung verarbeitet wird) eines Kunden nicht in der Lage sind, auf innerhalb derselben Umgebung gespeicherte Daten eines anderen Kunden zuzugreifen.
-
Wenn zum Beispiel nur statischer Inhalt erlaubt ist und alle Besucher autorisiert sind, den gesamten gehosteten Inhalt zu betrachten (z. B. keine Kunden setzen Anmeldeschemata (logon schemes) ein, um Zugriff zu filtern), dann sind Sicherheitsbedürfnisse relativ gleichförmig und grundlegend. Wenn jedoch Skripten und/oder ausführbaren Bildern erlaubt ist, innerhalb einer geteilten Webserver-Umgebung abzulaufen, wird der Bereich von Aktionen, welche ein Kunde den Webserver anweisen kann, diese in seinem Interesse durchzuführen, signifikant erhöht. Insbesondere können Kundenskripte böswillig oder zufällig (z. B. durch schlechtes Programmieren) Daten eines anderen Kunden beschädigen, zerstören oder auf andere Weise unerlaubt darauf zugreifen.
-
Wenn Sicherheitsbeschränkungen aber zu stringent sind, kann Zugriff auf ein bestimmtes Stück von Inhalt irrtümlicherweise behindert sein, Zugriff auf autorisierten Inhalt kann verzögert sein, Handhabbarkeit des Servers und des Inhalts kann aufgrund lästiger Sicherheitserwägungen sehr komplex werden, usw. Das Ergebnis ist eine ineffiziente Webhosting-Lösung, welche die Bedürfnisse von Kunden nicht adäquat bedient.
-
Selbst während adäquate Sicherheitsmaßnahmen durchgesetzt werden müssen, um Daten jedes Kunden vor anderen Kunden zu schützen, sollte die Möglichkeit aufrecht erhalten werden, Website-Besucher automatisch und anonym anzumelden (logon). Dies erlaubt ihnen, anonym mit dem Website-Inhalt ohne die Unbequemlichkeit, Anmeldeberechtigungen von einer zentralisierten Autorität (z. B. einen Benutzernamen und -passwort, ein digitales Zertifikat) zu erhalten, zu interagieren. Insbesondere ist es nützlich und wünschenswert, Besuchern anonymen Zugriff zu geben, während erlaubt ist, dass Kundenskripte im Interesse der Besucher im Hintergrund ablaufen.
-
Existierende Versuche, einen Webserver zu sichern, während automatische und anonyme Anmeldungen noch erlaubt sind, sind inadäquat oder ineffektiv, insbesondere wenn dynamischer Inhalt (z. B. Skripte) geliefert wird. In vielen Webhosting-Umgebungen werden zum Beispiel alle anonymen Inhaltbetrachter automatisch bei dem Webserver unter Benutzung desselben Serverkontos unabhängig von dem Inhalt, auf welchen sie zugreifen (z. B. eine statische Website, ein Bild, ein Skript, ein ausführbares Datum), angemeldet. Dieser Typ von Lösung löst nicht das Problem, zu versuchen, Zugriff auf Daten eines Kunden von Skripten eines anderen Kunden aus zu beschränken.
-
Wenn alle anonymen Website-Besucher ein Konto teilen, teilen sie einen Sicherheitskontext und es gibt keinen inhärenten oder einfachen Weg, einen Betrachter von einem anderen zu differenzieren. Daher kann ein File-Server, der Webserver oder ein anderer Bevollmächtigter eines Zugriffs auf gespeicherte Daten nicht leicht zwischen denjenigen differenzieren, welchen Zugriff auf eine gegebene Inhaltsdatei erlaubt werden sollte und welchen nicht. Wenn nicht alle Besucher (und alle Skripte, welche als ein Ergebnis einer Betrachtung einer Seite ablaufen) Zugriff auf den gesamten Inhalt haben, werden individuelle Kunden (oder andere involvierte Entitäten) im Allgemeinen Benutzerkonten zuzuordnen haben (und zu verteilen haben), um Anmeldeprozeduren zum Zugreifen auf geschützten Inhalt zu implementieren.
-
Wenn insbesondere ausführbarer Inhalt (z. B. Skripte, ausführbare Daten) auf einem Webserver geliefert wird, muss Sicherheit robust konfiguriert sein, um unautorisierten Zugriff auf gespeicherte Daten zu verhindern, aber ohne eine annehmbare Performance zu opfern. Ein Teil der Sicherheitsanforderung bringt ein Bedürfnis mit sich, Kunden und ihre Daten zu trennen oder zu segregieren, so dass dynamischer Inhalt von einem Kunden nicht benutzt werden kann, auf geschützte Daten eines anderen Kunden zuzugreifen.
-
Zum Beispiel könnte ein Kunde ein Skript erzeugen, welches versucht, alle Dateien auf dem Webserver, alle Dateien innerhalb einer Ordnerstruktur eines anderen Kunden zu löschen, oder zu einem anderen Schaden zu führen. Lösungen für dieses Problem sind aufgrund des Bedürfnisses, Betrachtern von Kundeninhalt zu erlauben, sich anonym und automatisch zu verbinden, kompliziert.
-
Einige Middleware-Software oder Software auf Anwendungsniveau versucht, Sicherheitswächter (safeguards) gegen unautorisierten Zugriff durch Benutzer dieser Software zu liefern. Zum Beispiel umfasst PHP (PHP-Hypertext-Prozessor) einen Sicherheitsoperationsmodus, welcher versucht, die Fähigkeit eines anonymen Inhaltbetrachters oder-benutzers, zu Schaden zu führen, wenn ein PHP-Skript abläuft, zu vermindern. Wie praktisch sämtliche Software auf Anwendungsniveau hat er aber Löcher, welche ausgenutzt werden können.
-
Eine andere Lösung für das Bedürfnis nach einem Sicherheitsschema, zu erlauben, dynamischen Inhalt sicher zu liefern, ohne Performance drastisch zu berühren, involviert die Benutzung von virtuellen Maschinen. In diesem Schema wird eine virtuelle Maschine oder ein virtueller Server für jeden Kunden auf dem Server erstellt. Wegen des Erfordernisses, viele virtuelle Umgebungen zu etablieren, ist diese Lösung prozessorintensiv und kann sehr kostenintensiv sein, weil Ressourcen auf jeder virtuellen Maschine lizenziert werden müssen. Weiterhin müsste eine Abbildungsressource eingesetzt werden, um Inhaltbetrachter auf die virtuelle Maschine des korrekten Kunden abzubilden.
-
IIS (Internet-Informationsdienste (Internet Information Services)) von Microsoft® umfasst eine zugeordnete Metabase, welche statisch kodierte URLs (Uniform Resource Locator) - welche Inhalt entsprechen, nach dem Betrachter nachfragen können - auf ein bestimmtes Benutzerkonto abbildet, um es auf jede Anfrage anzuwenden. Eine Metabase ist jedoch in ihrer Kapazität (d. h., wie viele Abbildungen sie speichern kann) begrenzt und kann nicht skalieren, um einen Webserver zu unterstützen, welcher Inhalt von zehntausenden oder hunderttausenden von Websites liefert.
-
Wenn mehrere Webserver und Metabasen zu implementieren wären, um eine große Zahl von Websites zu hosten, würden weitere Komplikationen auftreten. Weil eine Metabase eine begrenzte Kapazität hat, erfordert ein Unterstützen einer Anzahl von Sites, welche größer ist als die Kapazität einer Metabase, dass Inhaltanfragen vorverarbeitet werden. Vorverarbeitung führt dazu, dass jede Anfrage an den korrekten Server geleitet wird (d. h. an den Server mit der Metabase, welche der angefragten Website entspricht).
-
Weil Redundanz beim Liefern von Websites wünschenswert ist, würde jede Metabase unter einem Pool von Servern repliziert werden, um Ausfallsicherungsschutz bereitzustellen. Dies kann eine Herausforderung an ein Teilen von Metabasen stellen, insbesondere wenn die gehosteten Websites dynamisch sind - was bedeutet, dass sie sich nach der Laune des Kunden ändern, vielleicht ihre Namenskriterien modifizieren, einen Webservice entfernen, etc.
-
Lösungen, welche zu einer Datenverdoppelung ohne adäquate Werkzeuge zum Handhaben der Replikation dieser Daten führen, haben sich als kostenintensiv und fehleranfällig erwiesen. Weitere Ausgaben werden erlitten, wenn Server bereitgestellt werden, um Gruppen von verschiedenen Metabasen anstatt eine einzelne Metabase zu unterstützen.
-
Ein anderes Problem mit dem Unterstützen von anonymem Zugriff auf Inhalt auf einem Webserver ist die Mühe, wiederholt einen Domaincontroller (oder eine andere Authentifikationsentität) zu kontaktieren, um jede virtuelle Betrachtersitzung zu autentifizieren (z. B. jede Anfrage an einem voreingestellten anonymen Benutzerkonto anzumelden (logon)). Diese Bemühung kann nicht nur in dem Webserver zu einem Performanceabfall führen, sondern auch in einem Filer, welcher SMB (Server Message Block)-Netwerk-Logons annimmt, welche einer Webserver-Anmeldungssitzung (logon session) zugeordnet sind.
-
Cachen von anonymen Anmeldungssitzungen auf einem Webserver ist typischerweise nicht durchführbar, insbesondere wenn Betrachteranfragen nach Inhalt unter mehreren Prozessen verteilt sind, weil ein Logon-Handle oder Kontext standardmäßig nur in dem Prozess gültig ist, in welchem es bzw. er geladen wurde. Anfragen können unter mehreren Prozessen verteilt sein, um verhindern zu helfen, dass ein böswilliges oder fehlerhaftes Skript eines Kunden das Ablauferleben (run-time experience) anderer Betrachter nachteilig berührt. Existierende Anmelde-Caching-Schemata erlauben keine Inter-Prozess-Kommunikation, um das Teilen von Logon-Handles zu erlauben, und der Zuschlag (overhead) zum Etablieren von separaten Caching-Schemata für jeden Prozess würde wenig oder keinen Gesamtvorteil geben.
US 5,923,842 offenbart ein Verfahren zum Zulassen einer anonymen Benutzeranmeldung an einem Computer beginnend, wenn eine Anwendungsanforderung von einem Client empfangen wird. Der nächste verfügbare anonyme Benutzername wird bestimmt und der Anwendungsanfrage des Clients zugewiesen. Der anonyme Benutzername wird authentifiziert und eine neue Sitzung wird erstellt, die die Anwendung aufruft, auf die die Anwendungsanforderung des Clients abzielt. Wenn der Client die Ausführung der Anwendung beendet, wird der Name des anonymen Benutzers an den Pool anonymer Benutzernamen zurückgegeben und steht zur Neuzuweisung an den nächsten anonymen Benutzer zur Verfügung.
-
ZUSAMMENFASSUNG
-
In einigen Ausführungsformen der Erfindung sind ein System und Verfahren zum Segregieren von Zugriff auf dynamischen Inhalt auf mehreren durch einen Webserver gehosteten Websites, während Logon-Handles oder Logon-Merkmale (tokens) zum Teilen unter mehreren Prozessen gecacht werden, bereitgestellt.
-
Wenn eine Anfrage nach dynamischem Inhalt von einer Website empfangen ist, wird sie in diesen Ausführungsformen zuerst einem voreingestellten anonymen Benutzerkonto zugeordnet (z. B. angemeldet als). Ein UserRetriever-Filtermodul ruft dann einen Benutzernamen und Passwort, welche der Website entsprechen, von einer Datenbank ab, welche verschieden von dem Webserver ist und für andere Zwecke benutzt wird (z. B. Abrechnung, Website-Domain-Information, Dienstbereitstellung, Identifizieren, wo Inhalt gespeichert ist). Die Datenbank agiert als eine zentrale Datenquelle für einen Betrieb des Webservers und umgeht das Erfordernis für eine spezialisierte Datenbank, welche lediglich zwischen angefragtem Inhalt und Benutzerkonten, welche für die Anfrage benutzt werden können, abbildet (beispielsweise eine Metabase, welche mit IIS implementiert ist).
-
Basierend auf dem durch das UserRetriever-Modul erhaltenen Benutzernamen und Passwort fragt ein Userlmpersonator-Erweiterungsmodul nach einem Logon-Handle oder Token für diesen Benutzernamen von einem Logon-Cache-Manager an und kann den Benutzernamen und Passwort bereitstellen. Der Cache-Manager meldet sich als dieser Benutzer an (logs on), wenn ein Handeln nicht gecacht ist, verdoppelt dann das angefragte Logon-Handle und gibt es zurück. In diesen Ausführungsformen der Erfindung ist das Benutzerkonto mit geeigneten Rechten konfiguriert, um auf den angefragten Inhalt zuzugreifen, nicht aber andere Websites auf demselben Server oder Filer zu betrachten, zu modifizieren oder mit diesen zu interagieren.
-
Das Logon-Handle ist an die Anfrage gebunden, so dass die Anfrage unter Benutzung des imitierten Benutzerkontos anstatt des voreingestellten anonymen Benutzerkontos, welchem die Anfrage anfänglich zugeordnet war, beendet wird. Der dynamische Inhalt wird abgerufen und als dieses spezifische, eingeschränkte, imitierte Benutzerkonto geliefert; daher können auf diesem Ausführungsthread operierende Kommandos nur auf Ressourcen zugreifen, welche explizit erteilte Rechte für diesen Benutzer haben. Nachdem der Inhalt abgerufen ist oder die Skript-Verarbeitung beendet ist, wird das angewendete Logon-Handle abgezogen und die Anfrage wird wieder dem voreingestellten anonymen Benutzerkonto zugeordnet, bevor die Anfrage terminiert wird.
-
In einigen Ausführungsformen kann eine Imitierung von Benutzerkonten, um Zugriff auf Inhalt einer Website auf ein Benutzerkonto zu beschränken, welches dieser Site entspricht, wie oben beschrieben, implementiert werden, ohne Logon-Handles zu cachen.
-
Figurenliste
-
- 1 ist ein Blockdiagramm, welches eine Webhosting-Umgebung zeigt, in welcher Ausführungsformen der vorliegenden Erfindung implementiert werden können.
- 2 ist ein Flussdiagramm, welches ein Verfahren eines Segregierens von anonymem Zugriff auf dynamischen Inhalt in einer Webhosting-Umgebung in Übereinstimmung mit einer Ausführungsform der Erfindung illustriert.
- 3 ist ein Flussdiagramm, welches ein Verfahren eines Cachens von Logon-Handles zur Benutzung in mehreren gleichzeitigen Prozessen in einer Webhosting-Umgebung in Übereinstimmung mit einer Ausführungsform der Erfindung illustriert.
- 4 zeigt eine Datenstruktur zum Anfragen nach einem gecachten Logon-Handle in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
-
DETAILLIERTE BESCHREIBUNG
-
Die folgende Beschreibung ist präsentiert, um irgendeinem Fachmann in der Technik zu ermöglichen, die Erfindung durchzuführen und zu benutzen, und ist in dem Kontext von bestimmten Anwendungen der Erfindung und ihrer Anforderungen bereitgestellt. Verschiedene Modifikationen zu den offenbarten Ausführungsformen werden für die Fachleute in der Technik leicht offensichtlich sein und die hierin definierten allgemeinen Prinzipien können auf andere Ausführungsformen und Anwendungen angewendet werden, ohne von dem Geltungsbereich der vorliegenden Erfindung abzuweichen. Somit ist die vorliegende Erfindung nicht beabsichtigt, auf die gezeigten Ausführungsformen begrenzt zu sein, sondern ist in dem breitesten Geltungsbereich zu gewähren, welcher mit den hierin offenbarten Prinzipien und Merkmalen konsistent ist.
-
In einigen Ausführungsformen der Erfindung sind ein System und ein Verfahren zum Segregieren oder Isolieren von Inhalt von Kunden in einem Webserver, welcher dynamischen Inhalt (z. B. Skripte, ausführbare Daten) für mehrere Kunden (wobei jeder Kunde eine gehostete Website repräsentiert), derart liefert, dass der dynamische Inhalt jedes Kunden gehindert ist, ohne Erlaubnis auf Daten anderer Kunden zuzugreifen, bereitgestellt.
-
In einer Implementierung verbinden sich Betrachter (z. B. Internet-Benutzer) mit dem Webserver anonym (und sind anfänglich einem voreingestellten anonymen Benutzerkonto zugeordnet). Basierend auf dem Inhalt, nach dem sie angefragt haben, werden sie (oder ihre Anfragen) dann in einem Benutzerkonto angemeldet (logged), welches dem Kunden zugeordnet ist, der den angefragten Inhalt besitzt. Diesem Benutzerkonto werden Zugriffsrechte für den Inhalt des zugeordneten Kunden zugeteilt, diesem Benutzerkonto wird aber verwehrt, auf Inhalt anderer Kunden zuzugreifen. Weil das Benutzerkonto, wie der Inhalt, durch das Betriebssystem definiert ist, kann der Betriebssystemmechanismus zum Kontrollieren von Ressourcenzugriff (z. B. eine Zugriffskontrollliste (Access Control List) oder ACL)) ausgenutzt werden.
-
In einigen Ausführungsformen der Erfindung ist ein Schema zum Cachen von Anmeldungssitzungen auf einem Webserver bereitgestellt. Diese Ausführungsform kann implementiert werden, um zu erlauben, dass eine einzelne Anmeldung (logon) in ein Benutzerkonto, welches einer Kunden-Website zugeordnet ist, unter mehreren Prozessen geteilt wird, welche Anfragen nach Inhalt von dieser Website handhaben. Performance des Webservers ist erhöht, weil er nicht für jede Anfrage, welche auf diese Website abzielt, einen Domain-Controller oder einen anderen Authentifizierungsagenten aufrufen muss, und das Caching wird durch einen zentralen Prozess durchgeführt anstatt dass es parallel durch die mehreren Anfragehandhabungsprozesse durchgeführt wird.
-
1 ist ein Blockdiagramm einer Webhosting-Umgebung, in welcher einige Ausführungsformen der Erfindung implementiert werden können. Filer(s) 110, welche irgendeine Zahl von Filern oder Dateiservern (fileservers) umfassen können, speichern Inhalt von ungefähr einhunderttausend Kunden-Websites. Ähnlich arbeiten Webserver(s) 120 kooperativ, um Betrachtern 140 Kundeninhalt zu liefern. Betrachter/Benutzer können sich direkt oder durch ein Lokal- oder Fernbereichsnetzwerk (z. B. das Internet) mit den Webservern verbinden.
-
Filers 110 und Webserver 120 können nebeneinander stehen oder geografisch verteilt sein. Jeder Webserver ist in der Lage, Inhalt von jeder Kunden-Site unabhängig davon, auf welchem Filer der Inhalt gespeichert ist und welche Website den Inhalt besitzt, zu liefern.
-
Datenbank 150 kann durch die Organisation betrieben werden, welche Webserver 120 betreibt, und speichert operationale Daten und/oder Managementdaten, wie etwa die Adressen/Orte von Filer(n) 110, Orte von Inhalt oder Pfade zu Inhalt von Kunden, welches Benutzerkonto zum Zugriff auf Inhalt jedes Kunden (und das entsprechende Passwort) zu verwenden ist, Abrechnungsdatensätze, Dienstbereitstellungsinformation (z. B. Plattenplatz, Bandbreite), Website-Domain-Name(n), Login- und Benutzungsstatistik, Vermarktungsinformation, etc. Viele dieser Attribute sind nicht in einer Metabase gespeichert.
-
Ein Webserver 120 umfasst IIS (Internet Information Services)-Software 122 oder irgendeine andere Webservice-Software (z. B. Apache). Der Webserver ist konfiguriert, durch den Kunden angebotenen dynamischen Inhalt, wie etwa Skripte und/oder ausführbare Dateien, zu liefern (serve). Illustrative Skriptsprachen, welche unterstützt sein können, umfassen, sind jedoch nicht darauf beschränkt, PHP, ASP (Acitve Server Pages) und JSP (Java Server Pages). Daher umfasst Webserver 120 Maschinen, Interpreter oder Parser, wie benötigt, um die Skriptsprachen zu unterstützten, wie durch PHP-Maschine 122 exemplifiziert.
-
Webserver 120 umfasst auch verschiedene ISAPI (Internet Server Application Programming Interface)-Filter und -Erweiterungen, wie etwa UserRetriever-Modul 124 (ein ISAPI-Filter) und Userlmpersonator-Modul 126 (eine ISAPI-Erweiterung).
-
In der illustrierten Ausführungsform der Erfindung ist UserRetriever 124 konfiguriert, auf Datenbank 150 zuzugreifen, wenn eine Betrachteranfrage nach Inhalt bei Webserver 120 empfangen ist. Das UserRetriever-Modul ruft einen Benutzernamen und ein Passwort ab, welches für die Anfrage (basierend auf der Inhaltanfrage) zu benutzen ist und möglicherweise andere Information (z. B. Stelle des angefragten Inhalts oder Pfad zu dem angefragten Inhalt).
-
Einiges oder ein Gesamtes der abgerufenen Information wird an Userlmpersonator 126 übergeben, welcher ein Anmeldungsmerkmal (logon token) für das Benutzerkonto an den Thread bindet, welcher eine Betracherinhaltanfrage abwickelt. Die Anfrage wird dann an eine Skriptmaschine (script engine) oder einen anderen Prozess übergeben, welcher konfiguriert ist, tatsächlich den Inhalt abzurufen und zu liefern, während das durch UserRetriever 124 identifizierte Benutzerkonto imitiert (impersonate) wird.
-
Insbesondere ruft ein Prozess oder ein Thread, welcher eine Inhaltanfrage bedient, (z. B. eine Instanz von Userlmpersonator 126) Cache-Manager 128 mit dem vorher von Datenbank 150 abgerufenen Benutzernamen und Passwort, anstatt die Anmeldung (logon) selbst durchzuführen. Der Cache-Manager durchsucht seinen Cache nach einem Logon-Handle für dieses Benutzerkonto, verdoppelt das Handle und gibt es an den Anfrager zurück. Wenn es nicht gefunden wird, ruft er den geeigneten Anmeldungsdienst (logon service) auf (z. B. Windows' LogonUser), cacht das resultierende Handle, verdoppelt es und liefert es an den Anfrager.
-
Wie oben angezeigt, hält Cache-Manager 128 einen Cache von Logon-Handles oder Tokens zum Teilen unter den Prozessen und/oder Threads, welche Inhaltanfragen bedienen (serve). Der Cache (in 1 nicht gezeigt) kann eine Hash-Tabelle (hash table), eine Datenbank, eine flache Datei (flat file) oder irgendeine andere Struktur umfassen.
-
In einigen Ausführungsformen der Erfindung kann Cache-Manager 128 ausgelassen werden, in welchem Fall Logon-Handles für Benutzerkonten nicht gecacht werden müssen. Stattdessen kann jede Instanz von Userlmpersonator 126 das geeignete Anmeldungsdienstprogramm (logon utility) direkt aufrufen.
-
In einigen anderen Ausführungsformen der Erfindung können entweder UserRetriever 124 oder Userlmpersonator 126 oder beide gemeinsam ausgelassen werden oder durch andere Entitäten ersetzt werden, welche dieselben oder ähnliche Funktionen durchführen. In noch anderen Ausführungsformen kann irgendeine der in 1 illustrierten Komponenten kombiniert oder weiter unterteilt sein.
-
2 ist ein Flussdiagramm, welches ein Verfahren eines Erleichterns des Lieferns von dynamischem Inhalt von mehreren Kunden-Websites, ohne zu erlauben, dass Inhalt eines Kunden auf Inhalt eines anderen zugreift, gemäß einer Ausführungsform der vorliegenden Erfindung demonstriert.
-
In Operation 202 fragt ein Betrachter über seinen oder ihren Browser nach dynamischem Inhalt von einer Kunden-Website an (z. B. z.php). Obwohl das illustrierte Verfahren der Erfindung beschrieben ist, wie es in Bezug auf ein PHP-Skript durchgeführt werden kann, werden gewöhnliche Fachleute in der Technik schätzen, wie dieses Verfahren modifiziert werden kann, um mit anderen Typen von dynamischem Inhalt zu arbeiten (z. B. ASP-Skripte, JSP-Skripte, ausführbare Bilder), ohne den Geltungsbereich der vorliegenden Erfindung zu verlassen.
-
In Operation 204 wird die Anfrage des Betrachters an einen Webserver geliefert. In einer illustrativen Implementierung dieser Ausführungsform der Erfindung kann eine Organisation ein Cluster, eine Farm oder eine andere kooperative Zusammenstellung von mehreren Webservern (z. B. 5, 10) betreiben, von denen jeder in der Lage ist, Inhalt für jeden Kunden der Organisation zu liefern, von welchen Kunden es mehr als einhunderttausend geben kann. Ein Lastausgleicher (load balancer), Router oder eine andere Entität kann benutzt werden, Anfragen unter den Servern zu verteilen.
-
Betrachteranfragen können unter irgendeiner Zahl von Threads und/oder Prozessen verteilt werden. Zum Beispiel wird jede Anfrage einem verschiedenen Thread in einem Pool von Threads zugewiesen und irgendeine Anzahl von Threads kann durch einen gegebenen Prozess abgewickelt werden. In einer Implementierung wird jedoch ein Round-Robin (oder ein anderes Ablaufschema) benutzt, um Betrachterinhaltanfragen unter mehreren Prozessen (z. B. 100) zu verteilen. Die Anzahl von Prozessen ist begrenzt, um Ressourcen-Wettbewerb zu minimieren und Prozessisolation zu begünstigen, was Stabilität und Sicherheit erhöht. Dies hilft sicherzustellen, dass das Erleben jedes Betrachters soviel wie möglich von Erleben anderer Betrachter entkoppelt ist.
-
In Operation 206 hört ein Horcher (listener) auf dem Webserver die Anfrage und bindet daran einen Sicherheitskontext für einen voreingestellten anonymen Benutzer. In verschiedenen Ausführungsformen der Erfindung kann verschiedene Webserver-Software ausgeführt werden, wie etwa IIS, Apache, Lighttpd, nginx, etc. Auch ruft in Operation 206 der Webserver UserRetriever 124 (der 1) oder einen anderen kundenspezifischen ISAPI-Filter oder eine ähnliche Entität auf.
-
In Operation 208 führt der UserRetriever-Filter ein Nachschauen in einer Datenbank durch, welche nicht eng an den Webserver gebunden ist. Wenn der Webserver IIS ist, wird somit das Nachschauen nicht in der zugeordneten Metabase durchgeführt.
-
Insbesondere wird die Datenbank durch den Operator des Webservers zusätzlich zum Identifizieren von Benutzerkonten zur Benutzung für Segregieren von anonymem Zugriff auf dynamischen Inhalt von verschiedenen Websites für andere Zwecke benutzt. Zum Beispiel kann die Datenbank für Abrechnung von Kunden-Websites, Nachverfolgen von Verkehrsmustern (tracking traffic patterns), etc. verwendet werden. Weil die Datenbank aktualisiert wird, immer wenn sich eine Konfiguration der Webdienstumgebung ändert (z. B. wenn eine Website ihren Namen ändert, eine Website hinzugefügt oder entfernt wird), wird sie immer die momentane Konfiguration reflektieren.
-
Wenn an Stelle dieser separaten Datenbank zum Identifizieren von Benutzerkonten zu benutzen, um auf Anfragen nach dynamischem Inhalt anzuwenden, eine dem Webserver zugeordnete oder an diesen gebundene Datenbank benutzt würde, um zu bestimmen, welches Benutzerkonto für eine Inhaltanfrage anzuwenden ist (z. B. die Metabase, welche IIS aufnimmt), würde sich eine unnötige Verdopplung ergeben. Dies würde den Prozess eines Handhabens einer Webserver-Konfiguration und -Operation signifikant komplizieren (z. B. müsste Synchronisierung aufrechterhalten werden) und würde auch Skalierbarkeitsprobleme einführen, wie oben beschrieben.
-
Das Nachschauen in der Datenbank basiert auf dem angefragten Inhaltartikel (content item) (z. B. die exakte URL, nach welcher angefragt wurde, ein Muster, welches mit der angefragten URL übereinstimmt) und gibt einen Benutzernamen und ein Passwort zurück, was benutzt wird, dem Anfragethread einen verschiedenen Sicherheitskontext zuzuweisen - einem Kunden1 zugeordneten Kontext. Das Nachschauen kann auch eine Stelle (location) des angefragten Inhalts (z. B. Pfad, Netzwerkadresse) zurückgeben.
-
In dieser Ausführungsform der Erfindung wird Zugriff auf die Filer, Dateiserver oder andere Speichergeräte, welche Kundeninhalt enthalten, durch Zugriffskontrolllisten oder andere durch das Betriebssystem durchgesetzte Mittel kontrolliert. Jeder Kunde ist (in der Datenbank) einem Benutzerkonto zugeordnet, welches die richtigen Sicherheitsberechtigungen zum Zugreifen auf Inhalt dieses Kunden, aber nicht auf Inhalt anderer Kunden hat.
-
Nachdem das Nachsehen beendet ist, wird die Kontrolle des Threads an den Webserver zurückgegeben. Der Webserver ruft eine kundenspezifiche ISAPI-Erweiterung auf, welche PHP-Skripten zugeordnet ist - in diesem Fall Userlmpersonator 126 der 1. Verschiedene kundenspezifische ISAPI-Erweiterungen können für verschiedene Typen von dynamischem Inhalt konfiguriert sein oder mehrere Typen können durch eine einzige kundenspezifische Erweiterung abgewickelt werden. Mehrere Instanzen von Userlmpersonator können parallel, in separaten Prozessen ausführen.
-
In Operation 210 bindet Userlmpersonator ein Logon-Token für den in dem Nachschauen von Operation 208 abgerufenen Benutzernamen (z. B. Kundenbenutzer1) unter Benutzung des abgerufenen Passwortes an den Anfragethread und setzt den Threadkontext, um mit diesem Benutzerkonto übereinzustimmen.
-
In verschiedenen Ausführungsformen der Erfindung kann Userlmpersonator das Logon-Token oder Logon-Handle in verschiedenen Weisen erhalten. 3 beschreibt zum Beispiel ein Verfahren, in welchem ein Cache-Manager (z. B. Cache-Manager 128 der 1) Logon-Handles zum Teilen unter mehreren Prozessen cacht. In anderen Ausführungsformen der Erfindung kann Userlmpersonator ein Logon-Handle durch Aufrufen des geeigneten Logon-Dienstprogramms oder -Dienstes (z. B. Windows' LogonUser) direkt erhalten.
-
In Operation 212 wird eine Maschine (engine), ein Interpreter, Parser oder ein anderes Modul, welches in der Lage ist, den angefragten Inhalt auszuführen, aufgerufen, wie etwa eine PIP-Maschine. Die PHP-Maschine ruft den angefragten Inhalt ab (z. B. unter Benutzung des durch UserRetriever identifizierten Pfades) und zergliedert (parst) den Inhalt und führt den Inhalt aus. Weil das Skript innerhalb des dem Besitzer des angefragten Inhalts zugeordneten Sicherheitskontexts ausgeführt wird, kann der Inhalt korrekt ablaufen, aber ohne die Gelegenheit, Daten anderer Kunden zu berühren. Kontrolle des Threads wird dann an das Userlmpersonator-Modul zurückgegeben.
-
In Operation 214 werden der imitierte (impersonated) Sicherheitskontext und das Logon-Token abgezogen und der voreingestellte anonyme Benutzerkontext kann wieder daran gebunden werden, und das Verfahren endet.
-
3 ist ein Flussdiagramm, welches ein Verfahren zum Cachen von Logon-Handles auf einem Webserver zur Benutzung durch mehrere Prozesse zum Liefern von Inhalt gemäß einer Ausführungsform der Erfindung zeigt.
-
In Operation 302 wird eine Anfrage nach Inhalt von einer von mehreren Websites, welche auf einem Webserver gehostet sind, bei dem Webserver empfangen. Der Webserver kann nur ein Server von mehreren sein, welche kooperativ arbeiten, um Redundanz und Performance zu fördern, aber jeder Server ist konfiguriert, Inhalt für jede der Websites zu liefern. Mit anderen Worten, müssen Inhaltanfragen nicht an einen spezifischen Webserver (oder Untermenge von Servern) geleitet (routed) werden, welcher konfiguriert ist, nur einen Teil des Inhalts aller Websites zu liefern.
-
In Operation 304 wird ein Benutzerkonto mit einem Sicherheitskontext, welcher auf die Anfrage anzuwenden ist, identifiziert. In einer Implementierung kann das Konto, wie oben in Verbindung mit 2 beschrieben, identifiziert werden (z. B. durch Beziehen auf eine von dem Webserver getrennte Datenbank).
-
Insbesondere kann ein voreingestelltes anonymes Benutzerkonto und Sicherheitskontext auf die Anfrage angewendet werden, wenn sie bei dem Webserver empfangen ist, wonach ein kundenspezifisches Software-Modul aufgerufen werden kann, um Name und Passwort des Zielbenutzerkontos von einer von dem Webserver separaten Datenbank abzurufen. Verschiedene Benutzerkonten können für jede durch den/die Server gehostete Website spezifiziert werden.
-
In Operation 306 ruft ein Webserver-Prozess, welcher konfiguriert ist, Abwickeln der Inhaltanfrage zu erleichtern, einen Logon-Cache-Manager, einen anderen Prozess, welcher auf dem Server ausführt. Der Logon-Cache-Manager ist konfiguriert, einen Cache von Logon-Handles für die verschiedenen in der Datenbank identifizierten Benutzerkonten handzuhaben. Der aufrufende Prozess identifiziert sich selbst (z. B. durch eine Prozess-ID) und liefert das Benutzerkonto und Passwort für das Logon-Handle, welches er benötigt.
-
In Operation 308 durchsucht der Cache-Manager seinen Cache nach einem Logon-Handle, welches mit dem spezifizierten Benutzerkonto zusammenpasst. Wenn er eine Übereinstimmung findet, schreitet das Verfahren zu Operation 314 fort; andernfalls wird es bei Operation 310 fortgesetzt.
-
In Operation 310 ruft der Cache-Manager ein Anmeldungsdienstprogramm oder -dienst (logon utility or service) des Betriebssystems unter Benutzung des spezifischen Benutzernamens und des Passworts auf.
-
In Operation 312 empfängt der Cache-Manager ein Logon-Handle für das Benutzerkonto und speichert es indem Cache. Das Logon-Handle kann wie notwendig zum Beispiel in einen ganzzahligen Wert konvertiert werden.
-
In Operation 314 verdoppelt der Cache-Manager das Logon-Handle für das spezifizierte Benutzerkonto unter Benutzung eines Dienstprogrammes oder eines Dienstes, welches bzw. welcher durch das Betriebssystem angeboten ist (z. B. DuplicateHandle für Windows), für die durch den aufrufenden Prozess gelieferte Prozess-id.
-
In Operation 316 überträgt der Cache-Manager das Logon-Handle an den aufrufenden Prozess. In einer Implementierung kommunizieren der Cache-Manager und der aufrufende Prozess über benannte Pipes (named pipes), obwohl andere Verfahren einer Interprozess-Kommunikation in anderen Implementierungen eingesetzt werden können.
-
In Operation 318 bindet der aufrufende Prozess das verdoppelte Logon-Handle oder -Token an den der Inhaltanfrage zugeordneten Thread. Der Prozess fährt dann fort, die Anfrage aufzulösen oder übergibt sie einer anderen Entität, wie erforderlich (z. B. einer Skript-Maschine, welche konfiguriert ist, den Inhalt abzurufen und auszuführen, falls er ein Skript umfasst).
-
In einigen Ausführungsformen der Erfindung wird der Sicherheitskontext und das Logon-Handle des Zielbenutzerkontos von der Anfrage abgezogen, bevor die Anfrage terminiert wird.
-
4 zeigt eine Datenstruktur zum überführen einer Anfrage nach einem Logon-Handle an einen Logon-Cache-Manager gemäß einer Ausführungsform der Erfindung. In dieser Ausführungsform umfasst Logon-Handle-Anfragestruktur 410 Version 412, Größenfelder 414, 416, 418, Prozess-ID 424, Zielbenutzername 426 und Zielpasswort 428.
-
Prozess-ID 424 identifiziert den Prozess, welcher dem Logon-Cache-Manager die Logon-Handle-Anfrage unterbreitet hat, Zielbenutzername 426 identifiziert das Benutzerkonto, für welches nach einem Logon-Handle angefragt worden ist, und Zielpasswort ist das Passwort des Benutzerkontos, welches der Logon-Cache-Manager benötigen kann, um sich auf dieses Konto anzumelden (wenn ein Logon-Handle für das Konto momentan nicht gecacht ist). Größenfelder 414, 416 und 418 identifizieren die Größen von Datenfeldern 424, 426 bzw. 428.
-
Ein gewöhnlicher Fachmann in der Technik wird schätzen, dass Datenstrukturen mit anderen Formen entwickelt werden können, um das Cachen und Teilen von Logon-Handles zu erleichtern, ohne den Geltungsbereich der vorliegenden Erfindung zu verlassen.
-
Die Programmumgebung, in welcher eine vorliegende Ausführungsform der Erfindung ausgeführt ist, inkorporiert illustrativ einen Computer zum allgemeinen Zweck oder ein Gerät für einen Spezialzweck, wie etwa ein handgehaltener Computer. Details solcher Geräte (z. B. Prozessor, Speicher, Datenspeicher, Anzeige) können zum Zwecke einer Klarheit ausgelassen werden.
-
Es sollte auch verstanden werden, dass die Techniken der vorliegenden Erfindung unter Benutzung verschiedener Technologien implementiert werden können. Zum Beispiel können die hierin beschriebenen Verfahren in Software implementiert werden, welche auf einem Computersystem ausführt, oder können in Hardware implementiert sein, welche entweder eine Kombination von Mikroprozessoren oder andere speziell entworfene anwendungsspezifische integrierte Schaltkreise, programmierbare Logikgeräte oder verschiedene Kombinationen davon benutzt.
-
Insbesondere können hierin beschriebene Verfahren unter Benutzung von Datenstrukturen und Programmcode, welche bzw. welcher auf einem geeigneten computerlesbaren Medium gelegen sind bzw. ist, was irgendein Gerät oder Medium sein kann, welches Daten und/oder Code für Benutzung durch ein Computersystem speichern kann, implementiert werden. Dies umfasst, ist jedoch nicht darauf beschränkt, volatilen Speicher, nicht-volatilen Speicher, magnetische und optische Speichergeräte, wie etwa Plattenlaufwerke, magnetische Bänder, CDs (Kompakt-Disks), DVDs (digitale vielfältige Platten oder digitale Videoplatten) oder andere Medien, welche in der Lage sind, computerlesbare Medien, welche nun bekannt oder später entwickelt werden, zu speichern.
-
Die vorangehenden Ausführungsformen der Erfindung sind nur für Illustrations- und Beschreibungszwecke präsentiert worden. Sie sind nicht beabsichtigt, erschöpfend zu sein oder die Erfindung auf die offenbarten Formen zu begrenzen. Demgemäß ist der Geltungsbereich der Erfindung durch die angehängten Ansprüche, nicht die vorgehende Offenbarung definiert.
