Hi Ken, I don't say that you should test/use Karaf, it's just to illustrate that's probably a runtime related topic. In the case of "standalone" runtime (and probably webconsole), so it might impact the users integrating ActiveMQ (for instance in a servlet container or so). We have to be careful in what we push in broker core, avoiding to impact the runtimes.
Regards JB On Tue, Nov 5, 2024 at 7:04 AM Ken Liao <kenlia...@gmail.com> wrote: > > Thanks JB. I wasn't aware of using Karaf with ActiveMQ. Will try to set it > up first and see what the experience looks like. > > Thanks, > Ken > > On Fri, Nov 1, 2024 at 11:12 PM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > Hi Ken > > > > The behavior you describe is correct when using ActiveMQ standalone. > > If you are running ActiveMQ in Karaf, you already have a behavior > > similar to what you describe: the users/roles can be managed by in > > Karaf realms, no need to restart the broker. > > > > I like your idea, but it should be optional as a lot of users > > integrate ActiveMQ in their ecosystem, so with authentication plugin > > to plug into their system. > > > > So, I agree with the proposal as long as the current plugins system is > > still available. > > I think we can implement what you are proposing as its own plugin > > (including web console plugins). > > > > Regards > > JB > > > > On Fri, Nov 1, 2024 at 8:07 AM Ken Liao <kenlia...@gmail.com> wrote: > > > > > > Hi ActiveMQ community, > > > > > > I am asking for opinion and buy-in on an idea I have lately before diving > > > into implementation. The idea is a new user management experience in > > > ActiveMQ Classic. > > > > > > Right now, the way to provision new users on ActiveMQ Classic with > > default > > > JAAS plugin (and assuming not using LDAP) is by changing a few > > > configuration files and restarting the broker. There are a few drawbacks > > > with the current approach: > > > 1. Knowing which files to change and actually changing them correctly > > > require technical knowledge and needs to be performed by someone who has > > > access to the host servers. > > > 2. It is prone to human error (typo ... etc) that can cause the broker to > > > fail on startup. > > > 3. Any change to users will require a reboot of the broker, which reduces > > > the availability of the broker. > > > > > > Hence I am proposing a new user management experience that has two > > > important improvements: > > > 1. Broker users can be provisioned, removed and modified by an admin user > > > (who may not have technical knowledge or access to the server host) using > > > the web console of the broker. The admin can also use it to modify > > > authorization policy of each user on different destination via intuitive > > > UI. > > > 2. Any change made will kick in real-time without broker restart. > > > > > > Would love to get the community's opinion, potential concern ... etc on > > the > > > idea before following up with a design / requirement proposal. > > > > > > What do you think? Thanks. > > > > > > Regards, > > > Ken > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > For additional commands, e-mail: dev-h...@activemq.apache.org > > For further information, visit: https://activemq.apache.org/contact > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org For additional commands, e-mail: dev-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
