Integrate IBM WAS security with existing security systems
Terms
A list of terms used in this discussion follows:
- Protocol firewall
- Prevents unauthorized access from the Internet to the demilitarized zone. The role of this node is to provide the Internet traffic access only on certain ports and to block other IP ports.
Note: Firewalls can be used to create demilitarized zones, which serve as machines that are isolated from both the public Internet and other machines in the configuration. This improves portal security, especially for sensitive back-end resources such as databases.
- WAS plug-in
- Redirects all the requests for servlets and JSP pages. Also referred to in WAS literature as the Web server redirector, it was introduced to separate the Web server from the application server. The advantage of using Web server redirector is that we can move an application server and all the application business logic behind the domain firewall.
- Domain firewall
- Prevents unauthorized access from the demilitarized zone to an internal network. The role of this firewall is to allow the network traffic originating from the demilitarized zone and not from the Internet.
- Directory
- Provides information about the users and their rights in the application. The information can contain user IDs, passwords, certificates, access groups, and so forth. This node supplies the information to the security services like authentication and authorization service.
- Enterprise information system
- Represents existing enterprise applications and business data in back-end databases.
The Web server plug-in
WAS provides the infrastructure to run application logic and communicate with the internal back-end systems and database that web applications and enterprise beans can access. WAS has a built in HTTPS server that can accept client requests. A typical configuration, however, places WAS behind the domain firewall for better protection. A WAS plug-in to the Web server configuration can redirect Web requests to WAS. WAS provides plug-ins for many popular Web servers.
One can configure WAS and the Web server plug-in to communicate through secure SSL channels. One can configure a WAS HTTP server to open communication channels only with a restricted set of Web server plug-ins.
We can configure the HTTP server to require client certificate authentication with self-signed certificates and to trust only the signer certificate.
The WAS plug-in routes HTTP requests according to the virtual host and port configuration and URL pattern matching. Client authentication and finer grained access control are handled by WAS behind the firewall.
Tivoli WebSEAL
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.
User registry implementations
WAS supports various user registry implementations through the pluggable user registry interface.
WAS ships a Local OS user registry implementation for Windows, AIX, AS/400, and LDAP.
WAS 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, WAS can share the user registry with the third-party security provider. In the particular example of integrating with WebSEAL, one can configure WAS to use the LDAP user registry, which can be shared with WebSEAL and Tivoli Access Manager. Moreover, one can configure WAS to use the 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 WAS, and the RPSS can assert client identity to WAS to achieve single signon (SSO) between RPSS and WAS. When the request is forwarded to WAS, WAS uses the TAI plug-in for the particular RPSS server to evaluate the trust relationship and to extract the authenticated client identity. WAS then maps the client identity to a WAS security credential.
When configured to use the LDAP user registry, WAS uses LDAP to perform authentication. The client ID and password are passed from WAS to the LDAP server. One can configure WAS to set up an SSL connection to LDAP so that passwords are in the clear.
J2EE Connector Architecture (J2CA)
WAS supports the J2EE Connector Architecture (J2CA or JCA), which defines a standard interface for WAS to connect to heterogeneous enterprise information system.
Examples of enterprise information systems include database systems, transaction processing (such as CICS), and messaging (such as Message Queue (MQ)). The enterprise information system implementation (environments, servers and monitors) can perform authentication and access control to protect business data and resources. Resource Adapters authenticate enterprise information system. The authentication data can be provided either by application code or by WAS. WAS 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 enterprise information system security domain). WAS 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.
Mapping modules
A principal mapping module is a special purpose JAAS login module. We can develop your own principal mapping module to fit your particular business application environment.
WebSphere MQ series
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:
- -rw-rw-rw- /var/mqm/errors/AMQERR01.LOG
- -rw-rw-rw- /var/mqm/errors/AMQERR02.LOG
- -rw-rw-rw- /var/mqm/errors/AMQERR03.LOG
The previously mentioned files are world-writeable and enable any users on the system to fill up the /var file system where all the security logging information is stored. This leaves the security information unprotected because anyone can access the logging information without being tracked.
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 WAS on UNIX platforms, consider creating and mounting a 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:
- Maximum number of messages in the system at one time
- Contingency for message buildups, if there is a system problem
- Average size of the message data, plus 500 bytes for the message header
- Number of queues
- Size of log files and error messages
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).
See also
Interoperability issues for security
Interoperating with a C++ common object request broker architecture client
Interoperating with previous product versions
Security: Resources for learning
Trust associations
Configure IBM HTTP Server for Secure Sockets Layer mutual authentication
Configure the Web server plug-in for Secure Sockets Layer
Configure Secure Sockets Layer
Configure trust association interceptors
Configure Lightweight Third Party Authentication
Configure single signon
Configure user registries
Configure Lightweight Directory Access Protocol user registries
Configure Lightweight Directory Access Protocol search filters
Develop custom user registries
Configure custom user registries
Migrate custom user registries
Develop your own J2C principal mapping module
Configure application logins for Java Authentication and Authorization Service
See Also
Supported directory services
Custom user registries