LEIDENSCHAFT

BERUF

BERUFUNG

Bei einem Kunden stand die Aufgabe an, einen WCF Service abzusichern, SSL + Windows Authentifizierung.

 

Im Nachgang stelle sich dann heraus, dass es noch ein weiteres Reporting Service Projekt gibt,

welches ebenfalls diesen Service als Quelle benutzt.

 

 

Zuerst entschlossen wir uns das wsBinding einzusetzen.

 

Die Änderungen hierzu sind allgemein bekannt, also hier in Kürze

 

<wsHttpBinding>
          <binding
            name="wsBinding"
            maxBufferPoolSize="2147483647"
            maxReceivedMessageSize="2147483647"
            messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
            receiveTimeout="16:00:00"
            sendTimeout="16:00:00"
            closeTimeout="00:00:30"
            openTimeout="00:00:30"
          >
          <security mode="Transport">

          <transport clientCredentialType="Windows" />
          </security>
        </binding>
    </wsHttpBinding>

 

 

<endpoint name="wsBinding"
                  address="/"
                  binding="wsHttpBinding"
                  bindingConfiguration="wsBinding"
                  contract="Service.IService">
</endpoint>

 

Zusätzlich wurden im Service mehrere Methoden auf unterschiedliche Gruppen beschränkt.

[PrincipalPermission(SecurityAction.Demand, Role = "RoleName")]
public DataSet Get...(...paramlist...)

 

 

Leider benötigt das Reporting Projekt Soap 1.1 (ja, es gibt auch andere Möglichkeiten des Reportings)

und wsBinding liefert nun Soap 1.2.

 

Zu erkennen an der Fehlermeldung falscher Content Type (text/xml statt application/soap+xml).

Der Kunde möchte außerdem alsbald in Urlaub fahren, daher mußte eine schnelle, einfache

Lösung her, also kein CustomBinding mit der WCF oä.

 

Also mußte dass httpBasicBinding dann auch herhalten.

 

<basicHttpBinding>
        <binding
          name="basicHttpBinding"
          maxBufferPoolSize="2147483647"
          maxReceivedMessageSize="2147483647"
          messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
          receiveTimeout="16:00:00"
          sendTimeout="16:00:00"
          closeTimeout="00:00:30"
          openTimeout="00:00:30"
        >
        <security mode="Transport">
          <transport clientCredentialType="Windows" />
        </security>
      </binding>
</basicHttpBinding>

 

Hierzu gab es dann natrlüch auch einen Endpunkt,

wir haben uns dazu entsclossen, hierfür einen weiteren Service

anzubieten, dieser neue Service leitet sich direkt vom ersten ab,

so das keine CodeÄnderungen vorzunehmen waren.

 

<endpoint name="basicHttpBinding"
                  address="/"
                  binding="basicHttpBinding"
                  bindingConfiguration="basicHttpBinding"
                  contract="Service.IService">
</endpoint>

Um nun sicherzustellen, dass beide Services, dieselben SoapActions erzeugen,

wurde im Interface noch der entsprechende Namespace hinterlegt.

 

[ServiceContract(Namespace = "http://meinKunde.de/")]
public interface IService

 

Schon hatten wir zwei SSL Services mit beiden SOAP Defnitionen.

Es blieb noch die Aufgabe ein gültiges Zertifikat zu erzeugen,

das geht am einfachsten mit dem IIS 6.0 Resource Kit,

selfssl ....

 

Im IIS nur noch das Binding auf https mit dem Zertifikat eingerichtet,

 

Auf den Clients wurde dann programmtisch das Zertifikat (der den WCF direkt und indirekt über Reporting Service benutzt)

installiert.

 

string file; // Contains name of certificate file
X509Store store = new X509Store(StoreName.Root, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadWrite);
store.Add(new X509Certificate2(X509Certificate2.CreateFromCertFile(file)));
store.Close();

 

Dann noch eben das Zertifikat auf dem Reporting Server installiert

und schon ist der Urlaub meines Kunden entspannt.

 

 

Login Form