views:

58

answers:

4

We developed a web service which is accessed by various platforms clients, for example it is requested by c++ and Java enabled clients.

I want to use simple, effective encryption Algorithm which is easily decrypted by JAVA - C++ and JAVA script based clients.

A: 

If you already have the service implementation which is Base profile compliant and you want to keep on supporting various platform clients, extend your current service with WS-Security/WS-Trust. This will allow for encrypting/signing the content of the message, without loosing interoperability.

Depending on which toolset you used for your original implementation, the inclusion of WS-Security can be as easy as 'flicking a switch and selecting some options in your configuration file' (WCF/ASMX+WSE).

Since you mention the various platforms client side, I assume this is one of your main requirements.

Hope this helps.

Marvin Smit
I strongly recommend against using WSE, unless you have no other choices. It is obsolete and all but unsupported. Microsoft are only fixing critical bug in the code. If your projects matter, then don't use WSE - use WCF instead.
John Saunders
Although i agree with the sentiment of `do not use WSE´, i´d like to say ´do not START using WSE unless you have to´. Sometimes, there is no time/budget for rewriting a large existing application in ASMX/WSE to the new WCF. WSE is not a bad toolkit, its pretty ok, but it is outdated and stopped development (some support remains). So, for me technically: don´t use WSE, use WCF instead. Strategic: the risc of using WSE is acceptable untill we can rewrite to WCF.Your only problem remaining is; JScript support. Unless you jump out to external libs, encryption is not easy, and no WS-* support
Marvin Smit
+3  A: 

Why not just deliver your service over HTTPS? Why write anything?

chiggsy
Agreed - it's vastly more likely to actually be secure than something you cook up yourself.
caf
A: 

You can simply use HTTPS which is easily implementable in both C++/Java clients (e.g. using the GNUtls library). On the server side, you will only need some small configuration changes.

Apart from the different request code, you have to create a self-signed SSL server certificate and install it on the clients. Of course this is not a good idea if the web service is public, where you need trust (= a real SSL certificate). But if it's only used internally, self-signed certificates are a quite good solution, as long as you keep the private key secret.

AndiDog
Webservice written in java. i don't want to use https
Faisal khan
A: 

The most widely-compatible method of Web Service security that is still actually secure is Transport with Message Credentials. This uses SSL (https) for transport-layer security, which handles the encryption aspect, and passes a username/password in the SOAP header, which handles the authentication side.

It is not as secure as mutual-certificate authentication, which also gives you non-repudiation, but it is good enough for the vast majority of applications.

Several other options exist, but T/MC is usually the easiest to get working across platforms (.NET, Java, C++).

If you need to add javascript into the mix then I'm afraid you may be disappointed, as that is a serious game-changer. Although there do seem to exist various JavaScript SOAP Client implementations, SOAP is a second-class citizen in the JavaScript world, and I don't believe that any existing libraries have proper support for WS-Security or really WS-Anything except for the basic profile.

If you want your web service to be consumable by JavaScript then you want to go for REST instead of SOAP. I know that .NET (WCF) is pretty good at this but I'm not too sure how well Java and C++ fare. I believe that the transport security should be simple enough (it's just SSL), but it's likely that you'll have to implement some custom authentication code to get it working across platforms. Either way, you definitely want to go the SSL route; please do not try to roll your own encryption scheme.

Aaronaught