On Fri, 2013-08-30 at 12:37 -0400, Endi Sukma Dewata wrote:
----- 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
Comments 1, 3 and 4 are good questions that need to be discussed with
cfu, and will be addressed in further patches if needed.
Issue 2 has been addressed.
ACKed by Endi and pushed to master.
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