Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was ist .NET?
6 Installation
7 Die Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint Foundation und SharePoint Server
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
Windows Server 2012 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2012 R2

Windows Server 2012 R2
Rheinwerk Computing
1392 S., 4., aktualisierte Auflage 2014, geb.
59,90 Euro, ISBN 978-3-8362-2013-2
Pfeil 17 Webserver (IIS)
Pfeil 17.1 Begriffsdefinitionen
Pfeil 17.1.1 Webapplikation vs. Webservice
Pfeil 17.1.2 Website vs. Webseite
Pfeil 17.2 ASP.NET
Pfeil 17.2.1 Die Entwicklungsumgebung
Pfeil 17.2.2 Clientseitig: JavaScript
Pfeil 17.2.3 Die web.config-Datei
Pfeil 17.2.4 Kompilierung und Vorkompilierung
Pfeil 17.2.5 Sicherheit und ASP.NET
Pfeil 17.3 Installation
Pfeil 17.4 Kurzer Überblick über die Architektur des Webservers
Pfeil 17.4.1 Architektur
Pfeil 17.4.2 Anforderungsverarbeitung
Pfeil 17.4.3 Anforderungsverarbeitung im Anwendungspool
Pfeil 17.4.4 Die »Modulbauweise«
Pfeil 17.5 Webserver, Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools
Pfeil 17.5.1 Die Zusammenhänge
Pfeil 17.5.2 Webserver
Pfeil 17.5.3 Anwendungspool
Pfeil 17.5.4 Website
Pfeil 17.5.5 Anwendungen
Pfeil 17.5.6 Virtuelles Verzeichnis
Pfeil 17.6 Authentifizierung
Pfeil 17.6.1 Anonyme Authentifizierung
Pfeil 17.6.2 Standardauthentifizierung
Pfeil 17.6.3 Digestauthentifizierung
Pfeil 17.6.4 Windows-Authentifizierung
Pfeil 17.6.5 Authentifizierungsdelegierung
Pfeil 17.6.6 Webanwendungen und Kerberos
Pfeil 17.6.7 Delegierung, eingeschränke Delegierung und Protokollübergang
Pfeil 17.6.8 Formularauthentifizierung
Pfeil 17.7 Autorisierung
Pfeil 17.7.1 NTFS-Berechtigungen
Pfeil 17.7.2 URL-Autorisierung
Pfeil 17.8 Sonstiges zum Thema »Sicherheit«
Pfeil 17.8.1 SSL-Verschlüsselung
Pfeil 17.8.2 .NET-Vertrauensebenen
Pfeil 17.8.3 IP- und Domäneneinschränkungen
Pfeil 17.9 Sitzungszustand & Co.
Pfeil 17.10 Load Balancing und Redundanz
Pfeil 17.10.1 Verwendung von Microsoft NLB
Pfeil 17.10.2 Remoteanforderungen
Pfeil 17.10.3 Freigegebene Konfiguration
Pfeil 17.10.4 Sitzungsstatus
Pfeil 17.10.5 Datenbankserver & Co.
Pfeil 17.11 Administration
Pfeil 17.11.1 Remote-Administration
Pfeil 17.11.2 Remote-Administration für Nicht-Server-Administratoren und IIS-Benutzer
Pfeil 17.11.3 Delegierung von Features
Pfeil 17.11.4 Protokollierung
Pfeil 17.12 Der Best Practice Analyzer (BPA)
Pfeil 17.13 IIS-Schlussbemerkung

Rheinwerk Computing - Zum Seitenanfang

17.2 ASP.NET Zur nächsten Überschrift

ASP.NET ist eine serverseitige Technologie, mit der Entwickler komplexe Webanwendungen erstellen können. Mit ASP.NET ist es vergleichsweise einfach möglich, auch komplexeste Business-Logik zu implementieren, da eben nicht »nur« eine etwas aufgebohrte Skriptsprache zur Verfügung steht, sondern der volle Leistungsumfang des .NET Frameworks mit Tausenden von Klassen angesprochen werden kann. Bei aller Euphorie über den Leistungsumfang von ASP.NET bzw. des dahinterliegenden .NET Frameworks darf nicht vergessen werden, dass wir hier über »hartes« Programmieren sprechen.

