You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Justin Bertram (Jira)" <ji...@apache.org> on 2020/08/04 20:13:00 UTC

[jira] [Comment Edited] (ARTEMIS-2861) Add queue name as a parameter to ActiveMQSecurityManager

    [ https://issues.apache.org/jira/browse/ARTEMIS-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171036#comment-17171036 ] 

Justin Bertram edited comment on ARTEMIS-2861 at 8/4/20, 8:12 PM:
------------------------------------------------------------------

I certainly think the queue name can be concatenated for the checks were it makes sense (i.e. {{CREATE_DURABLE_QUEUE}} & {{CREATE_NON_DURABLE_QUEUE}}). I'm not sure it makes sense for any other checks aside from those two.

Also, I would change the concatenation to use {{::}} instead of {{.}}. The original work from ARTEMIS-592 was done before we had real support fully-qualified-queue-names (i.e. FQQN). Since then we've standardized on the {{::}} as a way to identify address/queue combinations. It's much less likely to conflict with existing resource naming conventions.


was (Author: jbertram):
I certainly think the queue name can be concatenated for the checks were it makes sense (i.e. {{CREATE_DURABLE_QUEUE}} & {{CREATE_NON_DURABLE_QUEUE}}). I'm not sure it makes sense for any other checks aside from those two.

Also, I would change the concatenation to use `::` instead of `.`. The original work from ARTEMIS-592 was done before we had real support fully-qualified-queue-names (i.e. FQQN). Since then we've standardized on the `::` as a way to identify address/queue combinations. It's much less likely to conflict with existing resource naming conventions.

> Add queue name as a parameter to ActiveMQSecurityManager 
> ---------------------------------------------------------
>
>                 Key: ARTEMIS-2861
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2861
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>    Affects Versions: 2.14.0
>            Reporter: Luís Alves
>            Priority: Major
>
> Currently I was trying to integrate Artemis with OpenId Connect (Oauth2.0) and User Managed Access 2.0 (UMA 2.0) using Keycloak implementation. I want to have fine grained access control over operations over addresses and queues (subscriptions) like described on https://issues.apache.org/jira/browse/ARTEMIS-592. I've investigated as proposed in https://medium.com/@joelicious/extending-artemis-security-with-oauth2-7fd9b3dffe3 and it solves the authN part. For the authZ part I've already had some feedback here https://stackoverflow.com/questions/63191001/activemq-artemis-activemqsecuritymanager4-verify-clientid-subscription, but I think org.apache.activemq.artemis.core.server.SecuritySettingPlugin will not give the needed control. So I'm proposing that ActiveMQSecurityManager latest implementation adds the queue name as the calling method:
> {code:java}
>  @Override
>    public void check(final SimpleString address,
>                      final SimpleString queue,
>                      final CheckType checkType,
>                      final SecurityAuth session) throws Exception {
> {code}
> already has this information. 
> Using UMA 2.0 each address can be a resource and we can have: SEND,CONSUME,CREATE_ADDRESS,DELETE_ADDRESS,CREATE_DURABLE_QUEUE,DELETE_DURABLE_QUEUE,CREATE_NON_DURABLE_QUEUE,DELETE_NON_DURABLE_QUEUE,MANAGE,BROWSE as scopes, which I think are quite fine grained. Depending on the use case a subscription also can be a resource.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)