I have a SOAP webserver developed in Delphi XE2 that exposes some methods and it uses SSL. I built my client also in Delphi XE2, and I use THTTPRIO to connect to webserver. My question is related to the use of SSL certificatest with THTTPRIO. If I call my webservice it works without having a certificate installed, but I think that it shouldn't.
Second scenario :I have a self signed certificate which I installed it and after I made a call to my webservice it works also.
When I inspected my events: HTTPRIOAfterExecute and HTTPRIOBeforeExecute, I converted SoapRequest and SOAPResponse to string from TStream and seems that it isn't encrypted in both cases. I also found on another forum the same question but with no response.
I searched for info about SOAP SSL Clients with Delphi but couldn't find any new info. Could any of you guys give me some advices regarding this issue?
If I call my webservice it works without having a certificate
installed, but I think that it shouldn't.
Not many web services require client certificates (with exceptions like banking and other high risk environments). It is more common that clients want to verify the server identity, and this is done with server certificates.
So I would say this web service does work in a normal, expected way.
HTTPRIOAfterExecute and HTTPRIOBeforeExecute, I converted SoapRequest
and SOAPResponse to string from TStream and seems that it isn't
encrypted in both cases
This is correct, the message payload will appear unencrypted because SSL / TLS does encryption on the transport layer. Your application will not see the encrypted data, which actually makes things easier.
You can add encryption for the message payload, there are generic libraries for this (however I have no experience with using encryption HTTPRio).
Related
I was asked this question in a technical interview for a integration intern role.
He was digging much into understanding of SOAP web services.
Question). Consider that you are exposing a web service through SOAP to a Client.
The url through which you are providing the service is up and running when you check it.
But the Client has a problem, he is not able to access your webservice.
How will you go on troubleshooting this issue?
My response:
I would first check whether the url the client is trying to access the service is correct.
Will check the .wsdl file: port, bindings & will check once whether upon sending a SOAP request to the URL, am I receiving the SOAP response in local through SOAP UI.
If I get error, will troubleshoot based on the kind of error I get: Like page not found, null exception etc.
I felt he was still expecting some other point. He hinted saying where in what registry you will check all the web services which have been hosted(I guess this was much of a production support issue :P)
I told I may look into UDDI registry, but was not sure with this.
Please let me know your inputs on what could be possibly a right approach?
Apache jUDDI PMC here. Yes UDDI could be used to verify that the client is pointed at the right location, assuming the client knows where the UDDI server and that it is registered and the client knows what to query for on the UDDI server and a UDDI query is part of that client's normal workflow. That's a lot of assumptions but certainly feasible.
Most of time, the endpoint is in a config file somewhere or some idiot hard coded it.
That said, this my go to list for checking SOAP service connectivity (from the client's perspective)
DNS resolution of the hostname in the URL
Ping the remote host
HTTP GET to the URL of the SOAP service + ?wsdl (this usually works). This is also a good time to verify SSL connectivity.
You can also parse the WSDL doc, assuming one is returned for identify the endpoint url.
Finally if that all works, execute the service. HTTP 200 is general a positive sign
Edit:
Another alternative approach is to implement a very simple API (wsdl method) on every SOAP service that simple returns a true/false that answers the question "Am I open for business?". This method would provide a standardized approach for identifying if a service was available or not by testing an external dependencies (databases and whatnot).
I am trying to send a message from NetSuite to another system via http SOAP, but I was told that I have send a signed soap message. NetSuite only has an operation called nlapiRequestURL(url, postdata, headers); I am trying to use this method to send over a manually created SOAP message. What I am having problems with is figuring out how to add the cert to the header. Has anyone does this before?
What I have learned about signing a soap message with the certificate is that I need private key and public in the local keystore. This tutorial in java shows how to do it, but how would I do something similar in NetSuite.
https://dzone.com/articles/signing-soap-messages
One possible solution is you write your own proxy web server in Java
or any other server side language for that matter.
Below is the summary of my suggestion:
1) Send the request details from NetSuite to proxy server using a
Suitelet or scheduled script.
2) In the proxy server create the signed SOAP request and send to the
vendor API
3) Now, to respond back to NetSuite there are two options a) you
keep the connection open with NetSuite until you get the response and
send it back to NetSUite's script b)you respond back to a NetSuite
RESTlet, which makes the design asynchronous and can be good specially
if the turn around time is more than 45 seconds.
Also, I would suggest to write web server using HTTPS, with your server having a trusted CA signed certificate, so, that communication between web server and NetSuite is secure. And this way your communication would be secure (P.S. I can't answer the question that is SSL 100% secure, there are good discussion on http://security.stackexchange.com on that topic).
Im working on some JSON-based web service that is supposed to work with Android application.
I would like to encrypt data transport between client (android) and server (virtual server in datacenter).
I don't have to make sure that my server is my server, just data encryption.
I have no idea how to use HTTPS.
Do I just put my PHP files in private_html and use https://example.com url?
To use HTTPS, you don't have to do anything in the coding of your web service - it's all in your hosting. Here the are steps you can follow. The specific instructions differ in your hosting (IIS, Apache, AWS/Azure, etc), but you can google specifics on how to accomplish any of these steps for whatever host and application framework you decide.
Buy an SSL certificate (there are many different vendors, but expect between $75-$200 for the certificate) based on the vendor, reputation, and level of security you need.
Generate a certificate signing request (CSR) from the server you'll be hosting.
Upload the CSR to the SSL vendor who will validate and provide the certificate for your use.
Import the SSL certificate into your application server, and configure the site to use the certificate. For instance, if you're hosting Microsoft IIS, you'd import the SSL certificate and then add HTTPS bindings on 443 to the specific website hosting your web service.
Another point of security. Since you are deploying SSL, you don't have to do any application level encryption (assuming you are not putting sensitive information in query strings - use POST if you think you need to). You probably would want to implement some security to restrict access to your web service so only your app can access it. Best practice is some level of OAuth, but at a minimum some type of pre-shared key in the header of the request is a lot better than nothing.
Here are some additional sites for more information:
https://www.digicert.com/ssl-certificate-installation.htm
https://support.godaddy.com/help/category/742/ssl-certificates-installing-ssl-certificates?prog_id=GoDaddy
If you don't want to pay for a certificate, you can use certificate signet by your own CA and add the root certificates into your application using HTTPClient and keystores
Here there's some guides
http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/
http://developer.android.com/reference/org/apache/http/client/HttpClient.html
KeyStore, HttpClient, and HTTPS: Can someone explain this code to me?
http://blog.antoine.li/2010/10/22/android-trusting-ssl-certificates/
You can limit users to use JUST and only HTTPS in apache, IIS or whatever do you use. If your client connects to your server, his communications will be likely to encrypted, because he is already using HTTPS. And for responsing in HTTPS you virtually cannot send HTTPS responses, as far as I know, unless that other side isn't also a website (for example, if you have your website, you could send such a response e.g. to Google). You should be okay to send data like http status codes (OK, NotModified, PageNotFound, ...), or if you want something more, or if it is a requirement, then there you still have JSON and you could encode it as well, with some encoding algorithms, or use binary JSON format.
Check if your hosting company provides a free public shared https address. Most of them do.
If you want to understand how to do it right, follow this thread
Warning: Don't stick with the solution below for production.
If you plan o use an https endpoint without a certificate you have to make sure to disable peer verification, check this answer
What advantages are there between implementing SOAP messages over SSL by modifying the web.xml/ejb-jar.xml VS modifying the WSDL with a WS-Policy?
Our project can acheive its goal of having our clients (ourselves) access the Web Service over a secured connection by adding a transport-guarantee but we're not sure if that is a complete/correct solution.
With SSL, you get a point-to-point encryption between client and service. If the service is not the ultimate receipient of the message, but a proxy that routes this message to another service, you have no encryption between the two services, or you have to configure that also.
WS-Security configured via WS-Policy has the potential to give you end-to-end encryption between the client and the ultimate receipient of the message, because you can encrypt the message body. You do not need to configure SSL for every pair of communicating entities. Every proxy can just route the message on, as defined in the header.
That said, if you do not need end-to-end guarantees, but point-to-point is enough (which is your scenario, as far as I understand), I would say that using SSL is a fair choice.
Another thing to consider is that the WS-Security implementations of client and service need to be able to interoperate. SSL generally is quite mature, but my personal experience is that WS-Security implementations are not. So, if you have different WS-* Stacks for client and server, it might be some hacking and trial-and-error to find a policy configuration that works for both.
I have been trying to encrypt soap message and send to the server, so that the server can decrypt, process the message, encrypt the response again and send back to the client...
I short i want to implement security in ASMX web services....
Please help me
Thanks
Sandeep
What's wrong with using HTTPS?
https and soap extensions are good solutions; you can always 'roll your own' by encryting the inputs and outputs directly
[WebMethod]
public string SecureMethodX(string secureInput)
{
string plainText = decrypt(secureInput);
//do something...
string encryptedResult = encrypt(someResult);
return encryptedResult;
}
this becomes a pain if you have several methods, but if you have a specific one-off need (such as passing hardware fingerprints and/or license keys between client and server) then this solution is probably the simplest to implement
Take a look at SOAP extensions. They allow you to monkey with the SOAP stream on both the client and server. They're nice because you can leave your service code alone - manipulation occurs before a webmethod begins and after it ends. They work a lot like an HttpModule but can be included on the client/request side as well.
http://msdn.microsoft.com/en-us/library/system.web.services.protocols.soapextension.aspx
http://msdn.microsoft.com/en-us/magazine/cc164007.aspx
http://www.theserverside.net/tt/articles/showarticle.tss?id=SOAPExtensions
HTTPS is a standard for encrypting web services. I use this for encrypting a web service.