7.7 Perspectives

7.7.1 Highlights

  • XML Encryption and XML Signature are the basic technologies for application- and message-level protection for Web Services applications.

  • WS-Security, XKMS, SAML, and XACML are emerging standards and specifications to provide a framework for end-to-end Web Services security. They are complementary in the current stage to cover different aspects. Many of these technologies are implemented as developer toolkits and will be embedded with security infrastructure products.

  • Platform security and end-to-end application architecture design are not currently emphasized in Web Services security design. Security hardening tools can be of great help here.

7.7.2 Best Practices and Pitfalls

A checklist for protecting Web Services hosts :

  • Run security-hardening tools before development starts and after development completes.

  • Always turn off unused network services and ports on the platform operating system.

  • Always use encryption and digital signatures for sensitive and confidential transactions.

  • Always ensure file protection for configuration files of UDDI registry and WSDL files.

For example, under the Java Web Services Developer Pack development environment (which uses Apache Tomcat as the Web Container), the Web Services objects that may be of interest for security protection and checking are listed in Table 7-3. On the development and production environment (whether Solaris OE or Windows), it is always a good practice to protect these objects or files from being a target for attack or exploitation with appropriate access rights.

Table 7-3. Examples of Web Services Objects That Need Security Protection

Web Services Objects

Location

Remarks

Web Container

 

In this example, this is Apache Tomcat 4.x.

User access control list

D:\Dev\WSDP\conf\ tomcat-users .xml

This file contains the user names , user passwords, and roles that are allowed to access and execute resources under the Web Container.

Server configuration file

D:\Dev\WSDP\conf\server.xml

This file contains the server configuration (for example, port number) for running the Tomcat server.

Log Files

   

Web Container log files

D:\Dev\WSDP\logs

In this example, Tomcat log files are used. This directory contains log files for Tomcat server (Catalina.out), server administration log (localhost_admin_log*.logand access_log*.log and services_log*.log), as well as Service Registry log (xindice.log).

Developer tool log files

D:\Dev\WSDP\logs\jwsdp_log*.log

In this example, Java Web Services Developer Pack's log files are shown.

Service Registry update activity log file

D:\Dev\WSDP\tools\xindice\logs\xindice.log

In this example, the Xindice database activity log file is used.

Message Provider

   

ebXML message provider administration logs

D:\Dev\WSDP\work\Services Engines\jaxm-provider\ebxml

There are four subdirectories that contain the messages received, sent, to be dispatched, and to be sent. This denotes the physical location where the JAXM message provider will send or receive the messages with the reliable message delivery capability.

SOAP Remote Provider message provider administration logs

D:\Dev\WSDP\work\Services Engines\jaxm-provider\soaprp

There are four subdirectories that contain the messages received, sent, to be dispatched, and to be sent. This denotes the physical location where the SOAP remote message provider will send or receive the messages with the reliable message delivery capability

Service Registry

 

In Java Web Services Developer Pack, UDDI Service Registry is implemented using Xindice object database.

Service Registry files

D:\Dev\WSDP\tools\xindice\db

This file location contains the subdirectory 'system' for the object database system files and security information, and the subdirectory 'uddi' for the actual UDDI data store.

WSDL documents

N/A

In this demo environment, the WSDL documents are generated dynamically and do not store in the Service Registry.

Here are some considerations:

  • Use of HTTPS and encryption has a direct impact on system performance and response time.

  • Profile each Web Services call for the benchmarking, and check the log files during the first few months of deployment. The performance statistics can be used as a baseline metric for future comparison and troubleshooting purposes. If there is any abnormal performance or unusual data traffic pattern (for example, a sudden outburst of data traffic may be due to Denial of Service), then security administrators can check the previous Web Services profiling metrics.



J2EE Platform Web Services
J2EE Platform Web Services
ISBN: 0131014021
EAN: 2147483647
Year: 2002
Pages: 127
Authors: Ray Lai

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net