Auch neue Webtechnologien wie AJAX (wobei dies zwar erst kürzlich richtig in Mode gekommen ist, aber eigentlich gar nicht so neu ist) haben in ASP.NET Einzug gehalten. Da ASP.NET auf dem .NET Framework aufbaut, stehen die .NET-Neuerungen wie beispielsweise LINQ auch für ASP.NET-Anwendungen zur Verfügung.

ASP.NET-basierte Websites erkennen Sie sehr einfach daran, dass die aufgerufenen Seiten nicht auf *.html, sondern auf *.aspx enden.

.NET-Grundwissen

ASP.NET ist ohne Grundwissen zu .NET nur teilweise zu verstehen. Ich möchte Ihnen daher an dieser Stelle Kapitel 5, »Was ist .NET?«, empfehlen.


Rheinwerk Computing - Zum Seitenanfang

17.2.1 Die Entwicklungsumgebung Zur nächsten ÜberschriftZur vorigen Überschrift

Wer heute professionell ASP.NET-Applikationen entwickelt, wird zu Visual Studio Professional greifen, das momentan (August 2013) in der Version 2012 vorliegt. Visual Studio ist eine kostenpflichtige Entwicklungsumgebung. Alternativ bietet Microsoft ein Produkt namens Visual Web Developer zum kostenlosen Download an.

Bei der Entwicklung einer ASP.NET-Applikation gibt es grundsätzlich zwei große Aufgaben, nämlich die Entwicklung der Oberfläche und die Entwicklung der eigentlichen Logik.

Für die Entwicklung der Oberfläche enthält Visual Studio einen grafischen Editor, den Sie in Abbildung 17.6 sehen können.

Es steht eine geteilte Ansicht (HTML-Code und grafische Anzeige) zur Verfügung, und aus der Toolbox können Steuerelemente (wie eine Listbox, eine Schaltfläche oder ein Textfeld) entnommen und auf der Seite platziert werden. Im Fensterbereich Eigenschaften werden die Steuerelemente konfiguriert.

Abbildung

Abbildung 17.6 Visual Studio beim Entwurf einer ASPX-Seite

Die optische Gestaltung von ASPX-Seiten können Sie anstatt mit Visual Studio auch mit Microsoft Expression Web erledigen (Abbildung 17.7). Expression Web richtet sich von der »Machart« her eher an Webdesigner als an Programmierer. Eine Arbeitsteilung innerhalb von Projekten ist durchaus möglich und auch gewollt:

  • Webdesigner entwerfen die Oberfläche der Anwendung mit Expression Web.
  • Programmierer entwickeln die Business-Logik innerhalb von Visual Studio.

In Abbildung 17.8 sehen Sie ein Stückchen Code bei der Bearbeitung in Visual Studio. Vielleicht sieht das für einen Nicht-Entwickler ein wenig kryptisch aus – jeder Entwickler wird aber bestätigen, dass es kaum eine Entwicklungsumgebung gibt, die bezüglich Komfort und Funktionalität an Visual Studio heranreicht. Bevor ich hier einen weiteren Glaubenskrieg vom Zaun breche, sei erwähnt, dass Eclipse-Entwickler von »ihrer« Entwicklungsumgebung auch durchaus sehr angetan sind.

Abbildung

Abbildung 17.7 Die Oberflächen für ASP.NET-Anwendungen können statt mit Visual Studio auch mit Microsoft Expression Web entwickelt werden.

Beim Thema »Programmieren« denkt man natürlich schnell auch an Programmiersprachen. ASP.NET ist, so wie .NET insgesamt, grundsätzlich sprachunabhängig. Trotz dieser Neutralität haben sich zwei Sprachen als die .NET-Sprachen herauskristallisiert:

  • VB.NET, also Visual Basic .NET
  • C#, gesprochen »C sharp«

