Safeguard access to your enterprise data by designating credentials
that WebSphere Application Server uses to authenticate database connections.
Before you begin
Review the history and roles of the database tables in your environment;
this information helps you determine the best approach for securing each table.
You can either rely on the default authentication mechanism of a user profile,
or override it by configuring a security scheme for the individual application
component that requires access to the database. Generally, consider overriding
the default profile security if your database tables were created prior to
the Application Server installation, or if programs outside of Application
Server also access the tables.
About this task
To authenticate database connections with user profile credentials,
use an existing profile from any of three scopes in your application serving
environment. Otherwise, consult the following Application component authentication
table for methods of overriding user profile settings.
Procedure
- System-level scope option: Change the default user profile
of WebSphere Application Server to an existing profile in your i5/OS system
that has authority to access the database tables.
- WebSphere Application Server instance scope option: Add
authority for accessing the tables to the default Application Server user
profile.
- Individual application server scope option: If you designated
a user profile for an individual application server that is different from
the profile of the entire WebSphere Application Server instance, add database
authority to that new user profile.
For database tables that
are created by WebSphere Application Server and are used only within the Application
Server environment, you generally do not need to change or override the default
security. You can simply add authority for accessing the database to the WebSphere
Application Server user profile.
- Overriding user profile credentials: In the following table,
locate the type of application component for which you need to create authentication
credentials. Choose a method from the Authentication strategies column.
Table 1. Application component authentication
Type of object that requires access to backend data |
The data is created by: |
Library |
Authentication strategies |
Servlet session |
WebSphere Application Server |
By default, QWAS6SN. Specify a different library by
editing the libraries custom property in the Session Manager persistence panel. |
By default, the user profile under which the application
server runs. Specify a different library by editing the libraries custom property
in the Session Manager persistence panel. |
Entity enterprise beans that use container managed persistence
(CMP) |
WebSphere Application Server or already exists |
User-defined |
By default, the user profile under which the application
server runs. Specify a different user profile by creating a JAAS alias for
the enterprise bean data source. See the "Creating
JAAS aliases" note that follows this table for more information. |
User-written data access code in servlets, session beans,
and entity beans with bean-managed persistence (BMP), which might use connection
pooling |
WebSphere Application Server, user code, or already
exists |
User-defined |
By default, the user profile under which the application
server runs. Specify a different user profile by modifying the user code to
explicitly use a user ID and password with the database connection. Alternatively,
you can create a JAAS alias for the data source that you configure for your
servlet or enterprise bean. See the "Creating
JAAS aliases" note that follows this table for more information. |
Creating JAAS aliases:
- Consult the Managing J2EE Connector Architecture authentication data entries article for instruction
on creating a JAAS alias.
- After following those steps, navigate to the relevant data source properties
page in the administrative console: Resources > Data sources > my_data_source.
- Designate the new JAAS credentials as the component-managed alias for
the data source.
- Restart the application server for the new security configuration to
take effect.
Hierarchy of authentication strategies: If
you use component-specific authentication, be aware that some
authentication strategies take precedence over others:
- Enterprise bean
- You can specify a data source for the enterprise bean and create a JAAS
alias for association with that data source. The user ID and password properties
of the alias control which user ID can access the tables that are defined
by the data source. The JAAS alias that you associate with the enterprise
bean data source takes precedence over both the application server user ID
and the ID of the EJB container data source. If you specify a data source
for the enterprise bean but do not specify a JAAS alias for it, your i5/OS
system uses the application server ID. The application server ID is the default,
regardless of whether you specified a data source for the EJB container.
- EJB container
- You can specify a data source for the EJB container and create a JAAS
alias for association with that data source. The user ID and password properties
of the alias control which user ID can access the tables that are defined
by the data source. The JAAS alias that you associate with the EJB container
data source takes precedence over the application server user ID. However,
if you do not specify a JAAS alias for the EJB container data source, your
i5/OS system uses the application server ID to authenticate access to the
database tables.
- Application server
- The application server runs under the user ID that is specified in the
USER ID property for the application server. Any database tables that are
accessed should allow access to the specified user ID. By default, the application
server runs under the QEJBSVR user profile. Therefore, the database tables
must allow access to the QEJBSVR user profile.