Audit logging features in WebSphere Portal 7

IBM WebSphere Portal provides an auditing feature that allows users to log certain events and their originators into a separate log file. This file can then be used to track administrative activities. For each event the timestamp, an optional transaction ID, the user performing the action, and individual event details are logged. If the user “ABC” is performing the action is being impersonated by another user “ XYZ”, the user is shown as [ABC [XYZ]] in the log file.

You can use the auditing function on the following events:

• Creating, modifying and deleting users and groups
• Creating, modifying and deleting portlet applications by using the portal user interface
• Assigning and revoking roles to and from users
• Modifying role blocks
• Modifying resource ownership
• Creating, modifying and deleting protected resources
• Externalizing and internalizing resources
• Installing and uninstalling Web modules
• Creating and deleting application roles
• Assigning and revoking application roles to and from users
• Adding and deleting roles to application roles
• Initializing a database domain
• Creating, modifying and deleting portlet applications by using IBM Lotus Component Designer.
• Starting and ending impersonating a user or impersonating a user without the appropriate permission

To activate and configure the auditing function, modify the auditing service settings in the Auditing Service using the steps provided in the Setting service configuration properties file.

Auditing Service:

The auditing service allows you to log a set of events into a separate audit log file. All events are organized in groups. For example, the logging events User created and User deleted are grouped together and can therefore only be switched on or off together. The section Available events lists and describes the events that are available for auditing.

The audit logging output is written to the audit log file. No other log messages are written to this file. For an explanation of the contents of the audit log file refer to the section Audit log file.

 Auditing service configuration:

By default the audit logging service is disabled. This means that the service is loaded, but does not register any event listeners for audit logging. The auditing service configuration is controlled by the AuditService.

audit.service.enable = (false)

This is the global switch. Use it to switch the service on (true) or off (false). The default setting is false.

The actual log file access of the service can be configured by using the following two properties:

audit.logging.class = com.ibm.wps.services.audit.logging.impl.AuditLoggingImpl

This property points to the logging class which writes the actual log statements to the log file. By default, this is set to the default implementation. Under normal circumstances there is no reason to replace it with another class.

audit.logFileName = log/audit_$create_time.log

This property defines the location and the name of the audit log file. The placeholder $create_time is replaced by a timestamp during filename generation. A second placeholder $APPSERVER_NAME is used for a vertical cluster configurations to make the log file name unique.

Example:

audit.logFileName = log/audit_$APPSERVER_NAME_$CREATE_TIME.log

The auditing service allows you to have the transaction ID written to the audit log file. As these IDs can be very long and might not be required in every environment, you can disable the inclusion of the IDs.

audit.showTransactionID.enable = (true)

Use this property to disable transaction IDs in the audit log. To do this, change the value to false. The default value is true.

You determine the events that you want to be logged by enabling the appropriate properties as required. Set the events that you want to enable to the value true. The following groups of events are defined:

                               audit.groupEvents.enable

                               audit.userEvents.enable

                               audit.portletEvents.enable

                               audit.roleEvents.enable

                               audit.roleBlockEvents.enable

                               audit.ownerEvents.enable

                               audit.resourceEvents.enable

                               audit.externalizationEvents.enable

                               audit.userInGroupEvents.enable

                               audit.webModuleEvents.enable

                               audit.applicationRoleEvents.enable

                               audit.principalToApplicationRoleMappingEvents.enable

                               audit.roleToApplicationRoleMappingEvents.enable

                               audit.domainAdminDataEvents.enable

                               audit.designerDeployServiceEvents.enable

                               audit.impersonationEvents.enable

 The default value for all of these settings is false. That means that no events will be logged by default, even if you have switched the service on by setting the property audit.service.enable to true. For more details about which events are included in each group refer to Available events .

To enable one or more groups of events, change the default value of the appropriate audit.eventGroup.enable property to true.

Audit log file:

The log file contains one audit log message per line. All log messages start with a timestamp, followed by the optional transaction ID, the message code and the event message. Each event message contains the following:

• The user ID of the user who has performed the action which triggered the audit event
• Additional information about the event itself.

Events for actions that run in a transaction are written to the log file when the transaction is committed. If the transaction is rolled back, no event messages are written to the log file.

Events for actions that do not run in a transaction are written to the log immediately. In such cases it is not guaranteed that the related action was completed successfully.

Available events:

