Basically provide what you need (or what you think you'll need) - and what you find fun ;). If sby needs more we'll add it later.
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 15:14 GMT+02:00 Marian Muller <[email protected]>: > 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 >> >> > > > > >> >> > > > > >> >> > > > >> >> > > >> >> > >> >> >>
