Technically speaking, an implementation of
o.a.a.a.s.c.s.ActiveMQSecurityManager5 like you have *is* allowed to change
the client ID on the o.a.a.a.s.c.p.RemotingConnection it receives (just as
you are doing in your implementation). The problem is that MQTT
implementation doesn't use this client ID and instead overwrites it with
the value from the MQTT CONNECT packet. However, I think the code could be
refactored fairly easily to accommodate this use-case. Can you open a Jira?


Justin

On Thu, Apr 7, 2022 at 11:19 AM Modanese, Riccardo
<riccardo.modan...@eurotech.com.invalid> wrote:

> Hello,
>     we are moving a security plugin from ActiveMQ 5.x broker to Artemis
> 2.x.
> To summarize the use case:
>     we need to prefix the MQTT client id provided during the connect with
> the account name (something like account_name|client_id) to allow devices
> with the same clientId, but different accounts, to connect to the broker
> without triggering the stealing link.
>
> Doing that with the ActiveMQ was possible. With Artemis SecurityPlugin any
> clientId set through the proper RemotingConnection setter has no effect (
> https://github.com/riccardomodanese/kapua/blob/feature-artemisAuthentication/broker/artemis/plugin/src/main/java/org/eclipse/kapua/broker/artemis/plugin/security/SecurityPlugin.java#L140
> ).
> Also the fully qualified queue name still use the “original” clientId
> without the account_name prefix
>
> We received a suggestion to use the interceptor but unfortunately the
> MQTTConnect is final and has all the fields final so we cannot change the
> clientId
> We tried, just as experiment, using reflection to change the accessibility
> (no security manager) and it seems to work. But, obviously, is just an
> experiment and cannot be used in a real environment.
>
> The MQTTConnect message is created by MQTTDecoder (
> https://github.com/netty/netty/blob/4.1/codec-mqtt/src/main/java/io/netty/handler/codec/mqtt/MqttDecoder.java#L534)
> but changing this part to introduce a callback that allows to change the
> decoded clientId is out of the scope of this layer IMHO.
>
> If someone has suggestion or, better, a solution please tell me!
>
> Thanks!
>
> Riccardo Modanese
>
>

Reply via email to