> Yes, hashes should be stored somewhere, e.g. in surviving records, but my point was about operational journal.
I don't understand what you mean. The "surviving records" are *in* the "operational journal." The "data print" command simply lists the surviving records as a convenience for readability. Can you clarify exactly what you mean by "operational journal"? Is that different in some way from just the "journal"? > If hash is stored for some time and hash changes during that time can be seen, I'm sure some clever mind will find a way to exploit this. Are you talking about if the algorithm used to hash the password is changed during this time or just if the user changes their password and the hash for that new password is therefore changed? In any case, secure hash algorithms are designed specifically for this kind of use-case (i.e. storing passwords) so I would expect reverse engineering the actual password from the hash would be difficult. > Artemis CLI already masks these hashes for some reason, no? :) I'm not sure what you mean. The hashed password is the *result* of this process. A hashed password isn't then masked. The "mask" command available from the Artemis CLI can be used for two different reasons: 1. To hash the password. This is done for user passwords and is considered a "one-way" operation. In other words, the original password cannot be derived from the hash by design. 2. To mask the password. This is done for configuration-based passwords, and it is considered a "two-way" operation. In other words, the broker can derive the original password from the masked value so that it can actually use the password (e.g. for opening an SSL keystore, connecting to a database, etc.). The hash stored in the journal is the first kind. > I was not aware that operational journal is cleared, that's good to know. It's not "cleared" per se. Stale data is simply removed and the space created from the removed records is re-used by existing records. That is why this process is referred to as "compaction." > I'm not sure if that's done automatically at some interval or not... It's done automatically based on the values configured for journal-compact-min-files and journal-compact-percentage which you can read more about in the documentation [1]. > I agree that this is not major issue, but still can be easily solved by just not storing hashes in operational journal at all. The entire point of the basic security manager is to store the hashed passwords in the journal so that those values are shared by the backup. If you removed them from the journal you would completely defeat the purpose. Justin [1] https://activemq.apache.org/components/artemis/documentation/latest/persistence.html On Mon, Apr 4, 2022 at 2:02 PM Vilius Šumskas <[email protected]> wrote: > Yes, hashes should be stored somewhere, e.g. in surviving records, but my > point was about operational journal. For me it is the same as storing > password hashes in plaintext *log* files. If hash is stored for some time > and hash changes during that time can be seen, I'm sure some clever mind > will find a way to exploit this. Artemis CLI already masks these hashes for > some reason, no? :) > > I was not aware that operational journal is cleared, that's good to know. > I'm not sure if that's done automatically at some interval or not, but it > still means that hashes exist in the operational journal during that > interval. I agree that this is not major issue, but still can be easily > solved by just not storing hashes in operational journal at all. > > -- > Best Regards, > Vilius > > -----Original Message----- > From: Justin Bertram <[email protected]> > Sent: Monday, April 4, 2022 7:22 PM > To: [email protected] > Subject: Re: ActiveMQBasicSecurityManager configuration examples > > > I think it is not a very good idea to store such kind of information > > in > operational journal, even if that's just hashes. > > The hashes have to be stored somewhere, whether that's in the journal, in > properties files, in a database, in an LDAP server, etc. It's not clear to > me that the journal is necessarily any worse than anywhere else. > > > Administrators could be unaware that this information exist even after > they removed the user itself... but that another story. > > For what it's worth, stale records will be removed from the journal by the > compaction process which runs automatically during broker runtime or you > can compact the journal manually using the "data compact" command. > > > Justin > > On Thu, Mar 31, 2022 at 4:18 PM Vilius Šumskas <[email protected]> > wrote: > > > Looks like you are right. I was looking at raw .bindings files with > > just a simple text editor. When looking via "artemis data print" I can > > see that there are multiple AddRecord operations but just one record > > in surviving records which is correct. > > > > Anyway, I have decided to remove bootstrap configuration after the > > initial start-up. This way I will have less admin password hashes > > exposed. I think it is not a very good idea to store such kind of > > information in operational journal, even if that's just hashes. > > Administrators could be unaware that this information exist even after > > they removed the user itself... but that another story. > > > > Thank you again for all the pointers and help. > > > > -- > > Vilius > > > > -----Original Message----- > > From: Justin Bertram <[email protected]> > > Sent: Wednesday, March 30, 2022 7:00 AM > > To: [email protected] > > Subject: Re: ActiveMQBasicSecurityManager configuration examples > > > > For what it's worth, I just spun up a fresh instance of Artemis 2.21.0 > > with the basic security manager and I started and stopped the broker a > > handful of times and the bindings data looks fine to me. Are you > > looking at the "Surviving Records Summary"? That is where you should > > be looking for what will actually be loaded back into memory from the > > journal when the broker restarts. If you look at the raw data you may > > see a number of AddRecord and DeleteRecord operations with similar > > data, but that is just a function of the way the write-only journal > works. > > > > > > Justin > > > > On Tue, Mar 29, 2022 at 10:49 PM Justin Bertram <[email protected]> > > wrote: > > > > > I would say that's a bug. > > > > > > > > > Justin > > > > > > On Tue, Mar 29, 2022 at 4:58 PM Vilius Šumskas > > > <[email protected]> > > > wrote: > > > > > >> Hello, > > >> > > >> >> Would you still advice to remove bootstrapUser configuration > > >> >> after the > > >> environment is built, or generally it should not be an issue? > > >> > > > >> > There's no technical reason to remove the bootstrap credentials. > > >> > If it > > >> makes more sense for your use-case for them to remain in the > > >> configuration then by all means leave them. > > >> > > >> I have had time to experiment with this today. > > >> I found that if I leave bootstrap credentials in the configuration > > >> these credentials are adding new entry to the binding files after > > >> every restart of the broker. When viewing user list via "artemis > > >> user list" the user count is correct, it's just bindings content is > > duplicated again and again. > > >> > > >> Is this a bug, or by design, and should I re-think this by removing > > >> boostrap configuration if I don't want to waste space? > > >> > > >> -- > > >> Vilius > > >> > > >> -----Original Message----- > > >> From: Justin Bertram <[email protected]> > > >> Sent: Friday, March 25, 2022 5:14 PM > > >> To: [email protected] > > >> Subject: Re: ActiveMQBasicSecurityManager configuration examples > > >> > > >> > Would you still advice to remove bootstrapUser configuration > > >> > after the > > >> environment is built, or generally it should not be an issue? > > >> > > >> There's no technical reason to remove the bootstrap credentials. If > > >> it makes more sense for your use-case for them to remain in the > > >> configuration then by all means leave them. > > >> > > >> > Since we will be having thousands of users, how Artemis > > >> > requirements > > >> changes moving away from PropertiesLogin and putting everything > > >> into the binding journal? For example, do we need much more RAM to > > >> run such instance? Maybe something else? Some technical limit > > >> regarding user count or binding journal size? > > >> > > >> I wouldn't expect any substantial change in requirements. However, > > >> the only way to know that is with careful testing. I would expect > > >> the basic security manager to be a bit faster since it uses the > > >> journal which is optimized for speed, but I wouldn't expect the > > >> difference to > > be significant. > > >> > > >> > > >> Justin > > >> > > >> On Thu, Mar 24, 2022 at 3:56 PM Vilius Šumskas > > >> <[email protected]> > > >> wrote: > > >> > > >> > Thank you for very detailed answers! This helps a lot actually. > > >> > > > >> > Follow-up question regarding item 5. We have an internal policy > > >> > to control our infrastructure via code and scripts so that > > >> > testing and staging environments can be built and destroyed > > >> > on-demand. Artemis is part of that infrastructure. Essentially > > >> > this means that everything is done in two > > >> > steps: a) infra configuration, b) pre-population of data needed > > >> > for testing. Infrastructure should not be re-configured/restarted > > >> > after > > >> step b). > > >> > In addition, we have three types of Artemis users: 1) > > >> > administrator accounts, mostly for Hawtio and cli management, 2) > > >> > users used by internal SaaS app backend services, 3) users for our > external clients. > > >> > > > >> > Given all of the above, I was thinking to pre-populate and mask > > >> > passwords in .properties files for type 1 and 2 accounts, leave > > >> > the bootstrapUser configuration present, and then automated tests > > >> > will create type 3 accounts as needed. > > >> > > > >> > Would you still advice to remove bootstrapUser configuration > > >> > after the environment is built, or generally it should not be an > issue? > > >> > > > >> > And one last question regarding ActiveMQBasicSecurityManager as a > > whole. > > >> > Since we will be having thousands of users, how Artemis > > >> > requirements changes moving away from PropertiesLogin and putting > > >> > everything into the binding journal? For example, do we need much > > >> > more RAM to run such instance? Maybe something else? Some > > >> > technical limit regarding user count or binding journal size? > > >> > > > >> > -- > > >> > Vilius > > >> > > > >> > -----Original Message----- > > >> > From: Justin Bertram <[email protected]> > > >> > Sent: Thursday, March 24, 2022 9:43 PM > > >> > To: [email protected] > > >> > Subject: Re: ActiveMQBasicSecurityManager configuration examples > > >> > > > >> > > 1. Is it enough to configure <security-manager> in bootstrap.xml? > > >> > > Do I > > >> > need to remove <jaas-security domain="activemq"/> line? Do I also > > >> > somehow change login.config? Currently it is configured to use > > >> > default PropertiesLogin JAAS module. > > >> > > > >> > You should remove the jaas-security configuration. As far as the > > >> > basic security manager is concerned you don't need to change > > login.config. > > >> > The basic security manager doesn't use JAAS at all (as noted in > > >> > the documentation [1]) so it isn't concerned with the contents of > > >> login.config. > > >> > > > >> > > 2. How do I separate Hawtio authentication from broker > > >> authentication? > > >> > Does this mean I have to separate default “activemq” realm, use > > >> > that different realm when starting Hawtio and then change > > >> > login.config so it includes both realms using different > > authentication modules? > > >> > > > >> > Hawtio uses JAAS internally and it is configured via system > > >> > properties in etc/artemis.profile. It will continue to use JAAS > > >> > while the broker uses the basic security manager. > > >> > > > >> > > 4. Can I use the same .properties file for both, populate > > >> > ActiveMQBasicSecurityManager bootstrap user credentials, and > > >> > Hawtio authentication? > > >> > > > >> > I suppose you could do that. > > >> > > > >> > > 5. How bootstrapUser and bootstrapPassword works in cluster > > >> > > environment > > >> > if binding journal already contains the same user? Let’s say I > > >> > restart primary and backup becomes live, but earlier I have > > >> > changed the password via management API using other means? Should > > >> > I set bootstrapUser configuration in all cluster nodes or just in > primary? > > >> > > > >> > As noted in the documentation [1], "Any bootstrap credentials > > >> > will be set whenever you start the broker no matter what changes > > >> > may have been made to them at runtime previously." The idea is to > > >> > boot the broker instance for the first time with a bootstrap user > > >> > that can be used to add all the necessary users and roles to the > > >> > journal and then you remove the boostrap user from bootstrap.xml > thereafter. > > >> > > > >> > > 6. From our code perspective, can we still use > > >> > JMSManagementHelper.putOperationInvocation() with "addUser" > > >> > operation to add/delete users dynamically, or do we need to use > > different API? > > >> > > > >> > No. You'll use the same management operations. However, those > > >> > operations will modify the accounts in the journal rather than > > >> > the > > >> properties files. > > >> > > > >> > > 7. Is there a tool to at least list all the users in the > > >> > > journal, or > > >> > this is only possible calling some kind of API? > > >> > > > >> > You can use the management API to list the users (including the > > >> > CLI "user list" command). You can also print the raw contents of > > >> > the journal using the CLI "data print" command. User account info > > >> > will be listed as part of the bindings. > > >> > > > >> > > 8. From the security perspective, are users’ passwords in > > >> > > binding > > >> > journal properly hashed and cannot be retrieved if someone pokes > > >> > at the data? > > >> > > > >> > If you tell the API to hash the passwords then they will be hashed. > > >> > > > >> > Hope that helps! > > >> > > > >> > > > >> > Justin > > >> > > > >> > [1] > > >> > > > >> > https://activemq.apache.org/components/artemis/documentation/late > > >> > st > > >> > /se > > >> > curity.html#basic-security-manager > > >> > > > >> > On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas > > >> > <[email protected]> > > >> > wrote: > > >> > > > >> > > Hello list, > > >> > > > > >> > > since, according to documentation, PropertiesLogin JAAS module > > >> > > is not recommended for production use, and .properties files > > >> > > are not synched in a cluster environment, we are now searching > > >> > > for possible authentication alternatives. > > >> > > > > >> > > At first I thought to build a Keycloak cluster, but reading > > >> > > through documentation I found that there is such a thing as > > >> > > ActiveMQBasicSecurityManager which should be enough (our case: > > >> > > thousands of external MQ clients using different Artemis user > > >> > > each, to separate their JMS queue data). > > >> > > > > >> > > Unfortunately documentation is a bit scarce on the examples how > > >> > > exactly ActiveMQBasicSecurityManager is configured, and > > >> > > internet search returns almost nothing, so I’m sorry in advance > > >> > > for a lot of > > >> > questions. > > >> > > > > >> > > 1. Is it enough to configure <security-manager> in > bootstrap.xml? > > >> > > Do I need to remove <jaas-security domain="activemq"/> line? Do > > >> > > I also somehow change login.config? Currently it is configured > > >> > > to use default PropertiesLogin JAAS module. > > >> > > 2. How do I separate Hawtio authentication from broker > > >> authentication? > > >> > > Does this mean I have to separate default “activemq” realm, use > > >> > > that different realm when starting Hawtio and then change > > >> > > login.config so it includes both realms using different > > authentication modules? > > >> > > 3. If the above answer is yes, is there an example somewhere > > >> > > how ActiveMQBasicSecurityManager is configured in login.config > > >> > > and what are the options? > > >> > > 4. Can I use the same .properties file for both, populate > > >> > > ActiveMQBasicSecurityManager bootstrap user credentials, and > > >> > > Hawtio authentication? > > >> > > 5. How bootstrapUser and bootstrapPassword works in cluster > > >> > > environment if binding journal already contains the same user? > > >> > > Let’s say I restart primary and backup becomes live, but > > >> > > earlier I have changed the password via management API using > other means? > > >> > > Should I set bootstrapUser configuration in all cluster nodes > > >> > > or just in > > >> primary? > > >> > > 6. From our code perspective, can we still use > > >> > > JMSManagementHelper.putOperationInvocation() with "addUser" > > >> > > operation to add/delete users dynamically, or do we need to use > > >> different API? > > >> > > 7. Is there a tool to at least list all the users in the > > >> > > journal, or this is only possible calling some kind of API? > > >> > > 8. From the security perspective, are users’ passwords in > > >> > > binding journal properly hashed and cannot be retrieved if > > >> > > someone pokes at the data? > > >> > > > > >> > > Thank you in advance for any pointers. > > >> > > > > >> > > -- > > >> > > Best Regards, > > >> > > > > >> > > Vilius Šumskas > > >> > > Rivile > > >> > > IT manager > > >> > > +370 614 75713 > > >> > > > > >> > > > > >> > > > >> > > > > > >