Es existieren diverse weitere .NET-Sprachen; auch Microsoft selbst entwickelt fleißig an einer neuen Sprache, genannt F# (siehe http://research.microsoft.com/fsharp/fsharp.aspx). Im, sagen wir mal, kommerziellen Umfeld spielen eigentlich nur die beiden zuvor genannten Sprachen eine wirklich wichtige Rolle. Beide sind vom Leistungsumfang recht ähnlich. Im Detail wird man natürlich Unterschiede feststellen, die ich hier aber nicht weiter thematisieren möchte.

Ich habe übrigens den Eindruck, dass C# im professionellen Umfeld erstens die größere Verbreitung hat und zweitens auch die »Dokumentationslage« deutlich besser ist. Das heißt, man findet eher Codebeispiele zu C# als zu VB.NET.

Abbildung

Abbildung 17.8 Visual Studio bietet außerordentlich komfortable Möglichkeiten für das Schreiben und Debuggen von Code.


Rheinwerk Computing - Zum Seitenanfang

17.2.2 Clientseitig: JavaScript Zur nächsten ÜberschriftZur vorigen Überschrift

ASP.NET ist zwar in erster Linie eine serverseitige Technologie, kommt aber um eine ganze Menge clientseitiges Skripting nicht herum – als Skriptsprache kommt natürlich das allgegenwärtige JavaScript zum Einsatz, sodass ASP.NET-Applikationen auch mit Nicht-Microsoft-Browsern problemlos funktionieren.

Wozu braucht eine serverseitige Technologie Skripting auf dem Client? Einige Gründe:

  • Wenn der Benutzer eine Aktion auslöst, beispielsweise auf eine Schaltfläche klickt und ein neues Element auswählt, soll ja vermutlich eine Aktion ausgelöst werden, die eine Verarbeitung auf dem Server auslöst. Dies könnte beispielsweise das Schreiben oder Lesen in einer Datenbank sein, das Absenden einer E-Mail oder das Anschalten der Sirene auf dem Dach des Gebäudes. Damit beim Bestätigen eines Elements (z. B. Schaltfläche) auch wirklich die Daten an den Server übergeben werden, wird ein clientseitiges Skript benötigt.
  • Ein Postback, also das Rücksenden der Seite an den Server zwecks serverseitiger Verarbeitung, ist immer ein vergleichsweise »teurer« Prozess, da Daten durch das Netz gesendet werden müssen, der Server Rechenzeit zur Verfügung stellen muss und letztendlich die Webseite neu aufgebaut werden muss (bzw. bei AJAX teilweise neu aufgebaut werden muss). Es bietet sich also schon an, einige einfachere Aufgaben auf dem Client abzuarbeiten. Ein Paradebeispiel ist die Überprüfung von Benutzereingaben: Wenn die Benutzer in einem bestimmten Feld eine Zahl zwischen 1 und 100 eingeben sollen, kann man auch mit clientseitigem Skripting feststellen, dass der Wert 199 einfach nicht in den vorgegebenen Bereich passt – dazu braucht man wirklich keinen Server. Eine vernünftige Webapplikation wird also solche Fehler bereits abfangen, bevor unsinnige Eingaben zum Server gesendet werden.
  • Je komplexer und reichhaltiger die Oberfläche sein soll, desto mehr clientseitiges Skripting ist erforderlich. Falls Sie bereits mit SharePoint gearbeitet haben, werden Sie vermutlich erstaunt gewesen sein, was alles in einer Weboberfläche möglich ist – das ist alles der exzessiven Nutzung von JavaScript zu verdanken.
  • Das momentan sehr populäre AJAX (Asynchronous JavaScript and XML) ist ein weiteres Beispiel dafür, dass reichhaltige Oberflächen JavaScript benötigen – selbst wenn die dahinterstehende Servertechnologie noch so mächtig ist.

