ASP.NET-Sicherheit

Bezüglich einer Webanwendung sind folgende Fragen der Sicherheit zu klären:

1.        Muss der Benutzer sich gegenüber der Anwendung authentifizieren oder darf er anonym bleiben?

2.        Wie soll sich der Benutzer authentifizieren?

3.        Welche Seiten/Ressourcen darf der Benutzer abrufen?

4.        Unter welchem Benutzerkontext agiert die Webanwendung auf dem Serversystem? (Identität des autorisierten Benutzers oder eine dedizierte Identität?)

Die Techniken, die Microsoft als Antwort auf diese Fragen liefert, werden in diesem Kapitel beantwortet. Dabei ist das Sicherheitssystem in ASP.NET im Vergleich zum Sicherheitssystem des klassischen ASP komplexer, aber auch flexibler geworden.

Authentifizierung 

Autorisation setzt die Authentifizierung der Benutzer voraus. Bei dem Prozess der Authentifizierung geht es darum zu überprüfen, ob eine Person tatsächlich die Person ist, die sie vorgibt zu sein. Dieser Nachweis geschieht in der Regel durch eine Kombination aus Benutzername und Kennwort. Um eben diesen Nachweis zu überprüfen, bieten ASP.NET verschiedene Möglichkeiten an. Die Windows-Betriebssysteme verfügen von Hause aus schon einen Authentifizierungsmechanismus mit der dazugehörigen Benutzerverwaltung. Dieser kann ohne Aufwand direkt verwendet werden. Microsoft bietet in ASP.NET zusätzliche Möglichkeiten. So lassen sich individuelle Methoden über eine (web-)formularbasierte Identifikation realisieren. Außerdem bietet Microsoft mit dem Passport-Dienst bereits einen internetbasierten universellen Authentifizierungsdienst an, der diesen Benutzer-Nachweis übernehmen kann.

Verfahren	Erläuterung
Windows	Es wird die IIS-Authentifizierung (Basic, Digest, NTLM, Kerberos, Zertifikate) verwendet. Innerhalb von ASP.NET gibt es jedoch zusätzliche Konfigurationsoptionen.
Forms	Es wird ein bestimmtes Webform zur Authentifizierung verwendet.
Passport	Es wird der von Microsoft betriebene Single-Sign-On-Dienst ".NET Passport" verwendet. UPDATE 2008: DIESE TECHNIK IST VERALTERT.
None	Keine Authentifizierung, nur anonyme Zugriffe sind erlaubt.

Ob und welchen Mechanismus man verwenden möchte, kann über die Web.config innerhalb der <authentication>-Element definiert werden.

<system.web>

  …

  <authentication mode="[Windows/Forms/Passport/None]” />

  …

</system.web>

Für jede der aufgeführten Möglichkeiten stehen unterschiedliche Konfigurationsmöglichkeiten zur Verfügung, auf die im Folgenden näher eingegangen wird.

Hinweis

Für die Webanwendung lässt sich nur genau eine Authentifizierungsmethode definieren. Diese Konfiguration muss innerhalb des Wurzelverzeichnisses der Anwendung definiert werden.

 

Windows-basierte Authentifizierung

Die Windows-basierte Authentifizierung greift auf die Authentifizierungsmethode des Internet Information Server (IIS) und damit auch auf die Windows-Sicherheit zurück. Im IIS besteht die grundsätzliche Wahlmöglichkeit, den anonymen Zugang zu einer Website zuzulassen oder aber eine Authentifizierung des Benutzers zu verlangen, die dann gegen die Windows-Benutzerdatenbank bzw. das Active Directory geprüft wird.

Listing 8:
Authentifizierungseinstellungen im IIS

 

Eine Authentifizierung auf Basis vorhandener Windows-Benutzerkonten ist besonders dann sinnvoll, wenn eine einheitliche Benutzeradministration gewünscht wird. Windows- und Web-Anwender benötigen nur eine Zugangskennung (Windows-Login). Dadurch entfällt der zusätzliche Administrationsaufwand, und der Anwender muss sich ein Kennwort weniger merken.

Greift ein Benutzer aus dem Intranet über den Internet Explorer auf einen Webserver innerhalb des gleichen Netzwerks zu, so kann die integrierte Windows-Authentifizierung verwendet werden. In allen anderen Fällen kann nur die unverschlüsselte Basic Authentication verwendet werden und der Benutzer erhält ein Dialogfeld zur Eingabe seiner Benutzerdaten (siehe Abbildung).

Abbildung 6:
Authentifizierung über den Internet Explorer

Die automatisch übermittelte oder eingegebene Benutzeranmeldung wird gegen die Windows-Benutzerdatenbank bzw. das Active Directory geprüft. Stimmen die Anmeldedaten nicht, so wird er vom IIS abgelehnt und erhält keinen Zugriff auf die Anwendung.

 

