[
https://issues.redhat.com/browse/DROOLS-1003?page=com.atlassian.jira.plug...
]
David Ward commented on DROOLS-1003:
------------------------------------
Hi [~tkobayashi], I think this issue is low priority now, and I will update this Jira
accordingly. Most people who use the kieserver do so using REST, not JMS. And if they are
using JMS, it is almost always internal to a cluster and not exposed externally anyways.
Last, I believe security roles have changed between 6 and 7, so this might not even be an
issue anymore, but further investigation would have to be done to make sure.
incongruous security granularity in kie-server
----------------------------------------------
Key: DROOLS-1003
URL:
https://issues.redhat.com/browse/DROOLS-1003
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 6.3.0.Final
Reporter: David Ward
Assignee: Toshiya Kobayashi
Priority: Major
Attachments: web.xml
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-serve...
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.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)