WebSphere Security, WebSphere and Firewalls

WebSphere Security

By default, WebSphere is installed with its built-in security features disabled. You can configure and control WAS without authentication - and so can anyone else with access to the administration console or host system. WebSphere Security is a complex topic; you must read the Infocenter, the Security Redbook, and all related documents carefully before enabling it. Here is an overview of the subject.

Once enabled, WAS Security encrypts some connections in cells using SSL and limits administrative access to defined username/password combinations authenticated against a defined registry. It can also be leveraged by applications for user access control and authentication, and internal security.

WebSphere is installed with a default ("dummy") set of SSL certificates and keys. Ideally, these should be replaced with a new set generated with IBM's ikeyman utility before enabling Security. The certificate sets have to be installed on each node in a cell and any Web servers that use the HTTP Plugin to communicate with the cell.

WebSphere can use either the local OS password file, an LDAP server, or a custom registry to retrieve authentication details. Sample code is provided for a file-based custom registry, but IBM doesn't recommend using it in a production deployment.
WAS ND can only use LDAP or a custom registry for authentication. All nodes in the cell have to be able to access the registry.
WebSphere doesn't support replicated LDAP servers (you can only specify a single LDAP server address). Any LDAP server you use has to have a transparent high-availability mechanism.
Once Security is enabled, a user name and password must also be given as arguments when using wsadmin or the command scripts. If you write shell scripts around them to run unattended, you'll have to embed the user name and password details in them. Obviously, this makes such information less secure (although user actions can be restricted to one of four defined roles).
WebSphere products install with global file read permissions. However, many of the files within them should be protected from general user access, including the configuration repository (config/), the SSL key files (etc/), and possibly the logs (logs/). This means changing the default file permissions manually.
If the HTTP Plugin configuration file is automatically generated, it will include the URI for the administration console. You do not want this to be accessible on a production Web server. Copy and edit the file to remove it, and include an ACL rule on your Web servers blocking all external access to /admin/*.
It's worth considering whether careful firewalling and IP access controls that limit connections to a small defined set of addresses can effectively control administrative access without having to enable WAS Security with its attendant overheads and complexities. This is particularly true if your application uses its own authentication system rather than relying on WebSphere to provide security.

Minimum Security RecommendationThe following configuration enables the minimum amount of WAS Security, mainly to protect the administration functions, without significant overhead. It may not be sufficient for production environments.

Using the file-based custom registry example, create a flat file containing defined users for the Administrator and Operator roles. Use the former for the Administration Console and the latter for scripts that control WAS. Copy the file to all nodes in the cell and make sure that only the user ID under which WAS runs has read access. If you have an existing resilient LDAP infrastructure, you may want to use that instead.

Enable WAS Global Security and configure the registry details for the chosen method.
Run WAS processes under a non-root account with limited access rights and privileges. (See the Infocenter topic "Running the application server with a non-root user ID." This can also be done for the WAS ND Deployment Manager.)
Limit access to the WAS configuration, application, and log files using normal Unix file permissions and ownerships.

WebSphere and Firewalls

WebSphere Application Server on a single node is reasonably simple to firewall; just make sure that the Web server can reach the application server HTTP and HTTPS ports, and the application server can reach any backend services such as databases. Ideally production application servers and Web servers should be on separate, dedicated network segments in demilitarised zones (DMZs).
In a distributed cell with the deployment manager firewalled from the application nodes (which is recommended), a number of ports must be opened up between the two. Regrettably, this includes the default administration console port (9090), since it's shared with the filetransfer application that the application servers use to pull data. Hence you may still need WebSphere Security to protect the console (e.g., in the event of the application servers being compromised).

Table 1 shows the TCP ports that must be opened between node agents and the DMgr for management and initial node federation, together with the default port numbers following a standard installation. You should confirm the port assignments by examining the serverindex.xml files in the WAS configuration repository, or the details for each server in the administration console.

Additional ports may be required when WAS Security is enabled.