0

Say, I have 4 servers, one publicly visible (A), others (B,C and D) only visible to the one (A). Where B, C and D are identical services, each in their own company.

Can I route a call from a client to server A through to servers B, C or D depending on the client's Certificate used in the call?

And further, is it possible to specify what the destination is inside the message to server A? (Would require a partial encrypted message) (for example: I need to provide an employee record to company C, but A should not be able to read the record.)

I mean, this is possible of course if I re-implement the service of B, C and D on A, and let A be a new client to B, C and D. But I'd like to keep the message secured from client to B,C or D and let A only know what it needs to know to deliver it to them. So, if I re-implement the service, I wouldn't be able to use the transparent message encryption that WCF can provide as it would just decrypt it all.

EDIT:

The goal is to get data from a client to B,C or D, while, B,C or D only accept TCP packets from A. And, A is not allowed to read the data meant for B, C or D.

Stijn Tallon
  • 373
  • 1
  • 4
  • 12

1 Answers1

0

Short answer is Yes, WCF technology can do those things.

Longer answer: Yes, you could for instance set up "A" as an SSL WCF endpoint. An inbound request could have, for instance, a client certificate or internal value pointing to it's final destination on "B", "C" or "D".

So the work flow would be something like this:

  • Client app intializes a WCF client and contacts server "A"

  • "A" negotiates SSL with client app

  • "A" WCF web service host receives inbound, SSL request.

  • "A" decryptes message

  • "A" checks content for destination - turns out the final destination is "D"

  • "A" initializes a WCF client connection

  • "A" sets the WCF client URL to the "D" WCF host endpoint URL

  • "D" Receives initial request from "A", intializing SSL communication

  • Server "A" WCF client forwards the newly encrypted request to "D", which decrypts, processes and then sends back acknowledgement that "A" relays back to the original client.

Certainly there are many options on this, but aside from the encryption specifics, the work flow would be about the same.

If server "A" is not supposed to read the content of the message before passing it along, I'm not sure where you go. SSL is all or nothing, basically.

Besides SSL, the other commonly used encryption method would be Message-Level (SOAP) encryption, but that only works if client sending the original message has resident on the device the public and private keys of the certificate used for Message encryption. So, conceivably, you could have a client send an SSL-wrapped request to server "A" which has internal content encrypted with Message Encryption that "A" cannot read. There could be enough unencrypted information in the headers of the request that "A" would know to route the message on to server "D".

But I'd only do that if we're talking about server-to-server traffic. If you're talking about clients with iPhones doing this, what I've suggested won't work.

Brian
  • 3,653
  • 1
  • 22
  • 33
  • Well, the setup i'm looking for would be phones connecting to an edge server (A), and this one then forwards it to the internal final destination (B, C, ..). So redirecting the URL on the client to B or such is impossible as they are not accepting traffic from anyone else then A. But A is not allowed to view the content of the packet, only the headers. But with the way WCF just calls the service's methods, I don't see a way to add extra headers, except maybe if I manually encrypt the data and provide it as a blob in the call. void sendData(EndpointType destination, DataBlob encryptedData); – Stijn Tallon Feb 26 '14 at 00:14
  • OK, if the original request comes from phones, I don't see a solution where server "A" can detect destinations "B" or "C" without reading the internal content. With SSL, the whole message is encrypted or decrypted. Only with Message-based encryption can you encrypt the body of the message leaving the headers alone. But message (soap) encryption requires a very specific certificate installment process for each client; certainly too complicated for normal users. Sorry ... good luck in your search. – Brian Feb 26 '14 at 08:01
  • Furthermore, even if you could hides some information in the request URL (query string), there's no way to establish an SSL connection from (say) "B", through "A", and onto your iPhone. The SSL negotiation must take place between client and host directly ... so no. – Brian Feb 26 '14 at 08:04