[
https://issues.apache.org/jira/browse/QPID-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241114#comment-15241114
]
Keith Wall commented on QPID-6986:
----------------------------------
The scope of this change to introduce the authoriseRead hook into ACO and wire
up to the existing security manager. The existing ACL rules are not
sufficient rich to capture read permission for all objects, but we have
BROKER/VIRTUALHOST and ACCESS which will be sufficient to allow users that are
restricted to viewing a single virtualhost a possibility.
For connections, the read authorisation check needs to be made against the
virtualhost, once the connection is associated.
For other objects such as queue, exchange etc the read authorisation change
needs to be made against the virtualhost.
Should ACO#getAttribute/getActualAttributes/getStatistics(?) can the control
point that calls out to authoriseRead? KW thinks getter themselves should not
call out to the authoriseRead method.
What should the behaviour be if I am denied read to one virtualhost and I query
Broker and children? Do I see a partial response or do I get a 403.
> Management: Users should not be able to view an object to which they have no
> access
> -----------------------------------------------------------------------------------
>
> Key: QPID-6986
> URL: https://issues.apache.org/jira/browse/QPID-6986
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> In a managed service scenario, a single Broker may hosts applications
> belonging to different groups. For management purposes, an operator needs
> to be able to enter the management console and check on queues, messages,
> exchanges etc of his application.
> However, the Broker should have the ability to restrict an operator from
> viewing the objects of a virtual host to which he has no access permission.
> Currently the Broker enforces CRUD permissions on all objects in the
> hierarchy, but this does not impose restrictions on *view*.
> The view restriction needs to apply to the Web Management Console and the
> REST-API.
> An interesting case is Connections. Connections are children on a Port but
> become associated with a Virtualhost. A management user with access
> permission a virtual host needs to be able to see the connections associated
> with that virtual host, even if he doesn't have permission to view the Broker
> or Port directly.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
