What is the optimal architecture for such case:

  1. Web application(.Net Web Forms) connects to third party web service via wcf.
  2. Third party web service accepts only digitally signed soap requests
  3. Some typical business processes consist of several soap requests.
  4. User must start business process (send several soap requests) via web application and digitally sign it in the front-end by its certificate (smart-card holding its certificate). Web application doesn't store any user certificates, it only stores user data that must be sent to web service.

My current thoughts are to create some proxy web service that would intercept user soap requests without digital signatures and put them into database. Then user would open some web form where he would see all requests that he must digitally sign. User signs requests via some web browser plugin. As the result of that operation web application gets digitally signed requests that it can send to original web service.

There is some problem with this realization though - it doesn't consider any if's logic and it can't use results gained from previous requests. The process of information exchange between web application and web service must be straightforward since user sends requests to fake proxy web service that can't return real data and results. So we would send data as-is hoping that there would be no results that our process of informational exchange would depend on.

Another option is to digitally sign all requests to web service in real-time. But I can't get how to do it in WCF. I can use IClientMessageInspector and intercept message before it would be sent to web service. In theory I can make some callback at this moment to frontend and wait for user to digitally sign request and then replace original request to user's one. But current realization of web application doesn't allow any callbacks to front end in WCF.

Any thoughts would be highly appreciated.

  • I've done a similar thing before. the approach was to put the card in a reader attached to the server. which could then sign stuff via an api with no manual input. I guess you could do the same thing on the client unless your card needs the user to type a code or something per signing? – Ewan Nov 18 '15 at 9:29
  • @Ewan Each user holds its own certificate(has his own smart-card). They have to manually enter its pin code in order to sign smth. I can't force users to store their certificates on server since - 1. It's not right. 2. Smart-card doesn't allow export of its private key anywhere. – nikita Nov 18 '15 at 9:31
  • but do they need to enter the pin each time? if so, there's not much you can do i guess – Ewan Nov 18 '15 at 12:35
  • @Ewan They need to enter pin code each time. Though I have solution for web browser plugin that allows to enter pin-code one time in order to sign multiple requests. But either way they need to enter pin-code. – nikita Nov 18 '15 at 12:47
  • if you can do multiple requests then you are good. just get them to enter the pin at the start and add websockets so your server can talk to the browser to get stuff signed as needed – Ewan Nov 18 '15 at 13:42

This is definitely an asynchronous workflow. The user cannot practically be in the loop in a blocking manner because it will tie up connections and resources upstream.

I would put unsigned messages on an queue for unsigned messages. I would have a user-interface that subscribes to the queue for unsigned messages. This could be EventSource-based for efficiency, but XHR long-polling will also suffice. This interface would allow signing and would submit signed messages back to the server which would put them on a queue for signed messages.

A separate process which can actually be on any machine with access to the queue for signed messages would then submit those messages to the consuming service.


I think you can do this with a combination of tech, its looks like you have most of it in place already.

1: website javascript or active X to communicate with the card reader

2: webserver side code for duplex communication with the client. this seems to be the bit you are missing. Its pretty new but this can now be done with websockets


3: custom signing pipeline on the WCF service

so the flow would be

client -> establish websockets connection to webserver

client -> button clicked POST json command to server

webserver-> do logic and send commands to WCF service

WCF -> create messages to 3rd party SOAP endpoint

Custom WCF signing -> send message to webserver requesting that it be signed.. (maybe use a messaging queue?) wait....

webserver -> using websocket connection send message to client to be signed

client -> receive message and talk to card reader to get it signed

client -> send signed message back to webserver (again websockets)

webserver -> complete RPC style call from WCF by sending the signed message back

WCF Custom Signing : complete pipeline with signed message

Not the answer you're looking for? Browse other questions tagged or ask your own question.