Client, which is communicating with a WCF service using transport security mode, has to keep records of original digitally signed responses along with the decrypted data.
Is there a way in WCF to get access the signed data from a response, or do I need to explicitly pass the signed data in the response message itself.
Related
I have a VB.NET website configured in IIS to use client certificate authentication.
When a user opens website url, he gets a popup to choose the certificate. Once the user is on the web page there is a button, clicking this will make a SOAP request to a 3rd party.
Presently I am able to use a single certificate stored on the server to make the SOAP request (by attaching the certificate). Thus the same certificate is used irrespective of which user clicks on the button.
How do I attach the client certificate of the respective user to a SOAP request? Is this possible?
How do I attach the client certificate of the respective user to a SOAP request? Is this possible?
simply attaching the public certificate of client makes little sense. If you need to co-sign the SOAP request with client certificate, then you need to send unsigned SOAP request to client (say, client downloads the request from your web site), sign it, send to server, allow the server to co-sign the SOAP request and then submit this SOAP request to 3rd party.
You cannot upload client certificate to server in order to make SOAP signing on server. It is unsupported and vulnerable approach. Client certificate's private key (which is used to sign data) MUST NEVER leave client machine/device. If you need to sign anything with client certificate, signing operation must be performed on that client only.
I have to make an WCF client for one external SOAP web-service written probably in Java. That web-service uses WS-Security for signing and encryption (so, I suppose I have to use WCF message level security). Transport mechanism between client and web-service is HTTPS with 2-way handshaking.
The problem is that I have to use four different certificates - let us call them CertA, CertB, CertC and CertD.
CertA and CertC must be used for signing the SOAP message.
CertB and CertD must be used for SOAP message encryption and HTTPS handshaking.
Basically, the client is supposed to sign a message using it's private key and encrypt the message using server's public key. The server do the opposite.
Precisely, here's what WCF client have to do in order to send a message to the server and receive the response back:
Client sign SOAP request with certificate CertA (using CertA's
private key)
Client encrypt SOAP request with certificate CertD
(using CertD's public key)
Client send signed and encrypted SOAP message over HTTPS to the server (certificate CertB is required by the server during HTTPS 2-way handshaking for authentication purpose)
On the server side:
Server receives the message, authenticate and authorize client
Server decrypt message with CertD's private key
Server verify message signature with CertA's public key. Server then process decrypted and verified message.
Server create response message and sign it with certificate CertC (using CertC's private key)
Server encrypts the response message with certificate CertB (using CertB's public key)
Server send response back to the client over HTTPS transport.
When client receive the server response:
Client decrypt response with its CertB's private key
Client verify message signature with CertC's public key
Client process the response.
The question is how to configure such WCF client? Which binding to use to enable SOAP signing & encryption on message layer + HTTPS 2-way handshake on the transport layer and how to "tell" WCF what's the purpose of each of the 4 certificates?
(Yes, I already saw this article: https://msdn.microsoft.com/en-us/library/ms729856(v=vs.110).aspx but I'm afraid that article doesn't provide solution for my case because they use some weird duplex binding which require a client to open an listening port and that's not an option for me since I have to use regular HTTPS connection).
This question is in context of web-services. If I invoke a web-service over SSL alongwith the required data for the service; I get an SSL error, if the SSL cert is invalid, and I wont make further requests. But what happened to the data I sent in the first request ? Will it be transmitted to the attacker ? Can he decrypt it ?
In a typical website this scenario hardly arises, as our request to server has hardly got any private data - once the server sends some form, only then we proceed with confidenial data.
Thanks.
SSL/TLS is established before any data is sent. Consequently if there was an error, nothing is sent and your data is safe.
I am currently in the process of integrating a WCF client into a java web service. The server requires the client to authenticate via certificate using SSL and the message to be signed.
I have successfully sent the message to the server through SSL, Signed, etc. However, the server response message is also signed but with a different certificate than the one used to authenticate the server.
The WCF client doesn't like this behavior. It failed with the message: "The incoming message was signed with a token which was different from what used to encrypt the body. This was not expected." The problem is described here in detail.
Looking around on Google I found it is possible to decouple the clients transport certificate from the singing certificate by implementing ClientCredentials and other security related classes, and adding a new extension. You can read all the details about it here. However I'm having some trouble figuring out where exactly do i have to extend to provide this same behavior for the server's certificate on client mode.
Any help on the subject or reference would be appreciated.
Thanks in advance.
Have a look here
This shows you how to create an custom ServiceCredentialsSecurityTokenManager that allows you to specify the various message signing and encryption certificates for requests and responses to and from the server.
I emphasise message because the problem as you describe it appears to me to be message security validation. The transport security is seaperate from the mechanism used to validate the message security, i.e. the message signature and message decryption.
Ignore the transport security as this is lower down in the WCF pipeline and appears to be working working correctly from your description. A seaperate concern is the message security. It appears that you need to be able to use a certificate for decrypting the response and a certificate for verifying the signature. The above article shows a example for enabling this type of certificate managment, it does detail how you could create behaviours and extensions to apply this to your client that is a seaperate concern. This depends on how you want to configure your proxies i.e. through code or through configuration.
The example article you linked too is not a complete implementation for what you require, it only provides for a certifiate for signing and a certificate for the transport client credentials.
You could create a hybrid ServiceCredentialsSecurityTokenManager that provides the transport certificate and the signing and decryption, this should be clear enough from looking at the SecurityTokenRequirement documentation
Can any one explain me, what exactly the role of Service Certificate and what exactly it does in this Combination (Message Security - Client: UserName Validator, Server: Server Certificate)..
If you can explain me step by step, it'll be really helpfull.
Thanks in advance
Service certificate is used as key artifact to establish secure channel between client and server.
When client starts communication with server it first validates that certificate is trusted (it must be either installed in clients certification store or it must be issued by the authority the client trusts to). This validation should ensure that client communicates with the right server it trust to.
My understanding of using service certificate for securing messages is:
The client creates derived key used to encrypt and sign the request message with symmetric security. Service will need the same key to decrypt the message and validate the signature so the client must pass the key within the message. The key is encrypted with service's public key passed in the certificate because only holder of the private key (the server) can decrypt this derived key and then decrypt the request message itself.
The service uses decrypted derived key to encrypt and sign the response message and pass it back to the client. The client remembers its derived key used to send the request so he can also decrypt the response.
The same process is used for the next exchange but client creates a new derived key for each request.
User name and password are only data passed in the message used on the server to validate that user can use the service.