The standard model of a web service system consists of a service, a client, and a discovery service. The SOAP specification specifies that a SOAP massage can be routed through a path of SOAP notes whit different responsibilities. This feature will not be used in this system; when a SOAP message is received it is always handled as if the node is the final destination. If more nodes are required to process a message, this must be handled in the web service application, and not by the SOAP message layer. This system will not make use of a discovery service; once the system is running, it can therefore be described as a standard client/server system with one client and one server:
Figure 6
To fulfill the requirement of easy deployment of services, many of the existing tools supplied with the web service platforms described in state of the art section, could be used. But because the security model should be easy to change and reuse among different services, it requires a mechanism to integrate security models in existing applications in an easy way. One way to implement a security model in a system is to develop an API that makes the integration of the model easy to the application developer. The approach of separating a program’s functionality in packages is commonly used, because it makes it easy to reuse the code in different applications. If the security models were implemented as API’s available to the application programmer the system would look like figure 7.
Web service Client
XML documents over network
Figure 7 – model 1 Payment model as API
There are several advantages in this model:
• It is possible to use one of the many deployment programs available to most
web service platforms.
• The API programmer does not have to concern about how the final application
becomes a web service.
• The web service platform can generate the WSDL documents that describe the
data types used to communicate with the service.
• The web service platform usually has tools to generate client interfaces and
proxy classes, to make the client development easy.
• The application has full access to the security model, which means that it is
easy to share information like authorization between the application and the security model.
The disadvantages of the model are:
• The security model is integrated in the application, which means that existing
applications must be re-written to use the security model.
• The WSDL documents generated on the server will not contain information
about security policy. Thus, it will most likely not be possible to develop a client that can communicate with the service, because the WSDL will not contain information about required authorization and encryption policy.
• The advantages of message level security cannot be obtained, because the
security is implemented after the message is un-marshaled into types known to the application.
Especially the second disadvantage breaks with the web service concept of making the communication interface usable across businesses, platforms and language. It is clear that a mechanism to describe the security assertions must be applied to the model. Most Web service platforms generates WSDL documents of deployed web services when a client requests a document, the WSDL documents are not static files stored on the server. This means that the web service platform must be modified to generate WSDL documents containing security information. Further the deployment tool must be modified to pass security information to the web service platform, so it can generate the WSDL containing security information.
Instead of having the security models as an API available to the application
programmer, the security models could be applied by wrapping the application with the security model, before the application was deployed as web service. The model would then look like figure 8.
Figure 8 – Model 2 Payment model as wrapper
This model would solve the first issue of the API model, because the application would not need to be modified before deployment, but it would still be a problem to generate the correct WSDL for the web service. And message level security could not be obtained.
If the wrapper moves to the network layer and acts as a proxy, message level security is possible to implement in the proxy. The proxy can take the responsibility of generating WSDL documents, and can therefore generate WSDL documents with the necessary security information included. The model would look like figure 9.
Web service platform Client Payment model proxy Application Firewall
Figure 9 - Model 3 payment model as proxy
How the proxy speaks with the SOAP container is not important to the client, and the client should not be able to communicate directly with the SOAP container, so the network connections coming from other than the proxy, must be rejected by the SOAP container, this could be obtained by installing a firewall.
Another way to gain control over the web service in the message layer, is to develop the soap container from scratch, or modify an existing soap container. This approach binds the system to one specific web service platform, and requires modifications whenever a new version of the platform is developed.
The public interface to describe the communication with a web service, is of great importance in the web service domain, therefore a solution without possibility to describe the security assertions of the service, is not acceptable when developing a system for secure payments via web services. To maintain the possibility of choosing between different web service platforms and versions, the best solution is to implement the security layer as a proxy server in front of the web service platform, as described in solution 3.
A challenge in this implementation is that the application shall not only be deployed against the web service platform, but also make the proxy aware of how a request to a specific service should be handled and routed. This requires extensions to the deployment tool used to deploy applications on the web service, so it can handle deployment against the proxy as well.