J2EE offers a standards-based integration infrastructure that facilitates enterprise application integration and provides mechanisms for establishing communication and exchange data with heterogeneous back-end business resources such as relational databases, EIS systems, and JMS messaging providers. The key integration technologies that are part of a J2EE environment are as follows:
Let's take a closer look at these technologies and the security mechanisms available for securing the Integration Tier of a J2EE environment.
Securing J2EE Connector and EIS
The J2EE Connector Architecture (J2EE CA) provides security management services that define the security mechanisms between the application server and the EIS resource. In general, it offers a variety of security mechanisms used to protect an EIS against unauthorized access and other security threats. These security mechanisms include:
In a typical usage scenario, the application component makes a request to establish a connection with the underlying EIS layer. To serve the request, the resource adapter security services authenticate the caller using the credentials and then establish a connection with the underlying EIS layer. After authentication, the security service determines the access privileges for the authenticated user in order to determine whether the user is permitted to access the EIS resource. All subsequent invocations that the application component makes to the EIS instance occur using the security context of the caller's principal identity.
Establishing a Secure EIS Connection
The J2EE CA provider has two choices for implementing the EIS connections:
Let's take a closer look at these two approaches.
With container-managed sign-on, the application developer assigns the responsibility of managing the EIS sign-on to the J2EE application server and the application deployer to be responsible for managing the EIS sign-on. To represent this, the application developer sets the res-auth element in the Connector deployment descriptor to Container. The deployer sets up and configures the EIS sign-on configuration with the required username and password for establishing the connection. The snippet in Example 5-33 represents the res-auth element in the connector module deployment descriptor.
Example 5-33. Declaring container managed sign-on
. . . <resource-ref> <res-ref-name>eis/PeopleSoft</res-ref-name> <res-type>javax.resource.cci.ConnectionFactory </res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref> . . .
In the application code, when the component invokes the getConnection method on the ConnectionFactory instance, it does not need to pass any security credentials. The application using the container managed sign-on will look like Example 5-34.
Example 5-34. Establishing EIS connection using container managed sign-on
// Perform JNDI lookup and obtain a connection factory javax.resource.cci.ConnectionFactory cxf = (javax.resource.cci.ConnectionFactory) ctx.lookup("java:comp/env/eis/PeoplesftCxFactory"); // Invoke factory to obtain a connection javax.resource.cci.Connection cx= cxf.getConnection();
With component-managed sign-on, the application developer includes the code that is responsible for managing the EIS sign-on. To represent this, the application developer sets the res-auth element in the Connector deployment descriptor to Application. This indicates that the component code is designed to perform a programmatic sign-on to the EIS. The application developer must pass the required credentials, such as username and password, to establish the connection. The snippet in Example 5-35 represents the use of the res-auth element in the Connector module deployment descriptor.
Example 5-35. Declaring component managed sign-on
. . . <resource-ref> <res-ref-name>eis/PeopleSoft</res-ref-name> <res-type>javax.resource.cci.ConnectionFactory</res-type> <res-auth>Application</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref> . . .
In the application code, when the component invokes the getConnection method on the ConnectionFactory instance, it is necessary to pass the required security credentials. The application using the component-managed sign-on will look like Example 5-36.
Example 5-36. Establishing EIS connection using component-managed sign-on
// Perform JNDI lookup and Obtain a connection factory javax.resource.cci.ConnectionFactory cxf = (javax.resource.cci.ConnectionFactory) ctx.lookup("java:comp/env/eis/PeoplesftCxFactory"); //Get a new ConnectionSpec com.eis.ConnectionSpecImpl myEIS = //../ // Invoke factory to obtain a connection myEIS.setUserName("javaman"); myEIS.setPassword("javarules"); javax.resource.cci.Connection cx= cxf.getConnection(myEIS);
EIS Sign-On Process
The creation of a new EIS connection usually involves the creation of a sign-on process. Implementing an EIS sign-on requires one or more of the following steps:
Once the EIS sign-on is established, the connection is associated with the security context of the initiating user. Subsequently, all application-level invocations of an EIS instance occur under the security context of that principal identity.
When deploying an application that uses a J2EE Connector, the deployer configures the security credentials required to create the connections to the underlying EIS systems. The deployer performs the principal mapping configuration to ensure that all connections are established under the security context of the EIS user who is the resource principal of the underlying EIS. The J2EE application server takes the responsibility of handling the principal mapping for all the authenticated caller principals. Thus, a user accesses the EIS under the security context of the configured resource principal.
Java Message Service (JMS) is an integral part of the J2EE platform. It provides a standard set of Java APIs that allow J2EE applications to send and receive messages asynchronously. It also allows access to the common features of any JMS-compliant enterprise messaging system (typical to message brokers). JMS defines a loosely coupled, reliable application communication mechanism for enabling J2EE components to send and receive messages with enterprise applications and legacy systems. The JMS specification primarily aims at defining a Java-based messaging API designed to support a wide range of enterprise messaging vendor products. It leaves the responsibility of adding security features to the JMS provider vendors.
From a security viewpoint, a JMS-based application security solution requires support for authentication, authorization, encryption, confidentiality, data integrity, and non-repudiation. Most messaging vendors provide support for some of these features:
It is also important to note that the JMS specification does not address these security requirements but leaves it to the JMS provider vendors to implement its requirements. So the features discussed in the following sections may differ among vendor implementations.
JMS Provider Authentication
Most JMS providers allow JMS clients to authenticate themselves with the JMS provider and target destinations. The authentication occurs either using a username/password combination or using digital certificates. In some vendor implementations, the JMS provider makes use of a repository such as LDAP or a relational database for storing privileged users or digital certificates.
Access Control for JMS Destinations
Establishing access control for JMS destinations allows rules and policies to be set with the JMS clients so that they are secure and accessed by designated systems. This requires that an access control list (ACL) be created to define the security policies for sending and receiving messages from a target destination (Queue or Topic). Most JMS providers facilitate support for setting access control on JMS destinations by applying ACLs that grant permissions to send and receive messages.
JMS Transport Security
The JMS specification does not address the choice of protocols to transport JMS messages. To secure JMS transport, most providers facilitate secure communication by adopting transport-layer integrity and confidentiality mechanisms based on SSL/TLS protocols. These transport-specific properties are configured at the JMS provider level and are applied to communication during the creation of the JMS connection.
JDBC technology is an API (included in both J2SE and J2EE releases) that provides a cross-DBMS connectivity supporting a wide range of data sources, including SQL databases and tabular data sources such as spreadsheets or flat files. With JDBC API mechanisms, Java-based applications are able to send SQL or other statements to data sources running on heterogeneous platforms. To access these data sources, JDBC makes use of appropriate JDBC-enabled drivers provided by the database vendor. The JDBC specification leaves the responsibility of providing security features to the JDBC drivers and the database implementation. With the introduction of JDBC 3.0 specification, JDBC provides compatibility with the J2EE Connector architecture. This means that JDBC drivers can be implemented as J2EE Connectors (Resource Adapters). They are packaged and deployed as a resource adopter that allows a J2EE container to integrate its connection, transaction, and security management services with the underlying data source.
So far there are no standard JDBC security mechanisms, but most of the major database and JDBC driver vendors offer custom security mechanisms to provide the following:
These mechanisms are represented in the JDBC driver properties by setting appropriate configuration parameters; there is no need to change code.