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:
Administrator: The administrator role has operator permissions, configurator permissions, and the permission required to access sensitive data, including server password, Lightweight Third Party Authentication (LTPA) password and keys, and so on.
Auditor: The auditor role has permission to view and change the configuration settings for the security auditing subsystem.
Configurator: The configurator role has monitor permissions and can change the WebSphere Application Server configuration.
Operator: The operator role has monitor permissions and can change the runtime state, for example, the operator can start or stop services.
Monitor: The monitor role has the least permissions. This role primarily confines the user to viewing the WebSphere Application Server configuration and current state.
Deployer: The deployer role has permission to perform both configuration actions and runtime operations on applications.
Admin Security Manager: The Admin Security Manager role gives permissions to users to map other users to administrative roles. When fine-grained administrative security is used, users granted this role can manage authorization groups. A user mapped to the administrator role does not have permissions to map users to administrative roles.
ISC Admin: The ISC Admin role has administrator privileges for managing users and groups from within the administrative console only.
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.
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.
The resource instances that are added to an authorization group can be the following types:
Business level applications
Nodes including application servers and web servers
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.
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:
Confirming the effectiveness and integrity of the existing security configuration (accountability and compliance with policies and laws), most commonly by reviewing who did what operation.
Identifying areas where improvement to the security configuration might be needed (vulnerability analysis)
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:
Audit subsystem-related runtime events such as start and stop
Authentication termination (timeout, session termination, and logout)
Principal or credential mapping
Resource access (access to all file system, database, HTTP, and other resources)
Security subsystem-related runtime events
Signing and encryption
User credentials modification
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
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:
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:
WRAP The log file is written round-robin with the oldest file being overwritten.
NOWRAP The server is quiesced.
SILENT_FAIL Audit logging is stopped, but the server process continues.
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
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
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:
Audit Event Factory, which captures data
Audit Service Provider, which outputs the captured data to a back-end repository
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
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]')