In der web.config-Datei wird die Windows-Authentifizierung durch

<authentication mode="Windows">

</authentication>

aktiviert. Dies ist jedoch die Standardvorgabe, sofern die machine.config-Datei nicht geändert wurde. In diesem Element können im Rahmen der ì Benutzer-Autorisierung einzelne Zugriffsrechte gesetzt werden.

Erkennen des authentifizierten Benutzers

Um den aktuell angemeldeten Benutzer zu ermitteln, kann man einfach mittels der HttpContext-Klasse auf den aktuellen Kontext der aktuellen Web-Anfrage zugreifen. Diese Klasse stellt im Unterobjekt User Daten über den Authentifizierungsvorgang bereit. Über das User-Objekt lässt sich erkennen, ob und wie ein bestimmter Benutzer authentifiziert wurde.

 

 

' //////////////////////////////////////////////////////

' /Kapitel05a/Default.aspx.vb

' //////////////////////////////////////////////////////

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

  C_AuthenticationType.Text = Context.User.Identity.AuthenticationType()

  C_Benutzer.Text = Context.User.Identity.Name

  C_Authentifiziert.Text = Context.User.Identity.IsAuthenticated

End Sub

Formularbasierte Authentifizierung

Es gibt durchaus Fälle, in denen eine Authentifizierung mittels eines Windows-Anmeldeserver nicht möglich oder nicht gewünscht wird. Besonders in einer Umgebung, in denen die Benutzer der Anwendung ansonsten keinen Zugriff auf den entsprechenden Anmeldedienst benötigen, wird oftmals eine Authentifizierung verwendet die auf andere Quellen zurückgreift. In vielen Fällen (besonders bei Webanwendung, die sich an die breite Öffentlichkeit richten) wird die Standard-Dialogbox des Browsers als störend und unpraktisch angesehen. In anderen Browsern kann dieser Dialog unter Umständen gar nicht verwendet werden, deswegen bieten die meisten Webseiten eigene Anmeldeseiten an. Unter dem klassischen ASP mussten nicht nur die Anmeldeseiten selbst, sondern auch ein Sicherheitsmechanismus selbst implementiert werden, der erreicht, dass ein Benutzer, der nicht durch die Startseite in die Webanwendung eintritt, sondern eine der Folgeseiten direkt aufruft, ebenfalls zum Anmeldedialog geleitet wird.

Abbildung 7:
Anmeldung über ein benutzerdefiniertes Formular

ASP.NET vereinfacht diese Entwicklung erheblich, indem es die Möglichkeit bietet, ein selbst entwickeltes Webform als Anmeldeseite einzubinden. Diese so genannte formularbasierte Authentifizierung von ASP.NET bietet vielfältige Möglichkeiten an, um eine Benutzeranmeldung zu verifizieren. Beispiele zur Verifizierung der Benutzerdaten, die in diesem Kapitel besprochen werden, sind:

• Benutzer-Kennwort-Paare innerhalb der Web.config
• Benutzertabelle in einer Datenbank
• Prüfung gegen Benutzer-Einträge im Active Directory

Tipp

Für die Authentifizierung muss nicht explizit die Kombination aus Benutzername und Kennwort verwendet werden. Jeder beliebige Abfragemechanismus ist realisierbar, z.B. Kennwörter die nur einmal oder nur einen bestimmten Zeitraum gültig sind.

Der Authentifizierungsvorgang bei der formularbasierten Authentifizierung

Bei einer Anfrage an eine bestimmte Ressource einer ASP.NET-Webanwendung wird diese auch bei der formularbasierten Authentifizierung zuerst vom Internet-Informationsdienst geprüft. Dort muss es zumindest möglich sein auf die Anwendung zuzugreifen.

Abbildung 8: Ablauf der formularbasierten Authentifizierung

Anschließend kann eine Authentifizierung durch die ASP.NET-Anwendung geschehen. ASP.NET prüft, ob sich innerhalb des HTTP-Request-Headers ein Authentifizierungscookie befindet, der darauf hinweist, dass der Benutzer den Authentifizierungsvorgang bereit durchlaufen hat.

Ist dies nicht der Fall wird er auf eine frei definierbare Anmeldeseite verwiesen, die diese Authentifizierung durchführt. Es ist Aufgabe, der Anmeldeseite, dem System mitzuteilen, dass die Authentifizierung erfolgreich war. Dies geschieht zum Beispiel durch den Aufruf der statischen Methoden RedirectFromLoginPage() oder SetAuthCookie() in der Klasse System.Web.Security.FormsAuthentication. In beiden Fällen setzt ASP.NET den Authentifizierungscookie. Durch einen zweiten Parameter kann festgelegt werden, ob der Cookie persistent gespeichert werden soll oder nur gelten soll, solange der Browser geöffnet ist.

