Authentifizierung in Web Services - SOAP Header

Geschrieben von: Christoph Wille
Kategorie: Web Services

This printed page brought to you by AlphaSierraPapa

Im letzten Artikel zum Thema Authentifizierung in Web Services haben wir uns mit protokollabhängiger Authentifizierung beschäftigt. Obwohl Windows Integrated eine gute Intranet-Lösung ist, so ist sie nicht Plattform-übergreifend, man ist an Windows Clients gebunden. Man kann diese Einschränkung umgehen, indem man zusätzliche SOAP Header in den SOAP Nachrichten mitschickt.

Der "Trick" mit den zusätzlichen SOAP Headern bringt uns Plattformunabhängigkeit, allerdings auch ein "Problem": wir müssen unsere Authentifizierungs-SOAP-Header und deren Verwendung für Konsumenten unseres Services dokumentieren. Denn ohne das Mitsenden der Authentifizierungsdaten kann niemand mit unserem Service kommunizieren - und diesen werden wir jetzt gleich implementieren.

Der Web Service

Beginnen wir damit, uns den Code für den Service Stück für Stück anzusehen:

using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.Services;

// Notwendig für die Definition neuer SOAP Header
using System.Web.Services.Protocols;

namespace SoapHeaderAuth
{
  public class Service1 : System.Web.Services.WebService
  {
    public Service1()
    {
    }

    // Unsere Klasse für den Authentifizerungs-SOAP-Header
    public class ServiceAuthHeader : SoapHeader 
    {
      public string Username;
      public string Password;
    }

Das hinzugefügte using Statement brauchen wir, damit wir eine von SoapHeader abgeleitete Klasse erstellen können. Diese Klasse - ServiceAuthHeader - ist der Authentifizierungs-SOAP-Header, der durch eine public Variable repräsentiert wird, welche via dem SoapHeaderAttribute auf der entsprechenden Methode befüllt wird.

    // Diese Instanzvariable wird später verwendet, um den SOAP Header auszulesen
    public ServiceAuthHeader CurrentUser;

    [WebMethod]
    [SoapHeader("CurrentUser")]
    public string SoapHeaderAuthSampleMethod()
    {
      Authenticate();

      return "Hello World, " + CurrentUser.Username;
    }

    private void Authenticate()
    {
      if (CurrentUser.Username != "test" || CurrentUser.Password != "test")
      {
        // Normalerweise würde man fehlgeschlagene Logins im Eventlog mitschreiben
        // Dem User wird so wenig sicherheitsrelevante Information zurückgeschickt als möglich
        throw new SoapException("Log in fehlgeschlagen", 
                                SoapException.ServerFaultCode);
      }
    }
  }
}

Da es sich um einen zusätzlichen SOAP Header und keine Authentifizierungsmethode der Infrastruktur handelt, müssen wir die Authentifizierung selbst vornehmen. Diese ist in die Authenticate Methode ausgelagert, damit sie in anderen Web Methods wiederverwendet werden kann. Im übrigen wird man im echten Leben gegen Benutzerdatenbanken und nicht hardcodierte Daten validieren.

Der Client

Das Generieren des Web Service Proxy verläuft identisch mit normalen, ungesicherten Web Services. Der Aufruf des Services ändert sich aber, da wir den zusätzlichen SOAP Header anlegen und übergeben müssen:

using System;

namespace SoapHeaderAuthClient
{
  class ConsoleAppWsClient
  {
    [STAThread]
    static void Main(string[] args)
    {
      // Instanz des Authentifierungs-SOAP-Headers anlegen und Werte eintragen
      localhost.ServiceAuthHeader sah = new localhost.ServiceAuthHeader();
      sah.Username = "test";
      sah.Password = "test";

      // Neue Service Instanz anlegen
      localhost.Service1 svc = new localhost.Service1();
      
      // Den SOAP Header anfügen; immer <Datentyp>Value
      svc.ServiceAuthHeaderValue = sah;

      string strResult = svc.SoapHeaderAuthSampleMethod();
      Console.WriteLine(strResult);
    }
  }
}

Das WSDL Utility (bzw das "Add Web Reference" Tool in VS.NET) autogeneriert eine Proxy-Klasse für den zusätzlichen SOAP Header. Einzig bei der Zuweisung muß man aufpassen - es wird nicht auf die public Variable des Services zugewiesen, sondern auf eine Eigenschaft namens <Datentyp>Value. Da es immer so ist, ist es auch leicht zu merken.

Damit hätten wir alles notwendige für die Authentifizierung via Custom SOAP Headers implementiert. Der Programmieraufwand hält sich in Grenzen, und schon haben wir einen Service, der Cross-Plattform Authentifizerung beherrscht.

Schlußbemerkung

Der Haken an der Sache ist, daß jeder seine eigenen SOAP Authentifizierungsheader erfinden würde, und man jedes Mal nachlesen muß, wie für den spezifischen Server diese Header auszusehen haben. Das haben sich einige Firmen wie IBM oder Microsoft auch gedacht, und einen Standard für Authentifizierung aus der Taufe gehoben: WS-Security. Dieser legt die Header für Authentifizierung fest, und die Herstellerfirmen liefern Toolkits, die man zur Programmierung von WS-Security verwenden kann. Mit dem Microsoft Toolkit beschäftigen wir uns in den nächsten beiden Artikeln.

This printed page brought to you by AlphaSierraPapa

Download des Codes

Klicken Sie hier, um den Download zu starten.
http://www.aspheute.com/code/20030501.zip

Verwandte Artikel

Authentifizierung in Web Services - Windows Integrated
http:/www.aspheute.com/artikel/20030429.htm
Authentifizierung in Web Services - WS-Security, Benutzername / Passwort
http:/www.aspheute.com/artikel/20030502.htm