5 Web Services Security

Out-of-the-box, OHI web services are not secured. This chapter explains how OHI web services can be used in a secure manner.

5.1 Web Services Security Overview

For any web service, it is important to guarantee integrity and confidentiality of messages and to ensure the identity of a client that is accessing OHI web services. This can be achieved by implementing different types of security measures.

Table 5-1 Web Services Security

Security Type	Description
Transport-level security	Secures the connection between the client application and a web service with Secure Sockets Layer (SSL).
Message-level security	Includes all the security benefits of SSL, but with additional flexibility and features. Message-level security is end-to-end, which means that a SOAP message is secure even when the transmission involves one or more intermediaries. The SOAP message itself is digitally signed and encrypted, rather than just the connection.
Access control security	Specifies which roles are allowed to access Web services (answers the question "who can do what?").

By default, OHI web services are not secured.The remaining paragraphs in this chapter outline different options to secure OHI web services.

WARNING:

Before these are used, make sure that OHI web services are properly secured in accordance with your organization's security requirements and standards.

5.2 Minimal Required Security for OHI Web Services

The minimal security measures for OHI web services should comprise the following:

• Encrypt any message using SSL in order to assure message confidentiality. Note that OHI web services may receive or send messages that contain protected health information. Even within the intranet or internal network these should be encrypted.

• At the network level, e.g. in a switch or router, configure that OHI web services can only be accessed through the load balancer or web server that is set up to regulate any access to OHI. OHI web services should not be accessible from any other device within the organization. Additional security measures to allow or prevent message traffic from certain clients within the organization may be configured in the load balancer or web server.

5.3 Applying WS-Security Policies

OHI applications support the WS-Security 1.1 standard, also know as WSS. WSS policies can be applied (or attached to the OHI web services) in two different ways:

• Through Oracle WebLogic WSS policies.

• Through the use of Oracle Web Services Manager (WSM).

Oracle WSM must always be enabled on the WebLogic domain in which OHI applications are executed. Note that OWSM should only be licensed if the OWSM WSS policies are applied. OWSM can be selected upon domain creation, or added to a domain by extending it at a later stage. Installation of OWSM comprises the following steps:

1. First, in order to enable OWSM in a domain, an MDS schema must be installed using Oracle Repository Creation Utility (RCU). MDS means Oracle Metadata Services, and provides a repository for Fusion Middleware components, such as OWSM. It is important that the RCU version matches the WebLogic version that is used for executing an OHI application. The OHI Installation Guide for a specific release mentions the required RCU version. In the RCU, select the Metadata Services as shown in the following figure:

   Figure 5-1 Creating an MDS Repository using the RCU

   
   

2. Next, when installing the domain using the Fusion Middleware installer, on the "Select Domain Source" screen select the checkbox "Oracle WSM Policy Manager 11.1.1.0 (oracle_common)":

   Figure 5-2 Creating a Domain with OWSM

   
   

3. On the "Configure JDBC Component Schema" screen, set the proper schema for mapping OWSM to the MDS schema that was created with the RCU earlier:

   Figure 5-3 Selecting the MDS Schema

   
   

4. The MDS schema must be targeted to the OHI domain, and the wsm-pm deployment (Web Services Manger – Policy Management) must be also targeted to it. This can be done on the Deployments and Services tab. On the "Select Optional Configuration" screen, check the box "Deployments and Services":

   Figure 5-4 Selecting the 'Deployment and Services' Option

   
   

5. On the "Target Deployments to Clusters or Servers" screen, the deployment called "wsm-pm" must be targeted to the Admin Server (and any managed server that runs OHI).:

   Figure 5-5 Targeting the wsm-pm deployment

   
   

6. On the "Target Services to Clusters or Servers" screen, the JDBC data source mds-owsm must be targeted to the Admin Server (and any managed server that runs OHI).:

   Figure 5-6 Targeting the JDBC deployment for MDS

   
   

7. Finish creating the domain and installing the OHI application to be able to apply WebLogic or OWSM WS-Security policies to OHI web services. To validate that the policies are available for applying to OHI web services:

   • Open the OHI deployment in the WebLogic console

   • Select one of the web services

   • In the Settings page for the web service open the Configuration tab and the WS-Policy tab below

   • Determine if the policy should be applied to the service endpoint or to a specific operation

   • Finally, determine what kind of policy will be used, either a WebLogic policy or an OWSM policy (OWSM licenses required):

   Figure 5-7 Determine the type of Policy

   
   

For additional information on using WSS policies please visit the following URLs:

• For WebLogic web services policies, see guide Securing WebLogic Web Services for Oracle WebLogic Server (http://docs.oracle.com/cd/E17904_01/web.1111/e13713/toc.htm).

• For OWSM web services policies, see guide Security and Administrator's Guide for Web Services (http://docs.oracle.com/cd/E17904_01/web.1111/b32511/toc.htm)