Wahlweise wird der Anwender von der Anmeldeseite zurück zur Einstiegsseite (RedirectFromLoginPage()) geleitet oder die Anmeldeseite entscheidet nach Setzen des Cookies mit SetAuthCookie() selbst über den weiteren Weg des Benutzers, z.B. indem er ihn mit Response.Redirect() oder Server.Transfer() zum Hauptmenü leitet. Für die Seite, auf die der Benutzer gelenkt wird, prüft ASP.NET selbstverständlich die Zugriffsrechte des autorisierten Benutzers.

Wichtig

Da die formularbasierte Authentifizierung auf Cookies basiert, wird ein Benutzer, der per Browser-Einstellung die Annahme von Cookies verweigert, keine Freunde haben: Er wird bei jedem Seitenaufruf erneut seine Benutzerdaten eingeben müssen.

Konfiguration innerhalb Web.config

Die Konfiguration für die formularbasierte Authentifizierung gestaltet sich etwas umfangreicher, bietet dafür aber auch mehr Möglichkeiten an, als die Windows-basierte Authentifizierung. Innerhalb des <authentication>-Element muss das <forms>-Element für die Definition des Authentifizierungsmechanismus verwendet werden.

Tabelle 6:
Forms-Authentication Attribute

Attribut	Beschreibung
Name	Der Name des für die Authentifizierung zu verwendende HTTP-Cookie. Standardmäßig lautet dieser .ASPXAUTH. Allerdings ist es ratsam, einen eindeutigen Namen zu verwenden, wenn auf einem Server verschiedene Anwendungen mit eindeutigen Cookie ausgeführt werden.
loginUrl	Die URL zu der umgeleitet werden soll, falls noch kein Authentifizierungscookie erstellt wurde.
Protection	Darüber lässt sich festlegen, ob eine Datenüberprüfung und Verschlüsselung des Cookies durchgeführt werden soll. Der Standardwert ist All. Mögliche Ausprägungen sind: All, None, Encryption und Validation.
Timeout	Definiert die Anzahl der Minuten seit der letzten Übermittlung des Cookie bevor dieses verfällt und somit ungültig wird. Der Standard liegt bei 30 Minuten. Diese Timeout-Zeit ist nicht von Bedeutung, wenn der Authentifizierungs-Cookie persistent gemacht wurde.
Path	Legt den Pfad für die von der Anwendung ausgegebenen Authentifizierungs-Cookie fest. Grundsätzlich sollte man auf die Groß- und Kleinschreibung achten, da die meisten Browser diese unterscheiden und ein Cookie nicht zurücksenden, falls die Pfadangabe nicht exakt übereinstimmt. Der Standardwert ist ein umgekehrter Schrägstrich (\).

Das folgende Listing zeigt ein Beispiel für die Deklaration der formularbasierten Authentifizierung in der Web.config-Datei.

Listing 9:
<authentication> in der Web.config

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.web>

…

    <authentication mode="Forms">

      <forms name="FormsLogin" loginUrl="LoginForm.aspx" protection="All"

          timeout="30" path="\">

…

      </forms>

    </authentication>

    <authorization>

      <deny users="?" />

    </authorization>

…

  </system.web>

</configuration>

Hinweis

Das <authorization>-Element legt fest, dass nur authorisierte Benutzer akzeptiert werden. Dadurch wird jeder nicht-authentifizierte Benutzer zu Beginn auf das Authentifizierungsformular geleitet.

Benutzerliste innerhalb der Web.config

Eine Möglichkeit der Überprüfung von Benutzernamen und Kennwort im Rahmen der formularbasierten Authentifizierung ist die Ablage einer Benutzer-Kennwort-Liste in der Web.config. Innerhalb das <forms>-Elements lassen sich die berechtigten Benutzer mit den dazugehörigen Kennwörtern direkt in der Web.config definieren.

Listing 10:
Benutzerdaten  in der Web.config

    <authentication mode="Forms">

      <forms name="FormsLogin" loginUrl="LoginForm.aspx" protection="All"

          timeout="30" path="\">

        <credentials passwordFormat="Clear">

          <user name="Anton" password="geheim" />

          <user name="Berta" password="geheimer" />

          <user name="Claus" password="am geheimsten" />

        </credentials>

      </forms>

    </authentication>

Hinweis

Diese Vorgehensweise ist allerdings nur für kleinere Anwenderkreise praktikabel. Für eine dynamisch wachsende Anzahl von Benutzern können leistungsfähigere Mechanismen verwendet werden. Diese werden in den folgenden Absätzen noch erläutert.

