Web services call handling for eMed application through SOAP/HTTP using DataPower

The World Wide Web is a medium being used to provide a wide array of e-commerce, business-to-business, business-to-consumer, and other information-based services. In Service Oriented Architecture (SOA) technology, Web Services are emerging as the enabling technology that bridges decoupled systems across various platforms, programming languages, security, and applications. 


Benefits

The benefits of Web Services and SOA come at the expense of introducing a new level of complexity to the environments where these services are deployed. This complexity is compounded by the freedom to compose Web Services to address requirements such as quality of service (QoS), availability, security, reliability, and cost. The complexity of composing services compounds the task of securing, testing, and managing the quality of the deployed services.
This chapter briefs how DataPower device can be used to meet security requirements for Web Services and describes how such security requirements are addressed.


DataPower

DataPower Appliance is a non-disruptive network device that provides common message transformation, integration, and routing functions on a single platform. It is a purpose-built hardware device that is easier-to-deploy, highly scalable and helps reduce IT complexity, lower operational costs and improve eMed application performance. WebSphere DataPower Integration Appliance enables new and reused services with a security and integration gateway appliance, built for simplified deployment and increased security, bridging multiple protocols and performing conversions at wire speed. It helps simplify connectivity using features such as any-to-any transformation and content-based routing. It supports compliances likes ISO27K, PCIDSS, HIPAA etc. and data governance through policy enforcement and audit trails. It provides advanced security to help support security-rich enablement of eMed critical applications. The following sections provide additional details related to DataPower.


Architecture

WebSphere DataPower SOA appliances provide a robust and secure platform for middleware integration that can be deployed in a wide array of deployment scenarios to perform a wide variety of middleware use cases. For eMed, DataPower is used for Web service Proxy (WSP) creation, which acts as a gateway for all the Web service transactions. The following figure illustrates the schematic DataPower architecture.
Figure: DataPower Architecture
 
When a web service call request from eMed users will be received at web gateway, the gateway device will offload  CA issued certificate and perform crypto service verification. DataPower is not a web gateway for eMed. This service request will be forwarded to DataPower. The DataPower will handle the input web call requests as per eMed policy handler and accordingly DataPower will call the SOAP over Http request to eMed application as a service request.


Deployment and Configuration

The DataPower appliance will be installed in DMZ. CA issued certificate will be offloaded at web gateway enterprise in DMZ. DataPower acts as a secure gateway for the Web services. All the Web services exposed to the outside world will be configured in DataPower. The Web service request will pass through the primary firewall and the services will be invoked through DataPower. The following figure depicts the deployment topology.
 
Figure: Deployment Topology
 
Deployment Topology depicts the layout of DataPower architecture. The DataPower appliance will be installed in DMZ. CA issued certificate will be offloaded at load balancer in DMZ. DataPower acts as a secure gateway for the Web services. All the Web service will be configured in DataPower. Any incoming request to DataPower will be routed to the corresponding backend service. 
DataPower device consists of layers of related objects. Service object, such as Web service Proxy, occupy the top layer. These objects provide the coordinated runtime service needed to implement solutions to SOA requirements. 
 
 
Figure: Configuration Architecture
 
A single device can run many services simultaneously. At the next layer, processing policy objects and many objects referenced by a processing policy provide message handling and routing services. These objects perform tasks such as message transformation, message filtering, authentication and authorization, cryptographic operations, error handling, and dynamic message routing. Any single service has only one processing policy.  
The processing policy has a number of rules such as:
 
  • Request Rule
  • Response Rule
  • Error Rule
The rules are framed by the sequence of actions. Each rule contains any number of actions such as:
 
  • Validation
  • Verify

Domains

DataPower will have Service domain. eMed DataPower receives web calls requests from eMed entities (organization using eMed application) and performs the digital signature validation. After successful validation, DataPower will route the request to IIB. 


Service Domain

This domain will basically be responsible for: 
 
  • Validating the requests based on defined schema
  • Performing required  validations
  • Catering to required transformations (if required)
  • Performing Encryption (for outbound traffic)
  • Sending the requests to the actual backend service.
There can be multiple services configured in the service domain based on the required eMed application functionality. These functionalities will handle requests from eMed entities (external partners/eMed users). The service configured in this domain will be shared. For example, there is 'functionality 1' which is required for some of the eMed entities (like external hospitals/partners). In this scenario, there will be only one service configured and this can be called by the eMed entities (like external hospitals/partners). The eMed domain will cater to the routing request. The services configured in this domain will route the requests finally to the respective backend services. Each service will have its own set of functions. eMed DataPower has some common actions such as schema validation and encryption (for outbound traffic).


Error Handling

Error handling will be done in the eMed domain for DataPower services. DataPower has an inbuilt property of sending error messages for any error situation. The error handling done will be as follows:
 
  • eMed Generic Errors: For generic errors like backend service not up, service not found and the like, eMed DataPower has an inbuilt property of returning the common HTTP error code in the response header. For example, if the server is down, it will send the HTTP header code as 500 and will denote it in the error message as “Internal server error”.
     
  • eMed Common Errors within DataPower Service:  There can an error situation within the DataPower service. For example, an XML message is received for a service which is basically configured for SOAP messages. For all these conditions, DataPower has an inbuilt property of sending an error message in the form of defined XML with an error message as “Internal error”.
     
  • eMed Customized Errors: For few specific error conditions, eMed DataPower will have to send customized error messages. For example, in a case of schema validation failure, eMed DataPower will have to send a specific error which will state the cause of the failure. For these conditions, an error rule will be created in the eMed DataPower service policy. This error rule will have the transform action where using XSLT, a customized error message will be created to send back as a response pertaining to the respective error.

Input and Output Validations

Following validations will be applied to all services that are invoked in the eMed application systems:
 
  • Input for the data type, length, range, format, syntax, missing or extra inputs, meta-characters and consistency across related fields will be validated. Also, whether all mandatory data for the service is present and Input data format is as per service specification will be validated. These have been taken care as part of schema validation at all levels.
  • All Web services being used are SOAP based. 
  • The following will be validated with respect to service authorization:  
  1. Whether a user is authorized to execute the service
  2. Whether a service is enabled for the entity  

Web Service Call Security

To ensure only authorized application components are consuming services and to prevent unauthorized service calls, web service authorization will be handled by DataPower. 


Conclusion

The SOA communication could either involve simple data transfer or it could involve multiple services coordinating some activity. These services are connected together by web services. The web services provide a standard means of interoperability between software applications running on a range of platforms and frameworks using XML, Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and UDDI open standards over an internet protocol. As benefits we can get:
 
  • Performance and reliability of the SOA are improved
  • Eases testing of both SOA-based and REST API-based web services
  • Test execution of web services in a cloud environment are also Supported
  • Reduces Testing efforts over regression cycles
  • Ensures 100% Functional Test coverage
Authored By - Anil Kumar Dubey
TCS Enterprise Security and Risk Management
Rate this article: 
Average: 1 (2 votes)
Article category: