Invoke secure web service by clicking on an HTML link

[Alec Swan]

I am looking for a way to allow the end-user to invoke a secure web service on my Tomcat server by clicking on an HTML link. Here is the user scenario:

1. The user opens a web page in any browser with an HTML link or a button.
2. The user clicks on the link which invokes a secure web service (rest? soap?) which updates the state of the server database.

I need help deciding which protocol (rest, soap, etc.) to use for this user scenario and how to secure the service (HTTPs, OAth, SOAP message-level security, Tomcat authentication)?

Thank you,

Alec

[Ivan Krizsan]

Hi!
Assuming you want to put the web service URL in the web page:
First of all, are you sure that you want to expose this web service in a web page?
If this is the case, then it is very simple for anyone being able to view your webpage to learn how to invoke the web service.
Provided the web service is not intentionally to be exposed to "the world", I would not invoke it from the presentation of a web application, but (depending on what it does etc etc) from a controller or a service layer. This has the advantage that you can put it behind a servlet, another service or an EJB and thus use the regular security mechanisms for servlets etc.
If you are going to expose a SOAP web service to "the world", then you should read up on web service security, which is quite a vast topic.

Second, what in-data does your web service need to update the state of the database?
Is it to return any outdata to the webpage?

Finally, I recommend listening to this podcast from SE-Radio about web application security:
http://se-radio.net/podcast/2009-03/episode-128-web-app-security-bruce-sams
It is both entertaining and interesting!
Best wishes!

[Alec Swan]

Thank you for your response Ivan.

We have a customer who would like its employees to click on a link on their intranet site and expects it to invoke a web service on the server that we are hosting externally. The web service only returns Success/Failure response back.

I've read quite a bit about invoking a SOAP web service from a web browser and almost all options (XmlHTTPRequest, FlashXMLHttpRequest) suffer from cross-domain web service access. Another option is the one you described, which involves the link invoking a simple servlet which invokes the remote web service from its controller layer. This solution adds the servlet as another layer of abstraction, which we need to maintain.

It sounds like you are recommending the solution which involves another level of indirection in a form of a servlet.

What about securing this SOAP service? Would you recommend using message-level security or rely on some other security mechanisms?

Thanks,

Alec

[Jimmy Clark]

The purpose of a "web service" is to enable applications (1,2,3) to invoke application (x). It is a communication mechanism to allow applications to communicate with other application. Is is not for "humans" to communicate with an application.

It seems like your customer does not have an accurate understanding of how to use a "web service" and what a "web service" is.

Attempting to code a HTML link so that it invokes a "web service" call directly seems rather silly and a misuse of the technology. Even if you can do it somehow...

[Alec Swan]

There is a lot of truth in what you are saying James. However, it also makes the use of XmlHTTPRequest sounds ridiculous

I would like to hear what you think about securing a SOAP service? Would you recommend using message-level security or rely on some other security mechanisms?

Thanks.

[Jimmy Clark]

I would like to hear what you think about securing a SOAP service? Would you recommend using message-level security or rely on some other security mechanisms?

Message-level security is the best practice in terms of web service and SOA security. I might add that it is a bit more complex than simply using HTTPS as the security mechanism (Transport-layer).

However, SOAP Extensions allow you to implement many different types of security measures for all different types of scenarios. WS-Security, WS-XML Encryption, WS-XML Addressing, etc. all provide the tools needed for implementing security with web services. The Apache Axis SOAP Engine supports all of this.

One thing to keep in mind, the code for the security and the logic of the web service should be kept separate. You do this by creating and using security handlers. These are classes that contain the security logic and are configured in web service deployment descriptiors. The SOAP Engine does all the work for you.

The book below is excellent and a very good read. Go buy it today!


SOA Security
http://www.manning.com/kanneganti/

[Jimmy Clark]

Customer Application <----------> (web service) <--------> External Business Application

The code of the web service provides a way for Customer Application to call a business operation in the External Business Application.

A common misunderstanding is that individuals think of the "web service" as the business operation. It is not. The purpose of the web service is to enable the communication between the applications in an efficient and reliable way. Applications written in different technologies can communicate via web service. Data from secured databases could be accessed via web service. There are many cases, but in all of them, all the web service is doing is allowing two apps to connect.

[Alec Swan]

Thank you for the feedback and the book reference. I like what you said about using handlers to secure web services. I will read the book to learn more.

Thanks!