Verschlüsseln von Kennwörtern innerhalb der Web.config

Um den Missbrauch von Kennwörtern zu minimieren, ist es möglich die Kennwörter auch verschlüsselt innerhalb der Web.config abzulegen. Dafür stehen Verschlüsselungen mittels SHA1 oder MD5 zur Verfügung.

Listing 11:
Verschlüsselte Benutzerinformationen

<credentials passwordFormat="SHA1">

  <user name="Anton" password="2AC5EC9614E65B0B005ABFEA7F0D3E4961D5ADBE" />

  <user name="Berta" password="E1920FEE83D25CDF9EE6E325903452F2B1EB89F5" />

  <user name="Claus" password="E43AA57639E6B03DAC5DB796373EACB33D99C5CD" />

</credentials>

Für die Verschlüsselung der Passwörter stellt die FormsAuthentication-Klasse eine entsprechende Methode zur Verfügung.

txtResult.Text = System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(txtTextstring.Text, "MD5")

Hinweis

Das vollständige Beispiel zum Verschlüsseln von Kennwörtern innerhalb einer Konfigurationsdatei befindet sich auf der CD-ROM ì Kapitel5b/KennwortVerschluesseln.aspx.

Überprüfung von Benutzer und Kennwort innerhalb der Web.config

Nach dem die Benutzerdaten (Name und Kennwort) über ein Webform abgefragt wurden, müssen diese Eingaben mittels einer Datenquelle überprüft werden. Um die Eingaben mit Daten, die innerhalb der Web.config hinterlegt sind, zu vergleichen, steht die Methode FormsAuthentication.Authenticate() zur Verfügung, die auf diese Einträge zugreift.

Listing 12:
Forms-Überprüfung von Benutzer und Kennwort

' ////////////////////////////////////////////////////

' /Kapitel05b/FormsLogin.aspx.vb

' ////////////////////////////////////////////////////

' --- Kennwort mittels Forms-Authentication überprüfen

    If Security.FormsAuthentication.Authenticate(txtBenutzername.Text, txtKennwort.Text) Then

      ' --- Überprüfung erfolgreich

      C_Information.Text = "Authentifizierung erfolgreich."

      ' --- Zur ursprünglich angefragten Seite weiterleiten

      Security.FormsAuthentication.RedirectFromLoginPage(txtBenutzername.Text, False)

    Else

      ' --- Überprüfung war fehlerhaft

      C_Information.Text = " Authentifizierung fehlgeschlagen."

    End If

Nach der Überprüfung wird der Benutzer auf die ursprünglich angefragte Seite weitergeleitet. Dies geschieht durch die Methode RedirectFromLoginPage(). Innerhalb dieser Methode wird ein AuthenticationTicket erzeugt, dass die erfolgreiche Authentifizierung nachweist.

Hinweis

Das vollständige Beispiel befindet sich auf der CD-ROM (Kapitel5b/FormsLogin.aspx).

Benutzerdefinierte Weiterleitung

Nicht in alle Fällen ist es sinnvoll, einen Benutzer nach erfolgreicher Authentifizierung auf eine andere Webseite weiterzuleiten. Dies kann beispielsweise dann der Fall sein, wenn man ein Benutzersteuerelement erstellen möchte, dass sich in verschiedene Seiten integrieren lässt, wie es von vielen Webseiten angeboten wird. Daher ist die Methode Security.FormsAuthentication.RedirectFromLoginPage() nicht immer praktikabel.

Um dennoch für den Benutzer ein Authentifizierungscookie manuell zu erzeugen, das den erfolgreichen Vorgang nachweist, steht die SetAuthCookie()-Methode zur Verfügung.

FormsAuthentication.SetAuthCookie(BenutzerName.Text, False)

Dadurch wird das Cookie an den Client gesendet, das bei zukünftigen HTTP-Anfragen verhindert, das der Benutzer sich erneut authenifizieren muss. Dabei hat man die Wahl, ob dieses Cookie sitzungsbasiert oder permanent für den Client erzeugt wird.

Danach kann die Anmeldeseite mit Response.Redirect() oder Server.Transfer() zu einer beliebigen Seite weiterleiten. Wenn die ursprünglich vom Benutzer angewählte Seite interessante ist, kann die Anwendung dies über GetRedirectUrl() ermitteln.

Abmeldung

Eine Webforms-Anwendung kann auch eine Abmelden-Funktion zur Verfügung stellen. Dazu ist die Methode SignOut() in der FormsAuthentication-Klasse aufzurufen. Der Authentifizierungs-Cookie wird dabei gelöscht.

Andere Authentifizierungsmechanismen