This section lists the events that you can log by using the auditing service. They are listed by the groups in which they are available. If you enable one group, all events in that group are logged. listed by the groups in which they are available. If you enable one group, all events in that group are logged.

 

Audit logging group	Audit logging event	Meaning of the event
audit.groupEvents	Group created event	A new user group has been created via portal UIs.
	Group modified event	A user group has been modified via portal UIs.
	Group deleted event	A user group has been deleted via portal UIs.
audit.userEvents	Portlet Application created event	A new web module or portlet application has been created via portal UIs.
	Portlet Application modified event	A web module or portlet application has been modified via portal UIs.
	Portlet Application deleted event	A web module or portlet application has been deleted via portal UIs.
audit.portletEvents	Portlet Application created event	A new web module or portlet application has been created via portal UIs.
	Portlet Application modified event	A web module or portlet application has been modified via portal UIs.
	Portlet Application deleted event	A web module or portlet application has been deleted via portal UIs.
audit.roleEvents	Role assigned event	A portal role has been assigned to a user. The user has been given the specified type of access permission on all resources that are affected by this role. For example, this can be EDITOR on Page1.
	Role unassigned event	A portal role has been unassigned from a user. The user no longer has the specified access rights on the resources that are affected by this role. For example, the user is no longer EDITOR on Page1.
audit.roleBlockEvents	Role block modified event	The portal role block information of a resource has been changed. The event message contains a list of blocked and non-blocked roles on the given resource. As roles can either be inherited or propagated, there are two separate lists for inheriting roles and propagating roles. If only propagating role blocks have been changed, the list for inheriting roles is empty and vice versa.
audit.ownerEvents	Resource owner modified event	The owner of a resource has been changed.
audit.resourceEvents	Resource created event	A new resource has been registered. This event is triggered when the resource is registered in Portal Access Control.
	Resource modified event	A registered resource has been modified.
	Resource deleted event	A registered resource is no longer registered in Portal Access Control. This usually happens when a resource is deleted.
audit.externalizationEvents	Resource externalized event	A resource has been externalized. This means that access permissions to this resource are no longer controlled by Portal Access Control, but by an external Access Manager. For example, this can be Tivoli Access Manager.
	Resource internalized event	A resource has been internalized. It is now controlled by Portal Access Control and no longer by an external Access Manager.
audit.userInGroupEvents	User added to group event	A user has been added to a group. The user is now a member of this group and therefore inherits access rights from the group.
	User removed from group event	A user has been removed from a group. The user is no longer a member of that group and does no longer have the inherited access rights.
audit.webModuleEvents	Web Module installed event	A new web module has been installed or deployed.
	Web Module uninstalled event	An installed web module has been uninstalled.
audit.applicationRoleEvents	Application role created event	An application role has been created.
	Application role deleted event	An application role has been deleted.
audit.principalToApplication RoleMappingEvents	Application role assigned event	An application role has been assigned to a user. The user has been given the access permissions contained in all the roles that are aggregated in this application role.
	Application role unassigned event	An application role has been unassigned from a user. The user no longer has the access permissions contained in all the roles that are aggregated in this application role.
audit.roleToApplication RoleMappingEvents	Role added to application role event	A portal role has been added to an application role. All permissions contained in the portal role are added to the application role. Effective immediately, these added permissions are given to all users or groups to whom the application role is currently assigned.
	Role removed from application role event	A portal role has been removed from an application role. The users who had this application role no longer have the access permissions that are contained by this role.
audit.domainAdminData Events.enable	Domain administration data initialized event	The administrative data for a domain, such as administrative user, administrative group, and virtual root resource, has been initialized during the startup of the portal. For the lifetime of the current portal process, this user and group have administrative permissions on the domain resource hierarchy, starting from the virtual root resource. For details about this refer to the Access Control Data Management Service. This event is always thrown for each defined domain during server startup. As this is done by the system, no performing user will be logged.
audit.designerDeployService Events.enable	Component installed event	A portlet application has been created by using IBM Lotus Component Designer.
	Component modified event	A portlet application created by using IBM Lotus Component Designer has been modified.
	Component uninstalled event	A portlet application created by using IBM Lotus Component Designer has been deleted.
audit.impersonationEvents	Impersonation started event	A user started impersonation with another user.
	Impersonation ended event	A user ended impersonation with another user.
	Impersonation attempted with no permission event	A user tried to impersonate another user but has no permission.