[WAS_8.5_ADMIN_GUIDE] Administrative security roles

Administrative security roles

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 into the administrative console or issue administrative commands, you must use a valid administrator user ID and password. The role of the user ID determines the administrative actions that the user can perform.

Fine-grained administrative security

Prior to WebSphere Application Server V6.1, users granted administrative roles and administered all of the resource instances under the cell. Starting with Version 6.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 exists for backward compatibility. Users who are assigned to administrative roles in the cell-wide authorization group can still access all of the resources within the cell.

The following administrative security roles are available:

Assigning administrative roles to users and groups

If you are using a file-based repository, you can add users and groups through the console by clicking Users and Groups > Manage Users or Users and Groups > Manage Groups. Otherwise, the users and groups must be added to the user registry using the tools provided by the registry product.

Role assignments for users and groups are managed through the administrative console. Click Users and Groups > Administrative user roles or Users and groups > Administrative group roles. Use these windows to assign an administrative role to a user or group.

Fine-grained security

WebSphere Application Server administrative security is fine-grained, meaning that access can be granted to each user per resource instance. For example, users can be granted configurator access to a specific instance of a resource (an application, an application server, or a node). The administrative roles are assigned per resource instance rather than to the entire cell.

To achieve the instance-based security or fine-grained security, resources that require the same privileges are placed in a group called the administrative authorization group or authorization group. Users can be granted access to the authorization group by assigning to them the required administrative role.

You can define groups of resources that are treated collectively by clicking Security > Administrative Authorization Groups.

Figure 5.6. Administrative Authorization Groups

The resource instances that are added to an authorization group can be the following types:

Figure 5.7. New Administrative Authorization Groups

After the authorization group is created, you can assign users or groups an administrative role for the authorization group.

Many administrative console pages have a preference setting that allows you to restrict the items that you can see to those that are valid for your authorization group level. The roles that you can choose from depend on the role of the user ID that logged into the administrative console.

Auditing

The security auditing feature was new in WebSphere Application Server V7. With the audit service, WebSphere Application Server can log significant system and application events so you can later review these long-term logs.

Security auditing has the following primary goals:

During run time, all code (except the Java EE application code) is considered to be trusted. Each time a Java EE application accesses a secured resource, any internal application server process with an audit point included can be recorded as an auditable event.

WebSphere Application Server auditing works through event logging. All security-related events are filtered with an audit filter and an event outcome filter. The captured events, which go through both filters, are added to the audit log.

The security auditing subsystem can capture the following types of auditable events:

The different audit outcome filters are as follows:

After the administrator selects the filter types from these two lists, WebSphere Application Server creates a Cartesian product and sets the filter definition.

WebSphere Application Server has a built-in auditor administrative role. Only the administrators in the auditor role can change settings related to the audit subsystem and review the audit logs. By default, the primary administrative user is a member of the auditor administrative role, but this role can be removed from this user. You can create a separate auditor user role and user principal. Assign these roles to a security team member for WebSphere Application Server. With this approach, only appropriate users have access to the audit data, and the audit subsystem and console administrator users cannot tamper with the audit content.

A user in the auditor role is necessary in WebSphere Application Server V8.5 to set up, configure, run, and review the auditing subsystem. Fine-grained security for the auditor role is not implemented. The auditor has full authority to read and modify the configuration information that is associated with the security auditing subsystem. Also, the auditor role includes the monitor role for the administrative console.

You can enable the audit subsystem in the administrative console by clicking Security > Security auditing, or by using the wsadmin.sh interface.

Figure 5.8. Security auditing

The security audit log is added to the audit message log file, or it can send email to one or more addresses. The log message file is a text file, but it is not for human interpretation. The message log file is generated in the server log directory, by default in the profile_root/logs/server_name directory, with a name using the following pattern: BinaryAudit_cellName_nodeName_serverName.log

For example:

BinaryAudit_aNode01Cell_aNode01_server1.log
					

Consider the performance and storage needs of the audit subsystem. WebSphere Application Server V8.5 adds controls to handle conditions when the audit flat files become full.

The following extra settings are available:

You can encrypt the log file to avoid unauthorized read access. You can also sign the log file to block unauthorized write access. Encryption and signing are not enabled by default, but configuring them is a preferred practice. Encryption is managed by the auditor. The certificate that is used to encrypt the data records is managed within the audit subsystem and defined in the audit.xml file. Signing is managed by WebSphere Application Server. The certificate that is used to sign the data records is managed with WebSphere Application Server and is described in the security.xml file.

Default plug-in implementations are shipped with WebSphere Application Server V8.5 that capture and output the audit records to a binary audit log file. The security audit subsystem is built on the following plug-ins:

If you need logging infrastructure, you can implement your own solution by using the plug-in architecture or by installing a third-party solution.

The audit log is not displayed in the administration console. The logs can be read, if they are not encrypted, by using a text editor. However, these logs are not formatted for human interpretation. WebSphere Application Server V8.5.5 has an audit reader utility that reads the audit message log file and generates an HTML report. You can start this utility by using a wsadmin.sh command.

The following Jython administrative script sample generates a basic audit report as shown in figure below:

AdminTask.binaryLogReader('[-fileName myFileName -reportMode basic -outputLocation /binaryLogs.html]')
					

Figure 5.9. Audit utility report