locked
Verifying Client Transport Certificate in AppFabric Service Bus RRS feed

  • Question

  • I have a packaged application that sends a client certificate along with service requests to an AppFabric Service Bus endpoint and need to validate it on my IIS-hosted service.  Does the Service Bus pass along transport certs sent by clients?

    Because my packaged app cannot change how it calls services, I cannot modify it to send Service Bus credentials.  So, I've turned off client authentication and want to validate the certificate once it hits my on-premises service.  I have tried multiple strategies (turned on IIS SSL and required client cert, set the Security Certificate settings in IIS AppFabric) and none seem to give me what I want.  In those cases, even if I don't put the client cert in my machine's certificate store, I'm STILL able to call the service!  I don't know if the Service Bus is swallowing the transport cert, or how my caller is still able to call the service without their transport cert registered.

    So, how can I verify transport certificate security (NOT message security) in my WCF service after it has traveled through the AppFabric Service Bus?

    Friday, November 12, 2010 4:07 PM

Answers

  • No, HttpRelayTransportSecurity does not allow you to configure client authentication type. Note both your service and client are communicating with Service Bus. They don't know about each other. So the transport level security must be configured so that both the service and client can establish a secure channel with Service Bus, respectively. So there're two separate secure channels, and thus two separate SSL sessions. But the service and the client don't establish a secure channel with each other. In general, transport level security is endpoint to endpoint. When an intermediate such as Service Bus exists, you must establish two separate secure channels.

    Can you use message security? TransportWithMessageCredential should also work fine.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, November 15, 2010 6:11 AM

All replies

  • No, HttpRelayTransportSecurity does not allow you to configure client authentication type. Note both your service and client are communicating with Service Bus. They don't know about each other. So the transport level security must be configured so that both the service and client can establish a secure channel with Service Bus, respectively. So there're two separate secure channels, and thus two separate SSL sessions. But the service and the client don't establish a secure channel with each other. In general, transport level security is endpoint to endpoint. When an intermediate such as Service Bus exists, you must establish two separate secure channels.

    Can you use message security? TransportWithMessageCredential should also work fine.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, November 15, 2010 6:11 AM
  • Thanks for the response.  Because I am dealing with a COTs product and basic HTTP communication, I cannot switch to a TransportWithMessageCredential since I have no way to configure message security on the outbound message.

    Is there a claim mapping that I can do in the SB STS?  That is, would I be able to find the inbound claim (if possible) holding the transport cert thumbprint and be able to pass that through?

    If we rely on the on-premises service to authenticate the user (and don't have the SB do it), what are the recommended patterns?

    Monday, November 15, 2010 8:04 PM
  • You can manage ACS for your Service Bus to map claims just like manage ACS for your own services. But this approach still relies on ACS, which requires modifications to the client application.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, November 16, 2010 9:09 AM