+

Search Tips   |   Advanced Search

Auditing Service

The Auditing Service allows us to log a set of events into a separate audit log file. The audit logging output is written to the audit log file. No other log messages are written to this file. All events are organized in groups. For example, the logging events...

  • User created
  • User deleted

...are grouped together and can therefore only be switched on or off together.

In the WAS console, the portal Auditing Service is listed as...

    WP AuditService


Auditing service configuration

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

    audit.service.enable = (false)

    Global switch. Switch the service on (true) or off (false). The default setting is false.

Log file access time of the service can be configured using...

    audit.logFileName = log/audit_$create_time.log

    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 us to have the transaction ID written to the audit log file. The project ID can also be written to the audit log file. As these IDs can be very long and might not be required in every environment, we can disable the inclusion of the IDs.

    audit.showTransactionID.enable = (true)

    Disable transaction IDs in the audit log. To do this, change the value to false. Default is true.

    audit.projects.enable = (true)

    Disable project IDs in the audit log. To do this, change the value to false. Default is true.

We determine the events to be logged by enabling the appropriate properties as required. Set the events 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
    audit.applicationRoleToApplicationRoleMappingEvents.enable
    audit.taggingEvents.enable
    audit.ratingEvents.enable
    audit.projectPublishEvents.enable
    audit.vanityURLEvents.enable

The default value for all of these properties is false. That means that no events will be logged by default, even if we 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 the section about Available events .

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


Available events

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

Audit logging group Audit logging event Meaning of the event
audit.groupEvents Group created New user group created via portal UIs.
Group modified A user group modified via portal UIs.
Group deleted A user group deleted via portal UIs.
audit.userEvents User created A new user created via portal UIs.
User modified A user modified via portal UIs.
User deleted A user deleted via portal UIs.
audit.portletEvents Portlet Application created A new web module or portlet application created via portal UIs.
Portlet Application modified A web module or portlet application modified via portal UIs.
Portlet Application deleted A web module or portlet application deleted via portal UIs.
audit.roleEvents Role assigned A portal role assigned to a user. The user 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 A portal role 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 The portal role block information of a resource 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 The owner of a resource changed.
audit.resourceEvents Resource created A new resource registered. This event is triggered when the resource is registered in Portal Access Control.
Resource modified A registered resource modified. This event is triggered if the resource is modified in Portal Access Control.
Resource deleted A registered resource is no longer registered in Portal Access Control. This usually happens when a resource is deleted.
audit.externalizationEvents Resource externalized A resource 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 A resource internalized. It is now controlled by Portal Access Control and no longer by an external Access Manager.
audit.userInGroupEvents User added to group A user added to a group. The user is now a member of this group and therefore inherits access rights from the group.
audit.userInGroupEvents User removed from group A user 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 started A new web module started.
Web Module stopped An installed web module stopped.
audit.applicationRoleEvents Application role created An application role created.
Application role deleted An application role deleted.
audit.principalToApplicationRoleMappingEvent Application role assigned An application role assigned to a user. The user given the access permissions contained in all the roles that are aggregated in this application role.
audit.principalToApplicationRoleMappingEvents Application role unassigned An application role 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.roleToApplicationRoleMappingEvents Role added to application role A portal role 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 A portal role removed from an application role. The users who had this application role no longer have the access permissions contained by this role.
audit.domainAdminDataEvents Domain administration data initialized The administrative data for a domain, such as administrative user, administrative group, and virtual root resource, 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.designerDeployServiceEvents Component installed A portlet application created using IBM Lotus Component Designer.
audit.designerDeployServiceEvents Component modified A portlet application created using IBM Lotus Component Designer modified.
Component uninstalled A portlet application created using IBM Lotus Component Designer deleted.
audit.impersonationEvents Impersonation started A user started impersonation with another user.
Impersonation ended A user ended impersonation with another user.
Impersonation attempted with no permission A user tried to impersonate another user but has no permission.
audit.applicationRoleToApplicationRoleMappingEvents Application role mapping created A user has created a mapping between an Application Role and another Application Role.
audit.applicationRoleToApplicationRoleMappingEvents Application role mapping deleted A user has deleted a mapping between an Application Role and another Application Role.
audit.vanityURLEvents Vanity URL created A user created a vanity URL.
Vanity URL modified A user modified a Vanity URL.
A user deleted a Vanity URL Vanity URL deleted A user deleted a Vanity URL.
audit.tagEvents Tag created A user created a tag.
audit.tagEvents Tag deleted A user deleted a tag.
audit.ratingEvents Rating created A user created a rating
Rating deleted A user deleted a rating.
audit.projectPublishEvents Project created A user created a project.
Project published A user published a project.
Project removed A user removed a project.


Audit log file

The audit 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 the related action was completed successfully.


Security auditing

One problem with the Auditing Service: No details of the user who tried to login/logout information is collected. Security auditing gathers the information specific to Authentication,Authorization, Principal/Credential Mapping, Audit policy management,Delegation. This method logs all login/logout event with complete information writing each event as a sequence. The events will have lot of useful information like which remote machine has tried accessing the URL and also, the IP of the same including the remote port number.

Global security must be enabled for the security audit subsystem to function, as no security auditing occurs if global security is not also enabled. We can configure event type filters to only record a specific subset of auditable event types in your audit logs. Filtering the event types that are recorded makes for easier analysis of audit records by ensuring only those records important to our environment are archived.

  • Trace strings - 1st option

    This is suggested in "http://www-01.ibm.com/support/docview.wss?uid=swg21592791 Collecting Data: Login for WebSphere Portal" link

      *=info:com.ibm.wps.engine.Servlet=all:com.ibm.wps.services.puma.*=all: com.ibm.wps.auth.*=all:com.ibm.wps.puma.*=all:com.ibm.wps.um.*=all: com.ibm.wps.sso.*=all:com.ibm.wps.services.authentication.*=all: com.ibm.ws.security.*=all:com.ibm.ws.wim.*=all: com.ibm.websphere.wim.*=all:com.ibm.wsspi.wim.*=all: com.ibm.wps.engine.phases.*=all

    If troubleshooting an impersonation issue, append the following string to the above trace:

      :com.ibm.wps.portletservice.impersonation.impl.*=all

    If using rule based user groups, append the following string to the above trace:

      :com.ibm.wps.vmm.adapter.*=all

  • Trace strings - 2nd option

      *=info: com.ibm.wps.auth.impl.LogoutDefaultFilter=all: com.ibm.wps.auth.impl.LoginDefaultFilter=all

Each option one provides different kind of information in the log when some security threat happens. One can decide to stick with only one type or combination of WAS audit log with setting Portal trace also to more information at that instance of time.


Parent Portal Access Control Services