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
