+

Search Tips   |   Advanced Search

J2EE connector security


The Java2 Platform, Enterprise Edition (J2EE) connector architecture defines a standard architecture for connecting J2EE to heterogeneous enterprise information systems (EIS). Examples of EIS include Enterprise Resource Planning (ERP), mainframe transaction processing (TP) and database systems.

The connector architecture enables an EIS vendor to provide a standard resource adapter for its EIS. A resource adapter is a system-level software driver used by a Java application to connect to an EIS. The resource adapter plugs into an appserver and provides connectivity between the EIS, the appserver, and the enterprise application. Accessing information in EIS typically requires access control to prevent unauthorized accesses. J2EE applications must authenticate to the EIS to open a connection.

The J2EE connector security architecture is designed to extend the end-to-end security model for J2EE-based applications to include integration with EIS environments. An appserver and an EIS collaborate to ensure the correct authentication of a resource principal, which establishes a connection to an underlying EIS. The connector architecture identifies the following mechanisms as the commonly supported authentication mechanisms, although other mechanisms can be defined:

Applications define whether to use application-managed sign-on or container-managed sign-on in the resource-ref elements in the deployment descriptor. Each resource-ref element describes a single connection factory reference binding. The res-auth element in a resource-ref element, whose value is either Application or Container, indicates whether the enterprise bean code can perform sign-on or whether appserver can sign-on to the resource manager using the principal mapping configuration. The resource-ref element is typically defined at application assembly time with an assembly tool. The resource-ref can also be defined, or redefined, at deployment time.

 

Application managed sign-on

To access an EIS system, applications locate a connection factory from the JNDI namespace and invoke the getConnection method on that connection factory object. The getConnection method might require a user ID and password argument. A J2EE application can pass in a user ID and password to the getConnection method, which subsequently passes the information to the resource adapter. Specifying a user ID and password in the application code might compromise some security, however.

The user ID and password, if coded into the Java source code, are available to developers and testers in the organization. Also, the user ID and password are visible to users if they decompile the Java class.

The user ID and password cannot be changed without first requiring a code change. Alternatively, application code might retrieve sets of user IDs and passwords from persistent storage or from an external service. This approach requires that IT administrators configure and manage a user ID and password using the application-specific mechanism.

To access this authentication data, the appserver supports a component-managed authentication alias to be specified on a resource. This authentication data is common to all references to the resource. Click Resources > Resource Adapters > J2C connection factories > configuration_name . Select Use component-managed authentication alias. When res-auth=Application, the authentication data is taken from the following elements, in order:

  1. The user ID and password that are passed to the getConnection method

  2. The component-managed authentication alias in the connection factory or the data source

  3. The custom properties user name and password in the data source

The user name and password properties can be initially defined in the resource adapter archive (RAR) file.

These properties can also be defined in the admin console or using wsadmin scripting from custom properties.

 

Container-managed sign-on

The user ID and password for the target enterprise information systems (EIS) can be supplied by the appserver. WAS ND v7.0 provides container-managed sign-on functionality. The appserver locates the proper authentication data for the target EIS to enable the client to establish a connection. Application code does not have to provide a user ID and password in the getConnection call when it is configured to use container-managed sign-on, and authentication data does not have to be common to all references to a resource. The uses a Java Authentication and Authorization Service (JAAS) pluggable authentication mechanism to use a pre-configured JAAS login configuration, and LoginModule to map a client security identity and credentials on the running thread to a pre-configured user ID and password.

WAS ND v7.0 supports a default many-to-one credential mapping LoginModule module that maps any client identity on the running thread to a preconfigured user ID and password for a specified target EIS. The default mapping module is a special purpose JAAS LoginModule module that returns a PasswordCredential credential specified by the configured Java 2 connector (J2C) authentication data entry. The default mapping LoginModule module performs a table lookup, but does not perform actual authentication. The user ID and password are stored together with an alias in the J2C authentication data list.

The J2C authentication data list is located on the Global security panel from Java Authentication and Authorization Service > J2C Authentication data. The default principal and credential mapping function is defined by the DefaultPrincipalMapping application JAAS login configuration.

J2C authentication data that is modified using the admin console takes effect when the modification is saved into the repository, and Test Connection is performed. Also, J2C authentication data that is modified using wsadmin scripting takes effect when any application is started or restarted for a given the appserver server process. J2C authentication data modification takes effect by invoking the SecurityAdmin MBean method, updateAuthDataCfg. Set the HashMap parameter to null to enable the Securityadmin MBean to refresh the J2C authentication data using the latest values in the repository.

Do not modify the DefaultPrincipalMapping login configuration because WAS ND includes performance enhancements to this frequently used default mapping configuration. WAS ND v7.0 does not support modifying the DefaultPrincipalMapping configuration, changing the default LoginModule module, or stacking a custom LoginModule module in the configuration.

For most systems, the default method with a many-to-one mapping is sufficient. However, WAS does support custom principal and credential mapping configurations. Custom mapping modules can be added to the application logins JAAS configuration by creating a new JAAS login configuration with a unique name. For example, a custom mapping module can provide one-to-one mapping or Kerberos functionality.

Trusted connections also provide a one-to-one mapping while supporting client identity propagation. In addition by utilizing the DB2 trusted context object, trusted connections can take advantage of connection pooling to reduce the performance penalty of closing and reopening connections with a different identity. Using trusted connections also enhances the security of the DB2 database by eliminating the need to assign all privileges to a single user. The connection is established by a user whose credentials are trusted by the DB2 server to open the connection and the same user is also then trusted to assert the identity of the other users accessing the DB2 server from the application. A new mapping configuration called TrustedConnectionMapping has been created to implemented trusted connections.

We also can use the WAS admin console to bind the resource manager connection factory references to one of the configured resource factories. If the value of the res-auth element is Container within the deployment descriptor for the application, specify the mapping configuration. To specify the mapping configuration, use the Resource references link under References on the Applications > Application Types > WebSphere enterprise applications > myapp panel. See the topic, Mapping resource references to references, for additional directions.

 

J2C mapping modules and mapping properties

Mapping modules are special JAAS login modules that provide principal and credential mapping functionality. We can define and configure custom mapping modules using the admin console.

We also can define and pass context data to mapping modules by using login options in each JAAS login configuration. In WAS ND, you also can define context data using mapping properties on each connection factory reference binding.

Login options defined for each JAAS login configuration are shared among all resources that use the same JAAS login configuration and mapping modules. Mapping properties defined for each connection factory reference binding are used exclusively by that resource reference.

Consider a usage scenario where an external mapping service is used.

For example, we might use the TAM global sign-on (GSO) service. Use the TAM GSO to locate authentication data for both backend servers.

we have two EIS servers: DB2 and MQ. The authentication data for DB2 is different from that for MQ, however. Use the login option in a mapping JAAS login configuration to specify the parameters that are required to establish a connection to the TAM GSO service. Use the mapping properties in a connection factory reference binding to specify which EIS server requires the user ID and password.

For more detailed information about developing a mapping module, see the topic, J2C principal mapping modules.




 

Related concepts


Programmatic login for JAAS
Assembly tools

 

Related tasks


Mapping resource references to references

 

Related


J2C principal mapping modules

 

Related information


Trusted connections with DB2