Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
von Saad Ladki
Einführung
Die Autorisierung war in früheren Versionen von Internetinformationsdiensten (Internet Information Services, IIS) schwierig. Da IIS nur mit Windows-Identitäten funktionierten, mussten Sie zum Dateisystem wechseln und Zugriffssteuerungslisten (Access Control Lists, ACLs) für Dateien und Verzeichnisse festlegen. Dies war mühsam, da die ACL-Benutzeroberfläche komplex ist und Autorisierungsregeln nicht sehr gut von Computer zu Computer kopiert werden.
IIS 7.0 und höhere Versionen verwenden die URL-Autorisierung. Auf diese Weise können Sie Autorisierungsregeln für die tatsächliche URL anstelle der zugrunde liegenden Dateisystemressource festlegen. Darüber hinaus wird die IIS-URL-Autorisierungskonfiguration in web.config-Dateien gespeichert. Sie können Autorisierungsregeln mit dem Anwendungsinhalt verteilen. In der folgenden exemplarischen Vorgehensweise wird das IIS-URL-Autorisierungsfeature in Windows Server® 2008 Beta 3 und Windows Vista Service Pack 1 erläutert.
Voraussetzungen
Für diese exemplarische Vorgehensweise ist zusätzlich zur Standardinstallation die Installation der folgenden oben aufgeführten IIS-Features erforderlich:
- „ASP.NET“ unter „Internetinformationsdienste“ – „WWW-Dienste“ – „Anwendungsentwicklungsfeatures“
- „URL-Autorisierung“ unter „Internetinformationsdienste“ – „WWW-Dienste“ – „Sicherheit“
Szenario
Im Szenario für diesen Artikel verfügen Sie über ein sicheres Verzeichnis, auf das nur Alice, Bob und die Administratorengruppe zugreifen kann. In diesem Verzeichnis befindet sich eine Datei namens „bobsSecret.aspx“, auf die nur Bob zugreifen soll.
Szenariosetup
Für dieses Szenario werden die drei Benutzer Alice, Bob und Fred benötigt. Zudem ist eine neue Gruppe namens „BobAndFriends“ erforderlich, der Alice und Bob angehören. Erstellen Sie die drei Konten und die Gruppe über den Windows-Benutzer-Manager, oder starten Sie eine Eingabeaufforderung mit erhöhten Rechten, und geben Sie die folgenden Befehle ein.
net user Alice <password_of_your_choice> /add
net user Bob <password_of_your_choice> /add
net user Fred <password_of_your_choice> /add
net localgroup BobAndFriends /add
net localgroup BobAndFriends Alice /add
net localgroup BobAndFriends Bob /add
Öffnen Sie den Explorer, und navigieren Sie zum Verzeichnis
%systemdrive%\inetpub\wwwroot.Erstellen Sie ein Verzeichnis namens „secure“.
Wechseln Sie zum Verzeichnis „secure“, und erstellen Sie eine neue Datei namens „default.aspx“. Sie können dies mit Editor oder einem beliebigen anderen Text-Editor tun.
Fügen Sie den folgenden Code auf der default.aspx-Seite ein:
<%@Language="C#"%> <% string currentUser = Request.ServerVariables["LOGON_USER"]; if (currentUser == "") currentUser = "anonymous"; Response.Write("<b>Current User:</b> " + currentUser); %>Erstellen Sie eine weitere Datei namens „bobsSecret.aspx“, und fügen Sie den folgenden Code ein:
<%@Language="C#"%> <% string currentUser = Request.ServerVariables["LOGON_USER"]; if (currentUser == "") currentUser = "anonymous"; Response.Write("<b>Current User:</b> " + currentUser); Response.Write(" <b>My secret:</b> I used Apache before I discovered IIS7.</b> "); %>Testen Sie nun, ob die beiden Webseiten funktionieren, indem Sie
http://localhost/secure/undhttp://localhost/secure/bobsSecret.aspxanfordern.
Konfigurieren der Authentifizierung
Im Rahmen der Authentifizierung wird beantwortet, „wer“ Zugriff haben möchte. Mit dem Autorisierungsprozess wird geprüft, „ob“ die authentifizierte Person tatsächlich Zugriff erhält. Bevor Sie also mit der URL-Autorisierung experimentieren können, müssen Sie die Authentifizierung aktivieren, da nicht entschieden werden kann, ob eine Person Zugriff erhält, wenn nicht klar ist, um welche Person es sich überhaupt handelt.
Starten Sie INETMGR, indem Sie „INETMGR“ im Menü „Suche starten“ eingeben.
Öffnen Sie den Computerknoten in der linken Strukturansicht, öffnen Sie dann den Knoten „Standardwebsite“, und wählen Sie das Verzeichnis „secure“ aus.
Doppelklicken Sie auf „Authentifizierung“.
Deaktivieren Sie „Anonyme Authentifizierung“, und aktivieren Sie „Standardauthentifizierung“.
Fordern Sie nun erneut
http://localhost/secureundhttp://localhost/secure/bobsSecret.aspxan. Sie werden aufgefordert, Anmeldeinformationen einzugeben. Geben Sie „Alice“ als Benutzername und das entsprechende Kennwort ein. Sie werden als „Alice“ authentifiziert.Hinweis
Wenn Sie den Internet Explorer verwenden, können Sie STRG+F5 drücken, damit der Internet Explorer die zwischengespeicherte Version der ASP.NET-Seite aktualisiert.
Konfigurieren der URL-Autorisierung
Schützen Sie nun die beiden Seiten, sodass nur Alice und Bob Zugriff haben:
Doppelklicken Sie erneut auf das Webverzeichnis „secure“, und wählen Sie „Autorisierungsregeln“ aus.
Entfernen Sie die Regel „Alle Benutzer zulassen“.
Klicken Sie auf „Zulassungsregel hinzufügen“, wählen Sie das Optionsfeld „Bestimmte Rollen oder Benutzergruppen“ aus, fügen Sie „BobAndFriends“ hinzu, und klicken Sie auf die Schaltfläche „OK“.
Schließen Sie alle Internet Explorer-Fenster, da der Internet Explorer die Anmeldeinformationen zwischenspeichert, die Sie im vorherigen Schritt eingegeben haben.
Öffnen Sie den Internet Explorer, und versuchen Sie, mithilfe der Anmeldeinformationen von Fred auf die Seite zuzugreifen. Sie erhalten keinen Zugriff.
Testen Sie dies nun mit den Anmeldeinformationen von Bob oder Alice. Sie erhalten Zugriff.
Konfigurieren der URL-Autorisierung für eine einzelne Webseite
Sie haben nach wie vor das Problem, dass Alice weiterhin auf „BobsSecret.aspx“ zugreifen kann. Sie können dies wie folgt beheben:
Doppelklicken Sie erneut auf das Webverzeichnis „secure“, und wählen Sie unten auf der Seite „Inhaltsansicht“ aus.
Eine Liste der Dateien wird im secure-Ordner angezeigt („default.aspx“ und „bobsSecret.aspx“).
Klicken Sie mit der rechten Maustaste auf „bobsSecret.aspx“, und wählen Sie „Featureansicht“ aus.
Jetzt nehmen Sie wie in der Statusleiste angegeben nur Änderungen für die bobsSecret.aspx-Seite vor.
Wählen Sie erneut „Autorisierungsregeln“ aus. Die geerbten Einstellungen werden angezeigt. Dies bedeutet, dass die Gruppe „BobAndFriends“ auf „bobsSecret.aspx“ zugreifen darf.
Entfernen Sie die Regel „BobAndFriends“.
Klicken Sie jetzt auf „Zulassungsregel hinzufügen“.
Klicken Sie auf das Optionsfeld „Bestimmte Benutzer:“, geben Sie „Bob“ ein, und klicken Sie auf „OK“.
Schließen Sie alle Internet Explorer-Fenster, und fordern Sie
http://localhost/secure/bobsSecret.aspxan.Nur durch die Eingabe von Bobs Anmeldeinformationen erhalten Sie Zugriff.
Weiterführende Themen zur URL-Autorisierung
Die nächsten Absätze enthalten einige weiterführende Themen zur URL-Autorisierung.
Konfiguration
Sie müssen die Benutzeroberfläche nicht verwenden, um URL-Autorisierungseinstellungen anzugeben. Sie können URL-Autorisierungsregeln direkt in der web.config-Datei angeben. Der IIS-Konfigurationsabschnitt <authorization> wird standardmäßig delegiert. Sie können Autorisierungsregeln zusammen mit Webinhalten verteilen. Hier sehen Sie, wie die %systemdrive%\inetpub\wwwroot\secure\web.config-Datei nach dem Ausführen der Schritte dieser exemplarischen Vorgehensweise aussieht:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" roles="BobAndFriends" />
</authorization>
</security>
</system.webServer>
<location path="bobsSecret.aspx">
<system.webServer>
<security>
<authorization>
<remove users="" roles="BobAndFriends" verbs="" />
<add accessType="Allow" users="Bob" />
</authorization>
</security>
</system.webServer>
</location>
</configuration>
Unterschiede zwischen der ASP.NET-URL-Autorisierung und der IIS-URL-Autorisierung
Es gibt kleine, aber wichtige Unterschiede zwischen „UrlAuthorization“ für ASP.NET und der IIS-URL-Autorisierung. Beide Module können über das IIS-Setup installiert werden. Die IIS-URL-Autorisierung wird installiert, wenn Sie das Feature „URL-Autorisierung“ über die Benutzeroberfläche des IIS-Setups installieren:
Die ASP.NET-URL-Autorisierung wird installiert, wenn Sie ASP.NET zusätzlich zu IIS installieren. Wenn Sie mit ASP.NET vertraut sind, erinnern Sie sich daran, dass „UrlAuthorization“ für ASP.NET im System.Web.Security.UrlAuthorizationModule-Modul implementiert wird. Der entsprechende Konfigurationsabschnitt ist „system.web/authorization“. Dies ist der Konfigurationseintrag.
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="managedHandler" />
Das IIS-URL-Autorisierungsmodul wird im globalen Modul „urlauthz.dll“ implementiert.
<add name="UrlAuthorizationModule" image="%windir%\System32\inetsrv\urlauthz.dll" />
Es ist wichtig zu beachten, dass sich die managedHandler-Vorbedingung im ASP.NET-Modul „UrlAuthorization“ befindet. Die Vorbedingung teilt Ihnen mit, dass das URL-Autorisierungsmodul nur aufgerufen wird, wenn der Code, der die Anforderung verarbeitet, verwaltetem Code zugeordnet ist (in der Regel eine ASPX- oder ASMX-Seite). Die IIS-URL-Autorisierung gilt dagegen für alle Inhalte. Sie können die managedHandler-Vorbedingung aus dem ASP.NET-Modul „UrlAuthorization“ entfernen. Auf diese Weise soll verhindert werden, dass Sie Leistungseinbußen hinnehmen müssen, wenn jede Anforderung (z. B. Anforderung von HTML- oder JPG-Seiten) verwalteten Code durchlaufen muss.
Regelauswertung
Es gibt auch Unterschiede in der Reihenfolge, in der IIS und die beiden URL-Autorisierungsmodule Autorisierungsregeln auswerten. Die ASP.NET-URL-Autorisierung ist entwicklerorientiert, und Entwickler haben volle Kontrolle darüber, welche Regeln sie festlegen. Die IIS-URL-Autorisierung behält den Administrator im Auge und versucht sicherzustellen, dass Entwickler die Regeln nicht außer Kraft setzen können, die Administratoren festgelegt haben.
Beispiel
Angenommen, die Administratoren möchten sicherstellen, dass alle Benutzer einer bestimmten Website authentifiziert werden müssen. Legen Sie dazu die folgende Konfiguration im Website-Stammverzeichnis fest:
<authorization lockElements="clear">
<add accessType="Deny" users="?" />
</authorization>
Diese Konfiguration verweigert den Zugriff für anonyme Benutzer (? = anonyme Benutzer, * = alle Benutzer). Mit „lockElements="clear"“ stellen Sie sicher, dass keine Person mit niedrigen Berechtigungen die Vererbung dieser Einstellung löschen kann. Ihre Einstellung würde an alle Anwendungen und virtuellen Verzeichnisse dieser Website vererbt werden. Es tritt eine Sperrverletzung auf, wenn Sie versuchen, die Anweisung „<clear/>“ bei niedrigeren Berechtigungen zu verwenden.
Weitere Informationen zur Konfigurationssperre finden Sie unter Sperren von ASP.NET-Konfigurationseinstellungen.
Sie können das clear-Element auch bei der ASP.NET-URL-Autorisierung sperren. Das Problem besteht darin, dass die ASP.NET-URL-Autorisierung Autorisierungsregeln von unten nach oben auswertet, d. h. sie wertet zuerst Regeln in der aktuellen web.config-Datei aus, bevor sie übergeordnete Regeln auswertet. Sobald eine Übereinstimmung gefunden wird, wird der Zugriff gewährt oder verweigert. Im obigen Beispiel können Sie anonymen Benutzern weiterhin Zugriff gewähren, indem Sie „<add users="?"/>“ als Autorisierungsregel in der web.config-Datei unter „secure“ angeben. Da sie zuerst ausgewertet wird, würden anonyme Benutzer Zugriff erhalten.
Das IIS-URL-Autorisierungsmodul wertet zuerst die Ablehnungsregeln aus. Da Sie den Zugriff für anonyme Benutzer verweigern, können Sie diese Regel nicht einfach außer Kraft setzen. Der andere große Unterschied besteht darin, dass übergeordnete Regeln zuerst ausgewertet werden. Dies bedeutet, dass Sie Fred den Zugriff auf niedriger Ebene nicht gewähren können, wenn Sie den Fred den Zugriff auf höherer Ebene verweigern.
Tabelle zu den Unterschieden
| Differenz | ASP.NET-URL-Autorisierungsverhalten | IIS-URL-Autorisierungsverhalten |
|---|---|---|
| Regelauswertung | Reihenfolge: a) Von niedrigerer Ebene nach oben zum übergeordneten Element b) Reihenfolge gemäß Anordnung in Regelsammlung | Reihenfolge: a) Verweigerungsregeln werden zuerst ausgewertet, beginnend mit dem übergeordneten Element b) Zulassungsregeln werden ausgewertet, beginnend mit dem übergeordneten Element c) Reihenfolge gemäß Anordnung in Regelsammlung |
| IIS-Benutzeroberfläche | Keine IIS-Benutzeroberfläche | Benutzeroberfläche „Autorisierungsregeln“ |
| Konfigurationsabschnitt | system.web/authorization | system.webServer/security/authorization |
| Modul | System.Web.Security.UrlAuthorization | %windir%\system32\inetsrv\urlauthz.dll |
| Inhalt | Gilt nur für Inhalte, die einem verwalteten Handler zugeordnet sind (kann über die managedHandler-Vorbedingung deaktiviert werden) | Gilt für alle Inhalte |
Verwenden von Domänenkonten und -gruppen
Sie müssen Domänenkonten und -gruppen wie folgt angeben:
<domainname or username>\<user>
In diesem Beispiel wird der Computername verwendet. Dabei wird vorausgesetzt, dass die Konten auf dem Computer „iis7test“ erstellt wurden:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" roles="iis7test\BobAndFriends" />
</authorization>
</security>
</system.webServer>
<location path="bobsSecret.aspx">
<system.webServer>
<security>
<authorization>
<remove users="" roles="iis7test\BobAndFriends" verbs="" />
<add accessType="Allow" users="iis7test\Bob" />
</authorization>
</security>
</system.webServer>
</location>
</configuration>
Verwenden von Nicht-Windows-Identitäten
Die URL-Autorisierung gilt nicht nur für Windows-Identitäten. Sie funktioniert auch gut für Nicht-Windows-Identitäten. Verwenden Sie sie zusammen mit ASP.NET-Mitgliedschaften und -Rollen und für benutzerdefinierte Identitäten, falls Sie Ihr eigenes Authentifizierungsmodul schreiben.
Zusammenfassung
Die URL-Autorisierung ist eine leistungsstarke neue Möglichkeit zum Angeben von Autorisierungsregeln für Webanwendungen. Jetzt können Sie Regeln in XML angeben, ohne Windows-Zugriffssteuerungslisten zu verwenden.