Kurz gesagt lässt sich feststellen, dass eine ASP.NET-Applikation, die Eingaben vom Benutzer erwartet, zwingend auf ein funktionierendes JavaScript angewiesen ist.


Rheinwerk Computing - Zum Seitenanfang

17.2.3 Die web.config-Datei Zur nächsten ÜberschriftZur vorigen Überschrift

ASP.NET-Anwendungen werden mit einer web.config-Datei konfiguriert und gesteuert, die sich im Verzeichnis der jeweiligen ASP.NET-Anwendung befindet. Die web.config ist ein mehr oder weniger komplexes XML-Dokument; ein Beispiel sehen Sie in Abbildung 17.9. Ich möchte nun nicht die komplette web.config diskutieren, sondern Sie lediglich auf zwei Zeilen hinweisen (ziemlich weit unten):

  • <authentication mode="Windows"/> sorgt dafür, dass die Zugriffe auf die Webanwendung mit Windows-integrierter Authentifizierung authentifiziert werden.
  • <identity impersonate="true"/> weist das Laufzeitsystem an, dass die Webanwendung mit der Identität des angemeldeten Benutzers und nicht mit der Identität des Anwendungspools ausgeführt wird.

Abbildung

Abbildung 17.9 Auszug aus der »web.config«-Datei einer ASP.NET-Anwendung

Sie brauchen vor der web.config-Datei, die auf den ersten Blick doch recht komplex aussieht, keine Angst (oder was auch immer) zu haben. Erstens müssen Sie sich im Normalfall als Administrator nur mit einem vergleichsweise kleinen Teilbereich der web.config auseinandersetzen. Zweitens lassen sich die wichtigsten Einstellungen auch über die grafische Benutzeroberfläche des Internetinformationsdienste-Managers erledigen: Die beiden Parameter bezüglich Authentifizierung und Impersonation (d. h., ein Prozess auf dem Webserver nimmt die Identität des angemeldeten Benutzers an), auf die ich Sie zuvor hingewiesen habe, finden Sie in Abbildung 17.10 in der grafischen Ansicht. Wenn Sie hier etwas konfigurieren, wird im Hintergrund die web.config geändert.

Dadurch, dass die solche Einstellungen wie die Authentifizierung für eine Webapplikation in der web.config stehen, eröffnen sich interessante Perspektiven für das Deployment: Der Programmierer kann in der mitgelieferten web.config diese Parameter bereits festlegen, und der Administrator braucht sich darum einfach nicht mehr zu kümmern – es ist schon alles »richtig« eingestellt.

Abbildung

Abbildung 17.10 In der grafischen Oberfläche des Internetinformationsdienste-Managers können die Authentifizierungsparameter bequem festgelegt werden. Im Hintergrund wird die »web.config« angepasst.

Zwei weitere wichtige Aspekte, die häufig konfiguriert werden müssen, sind Anwendungseinstellungen und Verbindungszeichenfolgen.

Applikationen aller Art benötigen in schöner Regelmäßigkeit einige grundlegende Konfigurationsangaben, beispielsweise den Namen einer Active Directory-Organisationseinheit. Diese Einträge finden sich in der web.config im Block <appSettings>. Ein Eintrag könnte also beispielsweise wie folgt aussehen:

<appSettings>
<add key="AD_OU_Salespeople"
value="OU=Sales,OU=RGS,DC=ubinf,DC=intra" />
</appSettings>

Solche Attribute wird der Entwickler der Applikation vorgeben, und die Administratoren müssen dann lediglich die entsprechenden Werte einsetzen. Angenehmerweise kann das auch in der grafischen Oberfläche des Internetinformationsdienste-Managers erfolgen, wie in Abbildung 17.11 zu sehen ist. Natürlich hindert niemand Sie daran, direkt in der web.config-Datei zu arbeiten.

Außer in der Rubrik Anwendungseinstellungen gibt es häufig noch bei den Verbindungszeichenfolgen etwas einzustellen. Hier wird konfiguriert, wie die Webapplikation auf Datenbanken zugreift, also der Datenbank-ConnectionString eingetragen.

