[jira] [Commented] (QPID-6986) Management: Users should not be able to view an object to which they have no access

["Keith Wall (JIRA)" <ji...@apache.org>]

    [ 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org