1.4 An Overview of Enterprise Security Integration

Enterprises typically use a number of security technologies, including authentication and authorization, cryptography and related services, firewalls, SOCKS, ^[4] and proxy servers. It is essential for Java components and J2EE to interoperate with these technologies, as they provide essential services. When Java technology can plug into existing security technology infrastructures , J2EE can leverage the existing services, thus avoiding duplication of administrative and processing overhead. It also leads to greater consistency between legacy and Java applications. Tying into existing security services will prevent Java technology and J2EE from operating as an island.

^[4] SOCKS is a shortened version of socket secure . Socket is the term used for the data structures that describe a TCP (Transmission Control Protocol) connection.

1.4.1 Authentication and Authorization Services

Typical authentication and authorization services include some, such as Resource Access Control Facility (RACF) on z/OS and Active Directory on Microsoft Windows, that are native to operating systems. Distributed system support for authentication and authorization technologies exists for Web-based applications and services, including Tivoli's Access Manager product. Kerberos, developed at Massachusetts Institute of Technology (MIT), has been in use for many years in support of distributed systems applications.

Since its inception, the Java 2 platform has provided a means to enforce access control based on where code came from and who signed it. The need for this type of access control derives from the distributed nature of Java technology, whereby mobile code may be downloaded over a public network and then run locally. The original design, however, lacked the means to enforce similar access control based on who runs the code. To provide this type of access control, the Java 2 security architecture required additional support for authentication ”determining who is running the code ”and extensions to the existing authorization components to enforce new access controls, based on who was authenticated. The JAAS framework, which is now integrated into the core Java platform, augments the Java 2 security architecture with such support and allows existing authentication and authorization services, such as those listed earlier, to be tied into Java technologies and J2EE, as described in Section 9.4 on page 338.

1.4.2 Cryptographic Services

Cryptography is a key element of enterprise security. The Java platform offers cryptographic support through JCA and JCE.

The basic JCA offers support for message digests and digital signatures. Support for encryption is provided through JCE, a JCA extension that was introduced to respond to the export restrictions on encryption imposed by the United States.

JCA is described as a provider architecture. The primary design principle of the JCA has been to separate the cryptographic concepts from their algorithmic implementations . JCA is designed to allow vendors to provide their own implementations of the cryptographic tools and other administrative functions. Providers may be updated transparently to the application: for example, when faster or more secure versions are available. The result is a flexible framework that will cater to future requirements and allow vendor independence and interoperability.

Even though JCA and JCE offer a flexible and powerful cryptographic support to Java applications, most programmers and application designers would prefer ready-built cryptographic protocols rather than having to create them from the basic elements of encryption and digital signatures. The JSSE framework allows Java programs to communicate with other programs and services using SSL, which is the most widely used cryptographic service provided in the Web.

1.4.3 Firewalls

Firewalls are intended to keep malicious entities from attacking systems within the enterprise. One way to let applications within the firewall access network resources outside the firewall is to use the SOCKS protocol within the intranet and a SOCKS server at the firewall. SOCKS encapsulates a client's network request and sends the data packets to a SOCKS server. SOCKS requests are allowed through the firewall; the SOCKS server unwraps the request and forwards it to the target system. Responses from the target system are encapsulated, sent through the firewall, and sent back to the system that originated the request. Unauthorized network messages are still blocked at the firewall. SOCKS is often enabled by replacing or wrapping the Transmission Control Protocol/Internet Protocol (TCP/IP) APIs on an underlying operating system with a SOCKSified version. This makes SOCKS transparent to applications.

Proxy servers work in a similar way by sending a network request through a third system. A proxy server's function is to receive a request from a Web client, perform that request on behalf of the client ”possibly after authorization ”and return the results to the browser. Like a SOCKS server, a proxy server prevents requests coming from the external network from accessing the internal network. Unlike a SOCKS server, however, a proxy server does not require TCP to be encapsulated within another protocol.

New network routers and firewalls are eliminating the need for SOCKS and proxy servers by integrating the filtering function directly rather than through a separate server or service. J2EE leverages firewalls to enhance the security of a system, as described in Section 2.4 on page 36, and in Chapter 6.