(The following is somewhat vague as my goal is to describe a problem and some considerations when resolving it, and not so much to specify the solution.)

The management RBAC architecture is based on a caller identity being associated with a thread seeking to access management resources, with a mapping of that identity to one of the RBAC roles. Authorization decisions are then based on the roles. The establishment of the caller identity is handled by the authentication logic associated with the various remote endpoints available to users. The authentication is not a direct concern of the RBAC system itself.

A thread with no associated caller identity receives no RBAC permissions. It doesn't, for example, get mapped to the Monitor role, the one with the least permissions.

However, a potential type of "RBAC user" is some sort of administrative agent running within the JVM process itself, and not doing its work in the context of a thread handling some external request. An example of such a thing would be a Java Agent, e.g. Dynatrace, which uses JMX APIs to access metrics exposed by management resources. Threads executing tasks for such an agent will have no associated caller and thus will receive no role. They cannot access MBeans in the jboss.as domain when the 'rbac' RBAC provider is enabled.

The task here is to consider how to identify such threads and provide configuration options such that WildFly administrators can map them to an RBAC role.

I haven't thought hard, but it's not clear to me how to identify such a thread, beyond trying to enumerate characteristics of threads coming via remote endpoints and disallowing their use. For sure threads handling calls coming via remote endpoints that we know are used for management must not be given a role.

A possibility is to use a ThreadGroup name, but this doesn't seem very robust, and risks users coming to treat the names of internal WildFly thread pools as a kind of API.

An assumption here is that we are operating in a post-SecurityManager world where any code running within the server process, including deployments, must be regarded as "trusted code", i.e. we're not trying to guard against malicious deployments, malicious agents, malicious extensions etc. We do however want to have safeguards in place that help prevent users carelessly bypassing RBAC. For example users can configure a server to allow deployment code to access jboss.as MBeans on behalf of the deployment's callers, and not via separate the management endpoint used for remote JMX clients. There's value in requiring that kind of configuration, as it forces the user to consider what they are doing.