The AuthorizationPlugin would also require to specify the destination type. And maybe the support for temp destinations configuration. This plugin also supports different kinds of "authorization maps", including LDAP and CachedLDAP. But maybe this is out of the scope for now.
Regarding the generic resource factory, in the beginning I felt like I was missing this kind of feature. But factories really do the job and allow to customize the configuration. Compared to factories, I think a generic resource factory would lead to less readable configuration (multiple resources to declare), and - depending on the class structure - may not solve all the problems (e.g. complex collection attributes, like a Map<String, Set<...>> would still not be supported). Anyway I will define a configuration/factory for AuthorizationPlugin. Regarding the factories, do you think this is OK to provide a limited set for a few plugins? -- Marian MULLER SERLI On Thu, Jun 5, 2014 at 2:38 PM, Romain Manni-Bucau <[email protected]> wrote: > 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 > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> >