Nicht immer ist es sinnvoll die Benutzer- und Kennwort-Informationen innerhalb der Web.config-Datei zu hinterlegen und diese dort überprüfen zu lassen. Dies dürfte besonders in Szenarien problematisch werden, die automatisch Zugriffskonten für die Webanwendung generieren können, wie es bei vielen Portalen der Fall ist.

Aus diesem Grund ist es möglich, anstelle der FormsAuthentication.Authenticate() eigene Mechanismen der Benutzerüberprüfung zu definieren. Die anderen Befehle der Klasse FormsAuthentication wie zum Beispiel  RedirectFromLoginPage(), SetAuthCookie() und SignOut() stehen ebenfalls zur Verfügung.

Authentifizierung über den Microsoft SQL Server

Die Daten für eine Authentifizierung lassen sich auch über eine Datenbank realisieren. Dazu wird in einer Tabelle mit Benutzerinformationen nach einer Kombination der eingegebenen Werte gesucht (in der Regel Benutzername und Kennwort). Dies setzt natürlich voraus, dass der Benutzername in dieser Tabelle eindeutig ist.

Die im folgenden Beispiel verwendeten Klassen und Methoden für den Datenzugriff aus dem Namespace System.Data.SqlClient werden detailliert in Kapitel 6 erläutert.

 

Listing 13:
Authentifizierung über SQL Server

' ///////////////////////////////////////////////

' /Kapitel05b/FormsLoginSqlServer.aspx.vb

' ///////////////////////////////////////////////

  Dim sqlCmd As SqlClient.SqlCommand

  Dim sqlConn As SqlClient.SqlConnection

  Dim sDsn As String

  Dim iFound As Integer

  Dim BenutzerKennwortRichtig As Boolean

  ' --- Connection String aus Web.config-appSettings lesen

  sDsn = ConfigurationSettings.AppSettings("dsnSample")

  ' --- Init Sql Connection

  sqlConn = New SqlClient.SqlConnection(sDsn)

  sqlCmd = New SqlClient.SqlCommand()

  sqlCmd.CommandType = CommandType.Text

  sqlCmd.CommandText = "Select Count(ID) From Usertable "

  sqlCmd.CommandText += "Where Username='" & C_Benutzername.Text

  sqlCmd.CommandText += "' And Password='" & C_Kennwort.Text & "'"

  sqlCmd.Connection = sqlConn

  Try

    ' --- Verbindung öffnen

    sqlConn.Open()

    ' --- Statement ausfuehren

    iFound = CType(sqlCmd.ExecuteScalar(), Integer)

    If iFound = 1 Then

      ' --- Erfolgreich

      BenutzerKennwortRichtig = True

    Else

      ' --- Fehlgeschlagen

      BenutzerKennwortRichtig = False

    End If

  Catch exc As Exception

    ' --- Fehler

    C_Information.Text = "Fehler aufgetreten: " & exc.Message

  Finally

    ' --- Aufräumen

    sqlConn.Close()

    sqlConn.Dispose()

    sqlCmd.Dispose()

  End Try

  If BenutzerKennwortRichtig Then

    ' --- Anmeldung erfolgreich

    C_Information.Text = "Anmeldung erfolgreich"

    ' --- Ticket manuell erzeugen   

    'System.Web.Security.FormsAuthentication.SetAuthCookie(txtBenutzername.Text, False)

    ' --- Oder Benutzer direkt weiterleiten auf die Ursprungsseite  

    System.Web.Security.FormsAuthentication.RedirectFromLoginPage( txtBenutzername.Text, False)

  Else

    ' --- Anmeldung fehlgeschlagen

    C_Information.Text = "Anmeldung fehlgeschlagen"

  End If

In diesem Beispiel werden die Benutzereingaben mittels einer Datenbank überprüft. Wird innerhalb der Datenbankabfrage genau ein Datensatz mit diesen Kriterien gefunden, so ist nachgewiesen, das dieses Kennwort in Verbindung mit dem Benutzernamen richtig ist.

Hinweis

Das vollständige Beispiel und das Skript zum Erstellen der Datenbanktabelle befinden sich auf der CD-ROM (Kapitel5/Authentication/AuthenticationSqlServer.aspx und CreateUserTable.sql).

Authentifizierung über Active Directory

Ähnlich wie bei einer Abfrage gegen eine Datenbank, lassen sich die Benutzerinformationen auch mittels Active Directory überprüfen. Die folgende Methode prüft anhand eines gültigen LDAP-Pfades (z.B. "LDAP://DC=IT-Visions, DC=de") den übergebenen Benutzer mit sein Kennwort und der angegebene Domäne.

In diesem Beispiel kommen die Klassen DirectoryEntry und DirectorySearcher aus dem Namespace System.DirectoryServices zum Einsatz, die in der FCL-Assembly System.DirectoryServices.dll implementiert sind. Diese Assembly muss dem Webprojekt hinzugefügt werden (Verweis in Visual Studio .NET)