Abbildung

Abbildung 17.11 Eine »typische« Einstellung in der »web.config«-Datei, die mit dem Internetinformationsdienste-Manager auch grafisch vorgenommen werden kann.


Rheinwerk Computing - Zum Seitenanfang

17.2.4 Kompilierung und Vorkompilierung Zur nächsten ÜberschriftZur vorigen Überschrift

Das Deployment einer ASP.NET-Applikation ist grundsätzlich sehr einfach, da Sie dem Webserver lediglich ein Verzeichnis nebst Unterverzeichnissen bekannt machen und als Anwendung definieren müssen – das zeige ich Ihnen später in diesem Kapitel.

Für ein genaueres Verständnis möchte ich aber nun ein wenig in diese Verzeichnisse hineinschauen und die verschiedenen Varianten der Weitergabe von ASP.NET-Anwendungen zeigen.

Standardkompilierung

Abbildung 17.12 zeigt eine ASP.NET-Anwendung, die mit Standardkompilierung bereitgestellt wird. Ich habe die Anwendung einfach von meiner Entwicklungsumgebung auf den Webserver kopiert, im Internetinformationsdienste-Manager eine Anwendung daraus gemacht – und fertig!

In dem Verzeichnis finden sich folgende Elemente:

  • *.aspx-Datei: In *.aspx-Dateien ist sozusagen die Gestaltung der Webseiten hinterlegt. Hier finden sich die HTML-Elemente, die Platzierung der ASP.NET-Steuerelemente (z. B. Textbox, Button, Listbox etc.) und der clientseitig auszuführende JavaScript-Code.
  • *.cs: Dies ist die C#-Datei mit dem serverseitigen Code. Falls der Entwickler nicht mit C#, sondern mit Visual Basic .NET entwickelt, enden diese Dateien auf *.vb. Man spricht hier übrigens von Code-Behind-Dateien – der serverseitige Code liegt sozusagen in einer Datei hinter der .aspx-Datei.
  • Web.config ist, wie bereits besprochen, die Konfigurationsdatei der Webapplikation.

Serverseitiger Code

Der serverseitige Code muss nicht in einer separaten Datei gespeichert werden, sondern kann sich auch in der *.aspx-Datei befinden.

In dem Verzeichnis können sich durchaus deutlich mehr Dateien befinden. Zum einen kann es beliebig viele .aspx-Dateien und zugehörige Code-Behind-Dateien geben, außerdem gibt es auch diverse andere Dateitypen, die ich hier weiter gar nicht besprechen möchte.

Eine umfangreichere ASP.NET-Applikation verfügt im Normalfall auch über etliche Unterverzeichnisse, die wir aber für das »Erstverständnis« zunächst nicht berücksichtigen müssen.

Abbildung

Abbildung 17.12 Diese simple ASP.NET-Anwendung wurde mit Standardkompilierung bereitgestellt.

Wenn Sie die Beschreibung aufmerksam gelesen haben, sind Sie vermutlich über zwei Aspekte gestolpert:

  • Liegt der Quellcode tatsächlich offen auf dem Server?
  • Wo sind die ausführbaren Dateien?

Beide Fragen lassen sich mit einer einzigen Antwort klären: Bei der Standardkompilierung liegt tatsächlich der komplette Quellcode auf dem Server und wird beim ersten Zugriff auf die Webapplikation kompiliert.

Kein Interpreter

Damit kein falscher Eindruck entsteht, möchte ich ganz explizit darauf hinweisen, dass der Code bei diesem Kompilierungsmodell zwar erst bei der ersten Ausführung kompiliert wird, dann aber als Binary vorliegt und »echt« ausgeführt wird. Der Code wird also nicht etwa wie bei einer Skriptsprache lediglich von einem Interpreter abgearbeitet.

