Sichern von mit ASP.NET erstellten XML-Webdiensten
Der Wahl der für einen XML-Webdienst am besten geeigneten Sicherheitsimplementierung geht die Prüfung zweier wichtiger Sicherheitsprinzipien voraus, nämlich der Authentifizierung und der Autorisierung. Die Authentifizierung beschreibt einen Prozess, bei dem eine Identität gegenüber einer Autorität überprüft wird, und zwar auf Grundlage von Anmeldeinformationen, wie Benutzername und Kennwort. Nach der Authentifizierung einer Identität wird durch die Autorisierung bestimmt, ob die Identität berechtigt ist, auf eine Ressource zuzugreifen.
Sicherheitsoptionen für die mit ASP.NET erstellten XML-Webdienste können aus den Authentifizierungs- und Autorisierungsoptionen ausgewählt werden, die von ASP.NET oder einem angepassten SOAP-basierten Sicherheitsmodell zur Verfügung gestellt werden. ASP.NET arbeitet mit den Internet-Informationsdiensten zusammen, um eine Reihe von Authentifizierungs- und Autorisierungsoptionen bereitzustellen. Außerdem besteht die Möglichkeit, benutzerdefinierte Authentifizierungsoptionen zu erstellen, die z. B. die Verwendung von SOAP-Headern vorsehen. Darüber hinaus bietet ASP.NET eine unter dem Namen Identitätswechsel geläufige Fähigkeit, bei der eine Anforderung mit den Anmeldeinformationen des Clients ausgeführt werden kann. Weitere Informationen zum Identitätswechsel finden Sie unter Identitätswechsel in ASP.NET.
Unter diesem Thema sind die Authentifizierungs- und Autorisierungsoptionen zusammengefasst, die für die mit ASP.NET erstellten XML-Webdienste verfügbar sind. Ausführliche Informationen zu den Sicherheitsoptionen, die in ASP.NET-Webanwendungen verfügbar sind, finden Sie unter Sicherheit für ASP.NET-Webanwendungen.
Authentifizierungsoptionen für XML-Webdienste
Die mit ASP.NET erstellten XML-Webdienste verfügen über mehrere Optionen für die Authentifizierung von Clients. Es stellt sich also die Frage, welche Option für welchen XML-Webdienst geeignet ist. Bei der Wahl der richtigen Sicherheitsoption muss ein Entwickler u. a. zwischen dem gewünschten Sicherheitslevel und der Leistung abwägen. Bei einigen XML-Webdiensten kommt es auf das verschlüsselte Senden der Clientanmeldeinformationen über das Netzwerk an. Aus diesem Grund ist ein Algorithmus zur Verschlüsselung der Clientanmeldeinformationen unverzichtbar. Ein Entwickler, der einen XML-Webdienst für Kreditkartentransaktionen schreibt, wird sich z. B. mehr um diebstahlsichere Clientanmeldeinformationen sorgen als um den zusätzlichen Aufwand, der durch die Verschlüsselung der Kreditkarteninformationen entsteht.
In der folgenden Tabelle sind die Authentifizierungsoptionen zusammengefasst, die für die mit ASP.NET erstellten XML-Webdienste verfügbar sind. Optionen mit dem vorangestellten Wort "Windows" gehören zu den Microsoft Windows-Authentifizierungsoptionen, die für die mit ASP.NET erstellten XML-Webdienste verfügbar sind.
Übersicht der Authentifizierungsoptionen
Authentifizierungsoption | Beschreibung |
---|---|
Windows - Basisauthentifizierung | Wird für die nicht sichere Identifizierung von Clients verwendet. Hierbei werden Benutzername und Kennwort in base 64-codierten Zeichenfolgen als Klartext gesendet. Kennwörter und Benutzernamen werden bei diesem Authentifizierungstyp zwar codiert, aber nicht verschlüsselt. So könnten Unbefugte, die über ein Tool zur Netzwerküberwachung verfügen, zielgerichtet Benutzernamen und Kennwörter abfangen. |
Windows - Basisauthentifizierung über SSL | Wird für die sichere Identifizierung von Clients in Internetszenarien verwendet. Benutzername und Kennwort werden im Netzwerk als SSL (Secure Sockets Layer)-verschlüsselte Daten und nicht als Klartext gesendet. Dieser Typ ist relativ einfach zu konfigurieren und funktioniert in Internetszenarien. SSL führt jedoch auch zu einer Leistungsminderung. |
Windows - Digestauthentifizierung | Wird für die sichere Identifizierung von Clients in Internetszenarien verwendet. Clientanmeldeinformationen werden mit der Hashmethode verschlüsselt übertragen, d. h., das Kennwort wird nicht als Klartext gesendet. Darüber hinaus kann die Digestauthentifizierung auch über Proxyserver erfolgen. Dieser Typ wird jedoch von vielen anderen Plattformen nicht unterstützt. |
Windows - Integrierte Windows-Authentifizierung | Verwendet NTLM oder Kerberos. Dieser Typ basiert auf einem kryptographischen Austausch mit dem Microsoft Internet Explorer-Webbrowser des Benutzers. |
Windows - Clientzertifikate | Wird für die sichere Identifizierung von Clients in Internet- und Intranetszenarien verwendet. Jeder Client benötigt ein Zertifikat von einer für beide Seiten vertrauenswürdigen Zertifizierungsstelle. Zertifikate werden optional Benutzerkonten zugeordnet, die von IIS verwendet werden, um den Zugriff auf den XML-Webdienst zu autorisieren. |
Formulare | Wird von XML-Webdiensten nicht unterstützt. Bei diesem System werden nicht authentifizierte Anforderungen an ein HTML-Formular umgeleitet, indem die clientseitige HTTP-Umleitung verwendet wird. Für die meisten XML-Webdienstclients kommt die Anzeige von Anmeldeinformationen auf einer Benutzeroberfläche aber nicht in Betracht. Sie müssen eine Umgehungslösung finden, damit das Anmeldeformular nicht angezeigt wird. |
SOAP-Header – Benutzerdefiniert | Hilfreiche Option sowohl für sichere als auch für nicht sichere Internetszenarien. Benutzeranmeldeinformationen werden im SOAP-Header der SOAP-Meldung übermittelt. Der Webserver bietet eine benutzerdefinierte Authentifizierungsimplementierung, die unabhängig von der Plattform des XML-Webdienstes ist. |
Mit Ausnahme der SOAP-Header werden die Sicherheitseinstellungen bei allen oben aufgeführten Optionen durch eine Kombination aus Konfigurationsdateien und IIS festgelegt. Ausführliche Informationen zu Konfigurationsdateien erhalten Sie unter ASP.NET-Konfiguration. Die benutzerdefinierte SOAP-Headeroption wird im Anschluss an den Autorisierungsabschnitt ausführlich behandelt, da diese Lösung sowohl die Authentifizierung als auch die Autorisierung beinhaltet.
Windows-Authentifizierung
Sowohl IIS als auch ASP.NET bieten durch die in Windows integrierten Sicherheitsfunktionen Unterstützung für die Authentifizierung von Webanwendungen, u. a. auch für XML-Webdienste. Windows bietet drei Authentifizierungsoptionen: Basisauthentifizierung, Digestauthentifizierung und Integrierte Windows-Authentifizierung. Jede dieser Optionen kann außerdem mit SSL verwendet werden. Da Daten bei allen Windows-Authentifizierungsoptionen, mit Ausnahme der Basisauthentifizierung, verschlüsselt werden, wird die von SSL bereitgestellte zusätzliche Verschlüsselungsebene normalerweise nur mit der Basisauthentifizierung oder mit Clientzertifikaten verwendet.
Unabhängig von der verwendeten Windows-Authentifizierungsoption gibt es zwischen dem Einrichten des XML-Webdienstes und des XML-Webdienstclients keine großen Unterschiede. Eine Ausnahme bilden die Clientzertifikate. Die Schritte zum Einrichten des Servers und des Clients für die Verwendung von Clientzertifikaten werden deshalb weiter unten gesondert behandelt. Ein XML-Webdienst benötigt keinen zusätzlichen Code zur Verwendung der Windows-Authentifizierung, da die Authentifizierungsoptionen in einer Konfigurationsdatei und in IIS festgelegt werden. Einem XML-Webdienstclient muss Code hinzugefügt werden, über den Clientanmeldeinformationen an den XML-Webdienst übermittelt werden.
Wenn SSL als Teil des von einem XML-Webdienst verwendeten Authentifizierungsmechanismus ausgewählt wird, muss SSL über IIS für die Webanwendung, in der der XML-Webdienst enthalten ist, oder für den XML-Webdienst selbst konfiguriert werden. Anhand der Dienstbeschreibung und folglich auch anhand der von der Dienstbeschreibung erstellten Proxyklassen ist erkennbar, dass der XML-Webdienst SSL verwendet (sofern der Zugriff auf die Dienstbeschreibung und die Diensthilfeseite über SSL erfolgt). Dem URL für den XML-Webdienst wird innerhalb der Dienstbeschreibung "https" vorangestellt. Ausführliche Informationen zum Einrichten von SSL finden Sie in der IIS-Dokumentation.
So konfigurieren Sie den XML-Webdienst für die Windows-Authentifizierung
Konfigurieren Sie den XML-Webdienst über IIS für die Windows-Authentifizierung.
Mit IIS können Sie Sicherheit sowohl auf Verzeichnis- als auch auf Dateiebene festlegen. Wenn Sie die Sicherheit für einen XML-Webdienst pro Datei festlegen möchten, geben Sie die Berechtigungen für den XML-Webdienst in IIS in der ASMX-Datei an. Die ASMX-Datei ist der Einsprungpunkt in den XML-Webdienst. Details finden Sie in der IIS-Dokumentation.
Ändern Sie die Konfigurationsdatei, um die Windows-Authentifizierung festzulegen.
Legen Sie das mode-Attribut des XML-Elements authentication in einer Konfigurationsdatei auf "Windows" fest. Ausführliche Informationen zum Konfigurieren einer Konfigurationsdatei erhalten Sie unter ASP.NET-Konfiguration. Im folgenden Codebeispiel wird eine Konfigurationsdatei für die Verwendung der Windows-Authentifizierung angepasst.
// Fragment of a Web.config file. <authentication mode= "Windows"> </authentication>
So übermitteln Sie Clientanmeldeinformationen mit Hilfe der Windows-Authentifizierung an einen XML-Webdienst
Erstellen Sie eine neue Instanz der Proxyklasse für den XML-Webdienst. Falls keine Proxyklasse erstellt wurde, finden Sie ausführliche Informationen unter Erstellen eines XML-Webdienstproxys.
Erstellen Sie eine neue Instanz der NetworkCredential-Klasse, und legen Sie die Eigenschaften UserName, Password und Domain fest.
Erstellen Sie eine neue Instanz der CredentialCache-Klasse.
Fügen Sie der CredentialCache-Klasse die NetworkCredential-Klasse hinzu, indem Sie die Add-Methode der CredentialCache-Klasse verwenden.
Weisen Sie der Credentials-Eigenschaft der Proxyklasse die Instanz von CredentialCache zu.
Wenn die integrierte Windows-Authentifizierung verwendet wird, müssen Sie die Credentials-Eigenschaft auf DefaultCredentials festlegen.
Wenn die Credentials-Eigenschaft auf CredentialCache.DefaultCredentials festgelegt wird, handelt der Client je nach der Konfiguration des Servers mit dem Server die Kerberos- und/oder NTLM-Authentifizierung aus.
Durch folgendes Codebeispiel werden die Clientanmeldeinformationen festgelegt, die mittels der Windows-Authentifizierung an eine XML-Webdienstmethode übermittelt werden.
Imports System Imports System.Web.Services.Protocols Imports System.Net Imports MyMath Public Class Calculator Public Shared Sub Main() ' Create a new instance of the proxy class to an ' XML Web service method. Dim mathproxy As MyMath.Math = New MyMath.Math() ' Create a new instance of CredentialCache. Dim mycredentialCache As CredentialCache = New CredentialCache() ' Create a new instance of NetworkCredential using the client ' credentials. Dim credentials As NetworkCredential = New _ NetworkCredential(UserName,SecurelyStoredPasword,Domain) ' Add the NetworkCredential to the CredentialCache. mycredentialCache.Add(New Uri(mathproxy.Url), "Basic", _ credentials) ' Add the CredentialCache to the proxy class credentials. mathproxy.Credentials = mycredentialCache ' Call the method on the proxy class. Dim result As Integer result = mathproxy.Add(3,5) End Sub End Class [C#] using System; using System.Web.Services.Protocols; using System.Net; using MyMath; public class Calculator { public static void Main() { // Create a new instance of the proxy class to an XML // Web service method. MyMath.Math math = new MyMath.Math(); // Create a new instance of CredentialCache. CredentialCache credentialCache = new CredentialCache(); // Create a new instance of NetworkCredential using the client // credentials. NetworkCredential credentials = new NetworkCredential(UserName,SecurelyStroredPassword,Domain); // Add the NetworkCredential to the CredentialCache. credentialCache.Add(new Uri(math.Url), "Basic", credentials); // Add the CredentialCache to the proxy class credentials. math.Credentials = credentialCache; // Call the method on the proxy class. int result = math.Add(3,5); } }
Authentifizierung mit Clientzertifikaten
Clientzertifikate bieten einen sicheren Authentifizierungsmechanismus, da Clients ein elektronisches Dokument, das so genannte Clientzertifikat, übermitteln müssen, mit dem ein Client mittels einer SSL-Verbindung gegenüber dem Webserver identifiziert wird. Die SSL-Verbindung verschlüsselt die im Clientzertifikat enthaltenen Clientanmeldeinformationen bei der Übertragung über das Netzwerk. Die Kommunikation zwischen Client und Webserver wird verschlüsselt, indem die vom Client gesendeten Verschlüsselungsschlüssel mit den vom Webserver zur Verfügung gestellten Schlüsseln kombiniert werden. Nachdem die Kommunikationsvoraussetzungen erfüllt sind, können nur Client- und Servercomputer über diese SSL-Verbindung miteinander kommunizieren.
Ein Clientzertifikat kann von einer Zertifizierungsstelle angefordert werden; dies ist entweder der Webserver selbst oder ein vertrauenswürdiges zwischengeschaltetes Medium zwischen Client und Server. Nachdem ein Zertifikat ausgestellt und der Webserver für das Akzeptieren von Clientzertifikaten konfiguriert wurde, kann ein Client beim Aufruf eines XML-Webdienstes das Clientzertifikat über eine SSL-Verbindung an den Webserver senden. Weitere Einzelheiten zu Clientzertifikaten finden Sie in der IIS-Dokumentation.
So konfigurieren Sie den XML-Webdienst für die Authentifizierung mit Clientzertifikaten
Die folgende Liste enthält eine Übersicht darüber, wie Sie IIS für die Authentifizierung von Clients mit Hilfe von Clientzertifikaten konfigurieren. Einzelheiten dazu finden Sie in der IIS-Dokumentation.
Installieren Sie SSL.
Konfigurieren Sie die Webanwendung für die Annahme von Clientzertifikaten.
Ändern Sie die Konfigurationsdatei, um für den XML-Webdienst die Windows-Authentifizierung festzulegen.
Legen Sie das mode-Attribut des XML-Elements authentication in einer Konfigurationsdatei auf "Windows" fest. Ausführliche Informationen zum Konfigurieren einer Konfigurationsdatei erhalten Sie unter ASP.NET-Konfiguration. Im folgenden Codebeispiel wird eine Konfigurationsdatei für die Verwendung der Windows-Authentifizierung angepasst.
// Fragment of a Web.config file. <authentication mode= "Windows"> </authentication>
So übermitteln Sie Clientanmeldeinformationen mit Hilfe der Windows-Authentifizierung an einen XML-Webdienst
Erstellen Sie eine neue Instanz der Proxyklasse für den XML-Webdienst. Falls keine Proxyklasse erstellt wurde, finden Sie ausführliche Informationen unter Erstellen eines XML-Webdienstproxys.
Erstellen Sie eine neue Instanz der X509Certificate-Klasse.
Rufen Sie die CreateFromCertFile-Methode auf, um das Clientzertifikat aus einer Datei zu laden.
Ein Client kann eine Clientzertifikatsdatei von einer vertrauenswürdigen Zertifizierungsstelle anfordern. Einzelheiten dazu finden Sie in der IIS-Dokumentation.
Fügen Sie der ClientCertificates-Auflistung der Proxyklasse die X509Certificate-Klasse hinzu.
Im folgenden Codebeispiel wird veranschaulicht, wie ein XML-Webdienstclient seine Anmeldeinformationen mit Hilfe eines Clientzertifikats übermittelt. Ein vom Webserver ausgestelltes Clientzertifikat wird mit der CreateFromCertFile-Methode aus einer Datei geladen und anschließend der ClientCertificates-Eigenschaft der Proxyklasse hinzugefügt.
' Instantiate proxy class to a Bank XML Web service. Dim bank As BankSession = new BankSession() ' Load the client certificate from a file. Dim x509 As X509Certificate = X509Certificate.CreateFromCertFile("c:\user.cer") ' Add the client certificate to the ClientCertificates property ' of the proxy class. bank.ClientCertificates.Add(x509) ' Call the method on the proxy class, which requires authentication ' using client certificates. bank.Deposit(500) [C#] // Instantiate proxy class to a Bank XML Web service. BankSession bank = new BankSession(); // Load the client certificate from a file. X509Certificate x509 = X509Certificate.CreateFromCertFile(@"c:\user.cer"); // Add the client certificate to the ClientCertificates property // of the proxy class. bank.ClientCertificates.Add(x509); // Call the method on the proxy class, which requires // authentication using client certificates. bank.Deposit(500);
Autorisierungsoptionen für XML-Webdienste
Der Zweck der Autorisierung ist zu bestimmen, ob einer Identität die angeforderte Zugriffsart auf eine angegebene Ressource gewährt werden soll. Es gibt zwei grundlegende Verfahrensweisen, um den Zugriff auf eine bestimmte Ressource zu autorisieren: Dateiautorisierung und URL-Autorisierung. Die Dateiautorisierung kann immer dann verwendet werden, wenn die Windows-Authentifizierung zum Einsatz kommt, da die Berechtigungen in IIS pro Datei vergeben werden. Die URL-Autorisierung kann mit einem beliebigen integrierten Authentifizierungsmechanismus gekoppelt werden, der von ASP.NET unterstützt wird. Bei der URL-Autorisierung erfolgt die Konfiguration über eine Konfigurationsdatei. Dabei kann Benutzern der Zugriff auf die mit ASP.NET verknüpften Dateien, einschließlich ASMX-Dateien, selektiv gewährt oder verweigert werden.
Ausführliche Informationen zum Einrichten der Autorisierung pro Datei finden Sie in der IIS-Dokumentation.
Einzelheiten zum Einrichten der Autorisierung mit Hilfe einer Konfigurationsdatei finden Sie unter ASP.NET-Autorisierung.
SOAP-Header – Benutzerdefinierte Lösung
Die Windows-Authentifizierungsmechanismen, einschließlich Clientzertifikate, basieren auf dem HTTP-Transport, während SOAP transportunabhängig ist. Mit ASP.NET erstellte XML-Webdienste verwenden SOAP über HTTP. Ein Grund für die Erstellung eines benutzerdefinierten Authentifizierungsmechanismus liegt also darin, die Authentifizierung vom Transport abzukoppeln. Dies wird erreicht, indem die Authentifizierungsanmeldeinformationen im SOAP-Header übermittelt werden.
SOAP-Header stellen eine effiziente Methode dar, um Out-of-Band-Daten oder Informationen ohne semantischen Bezug zu einem XML-Webdienst zu übermitteln. Im Unterschied zum Body-Element einer SOAP-Meldung, die die Eingabe- und Ausgabeparameter für die XML-Webdienstmethode enthält, die anschließend von der XML-Webdienstmethode verarbeitet werden, ist das Header-Element optional und kann folglich von der Infrastruktur verarbeitet werden. Die Verarbeitung findet also über eine Infrastruktur statt, die für die Bereitstellung eines benutzerdefinierten Authentifizierungsmechanismus entwickelt wurde.
Die folgende benutzerdefinierte Lösung wurde mit ASP.NET erstellt, um einen Authentifizierungsmechanismus über SOAP-Header zur Verfügung zu stellen. Die Lösung wird anhand der folgenden Schritte erstellt:
- Es wird ein benutzerdefiniertes HTTP-Modul erstellt, das auf dem Webserver ausgeführt wird, der den Host der XML-Webdienste darstellt.
- Das HTTP Module analysiert HTTP-Meldungen, um festzustellen, ob es sich um SOAP-Meldungen handelt.
- Wenn das HTTP Module eine SOAP-Meldung erkennt, werden die SOAP-Header gelesen.
- Wenn die SOAP-Meldung über den SOAP-Header mit Authentifizierungsanmeldeinformationen verfügt, löst HTTP Module ein benutzerdefiniertes global.asax-Ereignis aus.
Um den XML-Webdienst für die Verwendung der benutzerdefinierten SOAP-Headerauthentifizierung anzupassen, muss der XML-Webdienst zwei Punkte erfüllen: Er muss angeben, dass er den SOAP-Header mit den Authentifizierungsanmeldeinformationen erwartet, und er muss den Clientzugriff auf den XML-Webdienst autorisieren. Im angegebenen Beispiel wird der Benutzer über HTTP Module authentifiziert, und es werden Context-Eigenschaften festgelegt, mit deren Hilfe ein XML-Webdienst entscheiden kann, ob der Client für den Zugriff auf den XML-Webdienst autorisiert ist.
Ein XML-Webdienstclient sendet seine Anmeldeinformationen dann an den XML-Webdienst, indem er der SOAP-Anforderung den erwarteten SOAP-Header hinzufügt und ihn mit Clientanmeldeinformationen füllt. Es ist unbedingt zu beachten, dass der Text in diesem Beispiel im Netzwerk in Klartext gesendet wird (er ist also nicht verschlüsselt). Wenn Klartext die Schutzanforderungen Ihrer Anwendung nicht erfüllt, sollten Sie einen Verschlüsselungsalgorithmus hinzufügen.
Das folgende Codebeispiel ist ein HTTP-Modul, das HTTP-Meldungen für SOAP-Anforderungen analysiert. Wenn die HTTP-Meldung eine SOAP-Meldung ist, wird das benutzerdefinierte WebServiceAuthenticationEvent
ausgelöst.
using System;
using System.Web;
using System.IO;
using System.Xml;
using System.Xml.XPath;
using System.Text;
using System.Web.Services.Protocols;
namespace Microsoft.WebServices.Security {
public sealed class WebServiceAuthenticationModule : IHttpModule
{
private WebServiceAuthenticationEventHandler
_eventHandler = null;
public event WebServiceAuthenticationEventHandler Authenticate
{
add { _eventHandler += value;}
remove {_eventHandler -= value;}
}
public void Dispose()
{
}
public void Init(HttpApplication app)
{
app.AuthenticateRequest += new
EventHandler(this.OnEnter);
}
private void OnAuthenticate(WebServiceAuthenticationEvent e)
{
if (_eventHandler == null)
return;
_eventHandler(this, e);
if (e.User != null)
e.Context.User = e.Principal;
}
public string ModuleName
{
get{ return "WebServiceAuthentication"; }
}
void OnEnter(Object source, EventArgs eventArgs) {
HttpApplication app = (HttpApplication)source;
HttpContext context = app.Context;
Stream HttpStream = context.Request.InputStream;
// Save the current position of stream.
long posStream = HttpStream.Position;
// If the request contains an HTTP_SOAPACTION
// header, look at this message.
if (context.Request.ServerVariables["HTTP_SOAPACTION"] == null)
return;
// Load the body of the HTTP message
// into an XML document.
XmlDocument dom = new XmlDocument();
string soapUser;
string soapPassword;
try
{
dom.Load(HttpStream);
// Reset the stream position.
HttpStream.Position = posStream;
// Bind to the Authentication header.
soapUser =
dom.GetElementsByTagName("User").Item(0).InnerText;
soapPassword =
dom.GetElementsByTagName("Password").Item(0).InnerText;
}
catch (Exception e)
{
// Reset the position of stream.
HttpStream.Position = posStream;
// Throw a SOAP exception.
XmlQualifiedName name = new
XmlQualifiedName("Load");
SoapException soapException = new SoapException(
"Unable to read SOAP request", name, e);
throw soapException;
}
// Raise the custom global.asax event.
OnAuthenticate(new WebServiceAuthenticationEvent (context, soapUser, soapPassword));
return;
}
}
}
Das folgende Codebeispiel stellt ein benutzerdefiniertes Authentifizierungsereignis dar, das beim Empfang einer SOAP-Anforderung vom HTTP Module ausgelöst wird.
namespace Microsoft.WebServices.Security {
using System;
using System.Web;
using System.Security.Principal;
public class WebServiceAuthenticationEvent : EventArgs {
private Iprincipal _IPrincipalUser;
private HttpContext _Context;
private string _User;
private string _Password;
public WebServiceAuthenticationEvent(HttpContext context)
{
_Context = context;
}
public WebServiceAuthenticationEvent(HttpContext context,
string user, string password)
{
_Context = context;
_User = user;
_Password = password;
}
public HttpContext Context
{
get { return _Context;}
}
public IPrincipal Principal
{
get { return _IPrincipalUser;}
set { _IPrincipalUser = value;}
}
public void Authenticate()
{
GenericIdentity i = new GenericIdentity(User);
this.Principal = new GenericPrincipal(i, new String[0]);
}
public void Authenticate(string[] roles)
{
GenericIdentity i = new GenericIdentity(User);
this.Principal = new GenericPrincipal(i, roles);
}
public string User
{
get { return _User; }
set { _User = value; }
}
public string Password
{
get { return _Password; }
set { _Password = value; }
}
public bool HasCredentials {
get
{
if ((_User == null) || (_Password == null))
return false;
return true;
}
}
}
}
Im folgenden Codebeispiel wird der Delegat für das benutzerdefinierte WebServiceAuthenticationEvent
-Ereignis angegeben.
namespace Microsoft.WebServices.Security
{
using System;
public delegate void WebServiceAuthenticationEventHandler(Object sender, WebServiceAuthenticationEvent e);
}
Das folgende Codebeispiel entspricht einem XML-Webdienst, durch den der von einem Client zu übermittelnde Authentication
-SOAP-Header definiert wird. Der XML-Webdienst muss keine Authentifizierung durchführen. Vielmehr prüft er die User.Identity.IsAuthenticated-Eigenschaft, um zu bestimmen, ob der Benutzer vom HTTP Module authentifiziert wurde.
<%@ WebService Language="C#" Class="SecureWebService" %>
using System;
using System.Web.Services;
using System.Web.Services.Protocols;
public class Authentication : SoapHeader {
public string User;
public string Password;
}
public class SecureWebService : WebService{
public Authentication authentication;
[WebMethod]
[SoapHeader("authentication")]
public string ValidUser(){
if (User.IsInRole("Customer"))
return "User is in role customer";
if (User.Identity.IsAuthenticated)
return "User is a valid user";
return "not authenticated";
}
}
Das folgende Codebeispiel stellt einen XML-Webdienstclient dar, der innerhalb eines Authentication
-SOAP-Headers die erforderlichen Anmeldeinformationen für einen Authentifizierungsmechanismus übermittelt, der auf benutzerdefinierten SOAP-Headern basiert.
// Create a new instance of an XML Web service proxy class.
SecureWebService s = new SecureWebService();
// Create the Authentication SOAP header and set values.
Authentication a = new Authentication();
a.User = user.Value;
a.Password = password.Value;
// Assign the Header.
s.AuthenticationValue = a;
string result = s.ValidUser();
span1.InnerHtml = result;
Siehe auch
Sicherheit für ASP.NET-Webanwendungen | ASP.NET-Konfiguration | Erstellen von XML-Webdiensten mit ASP.NET | NetworkCredential | CredentialCache | X509Certificate