The KIE Server provides two endpoints: HTTP/REST and JMS. By default, there is a "kie-server" role that one must have to perform operations through either endpoint. But by having this role, you can do anything in a very coarse-grained fashion.

Luckily, the HTTP/REST endpoint can be modified by changing the kie-server.war/WEB-INF/web.xml, and adding/modifying the security constraints. For OpenShift purposes, this has been done to disallow creating and disposing containers, while still allowing for reading status and executing rules. This is because REST url-patterns can be filtered per various operations and also with different http-methods. (See attached web.xml for an example.)

However, the JMS endpoint has no such capability. There is only one request queue with appserver security on it on a coarse-grained level, and no way to filter the messages as can be done via the HTTP/REST endpoint.

I have an idea that might help? Clients invoke the server via serializing and sending in Command objects, and those objects themselves are fine-grained (they are named things like "CallContainerCommand" and "DisposeContainerCommand"). If the incoming messages could propagate some kind of property of who the caller was, then the server-side could do a isCallerInRole/isUserInRole to determine if that user is authorized to invoke that particular command before doing so. Just a brainstorming idea.

Here is an example of the server handling the commands:
https://github.com/droolsjbpm/droolsjbpm-integration/blob/6.2.x/kie-server-parent/kie-server-services/src/main/java/org/kie/server/services/impl/KieServerImpl.java#L53-L79

The desired goal would be that developers (like myself) would not have to edit the kie-server.war/WEB-INF/web.xml, and that the same level of security granularity would already be available out-of-the-box for both the HTTP/REST and JMS interfaces. All that would be left for us would be to grant users the appropriate roles.