4.2 Securing the console

WAS provides the ability to secure the console so only authenticated users can use it. Note that enabling administrative security does not enable application security.

With V6.1, you can enable administrative security during installation and profile creation. If you do this on distributed systems, you will automatically get a file-based user registry populated with an administrative user ID of your choosing. This registry can later be federated with the registry you choose for application security. On z/OS platforms, you will have the option of using the file-based registry or the z/OS system's SAF-compliant security database.

You can enable administrative security after profile creation through the console by navigating to Security  | Secure administration, applications, and infrastructure. Doing this allows you more flexibility in specifying security options.

Before enabling any type of security, you will need to complete the configuration items for authentication, authorization, and realm (user registry). You will also need to populate the chosen user registry with at least one user ID to be used as an administrator ID.

Figure 4-13 Enabling administrative security

Attention: Beware that when you check the box to enable administrative security, the application security and Java 2 security check boxes are enabled automatically. If you are not prepared to use Java 2 or application security at this time, be sure to uncheck the boxes.

Administrative security is based on identifying users or groups that are defined in the active user registry and assigning roles to each of those users. When you log in to the console, use a valid administrator user ID and password. The role of the user ID determines the administrative actions the user can perform.

Fine-grained administrative security (new): In releases prior to WAS V6.1, users granted administrative roles could administer all of the resource instances under the cell. With V6.1, administrative roles are now per resource instance rather than to the entire cell. Resources that require the same privileges are placed in a group called the authorization group. Users can be granted access to the authorization group by assigning to them the required administrative role within the group. A cell-wide authorization group for backward compatibility: Users assigned to administrative roles in the cell-wide authorization group can still access all of the resources within the cell.

The administrator role has operator permissions, configurator permissions, and the permission required to access sensitive data, including server password, LTPA (LTPA) password and keys, and so on.

The configurator role has monitor permissions and can change the WAS configuration.

The operator role has monitor permissions and can change the run time state. For example, the operator can start or stop services.

The monitor role has the least permissions. This role primarily confines the user to viewing the WAS configuration and current state.

The deployer role is only available for wsadmin users, not for console users. Users granted this role can perform both configuration actions and run time operations on applications.

The AdminSecurityManager role is only available for wsadmin users, not for console users. When using wsadmin, users granted this role can map users to administrative roles. When fine grained administrative security is used, users granted this role can manage authorization groups.

The iscadmins role has administrator privileges for managing users and groups from within the console only.

Role assignments are managed through the console. Navigate to Users and groups  | Administrative User Roles or Users and groups  | Administrative Group Roles.

If you are using a file-based repository, you can add users and groups through the console by navigating to Users and groups  | Manage Users or Users and groups  | Manage Groups.

After saving the configuration, restart the appserver in a stand-alone server environment or the deployment manager in a distributed server environment.

The next time you log in to the console, authenticate with one of the users that were identified as having an administrative role. Entering commands from a command window will also prompt you for a user ID and password.