Java EE connector security
- Overview
- Application managed sign-on
- Container-managed sign-on
- J2C mapping modules and mapping properties
- Secure message delivery with inbound SecurityContext
Overview
The Java EE connector architecture connects J2EE applications to heterogeneous enterprise information systems (EIS) such as database, ERP, and mainframe transaction processing systems. EIS vendors provide resource adapters, which plug into a application servers, and provide connectivity between the EIS, the application server, and the enterprise application. J2EE applications must authenticate to the EIS to open a connection. Commonly supported authentication mechanisms include:
Authentication mechanisim Description BasicPassword User-password-based. Specific to an EIS Kerbv5 Kerberos v5
Applications can use application-managed or container-managed sign-on. The resource-ref element in the deployment descriptor describes a single connection factory reference binding. The res-auth element in a resource-ref element is either Application or Container. 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 application server supports a component-managed authentication alias to be specified on a resource. This authentication data is common to all references to the resource...
Resources | Resource Adapters | J2C connection factories | configuration_name | Use component-managed authentication alias
When res-auth=Application, the authentication data is taken from the following elements, in order:
- The user ID and password passed to the getConnection method
- The component-managed authentication alias in the connection factory or the data source
- 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 administrative console or using wsadmin.sh from custom properties.
(iSeries) Do not use the custom properties, which enable users to connect to the resources.
Container-managed sign-on
The user ID and password for the target enterprise information systems (EIS) can be supplied by the application server. The product provides container-managed sign-on functionality. The application server 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 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.
The product 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:
Global security > JAAS > 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 administrative 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.sh takes effect when any application is started or restarted for a given the application server 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 the product includes performance enhancements to this frequently used default mapping configuration. The product 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, the product 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 our 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 administrative 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 link:
Applications > Application Types > WebSphere enterprise applications > application_name > References > Resource references
See the topic Mapping resource references to references
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 administrative console.
We also can define and pass context data to mapping modules using login options in each JAAS login configuration. In the product, 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 that are 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 Security Access Manager global sign-on (GSO) service. Use the ISAM GSO to locate authentication data for both backend servers.
We have two EIS servers: DB2 and Q. 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 required to establish a connection to the ISAM 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.
- The mapping configuration at the connection factory has moved to the resource manager connection factory reference. The mapping login modules developed using WAS v5 JAAS callback types can be used by the resource manager connection factory reference, but the mapping login modules cannot take advantage of the custom mapping properties feature.
- Connection factory reference binding supports mapping properties, and passes those properties to mapping login modules by way of a new WSMappingPropertiesCallback callback. In addition, the WSMappingPropertiesCallback callback and the new WSManagedConnectionFactoryCallback callback are defined in the com.ibm.wsspi package. Use the new mapping login modules with the new callback types.
Secure message delivery with inbound SecurityContext
Security information can be supplied by an EIS resource adapter to the application server using security inflow context. The security inflow context mechanism enables the work manager to execute the actions of a Work instance under an established identity. Those actions include the delivery of messages to Java EE message endpoints that are processed as message-driven beans (MDB) under an identity configured in a security domain of the application server.
Security inflow context is only supported for JCA 1.6-compliant resource adapters. Currently, the product does not provide a built-in resource adapter that supports a security inflow context. Using inbound SecurityContext to secure message delivery requires a resource adapter that supports Java EE messaging and security inflow context.
Secure message delivery to a message endpoint requires that global security is enabled in the global security configuration. It also requires that application security is enabled on the application server that hosts the application providing the message endpoint MDB. For more information about global security, see the topic, "Global security settings".
The security policy of the application deployment descriptor must be configured with roles associated with user identities in the application realm, which is the user registry of the security domain that scopes to the application. This security configuration enables EJB security and authorizes specific user identities in the application realm to access MDB methods. For more information about security overview, see the topic, "Security".
Secure message delivery also requires the resource adapter to define implementations for both the WorkContextProvider and SecurityContext interfaces. To deliver a secure message, a resource adapter first submits a work instance that provides a SecurityContext implementation, which the work manager uses to establish the execution subject for that work instance.
While establishing the execution subject, a SecurityContext can provide implementations of Java Authentication Service Provider Interface for Containers (JASPIC) callbacks that the work manager uses to determine caller and group identities (CallerPrincipalCallback, GroupPrincipalCallback), and to authenticate the caller identity and password (PasswordValidationCallback). If the caller identity is in the application realm, then the work manager asserts that identity by constructing a WSSubject instance containing the caller principal, any group principals, and all private credentials.
Alternatively, the SecurityContext can provide an execution subject that is an instance of WSSubject instance created by another login or authentication module. The work manager accepts this WSSubject instance only when its caller principal is in the application realm or within a trusted realm. For more information about realms, see the topic, "Configuring inbound trusted realms for multiple security domains".
The work manager rejects a Work instance whenever it cannot establish a WSSubject instance. Otherwise, it dispatches the instance on a managed thread under the WSSubject instance that was either asserted or accepted. If the SecurityContext provides no caller identity, the Work instance dispatches under a WSSubject instance containing the unauthenticated caller principal.
When dispatched, a Work instance might attempt to deliver messages to the MDB of the secured application. All messages are delivered under the WSSubject instance established for the Work instance. The EJB security collaborator affords access to the onMessage method of the MDB whenever the caller principal of the WSSubject instance is associated with a role that is declared in the application deployment descriptor. Otherwise, the collaborator denies access and the message fails to deliver. During delivery, the MDB can use the EJB Context methods, isCallerInRole and getCallerPrincipal, to make additional access decisions, and the MDB might access other entities in the security domain for which the caller principal has authorization.
Related:
Programmatic login for JAAS Trusted connections with DB2 Development and assembly tools Security Mapping resource manager connection factory references to resource factories Configure inbound trusted realms for multiple security domains Global security settings J2C principal mapping modules