Depend but if you think to authorizationplugin something like it could work:
<Resource id="..." class-name="...">
queue1 = read=user;admins,write=admin;sudo,admin=admin
</Resource>
We can still support a generic resource factory understading $dddd as
a lookup to do on dddd. This way you can wire beans together
genericly.
That said not sure there are enough specific plugins which would need it.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-06-05 14:31 GMT+02:00 Marian Muller <[email protected]>:
> Hi,
>
> Thanks for the tip. Using a factory is the way to go.
> After adding a factory/service provider in service-jar.xml, I can use the
> following configuration:
>
> <Resource id="MyAMQPlugin" type="AMQSimpleAuthenticationPlugin">
>> UserPasswords = user1=password1 \n user2=password2 \n
>> manager=password3
>> UserGroups = user1=users \n user2=users \n manager=users,admin
>
> # Anonymous access configuration is optional
>
> AnonymousUser = guest
>
> AnonymousGroup = guest
>
> AnonymousAccessAllowed = true
>
> </Resource>
>> <Resource id="MyJmsResourceAdapter" type="ActiveMQResourceAdapter">
>> BrokerXmlConfig = broker:(tcp://localhost:61617)
>> ServerUrl = tcp://localhost:61617
>> Plugins = [MyAMQPlugin]
>> </Resource>
>
>
> This works well for the SImpleAuthenticationPlugin, and I can set multiple
> plugins for a given ActiveMQResourceAdapter.
> Now I am having a look at the other ActiveMQ plugins. Some require much
> more complex configuration (e.g. AuthorizationPlugin) and others do not
> even require a factory (e.g. JaasAuthenticationPlugin and its subclasses).
>
> How do you think this should be made generic to support any plugin ?
> Providing a factory for every "built-in" AMQ plugins may be feasible, but
> would certainly be a hassle for a not-so-complete support. And users would
> still have to implement a factory for their custom or third-party plugins.
> We could also simply provide a limited toolset of factories for
> authentication related plugins (without declaring them as service
> providers) and write a detailed documentation on how to configure/implement
> a custom factory for the other plugins ?
> In any case, ActiveMQResourceAdapter would accept any BrokerPlugin beans,
> and set them up in the ActiveMQ broker (which is the part where it must be
> generic!).
>
> What do you think?
>
> --
> Marian MULLER
> SERLI
>
>
> On Tue, Jun 3, 2014 at 6:34 PM, Romain Manni-Bucau <[email protected]>
> wrote:
>
>> For these advanced cases we provide a factory in openejb users rely on (all
>> container are done this way for instance). So just use the config you want,
>> get properties injected in your factory and declare the class-name
>> attribute of your resource with the value of the qualified name of the
>> factory.
>>
>>
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>> 2014-06-03 18:22 GMT+02:00 Marian Muller <[email protected]>:
>>
>> > Hi Romain,
>> >
>> > I had a look at the XBean property editors to configure AMQ plugins from
>> > TomEE configuration file. I can easily set the userPasswords for the
>> > SimpleAuthenticationPlugin
>> > class (it is a simple Map<String,String>), but the userGroups property is
>> > not as easy (it is a Map<String, Set<Principal>>). Which makes me wonder
>> if
>> > XBean properties are appropriate for complex objects like AMQ plugins. I
>> > did not yet look at the other plugins, but I guess they could become even
>> > more complex that the rather-simple authentication plugin.
>> > And is there a way to instantiate such objects using XBean properties
>> > without hard-coding converters for plugin-specific classes (like
>> > GroupPrincipal, AuthenticationUser, ...).
>> >
>> > Thanks.
>> >
>> > --
>> > Marian MULLER
>> > SERLI
>> >
>> >
>> > On Tue, Jun 3, 2014 at 10:26 AM, Romain Manni-Bucau <
>> [email protected]
>> > >
>> > wrote:
>> >
>> > > Hi
>> > >
>> > > I think the solution without activemq.xml is great. We could make a
>> > default
>> > > jars.txt a user could drop in conf/ to add all the required
>> dependencies
>> > if
>> > > it helps but putting spring is the container is not a good idea as
>> > default
>> > > solution. In particular for this case where we know how to get it
>> > properly
>> > > done.
>> > >
>> > > Side note: would be great to be able to do a network of brokers between
>> > > tomee instances too.
>> > >
>> > >
>> > >
>> > >
>> > > Romain Manni-Bucau
>> > > Twitter: @rmannibucau
>> > > Blog: http://rmannibucau.wordpress.com/
>> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> > > Github: https://github.com/rmannibucau
>> > >
>> > >
>> > > 2014-06-03 10:23 GMT+02:00 Marian Muller <[email protected]>:
>> > >
>> > > > Hi Andy,
>> > > >
>> > > > Thanks for the insight. I think we need to take some time and discuss
>> > the
>> > > > topic, before going further.
>> > > >
>> > > > I understand your point about the simple "built-in" solution being
>> what
>> > > its
>> > > > name suggests: a simple solution for running localhost/vm-only
>> broker.
>> > > This
>> > > > makes much sense! And I also believe there is a need for a deep
>> > > > understanding of ActiveMQ configuration, when addressing more complex
>> > > > situations.
>> > > >
>> > > > I think the activemq.xml file fits this description, however I also
>> > think
>> > > > the Spring requirement may be a hurdle to some users. The TomEE
>> > > > website mentions
>> > > > the need for Spring and XBean libraries
>> > > > <http://tomee.apache.org/jms-resources-and-mdb-container.html>, yet
>> I
>> > > hit
>> > > > a
>> > > > few issues when following the instructions:
>> > > >
>> > > > 1/ Adding the 5 mentioned jars (spring-* and xbean-spring) is not
>> > enough,
>> > > > there is still a ClassNotFoundException
>> > > > (org.apache.activemq.xbean.XBeanBrokerFactory) when using
>> > > > 'xbean:file:conf/activemq.xml'. It looks like the activemq-spring jar
>> > is
>> > > > also required here.
>> > > >
>> > > > 2/ Maybe I missed something here, but I was not able to load the
>> > > > activemq.xml file using a relative path as suggested in TomEE
>> > > > documentation. I just keep getting a FileNotFoundException.
>> > > >
>> > > >
>> > > > Do you think we could improve the user experience wrt integrating the
>> > > > activemq.xml configuration file ? Maybe by making this a bit clearer
>> > and
>> > > > easier to get all the required dependencies ?
>> > > > Adding a way to declare AMQ plugins within tomee configuration file -
>> > as
>> > > > suggested by previous posts - would also make it simpler for users.
>> > > > Although I agree it would be better to stick to AMQ configuration
>> > syntax.
>> > > > And about point 2, did I miss something ?
>> > > >
>> > > > Thanks.
>> > > >
>> > > > --
>> > > > Marian MULLER
>> > > > SERLI
>> > > >
>> > > >
>> > > > On Fri, May 30, 2014 at 2:53 PM, Andy Gumbrecht <
>> > > [email protected]>
>> > > > wrote:
>> > > >
>> > > > > Hi Marian,
>> > > > >
>> > > > > I have always been of the opinion that the default configuration is
>> > the
>> > > > > simple way, and more complex scenarios need a more complex
>> solution,
>> > > > > and a really deep understanding of ActiveMQ configuration.
>> > > > >
>> > > > > The simple solution is seen as a localhost/vm only solution which
>> > never
>> > > > > goes outside the box - The clients do not see or access the MQ
>> > > directly.
>> > > > >
>> > > > > The complex solutions starts with your scenario - Clients should
>> have
>> > > > > remote access and authenticate (and that is a massive step, not to
>> be
>> > > > taken
>> > > > > lightly).
>> > > > >
>> > > > > So where to address that?
>> > > > >
>> > > > > Romain's plugin idea works, but seems like an awful lot of work to
>> > > > replace
>> > > > > something that is in effect already there -
>> > > > > The 'xbean:file:conf/activemq.xml'.
>> > > > >
>> > > > > I was also initially annoyed by the whole Spring requirement for a
>> > > > > 'simple' XML file, but that's an ActiveMQ issue which we have to
>> live
>> > > > with
>> > > > > if we want to configure it.
>> > > > > Once you use it there really is no issue. To add all that endless
>> > > > > functionality to OpenEJB is really outside the box in my opinion. A
>> > few
>> > > > > megs of jars isn't really such a big issue.
>> > > > >
>> > > > > If you start to dig in to ActiveMQ conf (
>> http://activemq.apache.org/
>> > > > > version-5-xml-configuration.html) then you'll understand why they
>> > maybe
>> > > > > opted for the Spring XBean configuration.
>> > > > >
>> > > > > What is your greater picture here? Why do you want to allow remote
>> MQ
>> > > > > clients to authenticate?
>> > > > >
>> > > > > If we start talking about local application authentication then
>> think
>> > > > > 'TomEE cluster', then you're only going to have one ActiveMQ server
>> > > > > (standalone, and maybe also a cluster) - Aligning authentication
>> with
>> > > > TomEE
>> > > > > is probably not going to work.
>> > > > >
>> > > > > A JDBC realm could be a solution - Both servers authenticate can
>> > > > > authenticate against it.
>> > > > >
>> > > > > But really you'd only need one ActiveMQ user/pw per application.
>> > > > >
>> > > > > Andy.
>> > > > >
>> > > > >
>> > > > > On 30/05/2014 11:35, Marian Muller wrote:
>> > > > >
>> > > > >> Hi all,
>> > > > >>
>> > > > >> For starters, let me introduce myself. I am Marian Muller and I
>> work
>> > > as
>> > > > a
>> > > > >> Java EE engineer at SERLI. As part of my job, I will dedicate some
>> > > time
>> > > > to
>> > > > >> contributing to TomEE.
>> > > > >>
>> > > > >> I am working on a simpler way to configure authentication in the
>> > > > embedded
>> > > > >> ActiveMQ broker. Currently, you can easily start the embedded
>> broker
>> > > > using
>> > > > >> just a few lines of xml:
>> > > > >>
>> > > > >>
>> > > > >> <Resource id="MyJmsResourceAdapter"
>> type="ActiveMQResourceAdapter">
>> > > > >>> BrokerXmlConfig = broker:(tcp://someHostName:61616)
>> > > > >>> ServerUrl = vm://localhost
>> > > > >>> </Resource>
>> > > > >>>
>> > > > >>>
>> > > > >> But if you want to add authentication to the broker, you need to
>> > write
>> > > > an
>> > > > >> ActiveMQ xml configuration file, and - that feels a bit wrong -
>> you
>> > > need
>> > > > >> to
>> > > > >> add Spring and ActiveMQ libraries in TomEE! (see
>> > > > >> http://tomee.apache.org/jms-resources-and-mdb-container.html)
>> > > > >>
>> > > > >> <Resource id="MyJmsResourceAdapter"
>> type="ActiveMQResourceAdapter">
>> > > > >>
>> > > > >>> BrokerXmlConfig = xbean:file:conf/activemq.xml
>> > > > >>> ServerUrl = tcp://someHostName:61616</Resource>
>> > > > >>>
>> > > > >>>
>> > > > >>> I looked up how the ActiveMQ embedded broker is configured and
>> > > > started,
>> > > > >> and
>> > > > >> I think it should be possible to add an option to the resource
>> > adapter
>> > > > to
>> > > > >> specify basic user/password authentication. Now I am wondering
>> what
>> > > this
>> > > > >> option should look like ? I see at least three possibilities:
>> > > > >>
>> > > > >> a) Specify a list of (username/password/groups) directly in the
>> > > > >> ResourceAdapter options (in tomee.xml). This feels a bit tedious,
>> > > would
>> > > > >> clutter the config file and would require to define a specific
>> > syntax.
>> > > > >> b) Specify the path to a file (xml? properties? ...), containing
>> the
>> > > > list
>> > > > >> of (username/password/groups). This would lighten the
>> configuration
>> > > file
>> > > > >> (tomee.xml) by moving away the verbose stuff.
>> > > > >> c) Maybe we could reuse the existing user database from
>> > > > >> conf/tomcat-users.xml ? This way we only need a single file to
>> > > configure
>> > > > >> all the users.
>> > > > >>
>> > > > >>
>> > > > >> This is for the simple username/password authentication, which
>> would
>> > > use
>> > > > >> ActiveMQ's SimpleAuthenticationPlugin.
>> > > > >>
>> > > > >> Now maybe a better way to add JMS authentication would be to reuse
>> > the
>> > > > >> existing Realm, which can be configured by the users. This would
>> > > > probably
>> > > > >> require to write a custom ActiveMQ plugin that checks
>> authentication
>> > > > >> against the realm. But this would open much more authentication
>> > > options!
>> > > > >> Now, if you don't mind, I could use some pointers on how to reuse
>> > this
>> > > > >> Realm, and also how to define another realm for JMS authentication
>> > (if
>> > > > the
>> > > > >> user wants so)?
>> > > > >> To me, this feels like a better way to centralize authentication
>> in
>> > > > Tomcat
>> > > > >> Realms!
>> > > > >>
>> > > > >> What do you think? How do you see JMS authentication?
>> > > > >> Please tell me if I am going the wrong way here.
>> > > > >> I could definitely use the community feedback here! :)
>> > > > >>
>> > > > >> Thank you.
>> > > > >> --
>> > > > >> Marian MULLER
>> > > > >> SERLI
>> > > > >>
>> > > > >>
>> > > > > --
>> > > > > Andy Gumbrecht
>> > > > >
>> > > > > http://www.tomitribe.com
>> > > > > [email protected]
>> > > > > https://twitter.com/AndyGeeDe
>> > > > >
>> > > > > TomEE treibt Tomitribe! | http://tomee.apache.org
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
