My group is evaluating HL7 Proxying and came across WS02 ESB. I have successfully configured an HL7 Proxy that seems to work well. Now my task is to secure the listening point with SSL (TLS specifically). This seems like something that the ESB should be able to handle. It can do HTTPS, Secured Web Services, etc. However, there doesn't seem to be a way to enable this with a simple check box for HL7 Proxying, nor am I finding any documentation on how to enable it manually.
Is it even possible to do secured HL7 Proxying within WS02 ESB?
Thanks in advance!
It seems WSO2 is using HAPI client for HL7 implementation and when I go through the code it seems TLS is disabled by default. Refer https://github.com/wso2/carbon-mediation/blob/master/components/business-adaptors/hl7/org.wso2.carbon.business.messaging.hl7.transport/src/main/java/org/wso2/carbon/business/messaging/hl7/transport/HL7TransportListener.java#L78
Related
I'm using the Lagom microservices framework and the Streaming requests and responses use websockets as the transport. However, the built in websocket client (netty) doesn't handle SSL connections. I understand there are various architectures where SSL termination isn't handled by Lagom itself that avoid this, but for our application we need TLS all the way to the endpoint.
The post (https://groups.google.com/forum/#!topic/lagom-framework/QcOvK8H3R94) suggests that akka-http websockets support TLS, but that isn't currently an option as a Lagom client.
This gist (https://gist.github.com/DaveDeCaprio/4db9d36a5e907fb5810c00e919347aa3) provides an example of an Akka HTTP websockets client for Lagom.
I don't include this as a full pull request in Lagom because it is still pretty hacky. The biggest issue is that the RequestHeader that is returned from a streamed call is a fake, generic Ok header. The actual HTTP call isn't made until the stream is materialized and run. This is due to a different in the way akka http and netty handle the websockets. This wasn't trivial to fix.
I am working with CoAP protocol on IoT but also I need a web service. I implemented the web service on Apache with HTTP protocol and a Proxy that converts CoAP-HTTP request and responses. But I don't want to use the Proxy to convert CoAP-HTTP. I want to implement directly CoAP web service. Do you have any idea about that. On Apache or different things. Just any idea?
As you wrote On Apache or different things, I will here talk about the second option :). To implement the CoAP server itself, I would recommend either
NodeJS with the CoAP package
Java implementation Californium, from Eclipse.org
More complete list available at http://coap.technology/impls.html#server-side, see Server-side
And then handle the communication with your Apache HTTP server via WebSockets and REST APIs.
coap.me is also great to run tests during development.
We are trying to integrate Jboss application to make Web services calls, so was wondering is it a good practice to make the web services call go through a web server always instead of handling SSL stuff by Jboss ?
Have this curious idea because if we want to implement authentication and make web server handle all the certificates for SSL so that in future if Jboss is replaced with a different technology the basic SSL configuration stills remains same in web server.
I agree for incoming requests to Jboss it makes sense to go through apache, but was wondering what about outbound connections from Jboss to a different provider ?
Any thoughts is very much appreciated.
If SSL is handled by a load balancer, do I still need to configure it in the WCF serviceCertificate node? My scenario is to use message level security. If someone can explain how load balancing with wcf and ssl works, that would be very nice.
WCF requires security tokens to be passed over a secure transport if the message itself is not signed/encrypted. Since traffic is HTTP between your Big-IP and your individual web servers, you need a way to have security tokens that you know are secured between the client and the Big-IP up front still be passed to your server farm. There's a couple ways to do that depending on what version of WCF you're using:
If you're using WCF 4.0 you can just create a custom binding and set the AllowInsecureTransport property on the built in SecurityBindingElement to signify that you don't care that the transport isn't secure.
If you're using WCF 3.5 you have to "lie" about security with a custom TransportSecurityBindingElement on the server side. You can read my old post about this here.
FWIW, they created a hotfix release for 3.5 SP1 that adds the AllowInsecureTransport to that version, but I don't know if your company will allow you to install custom hotfixes.
If you want to use message security then each message is encrypted and signed separately - there is no secure connection and load balancer behaves as with any other HTTP transport. Loadbalancer doesn't know about security and doesn't need certificate.
There are two gotchas:
All load balanced application servers hosting your WCF service must use the same certificate
You must ensure that your WCF binding doesn't use sessions (reliable, security) otherwise you will need load balancing algorithm with sticky sessions (all request for single session always routed to the same server)
It doesn't. Don't bother with this. You will be in a world of hurt. Just install the certs on each machine. We've recently been through this fiasco. WCF is not worth the effort it thinks it needs SSL but sees that it doesn't have it. Take a look at openrasta or something else if you want to do all your SSL on the loadbalancer. #microsoftfail
Here is my scenario:
I have a proxy that actually has the SSL Cert installed and this sits in front of a load balanced web farm. Each IIS server does not have SSL so I can't use transport security via wsHttp binding. I have not investigated basicHttp because we want to provide SOAP 1.2 going forward w/ this solution. In addition to this, my network team won't allow any use of certs to encrypt at the message level. (this alone would solve my dilemma i'm sure)
My security group has a requirement that we use Forms Authentication (membership provider).
The final solution must allow SSL via the front proxy, yet some type of WCF binding to keep complexity encapsulated in a config file.
I was working with a custom binding that allowed for username/password sent via clear text, but when I try to connect via https i get the usual "http expected" uri error.
How can I use SSL via the proxy to connect securely from client app to web service, but not have SSL installed on IIS and leverage the WCF stack + forms authentication?
I'm not new to WCF, but this very custom setup seems to have me unsure if the requirements allow for any type "easy" solution.
Thank you in advance!
EDIT: I did finally get this working and decided to write a short blog post with complete source code required to write the custom binding.
I think this is similar to a problem many have had when wanting to provide WCF services over SSL when the actual service in IIS is behind an SSL-offloading device. In which case, the following two pages should help you out:
http://blog.hackedbrain.com/archive/2006/09/26/5281.aspx
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/87a254c8-e9d1-4d4c-8f62-54eae497423f/
Basically you need to lie to WCF and say that the service is secure, even though the traffic will be conducted over HTTP (between the service and the proxy).