SSL Signing

[noiseunion]

What needs to happen to get Sekken working with an endpoint that requires SSL message signing? I have been combing through stuff for weeks and have had 0 luck in getting things working. I am starting to lean towards just creating a proxy service in .NET to get this thing working, but that is a disgusting idea and I hate myself for even considering it! ;)

Any thoughts on how I can get this done? Or maybe help contribute to Sekken to get it done?

[alexanderk23]

Our team is currently involved in a project with some commercial structure that requires us to sign our requests with SSL certs and also use WS-Addressing, so this feature is very important to us. I had to fork and patch Savon v2, Akami and Wasabi to get basic WS-Addressing and WS-Security support, but due to the specifics of Savon v2 architecture (ex., request header and body decoupling) the resulting code is way too ugly (though it works for us). I also would love to help implementing and real-world testing WSA/WSSE support in Sekken (and as far as I see this would be a whole lot easier than with Savon v2) but there are some general questions that should be clarified before (such as merging Akami functionality into Sekken or leaving it as is).

[tjarratt]

@noiseunion that's a great question. A cursory look at the codebase for Sekken seems to indicate that there is no explicit support for SSL message signing like Savon v2 has (by specifying a cert file, key and CA cert). The way it seems to be implemented in Savon v2 is to just accept the options on the constructor and pass those options to the HTTP adapter in a common way

It looks like the http client is configurable in sekken so this kind of configuration doesn't need to be passed through, which is probably a Good Thing™. Does that work for you? If so, I suppose we should document how to do this and then close the issue.

Re: @alexanderk23's discussion of WS-Addressing and WS-Security support in Sekken, I'd love to see some Pull Requests issued for that. If that's easiest using Akami, then I'm all for adding that dependency.

[noiseunion]

I don't have any issues with having to perform those configurations on the http client directly. I am not sure how to do that, so the documentation would be very helpful for me. I'm pretty new to SOAP concepts...they frighten me. :smile: Sekken makes me feel safe. LOL

[tjarratt]

I don't think there's anything scary about SOAP per se, it's just very complicated. Realistically, as a developer, I just want to write some code that uses some API or service without getting bogged down by ridiculous details. We're all very lucky that Savon and Sekken exist and help us achieve that goal.

I'm just looking at some examples in Savon for signing requests and inferring the correct steps here, so I might be making a few obvious errors; caveat emptor. I encourage you to try this out in irb and experiment a bit. Please let me know if this helps :)

require 'sekken'

client = Sekken.new("https://example.org/someService.wsdl")

# certificate can be associated with RSA, DSA or ECC keys (according to OpenSSL ruby docs)
cert = File.read('path/to/some/client.cer') # PEM or DER encoded certificate
key = File.read('path/to/some/client.key') # PEM or DER encoded private key (should be paired with certificate above)

client.http.ssl_config.client_cert = OpenSSL::X509::Certificate.new(cert)
client.http.ssl_config.client_key = OpenSSL::PKey.read(key)

[alexanderk23]

It's really easy to mix up, but in the example above, the SSL certificate and key are used to authenticate ourselves at transport level, not to sign the message. To sign a message, we need to use/integrate Akami which provides basic WS-Security extensions (WSSE) support.

Here is an example of a message signed with SSL certificate/key pair.