"Rejecting" the PR to get this issue in the correct state, as JIRA picked up the proposal PR, which is not the fix PR.

I would add, that we need to be careful about the performance hit here. This should be off by default.

FYI how audit logging fits in with Elytron is still something we need to work though but +1 on something common, and +1 on appropriate separation.

The management audit log needs to be clearly distinguished from other forms of logging in order to support the RBAC requirement that operations against its management resources can be limited to users in the Auditor role.

This doesn't mean the way it is configured is set in stone. It does mean though that the definition of the resources must be distinct from those of other logging resources, at least to the extent that the definition includes necessary information to identify the resource as being related to management audit logging. Currently what resource patterns are related to management audit logging is hard coded in the RBAC impl.

Just adding my same comment here as this would likely be looked at first when the work starts.

One thing we should start to consider is where/how these will be configured. Currently management access logs are configured under /core-service=management/access=audit and web access logging is configured under /subsystem=undertow/server=default-server/host=default-host/setting=access-log. The resources also have different models, log to different locations, etc. We should consider whether there should be a central place these can be configured or not.

To follow up on that too there is currently a log viewer that can view the plain text versions of only the logs defined on the logging subsystem. There has been some discussion around providing a better log viewer which can filter data resulting in requiring some kind of structured data. I assume there will be users wanting to view all these logs through the log viewer. Especially in a containerized environment. It really does seem we need to move to some kind of global solution.

We should also consider users attempting to use log aggregation like loggly or the ELK stack. Having to make configuration changes in several places if you want to push logs somewhere isn't really ideal.