You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Justin Bertram <jb...@apache.org> on 2023/01/05 03:30:35 UTC
Re: Migrating ActiveMQ plugin to Artemis
Can you elaborate on what exactly you haven't been able to translate into
Artemis' plugin architecture? As Gary mentioned, there's a fairly rich set
of integration points with the various plugins and the fact that the
security manager is pluggable as well. Examples of most of these are
shipped with the broker to help you get going. You shouldn't need to
implement your own JAAS login module as far as I can tell from your
description.
That said, right now you'll have to jump through a few hoops to get details
from the SSL certificate into the authorization method as the
RemotingConnection is no longer passed into it [1]. See ARTEMIS-4059 [2]
for additional discussion on that point.
Ultimately there's no set of classes which will give you a 1 to 1
translation for migrating plugins since the internal broker architectures
are so different. However, the basic concepts should translate such that
just about anything you could do in "Classic" you should be able to do in
Artemis. If not, we'll implement those abilities where it makes sense.
Justin
[1]
https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager5.html
[2] https://issues.apache.org/jira/browse/ARTEMIS-4059
On Wed, Dec 28, 2022 at 4:45 AM Jędrzej Dudkiewicz <
jedrzej.dudkiewicz@gmail.com> wrote:
> Hello,
>
> I wrote to this group earlier
> (https://www.mail-archive.com/dev@activemq.apache.org/msg67666.html)
> and got a response regarding migrating plugin from AMQ to Artemis. But
> honestly even after reading links provided by Garry Tully I can't
> figure out how I should proceed. My plugin extends BrokerFilter
> (import org.apache.activemq.broker.BrokerFilter) and uses most/all
> available methods: start(), addConnection(), removeConnection(),
> addConsumer(), removeConsumer(), addDestination(),
> addDestinationInfo(), removeDestination(), removeDestinationInfo(),
> addProducer() and send().
>
> My first problem is that the first thing I want to do is to retrieve
> the certificate from connection (so probably getTransportConnection()
> from RemotingConnection in Artemis should be used?), parse it, read
> few fields and store proper information in SecurityContext associated
> with this connection. Later this info is used to determine whether a
> connected client can create, delete or send messages to specific
> destinations (queues/topics?). Plugin also sends information about
> connecting/disconnecting clients and so on to predefined queue.
>
> I tried to figure out how the JAAS plugin can be used for this, but
> JAAS as a whole seems to be overly complicated and I'd rather
> reimplement everything from scratch than try to figure out how to use
> such umm... well regarded and mature solution.
>
> Is there some set of classes allowing for 1 to 1 translation of
> ActiveMQ to Artemis plugins?
>
> TIA,
> --
> Jędrzej Dudkiewicz
>
> I really hate this damn machine, I wish that they would sell it.
> It never does just what I want, but only what I tell it.
>
>
Re: Migrating ActiveMQ plugin to Artemis
Posted by Jędrzej Dudkiewicz <je...@gmail.com>.
On Thu, Jan 5, 2023 at 6:37 PM Łukasz Dywicki <lu...@code-house.org> wrote:
> From my earlier experiences I remember that getting client certificate
> on server side was always custom and specific to the tool.
> Anyhow, looking forward to see how it will look a like with Artemis.
It seems that the answer to your question lies in
org.apache.activemq.artemis.core.remoting.CertificateUtil in helper
method getCertsFromConnection(). It is ugly as always, I've never seen
a nice way to get certificates from connection.
Jędrzej Dudkiewicz
>
> Best,
> Łukasz
>
>
> On 5.01.2023 10:57, Jędrzej Dudkiewicz wrote:
> > To follow up: I have attached my test project. To send message to the
> > queue, simply call
> >
> > wget 'http://localhost:8080/send?msg=napis'
> >
> > from the command line. All calls to the plugin's methods are logged
> > using a custom aspect. Note that only methods that are overrode are
> > logged, so e.g. methods used for bridging or federation are not there
> > as I omitted them from the plugin (also bridging and federation are
> > not used).
> >
> > I hope this will help someone somehow.
> >
> > Regards,
> > Jędrzej Dudkiewicz
> >
> > On Thu, Jan 5, 2023 at 10:32 AM Jędrzej Dudkiewicz
> > <je...@gmail.com> wrote:
> >>
> >> Hello,
> >>
> >> Thank you for an answer. I have problems even with starting, since
> >> from what I see security was completely changed from what was
> >> available in ActiveMQ. First thing is that there is no SecurityContext
> >> object attached to the client so to say, so I don't really know where
> >> I should store information read from certificate and access
> >> permissions. It seems that e.g. BrokerMessageAuthorizationPlugin gets
> >> it from reference to server (that it gets from its "registered"
> >> callback) by getting its securityStore() and from that ServerSession
> >> and from that Subject. It seems that I could do the same, *but* I
> >> can't find any way to put my own information there. It seems that to
> >> do it I'd have to go the hard route and implement my own
> >> securityManager (as it is used when creating securityStore in
> >> ActiveMQServerImpl) at least and probably some other classes. This is
> >> why I thought about using JAAS - this way "all" I'd have to do is to
> >> reimplement "CertificateLoginModule" used by
> >> "ActiveMQJAASSecurityManager". It takes care of reading certificate
> >> and parsing it, but
> >>
> >> a) make different assumptions about which field from certificate will be used,
> >> b) from what I understand uses properties file to get roles for users.
> >>
> >> I use OID "0.9.2342.19200300.100.1.1" which contains data in format
> >> "ROLE/UUID", where "UUID" is client's UUID which serves as both its
> >> identifier and name of queue for messages sent to client, and "ROLE"
> >> is more or less a predefined set of permissions that controls what
> >> queues (by name) this client can read from, write to and create.
> >>
> >> This is one problem. Another is how I should check whether a client
> >> can create a queue. I wrote simple SpringBoot based program that
> >> embeds Artemis, installs my plugin and then sends message to
> >> "QUEUEDEF" (sorry my naming sense). It seems that from the plugin's
> >> perspective the flow of the process of client connecting and sending
> >> single message is as follows:
> >>
> >> CALLING: beforeCreateSession
> >> CALLING: beforeMessageRoute
> >> CALLING: afterMessageRoute
> >> CALLING: afterCreateSession
> >> CALLING: beforeAddBinding
> >> CALLING: beforeMessageRoute
> >> CALLING: afterMessageRoute
> >> CALLING: afterAddBinding
> >> CALLING: afterCreateQueue
> >> CALLING: beforeSend
> >> CALLING: beforeMessageRoute
> >> CALLING: afterMessageRoute
> >> CALLING: afterSend
> >>
> >> I don't know why but "beforeCreateQueue" is not called - not that it
> >> is important since I can't do anything with it as I have no access to
> >> ServerSession in this callback.
> >> What I am interested in is whether I am correctly assuming that
> >> basically the only place I can check anything is "beforeSend"
> >> callback. Unfortunately it is called after "afterCreateQueue" (and as
> >> I wrote "beforeCreateQueue" is not called), so I can't prevent queue
> >> creation in this case - there is not enough data passed to the
> >> callback.
> >> Also it seems that "canAccept" is called only when a message is about
> >> to be sent to the consumer, and it makes me wonder what is the reason
> >> for lack of other "canDoSomething" methods, e.g. "canCreateQueue()" :)
> >>
> >> To sum up:
> >>
> >> 1. I can't see a way to attach my own data to client's session and the
> >> only way to do it seems to be write JAAS plugin/login module.
> >> 2. I can't see a way to prevent client from creating arbitrary queues.
> >>
> >> TIA,
> >> Jędrzej Dudkiewicz
> >>
> >>
> >> On Thu, Jan 5, 2023 at 4:31 AM Justin Bertram <jb...@apache.org> wrote:
> >>>
> >>> Can you elaborate on what exactly you haven't been able to translate into
> >>> Artemis' plugin architecture? As Gary mentioned, there's a fairly rich set
> >>> of integration points with the various plugins and the fact that the
> >>> security manager is pluggable as well. Examples of most of these are
> >>> shipped with the broker to help you get going. You shouldn't need to
> >>> implement your own JAAS login module as far as I can tell from your
> >>> description.
> >>>
> >>> That said, right now you'll have to jump through a few hoops to get details
> >>> from the SSL certificate into the authorization method as the
> >>> RemotingConnection is no longer passed into it [1]. See ARTEMIS-4059 [2]
> >>> for additional discussion on that point.
> >>>
> >>> Ultimately there's no set of classes which will give you a 1 to 1
> >>> translation for migrating plugins since the internal broker architectures
> >>> are so different. However, the basic concepts should translate such that
> >>> just about anything you could do in "Classic" you should be able to do in
> >>> Artemis. If not, we'll implement those abilities where it makes sense.
> >>>
> >>>
> >>> Justin
> >>>
> >>> [1]
> >>> https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager5.html
> >>> [2] https://issues.apache.org/jira/browse/ARTEMIS-4059
> >>>
> >>> On Wed, Dec 28, 2022 at 4:45 AM Jędrzej Dudkiewicz <
> >>> jedrzej.dudkiewicz@gmail.com> wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> I wrote to this group earlier
> >>>> (https://www.mail-archive.com/dev@activemq.apache.org/msg67666.html)
> >>>> and got a response regarding migrating plugin from AMQ to Artemis. But
> >>>> honestly even after reading links provided by Garry Tully I can't
> >>>> figure out how I should proceed. My plugin extends BrokerFilter
> >>>> (import org.apache.activemq.broker.BrokerFilter) and uses most/all
> >>>> available methods: start(), addConnection(), removeConnection(),
> >>>> addConsumer(), removeConsumer(), addDestination(),
> >>>> addDestinationInfo(), removeDestination(), removeDestinationInfo(),
> >>>> addProducer() and send().
> >>>>
> >>>> My first problem is that the first thing I want to do is to retrieve
> >>>> the certificate from connection (so probably getTransportConnection()
> >>>> from RemotingConnection in Artemis should be used?), parse it, read
> >>>> few fields and store proper information in SecurityContext associated
> >>>> with this connection. Later this info is used to determine whether a
> >>>> connected client can create, delete or send messages to specific
> >>>> destinations (queues/topics?). Plugin also sends information about
> >>>> connecting/disconnecting clients and so on to predefined queue.
> >>>>
> >>>> I tried to figure out how the JAAS plugin can be used for this, but
> >>>> JAAS as a whole seems to be overly complicated and I'd rather
> >>>> reimplement everything from scratch than try to figure out how to use
> >>>> such umm... well regarded and mature solution.
> >>>>
> >>>> Is there some set of classes allowing for 1 to 1 translation of
> >>>> ActiveMQ to Artemis plugins?
> >>>>
> >>>> TIA,
> >>>> --
> >>>> Jędrzej Dudkiewicz
> >>>>
> >>>> I really hate this damn machine, I wish that they would sell it.
> >>>> It never does just what I want, but only what I tell it.
> >>>>
> >>>>
> >>
> >>
> >>
> >> --
> >> Jędrzej Dudkiewicz
> >>
> >> I really hate this damn machine, I wish that they would sell it.
> >> It never does just what I want, but only what I tell it.
> >
> >
> >
--
Jędrzej Dudkiewicz
I really hate this damn machine, I wish that they would sell it.
It never does just what I want, but only what I tell it.
Re: Migrating ActiveMQ plugin to Artemis
Posted by Łukasz Dywicki <lu...@code-house.org>.
I haven't looked into Artemis plugin system yet but long time ago I
evaluated hivemq plugin architecture and their approach towards
certificate handling was relying on proxy protocol from HA proxy. With
it, hivemq was able to stick certificate with connection attempts and
offer plugins an API to retrieve it.
From my earlier experiences I remember that getting client certificate
on server side was always custom and specific to the tool.
Anyhow, looking forward to see how it will look a like with Artemis.
Best,
Łukasz
On 5.01.2023 10:57, Jędrzej Dudkiewicz wrote:
> To follow up: I have attached my test project. To send message to the
> queue, simply call
>
> wget 'http://localhost:8080/send?msg=napis'
>
> from the command line. All calls to the plugin's methods are logged
> using a custom aspect. Note that only methods that are overrode are
> logged, so e.g. methods used for bridging or federation are not there
> as I omitted them from the plugin (also bridging and federation are
> not used).
>
> I hope this will help someone somehow.
>
> Regards,
> Jędrzej Dudkiewicz
>
> On Thu, Jan 5, 2023 at 10:32 AM Jędrzej Dudkiewicz
> <je...@gmail.com> wrote:
>>
>> Hello,
>>
>> Thank you for an answer. I have problems even with starting, since
>> from what I see security was completely changed from what was
>> available in ActiveMQ. First thing is that there is no SecurityContext
>> object attached to the client so to say, so I don't really know where
>> I should store information read from certificate and access
>> permissions. It seems that e.g. BrokerMessageAuthorizationPlugin gets
>> it from reference to server (that it gets from its "registered"
>> callback) by getting its securityStore() and from that ServerSession
>> and from that Subject. It seems that I could do the same, *but* I
>> can't find any way to put my own information there. It seems that to
>> do it I'd have to go the hard route and implement my own
>> securityManager (as it is used when creating securityStore in
>> ActiveMQServerImpl) at least and probably some other classes. This is
>> why I thought about using JAAS - this way "all" I'd have to do is to
>> reimplement "CertificateLoginModule" used by
>> "ActiveMQJAASSecurityManager". It takes care of reading certificate
>> and parsing it, but
>>
>> a) make different assumptions about which field from certificate will be used,
>> b) from what I understand uses properties file to get roles for users.
>>
>> I use OID "0.9.2342.19200300.100.1.1" which contains data in format
>> "ROLE/UUID", where "UUID" is client's UUID which serves as both its
>> identifier and name of queue for messages sent to client, and "ROLE"
>> is more or less a predefined set of permissions that controls what
>> queues (by name) this client can read from, write to and create.
>>
>> This is one problem. Another is how I should check whether a client
>> can create a queue. I wrote simple SpringBoot based program that
>> embeds Artemis, installs my plugin and then sends message to
>> "QUEUEDEF" (sorry my naming sense). It seems that from the plugin's
>> perspective the flow of the process of client connecting and sending
>> single message is as follows:
>>
>> CALLING: beforeCreateSession
>> CALLING: beforeMessageRoute
>> CALLING: afterMessageRoute
>> CALLING: afterCreateSession
>> CALLING: beforeAddBinding
>> CALLING: beforeMessageRoute
>> CALLING: afterMessageRoute
>> CALLING: afterAddBinding
>> CALLING: afterCreateQueue
>> CALLING: beforeSend
>> CALLING: beforeMessageRoute
>> CALLING: afterMessageRoute
>> CALLING: afterSend
>>
>> I don't know why but "beforeCreateQueue" is not called - not that it
>> is important since I can't do anything with it as I have no access to
>> ServerSession in this callback.
>> What I am interested in is whether I am correctly assuming that
>> basically the only place I can check anything is "beforeSend"
>> callback. Unfortunately it is called after "afterCreateQueue" (and as
>> I wrote "beforeCreateQueue" is not called), so I can't prevent queue
>> creation in this case - there is not enough data passed to the
>> callback.
>> Also it seems that "canAccept" is called only when a message is about
>> to be sent to the consumer, and it makes me wonder what is the reason
>> for lack of other "canDoSomething" methods, e.g. "canCreateQueue()" :)
>>
>> To sum up:
>>
>> 1. I can't see a way to attach my own data to client's session and the
>> only way to do it seems to be write JAAS plugin/login module.
>> 2. I can't see a way to prevent client from creating arbitrary queues.
>>
>> TIA,
>> Jędrzej Dudkiewicz
>>
>>
>> On Thu, Jan 5, 2023 at 4:31 AM Justin Bertram <jb...@apache.org> wrote:
>>>
>>> Can you elaborate on what exactly you haven't been able to translate into
>>> Artemis' plugin architecture? As Gary mentioned, there's a fairly rich set
>>> of integration points with the various plugins and the fact that the
>>> security manager is pluggable as well. Examples of most of these are
>>> shipped with the broker to help you get going. You shouldn't need to
>>> implement your own JAAS login module as far as I can tell from your
>>> description.
>>>
>>> That said, right now you'll have to jump through a few hoops to get details
>>> from the SSL certificate into the authorization method as the
>>> RemotingConnection is no longer passed into it [1]. See ARTEMIS-4059 [2]
>>> for additional discussion on that point.
>>>
>>> Ultimately there's no set of classes which will give you a 1 to 1
>>> translation for migrating plugins since the internal broker architectures
>>> are so different. However, the basic concepts should translate such that
>>> just about anything you could do in "Classic" you should be able to do in
>>> Artemis. If not, we'll implement those abilities where it makes sense.
>>>
>>>
>>> Justin
>>>
>>> [1]
>>> https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager5.html
>>> [2] https://issues.apache.org/jira/browse/ARTEMIS-4059
>>>
>>> On Wed, Dec 28, 2022 at 4:45 AM Jędrzej Dudkiewicz <
>>> jedrzej.dudkiewicz@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I wrote to this group earlier
>>>> (https://www.mail-archive.com/dev@activemq.apache.org/msg67666.html)
>>>> and got a response regarding migrating plugin from AMQ to Artemis. But
>>>> honestly even after reading links provided by Garry Tully I can't
>>>> figure out how I should proceed. My plugin extends BrokerFilter
>>>> (import org.apache.activemq.broker.BrokerFilter) and uses most/all
>>>> available methods: start(), addConnection(), removeConnection(),
>>>> addConsumer(), removeConsumer(), addDestination(),
>>>> addDestinationInfo(), removeDestination(), removeDestinationInfo(),
>>>> addProducer() and send().
>>>>
>>>> My first problem is that the first thing I want to do is to retrieve
>>>> the certificate from connection (so probably getTransportConnection()
>>>> from RemotingConnection in Artemis should be used?), parse it, read
>>>> few fields and store proper information in SecurityContext associated
>>>> with this connection. Later this info is used to determine whether a
>>>> connected client can create, delete or send messages to specific
>>>> destinations (queues/topics?). Plugin also sends information about
>>>> connecting/disconnecting clients and so on to predefined queue.
>>>>
>>>> I tried to figure out how the JAAS plugin can be used for this, but
>>>> JAAS as a whole seems to be overly complicated and I'd rather
>>>> reimplement everything from scratch than try to figure out how to use
>>>> such umm... well regarded and mature solution.
>>>>
>>>> Is there some set of classes allowing for 1 to 1 translation of
>>>> ActiveMQ to Artemis plugins?
>>>>
>>>> TIA,
>>>> --
>>>> Jędrzej Dudkiewicz
>>>>
>>>> I really hate this damn machine, I wish that they would sell it.
>>>> It never does just what I want, but only what I tell it.
>>>>
>>>>
>>
>>
>>
>> --
>> Jędrzej Dudkiewicz
>>
>> I really hate this damn machine, I wish that they would sell it.
>> It never does just what I want, but only what I tell it.
>
>
>
Re: Migrating ActiveMQ plugin to Artemis
Posted by Jędrzej Dudkiewicz <je...@gmail.com>.
To follow up: I have attached my test project. To send message to the
queue, simply call
wget 'http://localhost:8080/send?msg=napis'
from the command line. All calls to the plugin's methods are logged
using a custom aspect. Note that only methods that are overrode are
logged, so e.g. methods used for bridging or federation are not there
as I omitted them from the plugin (also bridging and federation are
not used).
I hope this will help someone somehow.
Regards,
Jędrzej Dudkiewicz
On Thu, Jan 5, 2023 at 10:32 AM Jędrzej Dudkiewicz
<je...@gmail.com> wrote:
>
> Hello,
>
> Thank you for an answer. I have problems even with starting, since
> from what I see security was completely changed from what was
> available in ActiveMQ. First thing is that there is no SecurityContext
> object attached to the client so to say, so I don't really know where
> I should store information read from certificate and access
> permissions. It seems that e.g. BrokerMessageAuthorizationPlugin gets
> it from reference to server (that it gets from its "registered"
> callback) by getting its securityStore() and from that ServerSession
> and from that Subject. It seems that I could do the same, *but* I
> can't find any way to put my own information there. It seems that to
> do it I'd have to go the hard route and implement my own
> securityManager (as it is used when creating securityStore in
> ActiveMQServerImpl) at least and probably some other classes. This is
> why I thought about using JAAS - this way "all" I'd have to do is to
> reimplement "CertificateLoginModule" used by
> "ActiveMQJAASSecurityManager". It takes care of reading certificate
> and parsing it, but
>
> a) make different assumptions about which field from certificate will be used,
> b) from what I understand uses properties file to get roles for users.
>
> I use OID "0.9.2342.19200300.100.1.1" which contains data in format
> "ROLE/UUID", where "UUID" is client's UUID which serves as both its
> identifier and name of queue for messages sent to client, and "ROLE"
> is more or less a predefined set of permissions that controls what
> queues (by name) this client can read from, write to and create.
>
> This is one problem. Another is how I should check whether a client
> can create a queue. I wrote simple SpringBoot based program that
> embeds Artemis, installs my plugin and then sends message to
> "QUEUEDEF" (sorry my naming sense). It seems that from the plugin's
> perspective the flow of the process of client connecting and sending
> single message is as follows:
>
> CALLING: beforeCreateSession
> CALLING: beforeMessageRoute
> CALLING: afterMessageRoute
> CALLING: afterCreateSession
> CALLING: beforeAddBinding
> CALLING: beforeMessageRoute
> CALLING: afterMessageRoute
> CALLING: afterAddBinding
> CALLING: afterCreateQueue
> CALLING: beforeSend
> CALLING: beforeMessageRoute
> CALLING: afterMessageRoute
> CALLING: afterSend
>
> I don't know why but "beforeCreateQueue" is not called - not that it
> is important since I can't do anything with it as I have no access to
> ServerSession in this callback.
> What I am interested in is whether I am correctly assuming that
> basically the only place I can check anything is "beforeSend"
> callback. Unfortunately it is called after "afterCreateQueue" (and as
> I wrote "beforeCreateQueue" is not called), so I can't prevent queue
> creation in this case - there is not enough data passed to the
> callback.
> Also it seems that "canAccept" is called only when a message is about
> to be sent to the consumer, and it makes me wonder what is the reason
> for lack of other "canDoSomething" methods, e.g. "canCreateQueue()" :)
>
> To sum up:
>
> 1. I can't see a way to attach my own data to client's session and the
> only way to do it seems to be write JAAS plugin/login module.
> 2. I can't see a way to prevent client from creating arbitrary queues.
>
> TIA,
> Jędrzej Dudkiewicz
>
>
> On Thu, Jan 5, 2023 at 4:31 AM Justin Bertram <jb...@apache.org> wrote:
> >
> > Can you elaborate on what exactly you haven't been able to translate into
> > Artemis' plugin architecture? As Gary mentioned, there's a fairly rich set
> > of integration points with the various plugins and the fact that the
> > security manager is pluggable as well. Examples of most of these are
> > shipped with the broker to help you get going. You shouldn't need to
> > implement your own JAAS login module as far as I can tell from your
> > description.
> >
> > That said, right now you'll have to jump through a few hoops to get details
> > from the SSL certificate into the authorization method as the
> > RemotingConnection is no longer passed into it [1]. See ARTEMIS-4059 [2]
> > for additional discussion on that point.
> >
> > Ultimately there's no set of classes which will give you a 1 to 1
> > translation for migrating plugins since the internal broker architectures
> > are so different. However, the basic concepts should translate such that
> > just about anything you could do in "Classic" you should be able to do in
> > Artemis. If not, we'll implement those abilities where it makes sense.
> >
> >
> > Justin
> >
> > [1]
> > https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager5.html
> > [2] https://issues.apache.org/jira/browse/ARTEMIS-4059
> >
> > On Wed, Dec 28, 2022 at 4:45 AM Jędrzej Dudkiewicz <
> > jedrzej.dudkiewicz@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > I wrote to this group earlier
> > > (https://www.mail-archive.com/dev@activemq.apache.org/msg67666.html)
> > > and got a response regarding migrating plugin from AMQ to Artemis. But
> > > honestly even after reading links provided by Garry Tully I can't
> > > figure out how I should proceed. My plugin extends BrokerFilter
> > > (import org.apache.activemq.broker.BrokerFilter) and uses most/all
> > > available methods: start(), addConnection(), removeConnection(),
> > > addConsumer(), removeConsumer(), addDestination(),
> > > addDestinationInfo(), removeDestination(), removeDestinationInfo(),
> > > addProducer() and send().
> > >
> > > My first problem is that the first thing I want to do is to retrieve
> > > the certificate from connection (so probably getTransportConnection()
> > > from RemotingConnection in Artemis should be used?), parse it, read
> > > few fields and store proper information in SecurityContext associated
> > > with this connection. Later this info is used to determine whether a
> > > connected client can create, delete or send messages to specific
> > > destinations (queues/topics?). Plugin also sends information about
> > > connecting/disconnecting clients and so on to predefined queue.
> > >
> > > I tried to figure out how the JAAS plugin can be used for this, but
> > > JAAS as a whole seems to be overly complicated and I'd rather
> > > reimplement everything from scratch than try to figure out how to use
> > > such umm... well regarded and mature solution.
> > >
> > > Is there some set of classes allowing for 1 to 1 translation of
> > > ActiveMQ to Artemis plugins?
> > >
> > > TIA,
> > > --
> > > Jędrzej Dudkiewicz
> > >
> > > I really hate this damn machine, I wish that they would sell it.
> > > It never does just what I want, but only what I tell it.
> > >
> > >
>
>
>
> --
> Jędrzej Dudkiewicz
>
> I really hate this damn machine, I wish that they would sell it.
> It never does just what I want, but only what I tell it.
--
Jędrzej Dudkiewicz
I really hate this damn machine, I wish that they would sell it.
It never does just what I want, but only what I tell it.
Re: Migrating ActiveMQ plugin to Artemis
Posted by Jędrzej Dudkiewicz <je...@gmail.com>.
Hello,
Thank you for an answer. I have problems even with starting, since
from what I see security was completely changed from what was
available in ActiveMQ. First thing is that there is no SecurityContext
object attached to the client so to say, so I don't really know where
I should store information read from certificate and access
permissions. It seems that e.g. BrokerMessageAuthorizationPlugin gets
it from reference to server (that it gets from its "registered"
callback) by getting its securityStore() and from that ServerSession
and from that Subject. It seems that I could do the same, *but* I
can't find any way to put my own information there. It seems that to
do it I'd have to go the hard route and implement my own
securityManager (as it is used when creating securityStore in
ActiveMQServerImpl) at least and probably some other classes. This is
why I thought about using JAAS - this way "all" I'd have to do is to
reimplement "CertificateLoginModule" used by
"ActiveMQJAASSecurityManager". It takes care of reading certificate
and parsing it, but
a) make different assumptions about which field from certificate will be used,
b) from what I understand uses properties file to get roles for users.
I use OID "0.9.2342.19200300.100.1.1" which contains data in format
"ROLE/UUID", where "UUID" is client's UUID which serves as both its
identifier and name of queue for messages sent to client, and "ROLE"
is more or less a predefined set of permissions that controls what
queues (by name) this client can read from, write to and create.
This is one problem. Another is how I should check whether a client
can create a queue. I wrote simple SpringBoot based program that
embeds Artemis, installs my plugin and then sends message to
"QUEUEDEF" (sorry my naming sense). It seems that from the plugin's
perspective the flow of the process of client connecting and sending
single message is as follows:
CALLING: beforeCreateSession
CALLING: beforeMessageRoute
CALLING: afterMessageRoute
CALLING: afterCreateSession
CALLING: beforeAddBinding
CALLING: beforeMessageRoute
CALLING: afterMessageRoute
CALLING: afterAddBinding
CALLING: afterCreateQueue
CALLING: beforeSend
CALLING: beforeMessageRoute
CALLING: afterMessageRoute
CALLING: afterSend
I don't know why but "beforeCreateQueue" is not called - not that it
is important since I can't do anything with it as I have no access to
ServerSession in this callback.
What I am interested in is whether I am correctly assuming that
basically the only place I can check anything is "beforeSend"
callback. Unfortunately it is called after "afterCreateQueue" (and as
I wrote "beforeCreateQueue" is not called), so I can't prevent queue
creation in this case - there is not enough data passed to the
callback.
Also it seems that "canAccept" is called only when a message is about
to be sent to the consumer, and it makes me wonder what is the reason
for lack of other "canDoSomething" methods, e.g. "canCreateQueue()" :)
To sum up:
1. I can't see a way to attach my own data to client's session and the
only way to do it seems to be write JAAS plugin/login module.
2. I can't see a way to prevent client from creating arbitrary queues.
TIA,
Jędrzej Dudkiewicz
On Thu, Jan 5, 2023 at 4:31 AM Justin Bertram <jb...@apache.org> wrote:
>
> Can you elaborate on what exactly you haven't been able to translate into
> Artemis' plugin architecture? As Gary mentioned, there's a fairly rich set
> of integration points with the various plugins and the fact that the
> security manager is pluggable as well. Examples of most of these are
> shipped with the broker to help you get going. You shouldn't need to
> implement your own JAAS login module as far as I can tell from your
> description.
>
> That said, right now you'll have to jump through a few hoops to get details
> from the SSL certificate into the authorization method as the
> RemotingConnection is no longer passed into it [1]. See ARTEMIS-4059 [2]
> for additional discussion on that point.
>
> Ultimately there's no set of classes which will give you a 1 to 1
> translation for migrating plugins since the internal broker architectures
> are so different. However, the basic concepts should translate such that
> just about anything you could do in "Classic" you should be able to do in
> Artemis. If not, we'll implement those abilities where it makes sense.
>
>
> Justin
>
> [1]
> https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager5.html
> [2] https://issues.apache.org/jira/browse/ARTEMIS-4059
>
> On Wed, Dec 28, 2022 at 4:45 AM Jędrzej Dudkiewicz <
> jedrzej.dudkiewicz@gmail.com> wrote:
>
> > Hello,
> >
> > I wrote to this group earlier
> > (https://www.mail-archive.com/dev@activemq.apache.org/msg67666.html)
> > and got a response regarding migrating plugin from AMQ to Artemis. But
> > honestly even after reading links provided by Garry Tully I can't
> > figure out how I should proceed. My plugin extends BrokerFilter
> > (import org.apache.activemq.broker.BrokerFilter) and uses most/all
> > available methods: start(), addConnection(), removeConnection(),
> > addConsumer(), removeConsumer(), addDestination(),
> > addDestinationInfo(), removeDestination(), removeDestinationInfo(),
> > addProducer() and send().
> >
> > My first problem is that the first thing I want to do is to retrieve
> > the certificate from connection (so probably getTransportConnection()
> > from RemotingConnection in Artemis should be used?), parse it, read
> > few fields and store proper information in SecurityContext associated
> > with this connection. Later this info is used to determine whether a
> > connected client can create, delete or send messages to specific
> > destinations (queues/topics?). Plugin also sends information about
> > connecting/disconnecting clients and so on to predefined queue.
> >
> > I tried to figure out how the JAAS plugin can be used for this, but
> > JAAS as a whole seems to be overly complicated and I'd rather
> > reimplement everything from scratch than try to figure out how to use
> > such umm... well regarded and mature solution.
> >
> > Is there some set of classes allowing for 1 to 1 translation of
> > ActiveMQ to Artemis plugins?
> >
> > TIA,
> > --
> > Jędrzej Dudkiewicz
> >
> > I really hate this damn machine, I wish that they would sell it.
> > It never does just what I want, but only what I tell it.
> >
> >
--
Jędrzej Dudkiewicz
I really hate this damn machine, I wish that they would sell it.
It never does just what I want, but only what I tell it.
Re: Migrating ActiveMQ plugin to Artemis
Posted by Justin Bertram <jb...@apache.org>.
Rony, your email seems to be completely unrelated to the rest of this
thread discussing plugin migration. Please start a new thread of your own
on the *users* list. Thanks!
Justin
On Thu, Jan 5, 2023 at 1:14 AM Rony Christian
<ro...@petpooja.com.invalid> wrote:
> Thanks for your reply.
>
> Currently I have connected to artemis (mqtt) but not able to connect with
> mqtts. I have attached here the current configuration (broker.xml).
> <acceptors>
> <!-- MQTT Acceptor -->
> <acceptor name="mqtt">tcp://
>
> 0.0.0.0:1883?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=MQTT;useEpoll=true
> </acceptor>
> <acceptor name="mqtt-ssl-acceptor">tcp://
>
> 0.0.0.0:8883?sslEnabled=true;needClientAuth=true;keyStorePath=server-keystore.jks;keyStorePassword=securepass;trustStorePath=client-ca-truststore.jks;trustStorePassword=securepass;protocols=MQTT
> </acceptor>
> <acceptor
>
> name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;needClientAuth=true;keyStorePath=server-keystore.jks;keyStorePassword=securepass;trustStorePath=client-ca-truststore.jks;trustStorePassword=securepass</acceptor>
> </acceptors>
>
> I'm using nodejs and here is my nodejs code to connect the mqtt server:
> this.username = 'myuname';
> this.password = 'mypass';
> this.endpoint = 'mqtt://my.endpoint.com;';
> this.options = {
> username: this.username,
> password: this.password,
> // ca: [fs.readFileSync(['/usr/share/ca-certificates/client.crt'])],
> rejectUnauthorized: false,
> protocol: "mqtts",
> port : 8883,
> // clientId: "mqttjs_" + new Date().getTime()
> // ssl: {
> // key: fs.readFileSync('./ssl/petpooja.pem'),
> // cert: fs.readFileSync('./ssl/STAR_petpooja_com.pem'),
> // },
> sslEnabled: true,
> trustStorePath: fs.readFileSync('./keystore.jks'),
> trustStorePassword: 'mypass',
> // keyStorePath: fs.readFileSync('./d/client-keystore.jks'),
> // keyStorePassword: 'securepass',
> };
>
> Can you please look into this, where I'm doing wrong?
>
> Thanks and Regards,
>
> On Thu, Jan 5, 2023 at 9:01 AM Justin Bertram <jb...@apache.org> wrote:
>
> > Can you elaborate on what exactly you haven't been able to translate into
> > Artemis' plugin architecture? As Gary mentioned, there's a fairly rich
> set
> > of integration points with the various plugins and the fact that the
> > security manager is pluggable as well. Examples of most of these are
> > shipped with the broker to help you get going. You shouldn't need to
> > implement your own JAAS login module as far as I can tell from your
> > description.
> >
> > That said, right now you'll have to jump through a few hoops to get
> details
> > from the SSL certificate into the authorization method as the
> > RemotingConnection is no longer passed into it [1]. See ARTEMIS-4059 [2]
> > for additional discussion on that point.
> >
> > Ultimately there's no set of classes which will give you a 1 to 1
> > translation for migrating plugins since the internal broker architectures
> > are so different. However, the basic concepts should translate such that
> > just about anything you could do in "Classic" you should be able to do in
> > Artemis. If not, we'll implement those abilities where it makes sense.
> >
> >
> > Justin
> >
> > [1]
> >
> >
> https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager5.html
> > [2] https://issues.apache.org/jira/browse/ARTEMIS-4059
> >
> > On Wed, Dec 28, 2022 at 4:45 AM Jędrzej Dudkiewicz <
> > jedrzej.dudkiewicz@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > I wrote to this group earlier
> > > (https://www.mail-archive.com/dev@activemq.apache.org/msg67666.html)
> > > and got a response regarding migrating plugin from AMQ to Artemis. But
> > > honestly even after reading links provided by Garry Tully I can't
> > > figure out how I should proceed. My plugin extends BrokerFilter
> > > (import org.apache.activemq.broker.BrokerFilter) and uses most/all
> > > available methods: start(), addConnection(), removeConnection(),
> > > addConsumer(), removeConsumer(), addDestination(),
> > > addDestinationInfo(), removeDestination(), removeDestinationInfo(),
> > > addProducer() and send().
> > >
> > > My first problem is that the first thing I want to do is to retrieve
> > > the certificate from connection (so probably getTransportConnection()
> > > from RemotingConnection in Artemis should be used?), parse it, read
> > > few fields and store proper information in SecurityContext associated
> > > with this connection. Later this info is used to determine whether a
> > > connected client can create, delete or send messages to specific
> > > destinations (queues/topics?). Plugin also sends information about
> > > connecting/disconnecting clients and so on to predefined queue.
> > >
> > > I tried to figure out how the JAAS plugin can be used for this, but
> > > JAAS as a whole seems to be overly complicated and I'd rather
> > > reimplement everything from scratch than try to figure out how to use
> > > such umm... well regarded and mature solution.
> > >
> > > Is there some set of classes allowing for 1 to 1 translation of
> > > ActiveMQ to Artemis plugins?
> > >
> > > TIA,
> > > --
> > > Jędrzej Dudkiewicz
> > >
> > > I really hate this damn machine, I wish that they would sell it.
> > > It never does just what I want, but only what I tell it.
> > >
> > >
> >
>
Re: Migrating ActiveMQ plugin to Artemis
Posted by Rony Christian <ro...@petpooja.com.INVALID>.
Thanks for your reply.
Currently I have connected to artemis (mqtt) but not able to connect with
mqtts. I have attached here the current configuration (broker.xml).
<acceptors>
<!-- MQTT Acceptor -->
<acceptor name="mqtt">tcp://
0.0.0.0:1883?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=MQTT;useEpoll=true
</acceptor>
<acceptor name="mqtt-ssl-acceptor">tcp://
0.0.0.0:8883?sslEnabled=true;needClientAuth=true;keyStorePath=server-keystore.jks;keyStorePassword=securepass;trustStorePath=client-ca-truststore.jks;trustStorePassword=securepass;protocols=MQTT
</acceptor>
<acceptor
name="netty-ssl-acceptor">tcp://localhost:5500?sslEnabled=true;needClientAuth=true;keyStorePath=server-keystore.jks;keyStorePassword=securepass;trustStorePath=client-ca-truststore.jks;trustStorePassword=securepass</acceptor>
</acceptors>
I'm using nodejs and here is my nodejs code to connect the mqtt server:
this.username = 'myuname';
this.password = 'mypass';
this.endpoint = 'mqtt://my.endpoint.com;';
this.options = {
username: this.username,
password: this.password,
// ca: [fs.readFileSync(['/usr/share/ca-certificates/client.crt'])],
rejectUnauthorized: false,
protocol: "mqtts",
port : 8883,
// clientId: "mqttjs_" + new Date().getTime()
// ssl: {
// key: fs.readFileSync('./ssl/petpooja.pem'),
// cert: fs.readFileSync('./ssl/STAR_petpooja_com.pem'),
// },
sslEnabled: true,
trustStorePath: fs.readFileSync('./keystore.jks'),
trustStorePassword: 'mypass',
// keyStorePath: fs.readFileSync('./d/client-keystore.jks'),
// keyStorePassword: 'securepass',
};
Can you please look into this, where I'm doing wrong?
Thanks and Regards,
On Thu, Jan 5, 2023 at 9:01 AM Justin Bertram <jb...@apache.org> wrote:
> Can you elaborate on what exactly you haven't been able to translate into
> Artemis' plugin architecture? As Gary mentioned, there's a fairly rich set
> of integration points with the various plugins and the fact that the
> security manager is pluggable as well. Examples of most of these are
> shipped with the broker to help you get going. You shouldn't need to
> implement your own JAAS login module as far as I can tell from your
> description.
>
> That said, right now you'll have to jump through a few hoops to get details
> from the SSL certificate into the authorization method as the
> RemotingConnection is no longer passed into it [1]. See ARTEMIS-4059 [2]
> for additional discussion on that point.
>
> Ultimately there's no set of classes which will give you a 1 to 1
> translation for migrating plugins since the internal broker architectures
> are so different. However, the basic concepts should translate such that
> just about anything you could do in "Classic" you should be able to do in
> Artemis. If not, we'll implement those abilities where it makes sense.
>
>
> Justin
>
> [1]
>
> https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/spi/core/security/ActiveMQSecurityManager5.html
> [2] https://issues.apache.org/jira/browse/ARTEMIS-4059
>
> On Wed, Dec 28, 2022 at 4:45 AM Jędrzej Dudkiewicz <
> jedrzej.dudkiewicz@gmail.com> wrote:
>
> > Hello,
> >
> > I wrote to this group earlier
> > (https://www.mail-archive.com/dev@activemq.apache.org/msg67666.html)
> > and got a response regarding migrating plugin from AMQ to Artemis. But
> > honestly even after reading links provided by Garry Tully I can't
> > figure out how I should proceed. My plugin extends BrokerFilter
> > (import org.apache.activemq.broker.BrokerFilter) and uses most/all
> > available methods: start(), addConnection(), removeConnection(),
> > addConsumer(), removeConsumer(), addDestination(),
> > addDestinationInfo(), removeDestination(), removeDestinationInfo(),
> > addProducer() and send().
> >
> > My first problem is that the first thing I want to do is to retrieve
> > the certificate from connection (so probably getTransportConnection()
> > from RemotingConnection in Artemis should be used?), parse it, read
> > few fields and store proper information in SecurityContext associated
> > with this connection. Later this info is used to determine whether a
> > connected client can create, delete or send messages to specific
> > destinations (queues/topics?). Plugin also sends information about
> > connecting/disconnecting clients and so on to predefined queue.
> >
> > I tried to figure out how the JAAS plugin can be used for this, but
> > JAAS as a whole seems to be overly complicated and I'd rather
> > reimplement everything from scratch than try to figure out how to use
> > such umm... well regarded and mature solution.
> >
> > Is there some set of classes allowing for 1 to 1 translation of
> > ActiveMQ to Artemis plugins?
> >
> > TIA,
> > --
> > Jędrzej Dudkiewicz
> >
> > I really hate this damn machine, I wish that they would sell it.
> > It never does just what I want, but only what I tell it.
> >
> >
>