Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

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:

  • J2EE Connector Architecture (J2EE CA): The J2EE CA provides a standards-based infrastructure for integrating J2EE applications with existing EISs and business applications. J2EE CA provides resource adapters for external EISs that can be plugged into a J2EE-compliant application server. Enterprise-class business applications can then be developed using these adapters to support and manage secure, transactional, and scalable integration with EISs and back-end systems.

  • Java Message Service (JMS): JMS is a Java-based API infrastructure defined to support message-oriented middleware and enterprise messaging systems. It facilitates a generic messaging API that can be used across different types of enterprise messaging providers. Applications use the JMS API to connect to an enterprise messaging system using either asynchronous or synchronous communication. Once a connection is established, the application can use a messaging provider (via the JMS API) to send and receive messages and communicate asynchronously with one or more business applications.

  • Java Database Connectivity (JDBC): The JDBC API defines a Java API for integration with relational database systems. A Java application uses the JDBC API for obtaining database connections, retrieving database records, executing database queries and stored procedures, and performing other database functions.

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:

  • User identification, authentication, and authorization of principals.

  • Secure communication between the application server and the EIS resource, using open network communication security protocols like Kerberos that provide end-to-end security with authentication and confidentiality services.

  • Enabling EIS-specific proprietary security mechanisms that exist in EIS systems such as SAP, BAAN, and Oracle.

  • Under the hood, the J2EE Connector establishes a security contract between the J2EE server and the EIS resource adapter that extends the connection management mechanisms to support secure communication with protocols that provide authentication, integrity, and confidentiality services. The Connector allows support for different security mechanisms to protect the underlying EIS against security threats such as unauthorized access and loss or corruption of information. Figure 5-7 illustrates the representation of a J2EE Connector security contract with J2EE components.

    Figure 5-7. J2EE Connector security contract with the J2EE platform

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:

  • Container-Managed Sign-On: The application component lets the container take the responsibility of configuring and managing the EIS sign-on. The container determines the username and password to establish the connection to an EIS instance.

  • Component-Managed Sign-On: The application component code manages the EIS sign-on by including code that performs the sign-on process to an EIS.

Let's take a closer look at these two approaches.

Container-Managed Sign-On

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();

Component-Managed Sign-On

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:

  • Determine the resource principal (identity of the initiating caller) under whose security context a new connection to an EIS will be established.

  • Authenticate the resource principal if the connection is not already authenticated.

  • Establish a secure association between the application server and the EIS. Additional mechanisms like SSL or Kerberos can also be deployed.

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.

Securing JMS

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:

  • JMS provider authentication and access control

  • JMS queues protection so that the destinations are available for access to privileged applications

  • JMS message and transport security

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.

Securing JDBC

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:

  • Secure communication between the application and the underlying database system using HTTP over SSL/TLS protocols

  • Data encryption mechanisms

  • Support for data integrity checking mechanisms

  • Support for secure rich-client communication to databases via Firewall

  • Support for security auditing and reporting on data access

These mechanisms are represented in the JDBC driver properties by setting appropriate configuration parameters; there is no need to change code.

Related

Категории