Secure Communication Channel





Secure Communication Channel

By providing layers of defense, authentication and authorization play critical roles in securing any environment. It is equally important to ensure integrity and confidentiality of information as it is propagated through data networks. Part of hardening the security of an enterprise environment is to ensure that all communication between the servers is over a secure communication channel. It is typical to use SSL when communication is over TCP.

1 HTTP Connections

When they connect to WASs behind the firewalls, Web servers typically use HTTP to route the requests. To ensure confidentiality and integrity, SSL is used. The resulting protocol is HTTPS. If such connections are long-lived and the SSL sessions are not frequently torn down, the SSL handshake overhead is minimal. Of course, encryption and decryption of every request has its own performance effect, but it should be considered in the context of the time the application takes to execute in the WAS and the payload size itself. For example, for an application that takes a long time to run, the time spent in encryption and decryption may be negligible. This should be combined with the fact that the time it takes to perform encryption and decryption is proportional to the size of the content.

2 IIOP Connections

If the enterprise beans are distributed across a set of WASs, it is also important to secure the communication between the WASs. These request invocations are performed as RMI-IIOP requests, so the communication can be secured by establishing an SSL session between the servers. Because enterprise beans are hosted within ORBs, the security context must be established between the ORBs. This can be enforced through the use of CSIv2, whereby ORB connections are handled per security requirements of the ORBs. The CSIv2 capabilities of a J2EE WAS can be configured to ensure that all the requests are over SSL. Additional tuning can be achieved by specifying the cipher suites that are acceptable or minimally required for these IIOP communications.

3 JMS Connections

Java Message Service is increasingly being adopted to enable message-driven enterprise applications. The JMS framework allows messaging providers, such as IBM WebSphere Message Queuing (MQ),[2] to be plugged in and used by J2EE applications. The JMS specification does not define any security functionality. The security of a messaging layer is dependent on the security capabilities of the JMS implementation. Therefore, when requests are sent over a JMS connection, care should be taken to secure the messages. For example, publishers should encrypt their messages, which should be decrypted only by trusted subscribers.

[2] Formerly known as IBM MQSeries. See http://www.ibm.com/websphere.

Messages sent over a JMS channel can be secured in at least two ways.

  1. Security requirements can be addressed at the application layer, where the messages can be encrypted or digitally signed. In the case of standard message formats, steps should be taken to take advantage of the existing security capabilities. For example, SOAP messages can be secured using the Web Services Security specification (WS-Security), according to which the elements of a SOAP message can be encrypted and/or digitally signed. Note that WS-Security is not part of the J2EE specification. More details on WS-Security are given in Section 14.5.2 on page 506 and Section 14.6 on page 507.

  2. Security requirements can be addressed by taking advantage of the built-in security capabilities of the message provider. For example, the encryption of the messages can be achieved by configuring the message endpoints, based on provider-specific mechanisms.

4 Connections to Non-J2EE Systems

As discussed in Section 6.2.4 on page 195, connections that are established between a J2EE environment and a back-end system are typically handled through Java connectors. The JCA deals with authentication requirements of the back-end system and expresses how credentials are passed to it from the J2EE environment. In addition, it is necessary to inspect each of the connectors and see whether the connection can be secured. This may be dependent on the capabilities of the back-end system. If connections are directly established from applications and not through the JCA framework, care should be taken to evaluate the security of such communications. For instance, a connection to a back-end LDAP directory can be configured to be over SSL.

5 Exploring Other Options

Certain protocols of communications may be proprietary to an enterprise. Such communication channels may be difficult to replace with standard protocols, such as HTTP, or to provide encryption for. In these cases, network security mechanisms, such as VPNs and IPSec, must be evaluated. Because VPNs are configured at the network layer, they do not require changes at the application layer. This may help harden the security of a computer network and meet the security requirements of an enterprise.


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows