Authentifizierung in Web Services - Windows Integrated

Geschrieben von: Christoph Wille
Kategorie: Web Services

Standardmäßig sind Web Services die man programmiert für jedermann zugänglich, das heißt, unauthentifizierte anonyme Benutzer können darauf zugreifen. Manches Mal ist das gewünscht, in vielen anderen Fällen (zb Kreditkarten-Abbuchungsservice) allerdings nicht. In dieser Artikelserie werden wir verschiedene Authentifizierungsmethoden beleuchten, und wir beginnen heute mit der Windows Integrierten Authentifizierung.

Grundsätzlich kann man unter drei verschiedenen Authentifizierungsmethoden wählen:

• Protokollabhängige Authentifizierung, im Falle von HTTP und IIS wären dies zB Basic Authentication und Windows Integrated (NTLM) Authentication.
• Zusätzliche SOAP Header. Man erweitert die SOAP Nachrichten um weitere Header, die Sicherheitsinformationen enthalten.
• Authentifizierung nach dem WS-Security Standard. Darunter fallen die UsernameToken und X.509 Authentifizierung aus den Web Services Enhancements 1.0.

Heute beschäftigen wir uns mit der protokollabhängigen Authentifizierung, im speziellen mit Windows Integrated. Bevor wir zum Hauptthema des Artikels kommen, möchte ich noch auf HTTP Basic Authentication eingehen: diese ist die einfachste Variante, und wird von allen Browsern / SOAP Clients verstanden. Soferne man Basic Authentication über SSL einsetzt, ist die Übertragung der Benutzerinformationen auch sicher, allerdings ohne SSL würde ich es nicht empfehlen - hier ist Windows Integrated Authentication besser.

Daß es nichts gibt, das nur Vorteile bietet, ist bekannt und bei Windows Integrated genauso: nur Microsoft Clients beherrschen diese Authentifizierungsvariante. Damit kann man sie nicht für nach außen zugängliche Web Services einsetzen, aber für das Firmen-Intranet ist es bei weitem die beste Lösung.

Grundsätzlich könnte man die gesamte Konfiguration für Windows Integrated in der web.config der jeweiligen ASP.NET Applikation abwickeln. Allerdings bin ich ein Fan von Sicherheit, deshalb sieht meine Liste für die Absicherung wie folgt aus:

1. Den Web Service per NTFS ACL's auf der WebServiceName.asmx Datei absichern, sodaß nur berechtigte Personen Zutritt bekommen. Warum? NTFS ist unsere letzte Bastion, hier kommt niemand daran vorbei.
   
2. In der ISM die Authentifizierung für die Web Applikation verbindlich machen - anonymen Zugriff verbieten.
   
3. In der web.config Windows Authentifizierung einschalten (standardmäßig ist das bereits so), und zusätzlich noch anonyme Nutzer vom Zugriff auf die Web Applikation ausschließen:

   <authentication mode="Windows" /> 
    <authorization>
     <deny users="?" />
    </authorization>
   

Damit haben wir unseren Web Service gründlich auf Windows Integrated vorbereitet. Einerseits können wir uns jetzt darauf verlassen, daß nur authentifizierte Benutzer den Web Service verwenden, andererseits können wir auf diese Benutzerinformationen zugreifen:

[WebMethod]
public string SecureMethod()
{
	string strValue = User.Identity.AuthenticationType;
	strValue += " " + User.Identity.IsAuthenticated;
	strValue += " " + User.Identity.Name;
	return strValue;
}

Zusätzlich kann man mit der Funktion User.IsInRole feststellen, ob der Benutzer in einer spezifischen Benutzergruppe Mitglied ist. Dadurch kann man sehr einfach rollenbasierte Sicherheit in den Web Service integrieren.

Der Client

Nachdem die Serverseite so leicht zu implementieren war, wie sieht es auf der Clientseite aus? Nun, man erzeugt sich wie gewohnt eine Web Referenz in Visual Studio.NET, nur beim Aufruf muß man die Benutzerinformationen weitergeben:

using System;
using System.Net;

class ConsoleAppWsClient
{
  static void Main()
  {
    localhost.Service1 svc = new localhost.Service1();
    svc.Credentials = CredentialCache.DefaultCredentials;
    string strRetVal = svc.SecureMethod();
    Console.WriteLine(strRetVal);
  }
}

Durch CredentialCache.DefaultCredentials werden die Credentials des aktuell eingeloggten Benutzers an den Web Service übergeben. Alternativ kann man ein beliebiges Benutzerkonto mit übergeben, allerdings steht dann das Passwort im Sourcecode:

svc.Credentials = new NetworkCredential("Administrator", "pwd");
string strRetVal = svc.SecureMethod();

Grundsätzlich bleibt der Client-Code bis auf das "Anhängen" der Credentials identisch zu einem Web Service der keine Authentifizierung verlangt.

Schlußbemerkung

Protokollabhängige Authentifizierung, im speziellen Windows Integrated, hat im Intranet seine Daseinsberechtigung. Muß man aber unterschiedliche Plattformen miteinander kommunzieren lassen, muß man zu anderen Mitteln und Wegen greifen, um die Authentifizierung zu implementieren.

Verwandte Artikel

Authentifizierung in Web Services - SOAP Header
Authentifizierung in Web Services - WS-Security, Benutzername / Passwort
Web Services 101 in ASP.NET
Web Services in Anwendungen konsumieren

Wenn Sie jetzt Fragen haben...

Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten.

Eine weitere sehr hilfreiche Resource ist das deutsche ASP.NET Wiki, das als zentrale Anlaufstelle für Tips, Tricks, Know How und alles Nützliche was man in seinem Alltag als (ASP).NET-Entwickler so braucht und entdeckt gedacht ist.

Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.

Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.