You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org> on 2007/03/16 10:37:09 UTC
[jira] Created: (QPID-419) Introduce read-only and modify
authorisation for all objects in a virtual host
Introduce read-only and modify authorisation for all objects in a virtual host
------------------------------------------------------------------------------
Key: QPID-419
URL: https://issues.apache.org/jira/browse/QPID-419
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Affects Versions: M1, M2
Reporter: Marnie McCormack
Assigned To: Martin Ritchie
Fix For: M2
At present, any authenticated user can perform actions on all available objects e.g. queues, topics, etc
>From the management console, particularly, this introduces security risk since we can move messages, create queues etc from the console very simply.
To address this issue, initially, we need to introduce a simple two level permission model for all objects contained in a virtual host such that authenticated users have one of the two permissions:
- read-only i.e. can access but not change any object (i.e. cannot write to a queue but can see its contents)
- modify i.e. can amend the object (i.e. can move messages into/out of a queue, delete the queue etc)
Some detailed thought should be given to each object (queue, topic, message, connection) to define the set of applicable read-only/modify actions for each appropriately.
Bear in mind that the read-only permission is mainly driven at the management console since by definition most users connecting will require modify permissions to send/receive messages !
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (QPID-419) Introduce read-only and modify
authorisation for all objects in a virtual host
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie reopened QPID-419:
---------------------------------
Sorry, this currently only limits access to the Vhost not to queues with in that vhost.
To control publish :A access check would be required in <Exchange>.route()
To control consume : changes to BasicConsumer and BasicGet would be needed.
> Introduce read-only and modify authorisation for all objects in a virtual host
> ------------------------------------------------------------------------------
>
> Key: QPID-419
> URL: https://issues.apache.org/jira/browse/QPID-419
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Affects Versions: M1, M2
> Reporter: Marnie McCormack
> Assigned To: Martin Ritchie
> Fix For: M2
>
>
> At present, any authenticated user can perform actions on all available objects e.g. queues, topics, etc
> From the management console, particularly, this introduces security risk since we can move messages, create queues etc from the console very simply.
> To address this issue, initially, we need to introduce a simple two level permission model for all objects contained in a virtual host such that authenticated users have one of the two permissions:
> - read-only i.e. can access but not change any object (i.e. cannot write to a queue but can see its contents)
> - modify i.e. can amend the object (i.e. can move messages into/out of a queue, delete the queue etc)
> Some detailed thought should be given to each object (queue, topic, message, connection) to define the set of applicable read-only/modify actions for each appropriately.
> Bear in mind that the read-only permission is mainly driven at the management console since by definition most users connecting will require modify permissions to send/receive messages !
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (QPID-419) Introduce read-only and modify
authorisation for all objects in a virtual host
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack resolved QPID-419.
-----------------------------------
Resolution: Fixed
Resolving this JIRA (after discussion with Martin). Access control work covered by this JIRA now complete and in M2.
> Introduce read-only and modify authorisation for all objects in a virtual host
> ------------------------------------------------------------------------------
>
> Key: QPID-419
> URL: https://issues.apache.org/jira/browse/QPID-419
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Affects Versions: M1, M2
> Reporter: Marnie McCormack
> Assigned To: Martin Ritchie
> Fix For: M2
>
>
> At present, any authenticated user can perform actions on all available objects e.g. queues, topics, etc
> From the management console, particularly, this introduces security risk since we can move messages, create queues etc from the console very simply.
> To address this issue, initially, we need to introduce a simple two level permission model for all objects contained in a virtual host such that authenticated users have one of the two permissions:
> - read-only i.e. can access but not change any object (i.e. cannot write to a queue but can see its contents)
> - modify i.e. can amend the object (i.e. can move messages into/out of a queue, delete the queue etc)
> Some detailed thought should be given to each object (queue, topic, message, connection) to define the set of applicable read-only/modify actions for each appropriately.
> Bear in mind that the read-only permission is mainly driven at the management console since by definition most users connecting will require modify permissions to send/receive messages !
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (QPID-419) Introduce read-only and modify
authorisation for all objects in a virtual host
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie resolved QPID-419.
---------------------------------
Resolution: Fixed
Completed: At revision: 526117
To utilise add this Access Manger to your Vhost security section
<access>
<class>org.apache.qpid.server.security.access.FileAccessManager</class>
<attributes>
<attribute>
<name>accessFile</name>
<value>${conf}/access</value>
</attribute>
</attributes>
</access>
The access file should be formated such as:
guest:localhost(rw),test(rw)
<user>:<vhost-access-entry>[,<vhost-access-entry>]*
<vhost-access-entry>=<vhost>(<rights>)
<rights>=[r][w]
> Introduce read-only and modify authorisation for all objects in a virtual host
> ------------------------------------------------------------------------------
>
> Key: QPID-419
> URL: https://issues.apache.org/jira/browse/QPID-419
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Affects Versions: M1, M2
> Reporter: Marnie McCormack
> Assigned To: Martin Ritchie
> Fix For: M2
>
>
> At present, any authenticated user can perform actions on all available objects e.g. queues, topics, etc
> From the management console, particularly, this introduces security risk since we can move messages, create queues etc from the console very simply.
> To address this issue, initially, we need to introduce a simple two level permission model for all objects contained in a virtual host such that authenticated users have one of the two permissions:
> - read-only i.e. can access but not change any object (i.e. cannot write to a queue but can see its contents)
> - modify i.e. can amend the object (i.e. can move messages into/out of a queue, delete the queue etc)
> Some detailed thought should be given to each object (queue, topic, message, connection) to define the set of applicable read-only/modify actions for each appropriately.
> Bear in mind that the read-only permission is mainly driven at the management console since by definition most users connecting will require modify permissions to send/receive messages !
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.