4.7.  Configure auditing.

[Note]

Auditing

WebSphere Application Server V7.0 introduces a new feature as part of its security infrastructure: the security auditing subsystem.

Security auditing has two primary goals:

Security auditing achieves these goals by providing the infrastructure that allows you to implement your code to capture and store supported auditable security events. During run time, all code (except the Java EE 5 application code) is considered to be trusted. Each time a Java EE 5 application accesses a secured resource, any internal application server process with an audit point included can be recorded as an auditable event.

If compliance with regulatory laws or organizational policies have to be proved, you can enable auditing and configure filters to log the events you are interested in according to your needs.

The security auditing subsystem has the ability to capture the following types of auditable events:

These events are recorded in signed and encrypted audit log files in order to ensure its integrity. Encryption and signing of audit logs are not set by default, though we suggest its use to protect those records from being altered. You will have to add keystores and certificates for encryption and signing.

Log files can be read with the audit reader, a tool that is included in WebSphere Application Server V7.0 in the form of a wsadmin.sh command. For example, the following wsadmin.sh command line returns a basic audit report:

AdminTask.binaryAuditLogReader('[-fileName myFileName -reportMode basic 
-keyStorePassword password123 -outputLocation /binaryLogs]')
					

WebSphere Application Server provides a default audit service provider and event factory, but you can change them if you have special needs. For instance, you could configure a third-party audit service provider to record the generated events to a different repository.

Professional hosting         Free 'Oracle Certified Expert Web Services Developer 6' Guide     Free SCDJWS 5.0 Guide