A Guide to Password use in WebSphere Application Server

Abstract

Nearly every WebSphere administrator has desired a deeper understanding of how passwords are created, used, stored, and encrypted. Learn about the different types of passwords used inside of the WebSphere Application Server and the recovery plans to help restore your server when passwords go awry.

Sample

We've all been there-sitting at the login screen of the WebSphere® Integrated Solutions Console, trying to remember the password that was used when the product was installed last year. Or perhaps the certificate we've been using has just expired and the system is down. If you could just figure out where you stashed the keystore password, you could get your e-commerce site back up and running.

Whatever the scenario might be, nearly every WebSphere administrator has been in a position to desire a deeper understanding of how passwords are created, used, stored, and encrypted. In this paper, I'll go over the different types of passwords used inside of the WebSphere Application Server (WAS) and suggest recovery plans to help restore your server when passwords go awry.

Passwords are a necessary component of a secure IT system, but they can also be very challenging to manage. Lost, forgotten or poorly documented passwords are a very commonplace occurrence, but their frequency with which this problem occurs doesn't make it any less frustrating, time consuming or difficult to resolve.

The aim of this paper is to give the reader some background about WAS passwords and how they work as well as to share some tips that are likely to be helpful in getting a WebSphere system up and running again if there is a password snafu.

This paper contains an overview of each of the four types of passwords used in a WAS. However, before password troubleshooting can start, the user will have to determine whether their installation of WAS is even configured to use passwords, so let's start there.

Determining Whether Security is Enabled on a WAS

First things first. Back in the good ol' days (pre WebSphere v6.0), WAS was commonly configured to allow administrators to log in without a password. Now, times have changed. Although newer versions of WAS can be configured to run in a security disabled mode, that is certainly not a recommended configuration in this day and age. When running in the security disabled mode, administrative access to the server only requires a user name with no password. Therefore, any security for the application has to be enforced by the application itself. When running in security disabled mode, there is no access control to prevent unauthorized users from accessing the system. In order to prevent such a scenario, WAS should be configured in the security enabled mode whenever possible.

However, running WAS in the security enabled mode adds layers of complexity to its use. Configuring the security enabled mode will necessitate the creation of a primary admin account and, after security is enabled, accessing the console will require both a valid username and a password.

You can determine which security mode (enabled or disabled) is running on your server by checking security XML that can be found at WebSphere profile directory, in the config/cells//security.xml.

Once you enable security on your WAS, you can start defining users and passwords to access the system.

There are four primary types of passwords:

• Admin
• Java Authentication and Authorization Service (JAAS)
• User
• Keystore

Each type of password has its own management considerations. We can split these four passwords into two broad categories:

• Passwords that use one-way encryption (user and admin)
• Passwords that use two-way encryption (JAAS and keystore)