Per discussions, targeted 10.2 Backlog

• Proposed milestone: 10.2 (May)

Patch to address this problem (now stores information in signed audit log).
20140725-Remove-ACL-mapping-to-user-from-error-messages.patch

Test procedure to verify attached patch
965-test-procedure

cfu@redhat.com posted the following comments:
Here are my review comments per discussion:

• The exception message with less detail looks fine
• First thing I noticed is that the "signed audit" messages don't conform to the format. Looking closely, I see that you have picked up an outdated interface. The real signed auditor is supposed to be called by doing:
  IAuditor auditor = CMS.getAuditor();
  The authz fail event is supposed to be LOGGING_SIGNED_AUDIT_AUTHZ_FAIL_4
  and the call is done as:
  auditMessage = CMS.getLogMessage(
  LOGGING_SIGNED_AUDIT_AUTHZ_FAIL,
  auditSubjectID,
  ILogger.FAILURE,
  auditACLResource,
  auditOperation);
  audit(auditMessage); where audit is resolved to auditor.log(auditMessage);
  See AdminServlet.java for example.

Anyway, all the CS servlets do auditing that way, and so the REST interface should do it the same way. So, instead of adding audit messages in the authorization modules, I suggest you
1. put the message in debug log instead
2. If it does not exist, file a ticket for REST interface to do signed auditing

Replying to [comment:9 mharmsen]:

cfu@redhat.com posted the following comments:
Here are my review comments per discussion:

• The exception message with less detail looks fine
• First thing I noticed is that the "signed audit" messages don't conform to the format. Looking closely, I see that you have picked up an outdated interface. The real signed auditor is supposed to be called by doing:
  IAuditor auditor = CMS.getAuditor();
  The authz fail event is supposed to be LOGGING_SIGNED_AUDIT_AUTHZ_FAIL_4
  and the call is done as:
  auditMessage = CMS.getLogMessage(
  LOGGING_SIGNED_AUDIT_AUTHZ_FAIL,
  auditSubjectID,
  ILogger.FAILURE,
  auditACLResource,
  auditOperation);
  audit(auditMessage); where audit is resolved to auditor.log(auditMessage);
  See AdminServlet.java for example.

Anyway, all the CS servlets do auditing that way, and so the REST interface should do it the same way. So, instead of adding audit messages in the authorization modules, I suggest you
1. put the message in debug log instead
2. If it does not exist, file a ticket for REST interface to do signed auditing

In response, I filed the following new Dogtag ticket:

• PKI TRAC Ticket #1082 - Integrate Signed Audit Framework into the REST Interface

and attached a new patch which logs the messages to the 'system' log rather than the 'Signed Audit' log.

Patch to address this problem (now stores information in 'system' log). Replaces patch https://fedorahosted.org/pki/attachment/ticket/965/20140725-Remove-ACL-mapping-to-user-from-error-messages.patch 20140725-Remove-ACL-mapping-to-user-from-error-messages.patch]
20140728-Remove-ACL-mapping-to-user-from-error-messages.patch

Testing this revised patch yielded:

# pki -d . -c <password> -n "PKI Administrator for example.com" user-find
ForbiddenException: Authorization Error

# tail -f /var/log/pki/pki-tomcat/ca/system
0.http-bio-8443-exec-2 - [28/Jul/2014:14:43:06 PDT] [13] [6]  checkACLs():
permission denied
0.http-bio-8443-exec-2 - [28/Jul/2014:14:43:06 PDT] [13] [3] Authorization
Failed
0.http-bio-8443-exec-2 - [28/Jul/2014:14:43:06 PDT] [13] [3] Authorization
failed on resource: certServer.ca.users, operation: execute

and:

# pki -d . -c <password> -n "PKI Administrator for example.com" user-show caadmin

# tail -f /var/log/pki/pki-tomcat/ca/system
0.http-bio-8443-exec-8 - [28/Jul/2014:14:43:20 PDT] [13] [6]  checkACLs():
permission denied
0.http-bio-8443-exec-8 - [28/Jul/2014:14:43:20 PDT] [13] [3] Authorization
Failed
0.http-bio-8443-exec-8 - [28/Jul/2014:14:43:20 PDT] [13] [3] Authorization
failed on resource: certServer.ca.users, operation: execute

Checked into 'master':

• 7883dc39b639b825e7b6aeb6cce75878fc1d3e63

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/1531

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.