Abbildung 10:
Formularbasierte Authentifizierung gegen das Active Directory

Listing 14:
Kapitel5b/
ActiveDirectory.vb

 

' ///////////////////////////////////////////////

' /Kapitel05b/FormsLoginAD.aspx.vb

' ///////////////////////////////////////////////

  Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

    C_DomainLDAP.Text = ConfigurationSettings.AppSettings("DomainLDAP")

    C_DomainName.Text = ConfigurationSettings.AppSettings("DomainName")

  End Sub

 

  Public Shared Function IstBenutzerAuthentifiziert(ByVal Pfad As String, ByVal Domain As String, ByVal BenutzerName As String, ByVal Kennwort As String) As Boolean

    Dim VollstaendigerBenutzerName As String = Domain + "\" + BenutzerName

    Dim Eintrag As DirectoryEntry = New DirectoryEntry(Pfad, VollstaendigerBenutzerName, Kennwort)

    Try

      Dim Objekt As Object = Eintrag.NativeObject

      Dim Suche As DirectorySearcher = New DirectorySearcher(Eintrag)

      Suche.Filter = "(SAMAccountName=" + BenutzerName + ")"

      Suche.PropertiesToLoad.Add("cn")

      Dim SucheErgebnis As SearchResult = Suche.FindOne()

      If SucheErgebnis Is Nothing Then

        ' --- Suche war erfolglos

        Return False

      Else

        ' --- Suche war erfolgreich

        Pfad = SucheErgebnis.Path

        Return True

      End If

    Catch Exc As Exception

      'Throw New Exception("Fehler während der Autorisierung. " + Exc.Message)

      Return False

    End Try

  End Function

 

  Private Sub C_Login_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles C_Login.Click

    Dim Pfad As String = C_DomainLDAP.Text

    Dim Domain As String = C_DomainName.Text

    If IstBenutzerAuthentifiziert(Pfad, Domain, C_Benutzername.Text, C_Kennwort.Text) Then

      ' --- Erfolgreich

      C_Information.Text = "Erfolgreich"

    Else

      ' --- Nicht erfolgreich

      C_Information.Text = "Nicht erfolgreich"

    End If

  End Sub

Konfiguration

Die Einrichtung der Authentifizierung mittels des Passport-Dienstes wird ebenfalls über die Web.config eingerichtet.

Listing 15:
Authentication mit Passport

<configuration>

  <system.web>

    <authentication>

      <passport redirectUrl="Login.aspx" … />

    </authentication>

  </system.web>

</configuration>

Zusätzlich können noch diverse Attribute für die Kommunikationsform (z.B. über SSL) und Behandlung bei erfolgreicher bzw. erfolgloser Authentifizierung eingegangen werden. Für diese Aspekte wird allerdings auf die ì Passport SDK Dokumentation verwiesen.

Passport Software Development Kit

Microsoft bietet für die Entwicklung von Anwendungen eine sehr umfangreiches und dokumentiertes Software Development Kit zu Download über MSDN-Seiten an. Sie finden das SDK auch auf der CD-ROM zu diesem Buch.

Hinweis