Die Standardkompilierung hat Vorteile:

  • Für den Entwickler ist sie maximal einfach zu handhaben. Er braucht letztendlich nichts anderes zu tun, als sein komplettes Entwicklungsverzeichnis an einen Administrator zu übergeben, der es dann auf den Webserver kopiert und als Anwendung einrichtet.
  • Befindet sich eine Applikation noch in der Testphase, kann problemlos eine einzelne Datei ausgetauscht werden – das ASP.NET-Laufzeitsystem wird dann die Anwendung automatisch neu kompilieren.

Es gibt aber auch Nachteile:

  • Beim ersten Start der Applikation kann der Kompilierungsvorgang leicht zu einer deutlichen Verzögerung führen. Sehr komplexe Applikationen sind nicht in einer halben Sekunde zu kompilieren.
  • Verständlicherweise muss der komplette Quellcode auf dem Webserver liegen, was häufig nicht erwünscht ist.
  • Ein Unternehmen, das Geld mit dem Verkauf von ASP.NET-Anwendungen – also letztendlich mit seinem Entwicklungs-Know-how – verdient, wird keinen Quellcode ausliefern und damit sein Wissen preisgeben wollen.

Die Standardkompilierung sollte eigentlich nur dann eingesetzt werden, wenn sich eine ASP.NET-Applikation im Entwicklungsstadium befindet. Meiner Beobachtung nach gelangen auch viele »hausinterne« Projekte auf diese Weise in die Produktivumgebung; bezüglich Stabilität und Performance ist das allerdings kein Problem, sieht man einmal von dem ersten Start ab (die Kompilierung findet einmalig statt).

Vorkompilierung

Im Normalfall sollten Webanwendungen bereits vorkompiliert sein. Das dann verwendete Verfahren nennt sich Vorkompilierung. Dabei erzeugt der Entwickler mithilfe des Werkzeugs aspnet_compiler.exe, das sich im .NET Framework-Verzeichnis befindet, eine oder mehrere Assemblys (Binärdatei[en] mit .NET-Code). Es gibt verschiedene Möglichkeiten bei der Vorkompilierung. Beispielsweise kann der Entwickler entscheiden, nur die eigentlichen Code-Dateien (*.cs oder *.vb) zu kompilieren, alternativ kann er auch zusätzlich die *.aspx-Dateien in die Assembly hineinkompilieren lassen.

Die Vorteile der Vorkompilierung liegen auf der Hand:

  • Der Kompilierungsvorgang beim ersten Start der Webapplikation entfällt.
  • Der Entwickler schützt sein geistiges Eigentum, indem er verhindert, dass jeder, der Zugriff auf das Dateisystem des Webservers hat, den Quellcode einsehen kann.

In Abbildung 17.13 sehen Sie dieselbe Anwendung wie in Abbildung 17.12, diesmal aber vorkompiliert, und zwar in der »stärksten Stufe«, in der auch die Inhalte der *.aspx-Dateien in die Assembly kompiliert worden sind.

Abbildung

Abbildung 17.13 Das Anwendungsverzeichnis bei der Nutzung von Vorkompilierung. In der »stärksten« Stufe sind auch die Inhalte der ».aspx«-Dateien in die Assembly kompiliert worden, zurück bleibt nur ein Platzhalter.

Vorkompilieren

Diese Stufe nennt man übrigens Vorkompilieren mit nicht aktualisierbarer Benutzeroberfläche. Der Grund ist einleuchtend: Da die *.aspx-Dateien auch nicht mehr geändert werden können, kann die Benutzeroberfläche nicht geändert bzw. aktualisiert werden.

Im Anwendungsverzeichnis befinden sich in diesem Fall:

  • die Konfigurationsdatei web.config
  • eine .aspx-Datei. Diese enthält allerdings nicht den erwarteten Code, sondern lediglich den Hinweis, dass es sich um eine Markierungsdatei handelt. Man soll sie zwar nicht löschen, die Webapplikation würde aber trotzdem funktionieren.
  • die Datei PrecompiledApp.config: Sie enthält Informationen zum Vorkompilierungsstatus der Anwendung.

