Connecting Your Database through the Connector Architecture

The J2EE Connector API provides a generic framework to map data from Enterprise Application Integration (EAI) systems and EIS systems. A good site for information is the J2EE Connector architecture discussion in the java.sun.com/j2ee/connector/ site, on which some of this discussion is based. Some of the benefits of the Connector API include connection management , security management , and transaction management . The J2EE Connector architecture defines the following three system-level contracts (between an application server and EIS):

A Connection Management contract , which allows an application to have server pool connections - for reuse without the delay of connection instance allocation and deallocation - to an underlying EIS, and lets application components connect to an EIS.
A Transaction Management contract , which lets an application server use a transaction manager to manage transactions across multiple resource managers. This contract also supports transactions that are managed internal to an EIS resource manager without the necessity of involving an external transaction manager. Data manipulation requires transactional integrity to ensure that rollbacks and commits can be supported, and so transaction management is important.
A Security contract, which enables a secure access to an EIS. This contract provides support for a secure application environment to reduce security threats to the EIS.

The J2EE Connector architecture defines a Common Client Interface (CCI) for EIS access that defines a standard client API for application components. The purpose of the CCI is to provide a generic Connector implementation independent of the application server. This connection is not aware of the security management, the transaction management, or the connection management. Figure 20-2 shows where the CCI is used.

Figure 20-2: The Common Client Interface

Caution

Security management (as well as transaction and connection management) is not automatically provided for you just because you use the CCI.

In the example code of Listing 20-3, I used the JDBC javax.sql.DataSource and java.sql.Connection interfaces for database connections. The connection and connection factory are defined for the CCI with the interfaces javax.resources.cci.ConnectionFactory and javax.resources.cci.Connection . The ConnectionFactory creates (or finds in a pool) a ManagedConnection that has an associated transaction.

Note	The Connector API does not define a standard format and requirements for security mechanisms for specific credentials, but it does offer a GenericCredential interface to wrap Kerberos credentials.

The authentication is specified in the <authentication-mechanism-type> tag of resource adapter's deployment descriptor, which allows the resource adapter to get the information about the credential. As with JDBC, the security context is propagated and principals are passed through the subject during the getConnection .

Cross-Reference

Chapter 19 describes credential, principals, and subject concepts.

As noted earlier, the communications between the EIS and the application server are subject to attacks. These threats include data modification and man-in-the-middle attacks. Therefore, securing the communication is important and can be done with SSL, and some EISs can support the GSS-API. The GSS-API is the Generic Security Services Application Programming Interface . The application server uses the createManagedConnection when it requests a resource adapter to create a new connection. It can pass in the subject by using either the application-managed sign-on (the application component passes the subject to the resource) or container-managed sign-on (application server fills in the subject ).

A subject represents a grouping of related information for a single entity. This information includes the subject's identity, passwords, and cryptographic keys. A subject may have multiple identities, which are the principals within the subject. A subject may have credentials that are the security- related attributes; the sensitive credentials are stored within a credential set. Credential sets can be public (intended to be shared) or private.

For sign-on:

The application server provides one-to-many PasswordCredentials in the Subject class. The resource adapter uses this information to sign on to the EIS. The PasswordCredentials are set in the private credential set. The resource adapter extracts the username and password and uses this information for EIS sign-on.
The application server provides one-to-many GenericCredentials in the Subject class. The resource adapter uses this information as private or public keys, which could be Kerberos keys. The resource adapter extracts these credentials , and if Kerberos is selected as the authentication mechanism type, it gets this information out of the private credential as Kerberos-based keys.
By passing a null subject, the application server does not provide any security information. In this case the application component is responsible for the security. The security can be placed in a ConnectionRequestInfo for component information; however, the application server cannot read this information because the ConnectionRequestInfo is a data structure for the resource adapter to pass information for its own data in the connection request. If the resource adapter does not find information in the ConnectionRequestInfo , it uses the default security configuration.

Cross-Reference

Chapter 16 discusses Kerberos. Chapter 17 discusses the GSS-API.

Table of content

Java Security Solutions

ISBN: 0764549286
EAN: 2147483647

Year: 2001
Pages: 222

Authors: Rich Helton, Johennie Helton

BUY ON AMAZON

Java I/O

Kanban Made Simple: Demystifying and Applying Toyotas Legendary Manufacturing Process

A Practitioners Guide to Software Test Design

Excel Scientific and Engineering Cookbook (Cookbooks (OReilly))

The Complete Cisco VPN Configuration Guide

Cisco Voice Gateways and Gatekeepers