[
https://issues.apache.org/jira/browse/ARTEMIS-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170602#comment-17170602
]
Luís Alves commented on ARTEMIS-2861:
-------------------------------------
After peeked the
https://github.com/apache/activemq-artemis/pull/701/files/856f90c3ab39e86dea73379277a8d88eadfcb81f#r73435791
I get it, but can't you do the same for the other check types? Nevertheless,
not sure it's the best strategy as I need to store state (address), so on the
second check I can subtract the address from the address+queue.
Meanwhile I think it's a bad idea to deliver clientId+clientSecret to the
broker, so I need to figure out a way to pass an access token instead and
manage the whole life-cycle of the token.
> 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)
