----- Original Message -----
This patch adds audit logging to the profile interface. I used the
same
logging categories (scope, op, id, messages) as for the old interface.
More needs to be added - in particular, when an input, output or policy
is added, modified or removed, the details of the attributes in that
object should probably be logged, rather than just the id's.
I'll fix this in a subsequent patch.
A comprehensive review of the audit logs will likely be done when we do
common criteria testing.
Please review.
Ade
Some comments/questions:
1. Are we supposed to create an audit log for each invocation of the REST methods
regardless it passes/fails for any reasons? For example in
ProfileService.modifyProfileState() for action == "enable" there are possible
errors where the code would throw exception without creating an audit log (see lines 328,
333, 341). If the intention is to audit valid invocations only then this is probably ok.
But if the intention is to audit all invocations we probably should do something like
this:
try {
// do error checking, throw an exception if necessary
// perform the actual operation
audit(SUCCESS); // log success
} catch (Exception e) { // catch all exception
audit(FAILURE); // log failure
throw e; // throw the original exception
}
2. In ProfileService.java:361 assuming there's no error this would be a successful
operation but it's not logged.
3. The createProfile() creates an audit log, but then it will call changeProfileData()
which looks like will create additional audit logs. Does it matter if it creates multiple
audit logs for a single createProfile() invocation?
4. In populateProfileInputs() if it's a success the inputs are logged separately for
add, modify, and delete. If it's a failure they are combined into a single modify
failure log. Are we supposed to have a consistent number of logs in either case?
--
Endi S. Dewata