Securing Middleware Management

So, having got this far into the discussion of middleware management for WebSphere, you may have started to wonder how you will protect yourself from the power offered through the administration facility. WebSphere employs the J2EE roles-based security model, along with standard WebSphere authentication mechanisms to protect the middleware. Remember that the Admin UI is a web application. As such, the Admin UI is subject to standard J2EE security policies. This same model is extended to the other admin clients as well – command-line, scripting, and programming clients are subject to the same security requirements.

All of the middleware management functions have been classified as either being monitoring functions, operations functions, or configuration functions. The management facility supports four permissions: Monitor, Operator, Configurator, and Administrator – the permission you must possess to use the corresponding function:

• Monitor
  You must be granted the Monitor permission to simply look at the configuration and state, or to query performance metrics information about the running system.

• Operator
  You must be granted the Operator permission to issue operational commands on the running system; for example, to start or stop an application server. The Operator permission implies the Monitor permission – in other words, if you are granted the Operator permission then you can also perform Monitor functions.

• Configurator
  You must be granted the Configurator permission to change the configuration of the system; for example, to create new application servers, change their attributes, or to install applications. The Configurator permission implies the Monitor permission.

• Administrator
  You must be granted the Administrator permission to both perform operations and change the configuration of the system. The Administrator permission implies both the Operator and Configurator (and by extension, Monitor) permissions.

If you want to control access to the management facility you must enable global security. If it is enabled, administrators are registered in the security system like any other authenticated user. You can then grant any user or group any of the four administration permissions through the admin UI.

Individual users can be granted permission under the Console Users selection and groups can be granted permission under the Console Groups selection of the System Administration task navigation:

If you have not already granted any permissions to the user, then you need to add that user to the Console Users group. You can then select the permissions that you want to grant that user. The user you define here must be a valid user in the user registry for the WebSphere realm:

Of course, once you've added the user you must be sure to save your changes. You can always go back later and change the permissions for a given user or group. Setting the permissions for a group is the same, done under the Console Groups selection.

You must already possess the Configurator or Administrator permission to grant permissions to other users, or yourself. By implication, you can downgrade your own permission to Operator or Monitor and thus lose the ability to grant permissions to other users. You should take care to ensure that at least one administrator always has the Administrator and/or Configurator authority or else you could lose the ability to grant, change, or deny anyone else authority to administer the system.

Again, none of this applies unless security is enabled. If it is not, you can grant permissions but they won't be enforced until you do enable security. Likewise, when the system is first configured, and security is enabled, everyone will be granted access to administer the system – until you define at least one administrator (or group) to the console users collection.

With security disabled, you will still be prompted to sign in a user ID when you start the Admin UI. The admin application uses this to correlate you to your workspace.