Damit der Passport-Authentifizierungsdienst überhaupt verwendet werden kann und darf, muss man sich über die Passport-Homepage (http://www.passport.com) registrieren lassen. Dabei gibt es explizit die Möglichkeit seine Anwendung als Entwicklungs- und nicht als Produktivversion zu kennzeichnen.

Benutzer-Autorisierung

Nach dem der Benutzer eindeutig über eine bestimmte Authentifizierungsmethode identifiziert wurde, bedeutet dies noch nicht, dass er alle Berechtigungen innerhalb der Anwendung besitzt. Im klassischen ASP waren dafür alleine die im Dateisystem gesetzten Rechte verantwortlich (soweit das NTFS-Dateisystem verwendet wurde). Wenn kein NTFS-Dateisystem verwendet wurde, gab es keine Möglichkeit zur Deklaration von benutzerspezifischen Zugangsbeschränkungen. Solche mussten dann immer per Programmcode in jeder einzelnen Seite implementiert werden. Auch die Verwendung der NTFS-Sicherheit war unbefriedigend, weil diese (mühsam) im Windows Explorer gesetzt werden musste. Die vergebenen Rechte wurden schnell unübersichtlich und konnten beim Verschieben der Anwendung verloren gehen.

ASP.NET erlaubt daher nun deklarative Zugangsbeschränkungen über die web.config-Dateien. Zu diesem Zweck kann die <authorization>-Sektion verwendet werden. Mit ihr lässt sich der Clientzugriff auf bestimmte Ressourcen reglementieren. Dafür stehen innerhalb der Sektion zwei Untertags zur Verfügung (<allow> und <deny>). Über diese lassen sich für verschiedene HTTP-Verben der Zugriff für bestimmte Benutzer oder Rollen definiert werden können.

Tipp

In Verbindung mit dem <location>-Element ermöglicht dieser Mechanismus auch einen zentralen Schutz von Unterverzeichnissen.

 

Benutzer können über bestimmte Rollen verfügen, d.h. sie können die Rechte einer oder mehrere Rollen übernehmen, ohne dass ihnen direkt Rechte zugewiesen werden. Ein Benutzer kann beispielsweise Mitglied in den Rollen Administrator und Moderator sein. Durch diese Mitgliedschaft erhält er die Rechte dieser Rollen. Um einem Benutzer eine oder mehrere Rollen zuzuweisen, müssen diese nach der Authentifizierung der angemeldeten Identität hinzugefügt werden.

Konfigurationselemente für Autorisation

Über das <allow>-Element lässt sich der erlaubte Zugriff für bestimmte Ressourcen definieren.

Tabelle 7:
Erlaubter Zugriff

Attribut	Beschreibung
user	Komma-getrennte Liste von bestimmten Benutzern denen der Zugriff erlaubt ist. Ein "*" gestatten allen Benutzern den Zugriff. Ein "?" gestattet auch Zugriffsrechte für anonyme Benutzer.
roles	Komma-getrennte Liste von Rollen denen der Zugriff erlaubt ist.
verbs	HTTP-Übertragungsmethoden (GET, HEAD, POST, DEBUG) denen der Zugriff auf eine bestimmte Ressourcen erlaubt ist.

Über das <deny>-Element lässt sich der Zugriff für bestimmte Ressourcen unterbinden.

Tabelle 8:
Verweigerter Zugriff

Attribut	Beschreibung
user	Komma-getrennte Liste von bestimmten Benutzern denen kein Zugriff gewährt wird. Ein "*" schließt alle Benutzer aus. Ein "?" schließt nur anonyme Benutzer aus.
roles	Komma-getrennte Liste von Rollen denen der Zugriff nicht erlaubt ist.
verbs	HTTP-Übertragungsmethoden (GET, HEAD, POST, DEBUG) denen der Zugriff auf eine bestimmte Ressourcen verwährt wird.

Durch eine Kombination von <allow>- und <deny>-Konstellationen lässt sich ein wirkungsvoller, aber einfacher Sicherheitsmechanismus für Ressourcen definieren.

Beispiele

Die folgende Autorisierung erlaubt es lediglich Anton und Berta, auf das aktuelle Verzeichnis und dessen Unterverzeichnis zuzugreifen.

<system.web>

  <authorization>

    <allow users="Anton, Berta" />

    <deny users="*" />

  </authorization>

</system.web>

Hier werden explizit Anton und Berta Berechtigungen erteilt. Allerdings wird nur nicht authentifizierten Benutzer der Zugriff verweigert. Auch andere Benutzer, die über eine gültige Authentifizierung (Windows, Forms, etc.) verfügen, dürfen zugreifen.

<system.web>

  <authorization>

    <allow users="Anton, Berta" />

    <deny users="?" />

  </authorization>

</system.web>

Das dritte Beispiel unterbindet alle Benutzern den Zugriff, auch Anton und Berta. Es gilt immer die erste auf den authentifizierten Benutzer zutreffende Regel. Trifft eine Regel zu, werden die folgenden nicht mehr verarbeitet.

<system.web>

  <authorization>

    <deny users="*" />

    <allow users="Anton, Berta" />

    <allow roles="Administrator, Moderator" />

  </authorization>

</system.web>

Anwendungsidentität

Eine Webanwendung benötigt Rechte auf dem Webserver, um dort agieren zu können. Zumindest benötigt sie die Rechte, die zu der Webanwendung gehörenden Dateien aus dem Dateisystem lesen zu dürfen. Darüber hinaus gibt es aber auch Webanwendungen, die auf Systembausteine wie die Registry, Datenbanken oder das Active Directory zugreifen. Diesen Anwendungen müssen entsprechende Rechte gegeben werden.

Eine Webanwendung grundsätzlich unter dem Benutzerkontext des (Domänen-)Administrators auszuführen, wäre ein Sicherheitsrisiko. Zwar ist der Nutzer der Webanwendung durch die Funktionalität der Webanwendungen in seinen Aktionen beschränkt, dennoch besteht die Gefahr, dass auf dem Webserver anderer Programmcode abgelegt werden könnte, der die weitreichende Rechte des Administrator für nicht beabsichtigte Aktionen ausnutzt. Bei der ungewollten Ablage von Programmcode ist nicht nur an Hacker-Angriffe zu denken, sondern auch an Personen, die zwar Zugang zum Verzeichnis der Webanwendung habe, weil Sie dort Webseiten ablegen sollen, denen man aber dennoch nicht administrative Rechte geben will.

Die Einstellung der Benutzeridentität einer Webanwendung ist daher einer wichtige Frage. Es gibt grundsätzlich zwei alternative Möglichkeiten:

1. Die Webanwendung verwendet den Benutzerkontext des authentifizierten Benutzers als Identität der Webanwendung.
2. Die Webanwendung verwendet einen dedizierten Benutzerkontext, der für alle Nutzer der Webanwendung gleich ist.

Der IIS ermöglichen nur eine beschränkte Einstellung: Wenn sich der Browser anonym anmeldet (und das versucht jeder Browser zuerst), dann wird die Anwendung unter dedizierten Identität (im Standard das lokale Benutzerkonto IUSR_Computername) ausgeführt. Wenn sich der Browser authentifiziert, wird diese Identität verwendet.

Konfigurationselemente

ASP.NET erlaubt, in einer web.config-Datei im Element <identity> feinere Einstellungen zu machen. Um den Benutzerkontext der Anwendung zu definieren stehen innerhalb des <identity>-Elements die in nachfolgender Tabelle genannten Attribute zur Verfügung.

Tabelle 9:
 Konfigurations-Attribute

Attribut	Beschreibung
impersonate	Definiert, ob die andere Identität als das Benutzerkonto des ASP.NET-Arbeitsprozess verwendet werden soll.
userName	Festlegung eines dedizierten Windows-Benutzerkontos, dass als Identität verwendet werden soll.
password	Das Passwort, das zum verwendeten Konto gehört, falls eine bestimmte Identität gewünscht wird.

Konfigurations-Beispiele

Im Standard wird eine ASP.NET-Webanwendung unter dem Konto ausgeführt, unter dem der ASP.NET-Arbeitsprozess läuft, also das lokale Konto "ASPNET". Um ein anderes Konto zu verwenden reicht folgender Ausdruck:

<identity
   impersonate="true"
   userName="Domain\UserAbc"
   password="geheim" />

Eine Impersonifizierung der Anwendung über den aktuell authentifizierten Benutzer kann durch folgende Konfiguration ermöglicht werden:

<identity impersonate="true" />

Wenn allerdings diese Option gesetzt wird und gleichzeitig der IIS den anonymen Zugang zulässt, dann wird die im IIS für den anonymen Zugang definierte Benutzeridentität (also in der Regel IUSR_Computername) verwendet.

Die oben dargestellten Möglichkeiten veranschaulicht der nachstehende Entscheidungsbaum.

Abbildung 12:
Entscheidungsbaum zur Identität einer ASP.NET-Anwendung

Ändern des Standardbenutzerkontos von ASP.NET

Sie können auch das "ASPNET"-Benutzerkonto, das im Standard verwendet wird, ändern, indem Sie in der Maschine.config in der Sektion <processModel > ein anderes Benutzerkonto angeben.

Im Standard steht dort:

 <processModel userName="machine"  password="AutoGenerate" … />

Der Benutzername "machine" steht dabei für das "ASPNET"-Konto.

Der folgende Eintrag verwendet ein anderes Benutzerkonto:

<processModel userName="hs" password="egal" … />

Wichtig

Sie können auch das Windows-System-Konto angeben.

<processModel userName="system" password="autogenerate"… />

Sie müssen sich aber im Klaren sein, dass damit Ihre ASP.NET-Anwendung volle Rechte auf Ihrem System hat und damit das Gefährdungspotenzial bei Angriffen gegen Ihre Webserver steigt.

Ermitteln der Identität

Die aktuelle Identität kann man natürlich per Programmcode ermitteln über die statische Methode GetCurrent() in der Klasse System.Security.Principal.WindowsIdentity.

In dem folgenden Beispiel werden der autorisierte Benutzer und die aktuelle Identität der Webanwendungen gegenüber gestellt.

' //////////////////////////////////

' /Kapitel5/Identitaet/User.aspx.vb

' //////////////////////////////////

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

    ' --- Ermitteln des autorisierten Benutzers

    Dim user_autorisiert As System.Security.Principal.IIdentity

    user_autorisiert = User.Identity

 

    ' --- Ermitteln der Identität

    Dim user_identity As System.Security.Principal.WindowsIdentity

    user_identity = System.Security.Principal.WindowsIdentity.GetCurrent

 

    ' --- Ausgabe

    Response.Write("Angemeldete Benutzer: " & user_autorisiert.Name & "<br>")

    Response.Write("Konto, unter dem die Anwendung im System agiert: " & user_identity.Name & "<br>")

End Sub