Why and when to perform this task
WebSphere Application Server plays an integral part of the multiple-tier enterprise computing framework. WebSphere Application Server adopts the open architecture paradigm and provides many plug-in points to integrate with enterprise software components to provide end-to-end security. WebSphere Application Server plug-in points are based on standard J2EE specifications wherever applicable. WebSphere Application Server is actively involved in various standard bodies to externalize and to standardize plug-in interfaces.
In the following
example, several typical multiple-tier enterprise network configurations are
discussed. In each case, various WebSphere Application Server plug-in points
are used to integrate with other business components. The discussion starts
with a basic multiple-tier enterprise network configuration:
A list of terms used in this discussion follows:
WebSphere Application Server provides the infrastructure to run application business logic and communicate with internal back-end systems and databases Web applications and enterprise beans can access. WebSphere Application Server has a built in HTTPS server that can accept client requests. A typical configuration, however, places WebSphere Application Server behind the domain firewall for better protection. A WebSphere Application Server plug-in to Web server configuration can redirect Web requests to WebSphere Application Server. WebSphere Application Server provides plug-ins for many popular Web servers.
You can configure WebSphere Application Server
and the Web server plug-in to communicate through secure SSL channels. You
can configure a WebSphere Application Server HTTP server to open communication
channels only with a restricted set of Web server plug-ins. You can configure
the HTTP server to require client certificate authentication with self-signed
certificates and to trust only the signer certificate. For
instructions on how to generate self-signed certificates and how to set up
secure communications channels between an HTTP server and the WebSphere Application
Server plug-in, refer to Configuring IHS plug-in and the Internal Web Server for SSL and Configuring
IHS for SSL Mutual Authentication.
The WebSphere Application Server plug-in routes HTTP requests according to the virtual host and port configuration and the URL pattern matching. Client authentication and finer grained access control are handled by WebSphere Application Server behind the firewall.
In cases where the Web server can contain sensitive data and direct access is not desirable, the following configuration uses Tivoli WebSEAL to shield a Web server from unauthorized requests. WebSEAL is a Reverse Proxy Security Server (RPSS) that uses Tivoli Access Manager to perform coarse-grained access control to filter out unauthorized requests before they reach the domain firewall. WebSEAL uses Tivoli Access Manager to perform access control as illustrated in the picture. WebSphere Application Server supports various user registry implementations through the pluggable user registry interface. WebSphere Application Server ships a Local OS user registry implementation for Windows, AIX, AS/400, and Lightweight Directory Access Protocol (LDAP).
WebSphere Application Server also supports users in developing their own custom registry and plug-in through the pluggable user registry interface. When integrated with a third party security provider, WebSphere Application Server can share the user registry with the third-party security provider. In the particular example of integrating with WebSEAL, you can configure WebSphere Application Server to use the LDAP user registry, which can be shared with WebSEAL and Tivoli Access Manager. Moreover, you can configure WebSphere Application Server to use the Light Weight Third Party (LTPA) authentication mechanism, which supports the Trust Association Interceptor plug-in point.
Basically, the RPSS performs
authentication and adds proper authentication data into the request header
and then redirects the request to Web server. A trust relationship is formed
between an RPSS and WebSphere Application Server, and the RPSS can assert
client identity to WebSphere Application Server to achieve single signon between
RPSS and WebSphere Application Server. When the request is forward to WebSphere
Application Server, WebSphere Application Server uses the TAI plug-in for
the particular RPSS server to evaluate the trust relationship and to extract
the authenticated client identity. WebSphere Application Server then maps
the client identity to a WebSphere Application Server security credential.
For instructions on setting up a trust association interceptor, refer to Trust associations, Configuring trust association interceptors.
When configured to use the LDAP user registry, WebSphere Application Server uses LDAP to perform authentication. The client ID and password are passed from WebSphere Application Server to the LDAP server. You can configure WebSphere Application Server to set up an SSL connection to LDAP so that passwords are not passed in plain text. To set up an SSL connection from WebSphere Application Server to the LDAP server, refer to Configuring SSL for the LDAP client. WebSphere Application Server Version 5 supports the J2EE Connector Architecture (J2CA or JCA can be used to abbreviate J2EE Connector Architecture, but this documentation will use J2CA). The connector architecture defines a standard interface for WebSphere Application Server to connect to heterogeneous enterprise information systems (EIS). Examples of EIS includes database systems, transaction processing such as CICS, and messaging such as Message Queue (MQ). The EIS implementation can perform authentication and access control to protect business data and resources. Resource Adapters authenticate EIS. The authentication data can be provided either by application code or by WebSphere Application Server. WebSphere Application Server provides a principal mapping plug-in point. A principal mapping module plug-in maps the authenticated client principal to a password credential, (that is, user ID and password, for the EIS security domain). WebSphere Application Server ships a default principal mapping module, which maps any authenticated client principal to a configured pair of user IDs and passwords.
Each connector can be configured to use a different set of IDs and passwords. For a description on how to configure J2CA principal mapping user IDs and passwords, refer to Managing J2C Authentication Data Entries. A principal mapping module is a special purpose Java Authentication and Authorization Service (JAAS) login module. You can develop your own principal mapping module to fit your particular business application environment. For detailed steps on developing and configuring a custom principal mapping module, refer to the articles, Developing your own Java 2 security mapping module underneath JAAS Programmatic Login and Managing Java Authentication and Authorization Service (JAAS) Login Configuration.
Security and WebSphere MQseries
It is important to note that security logging information on UNIX systems is not protected because of the world-writeable files in the /var file system of MQseries. MQseries ships the following files with its product:
To work around this problem, create a file system for the embedded messaging component working data on UNIX. Before you install the embedded messaging component of WebSphere Application Server on UNIX platforms, consider creating and mounting a journalized file system called /var/mqm. Use a partition strategy with a separate volume for the WebSphere MQ data. This means that other system activity is not affected if a large amount of WebSphere MQ work builds up.
To determine the size of the /var/mqm file system for a server installation, consider the following:
Allow 50MB as a minimum for a WebSphere MQ server. You need less space in the /var/mqm file system for a WebSphere MQ client (typically 15MB).