2009-09-15 3 views
7

Ich habe einige Dienste, die von Clients innerhalb einer sicheren Zone genutzt werden. Ich wurde gebeten, diese Dienste in der Regel gegen Entwicklungsclients zu schützen, die fälschlicherweise eine Verbindung mit dem falschen Dienst herstellen.So schränken Sie den Zugriff auf einen WCF-Dienst mit einem freigegebenen Schlüssel ein

Die Idee war, Pre-Shared Key (wie ein GUID), der sowohl für die Kunden in der Konfigurations gesetzt ist und die Host-Dienst. Immer wenn der Client versucht, den Dienst zu verwenden, muss er den richtigen Schlüssel anzeigen.

Wie würde ich mich über einen Dienst zu konfigurieren, diese Art von Sicherheit zu implementieren? Wie viel Anpassung ist notwendig?

Antwort

0

Wenn Sie es mit dem Schlüssel tun, würden Sie den Vertrag des Dienstes ändern, um ein Feld zu schließen, dass der Schlüssel in platziert werden würde. Dann überprüfen Sie den Wert in dem Schlüssel auf der Server-Seite.

in Ihrem Fall jedoch könnten Sie die IP-Adressen wurden erlaubt den Zugriff auf den Dienst, durch die Netzwerk-Konfiguration beschränken. Dies wäre weniger Arbeit als das Ändern der Signatur Ihrer Dienste.

+0

Dies ist keine gute Idee - auf diese Weise müssen Sie Ihre Verträge ändern, und Sie " verschmutzen "Ihre eigentliche Geschäftslogik mit Infrastruktur/Steuerungsfeldern. Ich würde diesen Ansatz nicht empfehlen. –

2

würde ich der Kunde den Schlüssel als Extra-Message-Header senden und eine IDispatchMessageInspector erstellen für den Header zu prüfen und gegebenenfalls abzulehnen. This Code Project beschreibt den Filterteil basierend auf der IP-Adresse.

+0

Vielen Dank, ich mag das Aussehen dieses Ansatzes. Ich habe ein bisschen nach dieser Idee gesucht, und es sieht so aus, als ob ich einen IClientMessageInspector verwenden sollte, um den Schlüssel auf der Client-Seite einzufügen - implementiert als ein Endpunkt-Verhalten. Und dann auf der Serverseite werde ich ein Verhalten haben, das IDispatchMessageInspector implementiert, der nach dem Schlüssel sucht. Eine letzte Sache - gibt es in wcf etwas Readymade, das ein ähnliches Ziel erreichen würde, aber ohne das Bedürfnis nach einem benutzerdefinierten Verhalten? – Columbo

+0

Wenn Sie die WCF-Sicherheitsfunktionen nicht verwenden, können Sie sie für diesen Ansatz verwenden. In diesem Fall würde ich für jede Client-App ein Zertifikat erstellen und in jedem Dienst nach den zulässigen Client-Zertifikaten suchen. Und ich nehme an, Sie könnten das gleiche mit Benutzername/Passwort tun, obwohl das Sie zwingen würde, auch HTTPS zu verwenden. – Maurice

+0

Danke, die Benutzer/Pass-Authentifizierung war etwas, das wir vorher in Betracht gezogen hatten, aber wir hatten ein paar Probleme mit der SSL und unserer Netzwerkkonfiguration, was bedeutete, dass wir nach anderen Möglichkeiten suchten, die Anforderung zu erfüllen. Von dem, was ich heute gelernt habe, denke ich, werde ich diesen Ansatz des Sendens eines gemeinsamen Schlüssels in der Kopfzeile verwenden. So, jetzt ist es nur ein kleines Testprojekt zu machen :) – Columbo

3

Sie könnte leicht eine benutzerdefinierte Message-Header zu jedem Anruf hinzufügen - recht einfach zu tun, tatsächlich, und es „verschmutzen“ nicht Ihren echten Service-Vertrag, zum Beispiel Sie müssen Ihren Serviceaufrufen keine zusätzlichen Parameter hinzufügen, um dies zu bestehen.

Sehen Sie diese Artikel für Informationen darüber, wie dieses Ziel zu erreichen:

Grundsätzlich müssen Sie Ihren Anruf an den Dienst in einer Operation wickeln - das ist alles, keine ClientMessageInspector und andere Tricks benötigt :-)

using (OperationContextScope scope = new OperationContextScope(proxy)) 
{ 
    Guid myToken = Guid.NewGuid(); 

    MessageHeader<Guid> mhg = new MessageHeader<Guid>(myToken); 
    MessageHeader untyped = mhg.GetUntypedHeader("token", "ns"); 

    OperationContext.Current.OutgoingMessageHeaders.Add(untyped); 

    proxy.DoOperation(...); 
    } 

und auf der Serverseite, können Sie einfach die IncomingMessageHeaders Sammlung inspizieren:

Guid myToken = OperationContext.Current. 
       IncomingMessageHeaders.GetHeader<Guid>("token", "ns"); 

Marc

+0

Hallo Marc, vorausgesetzt, Columbo hatte keine andere Sicherheit für den Dienst konfiguriert, wird diese Lösung immer noch in der WCF-Nachricht Inhalte verschlüsselt werden? – Xiaofu

+0

@Xiaofu: Standardmäßig (sofern Sie es nicht explizit deaktivieren) ** sind alle WCF-Nachrichten verschlüsselt und digital signiert. –