Der eigentliche Code der Anwendung befindet sich nun im bin-Verzeichnis unterhalb des Anwendungsverzeichnisses. Dort finden sich in diesem Fall (Abbildung 17.14):

  • die App_Web_bibilcwt.dll-Datei: Sie enthält in diesem Fall sowohl den serverseitig auszuführenden Code als auch die *.aspx-Seite. Die Wahl des Namens habe ich in diesem Fall dem Vorkompilierungswerkzeug überlassen, man kann den Namen aber auch manuell festlegen. Je nach Komplexität der Anwendung können auch mehrere Assembly-Dateien erzeugt werden.

    Abbildung

    Abbildung 17.14 Das »bin«-Verzeichnis einer vorkompilierten Anwendung enthält u. a. eine Datei, der entnommen werden kann, welche Dateien in die Assembly kompiliert wurden.

  • die *.compiled-Datei: Ihr Inhalt ist in der Abbildung gezeigt. Sie enthält unter anderem Angaben darüber, welche Dateien dort in die Assembly hineinkompiliert worden sind.
  • die Datei Interop.ActiveDs.dll: Sie ist eine »externe« Datei, die von dieser speziellen Webapplikation benötigt wird.

.NET-Grundwissen

Ich möchte Ihnen an dieser Stelle auch Kapitel 5, »Was ist .NET?«, empfehlen. Viele Vorgänge in ASP.NET sind mit ein wenig .NET-Grundwissen wesentlich einfacher zu verstehen.


Rheinwerk Computing - Zum Seitenanfang

17.2.5 Sicherheit und ASP.NET Zur vorigen Überschrift

ASP.NET bietet sehr leistungsfähige Möglichkeiten, um Webanwendungen und somit auch den Webserver »sicher« zu machen. Bekanntlich ist IT-Sicherheit nicht ein erreichter Zustand, sondern ein fortlaufender Prozess, der außerordentlich viele Facetten und Abhängigkeiten aufweist.

Sicherheit beginnt letztendlich mit der Qualität der Anwendung und geht über das sorgfältige Einspielen von Sicherheitspatches und das Verhalten der Administratoren bei Änderungen bis hin zum Verhalten des einzelnen Anwenders.

Speziell für ASP.NET wären folgende Aspekte zu nennen:

  • Authentifizierung: Auf welche Weise bestätigt der Benutzer gegenüber dem Webserver seine Identität?
  • Autorisierung: Wie wird festgelegt, auf welche Bestandteile der Website der authentifizierte Benutzer zugreifen kann? Dies kann in ASP.NET durch Mitgliedschaften oder Rollen abgewickelt werden.
  • Welche Möglichkeiten hat der im Rahmen der ASP.NET-Ausführung ausgeführte Code? Dies betrifft die .NET-Codezugriffssicherheit, die in Kapitel 5 besprochen wird.

Die Themen Authentifizierung und Autorisierung werden im Laufe dieses Kapitels anhand der Konfiguration im Internetinformationsdienste-Manager recht ausführlich behandelt. Insofern gerät dieser Abschnitt recht kurz – das Thema ist allerdings extrem wichtig und wird Ihnen an vielen Stellen dieses Kapitels begegnen.

Es ist keine Frage, dass man problemlos ein ganzes Buch damit füllen könnte, wie man sichere ASP.NET-Applikationen entwickelt – einige Kollegen haben ja auch genau das bereits getan. Viele Aspekte sind dann aber einfach zu entwicklerlastig, als dass sie in diesem Buch, das sich vorwiegend an Systemarchitekten und -administratoren richtet, gut aufgehoben wären.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern


  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Windows Server 2012 R2






Windows Server 2012 R2
Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Office 365






 Office 365


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Linux-Server






 Linux-Server


Zum Rheinwerk-Shop: Vmware vSphere 5






 Vmware vSphere 5


Zum Rheinwerk-Shop: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo