You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Vilius Šumskas <vi...@rivile.lt> on 2022/03/24 16:00:24 UTC
ActiveMQBasicSecurityManager configuration examples
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
RE: ActiveMQBasicSecurityManager configuration examples
Posted by Vilius Šumskas <vi...@rivile.lt>.
I'm talking about single master/slave pair using NFS as shared storage.
--
Vilius
-----Original Message-----
From: Justin Bertram <jb...@apache.org>
Sent: Thursday, March 24, 2022 6:25 PM
To: users@activemq.apache.org
Subject: Re: ActiveMQBasicSecurityManager configuration examples
When you say "cluster environment" are you talking about multiple master brokers or just a single master/slave pair? ActiveMQBasicSecurityManager only provides synchronization between master/slave pairs. It doesn't provide any synchronization for multiple master brokers. You'd need to use a centralized repository for that (e.g. LDAP).
Justin
On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas <vi...@rivile.lt>
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
>
>
Re: ActiveMQBasicSecurityManager configuration examples
Posted by Justin Bertram <jb...@apache.org>.
When you say "cluster environment" are you talking about multiple master
brokers or just a single master/slave pair? ActiveMQBasicSecurityManager
only provides synchronization between master/slave pairs. It doesn't
provide any synchronization for multiple master brokers. You'd need to use
a centralized repository for that (e.g. LDAP).
Justin
On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas <vi...@rivile.lt>
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
>
>
RE: ActiveMQBasicSecurityManager configuration examples
Posted by Vilius Šumskas <vi...@rivile.lt>.
Thank you again. I have improved docs a bit so other can find it as needed https://github.com/apache/activemq-artemis/pull/4000
--
Best Regards,
Vilius
-----Original Message-----
From: Justin Bertram <jb...@apache.org>
Sent: Friday, March 25, 2022 5:14 PM
To: users@activemq.apache.org
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 <vi...@rivile.lt>
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 <jb...@apache.org>
> Sent: Thursday, March 24, 2022 9:43 PM
> To: users@activemq.apache.org
> 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/latest/se
> curity.html#basic-security-manager
>
> On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas
> <vi...@rivile.lt>
> 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
> >
> >
>
RE: ActiveMQBasicSecurityManager configuration examples
Posted by Vilius Šumskas <vi...@rivile.lt>.
Good to know, that previous email almost gave me heart attack :)
--
Vilius
-----Original Message-----
From: Justin Bertram <jb...@apache.org>
Sent: Thursday, April 7, 2022 10:28 PM
To: users@activemq.apache.org
Subject: Re: ActiveMQBasicSecurityManager configuration examples
> Wait, so does this mean that if I add or delete a user I have to
> restart
a broker for the ActiveMQBasicSecurityManager to pickup changes?
Certainly not. The data structures in memory are modified in real-time and those modifications are also written to the journal so they can be recovered when the broker restarts. It wouldn't be very useful if it worked the way you describe.
Justin
On Thu, Apr 7, 2022 at 2:15 PM Vilius Šumskas <vi...@rivile.lt>
wrote:
> Wait, so does this mean that if I add or delete a user I have to
> restart a broker for the ActiveMQBasicSecurityManager to pickup changes?
>
> --
> Vilius
>
> -----Original Message-----
> From: Justin Bertram <jb...@apache.org>
> Sent: Thursday, April 7, 2022 9:31 PM
> To: users@activemq.apache.org
> Subject: Re: ActiveMQBasicSecurityManager configuration examples
>
> > It still beyond me how this kind of data structure actually works
> > during
> authentication on every connection then, but you probably can ignore
> what I said earlier regarding hashes.
>
> The journal is irrelevant at runtime during authentication. When the
> broker starts it reads the contents of the journal into memory. That's
> the whole purpose of the journal. The journal is never read again
> after that until the broker is restarted. As users are added, removed, modified, etc.
> the broker writes new records to the journal, but nothing is read from
> or written to the journal during authentication. The broker simply
> uses the data it has in memory.
>
>
> Justin
>
> On Thu, Apr 7, 2022 at 1:20 PM Vilius Šumskas
> <vi...@rivile.lt>
> wrote:
>
> > >> Correct me if I'm wrong on my understandings. My proposal was to
> > >> not
> > > store hashes (or plaintext passwords) in b) type records.
> >
> > > As far as I can tell, you believe that "surviving records" and
> > "operational records" are two fundamentally different things which
> > is, in fact, not the case. As I noted in a previous email, the "data print"
> > command simply lists the "surviving records" as a convenience for
> > readability. The only kinds of records which *actually exist* in the
> > journal are the "operational records."
> >
> > > To use an analogy, surviving records are to operational records as
> > > net
> > income is to gross income.
> >
> > I see. It still beyond me how this kind of data structure actually
> > works during authentication on every connection then, but you
> > probably can ignore what I said earlier regarding hashes.
> >
> > > If that happens you can run the "data compact" command to remove
> > > any
> > stale operational records that contain the plaintext password(s).
> >
> > I agree, however to actually *know* that you have to run "data compact"
> > one must know how journal works. But I guess that's another question
> > for another day.
> >
> > Thank you for detailed explanations!
> >
> > --
> > Vilius
> >
>
Re: ActiveMQBasicSecurityManager configuration examples
Posted by Justin Bertram <jb...@apache.org>.
> Wait, so does this mean that if I add or delete a user I have to restart
a broker for the ActiveMQBasicSecurityManager to pickup changes?
Certainly not. The data structures in memory are modified in real-time and
those modifications are also written to the journal so they can be
recovered when the broker restarts. It wouldn't be very useful if it worked
the way you describe.
Justin
On Thu, Apr 7, 2022 at 2:15 PM Vilius Šumskas <vi...@rivile.lt>
wrote:
> Wait, so does this mean that if I add or delete a user I have to restart a
> broker for the ActiveMQBasicSecurityManager to pickup changes?
>
> --
> Vilius
>
> -----Original Message-----
> From: Justin Bertram <jb...@apache.org>
> Sent: Thursday, April 7, 2022 9:31 PM
> To: users@activemq.apache.org
> Subject: Re: ActiveMQBasicSecurityManager configuration examples
>
> > It still beyond me how this kind of data structure actually works
> > during
> authentication on every connection then, but you probably can ignore what
> I said earlier regarding hashes.
>
> The journal is irrelevant at runtime during authentication. When the
> broker starts it reads the contents of the journal into memory. That's the
> whole purpose of the journal. The journal is never read again after that
> until the broker is restarted. As users are added, removed, modified, etc.
> the broker writes new records to the journal, but nothing is read from or
> written to the journal during authentication. The broker simply uses the
> data it has in memory.
>
>
> Justin
>
> On Thu, Apr 7, 2022 at 1:20 PM Vilius Šumskas <vi...@rivile.lt>
> wrote:
>
> > >> Correct me if I'm wrong on my understandings. My proposal was to
> > >> not
> > > store hashes (or plaintext passwords) in b) type records.
> >
> > > As far as I can tell, you believe that "surviving records" and
> > "operational records" are two fundamentally different things which is,
> > in fact, not the case. As I noted in a previous email, the "data print"
> > command simply lists the "surviving records" as a convenience for
> > readability. The only kinds of records which *actually exist* in the
> > journal are the "operational records."
> >
> > > To use an analogy, surviving records are to operational records as
> > > net
> > income is to gross income.
> >
> > I see. It still beyond me how this kind of data structure actually
> > works during authentication on every connection then, but you probably
> > can ignore what I said earlier regarding hashes.
> >
> > > If that happens you can run the "data compact" command to remove any
> > stale operational records that contain the plaintext password(s).
> >
> > I agree, however to actually *know* that you have to run "data compact"
> > one must know how journal works. But I guess that's another question
> > for another day.
> >
> > Thank you for detailed explanations!
> >
> > --
> > Vilius
> >
>
RE: ActiveMQBasicSecurityManager configuration examples
Posted by Vilius Šumskas <vi...@rivile.lt>.
Wait, so does this mean that if I add or delete a user I have to restart a broker for the ActiveMQBasicSecurityManager to pickup changes?
--
Vilius
-----Original Message-----
From: Justin Bertram <jb...@apache.org>
Sent: Thursday, April 7, 2022 9:31 PM
To: users@activemq.apache.org
Subject: Re: ActiveMQBasicSecurityManager configuration examples
> It still beyond me how this kind of data structure actually works
> during
authentication on every connection then, but you probably can ignore what I said earlier regarding hashes.
The journal is irrelevant at runtime during authentication. When the broker starts it reads the contents of the journal into memory. That's the whole purpose of the journal. The journal is never read again after that until the broker is restarted. As users are added, removed, modified, etc. the broker writes new records to the journal, but nothing is read from or written to the journal during authentication. The broker simply uses the data it has in memory.
Justin
On Thu, Apr 7, 2022 at 1:20 PM Vilius Šumskas <vi...@rivile.lt>
wrote:
> >> Correct me if I'm wrong on my understandings. My proposal was to
> >> not
> > store hashes (or plaintext passwords) in b) type records.
>
> > As far as I can tell, you believe that "surviving records" and
> "operational records" are two fundamentally different things which is,
> in fact, not the case. As I noted in a previous email, the "data print"
> command simply lists the "surviving records" as a convenience for
> readability. The only kinds of records which *actually exist* in the
> journal are the "operational records."
>
> > To use an analogy, surviving records are to operational records as
> > net
> income is to gross income.
>
> I see. It still beyond me how this kind of data structure actually
> works during authentication on every connection then, but you probably
> can ignore what I said earlier regarding hashes.
>
> > If that happens you can run the "data compact" command to remove any
> stale operational records that contain the plaintext password(s).
>
> I agree, however to actually *know* that you have to run "data compact"
> one must know how journal works. But I guess that's another question
> for another day.
>
> Thank you for detailed explanations!
>
> --
> Vilius
>
Re: ActiveMQBasicSecurityManager configuration examples
Posted by Justin Bertram <jb...@apache.org>.
> It still beyond me how this kind of data structure actually works during
authentication on every connection then, but you probably can ignore what I
said earlier regarding hashes.
The journal is irrelevant at runtime during authentication. When the broker
starts it reads the contents of the journal into memory. That's the whole
purpose of the journal. The journal is never read again after that until
the broker is restarted. As users are added, removed, modified, etc. the
broker writes new records to the journal, but nothing is read from or
written to the journal during authentication. The broker simply uses the
data it has in memory.
Justin
On Thu, Apr 7, 2022 at 1:20 PM Vilius Šumskas <vi...@rivile.lt>
wrote:
> >> Correct me if I'm wrong on my understandings. My proposal was to not
> > store hashes (or plaintext passwords) in b) type records.
>
> > As far as I can tell, you believe that "surviving records" and
> "operational records" are two fundamentally different things which is, in
> fact, not the case. As I noted in a previous email, the "data print"
> command simply lists the "surviving records" as a convenience for
> readability. The only kinds of records which *actually exist* in the
> journal are the "operational records."
>
> > To use an analogy, surviving records are to operational records as net
> income is to gross income.
>
> I see. It still beyond me how this kind of data structure actually works
> during authentication on every connection then, but you probably can ignore
> what I said earlier regarding hashes.
>
> > If that happens you can run the "data compact" command to remove any
> stale operational records that contain the plaintext password(s).
>
> I agree, however to actually *know* that you have to run "data compact"
> one must know how journal works. But I guess that's another question for
> another day.
>
> Thank you for detailed explanations!
>
> --
> Vilius
>
RE: ActiveMQBasicSecurityManager configuration examples
Posted by Vilius Šumskas <vi...@rivile.lt>.
>> Correct me if I'm wrong on my understandings. My proposal was to not
> store hashes (or plaintext passwords) in b) type records.
> As far as I can tell, you believe that "surviving records" and "operational records" are two fundamentally different things which is, in fact, not the case. As I noted in a previous email, the "data print" command simply lists the "surviving records" as a convenience for readability. The only kinds of records which *actually exist* in the journal are the "operational records."
> To use an analogy, surviving records are to operational records as net income is to gross income.
I see. It still beyond me how this kind of data structure actually works during authentication on every connection then, but you probably can ignore what I said earlier regarding hashes.
> If that happens you can run the "data compact" command to remove any stale operational records that contain the plaintext password(s).
I agree, however to actually *know* that you have to run "data compact" one must know how journal works. But I guess that's another question for another day.
Thank you for detailed explanations!
--
Vilius
Re: ActiveMQBasicSecurityManager configuration examples
Posted by Justin Bertram <jb...@apache.org>.
> Correct me if I'm wrong on my understandings. My proposal was to not
store hashes (or plaintext passwords) in b) type records.
As far as I can tell, you believe that "surviving records" and "operational
records" are two fundamentally different things which is, in fact, not the
case. As I noted in a previous email, the "data print" command simply lists
the "surviving records" as a convenience for readability. The only kinds of
records which *actually exist* in the journal are the "operational records."
To use an analogy, surviving records are to operational records as net
income is to gross income.
> For example, there could be cases where the instance is migrated from
plaintext to hashed passwords.
You should never store passwords in plaintext in any environment where
security matters. If that happens, for whatever reason, there's not much
the broker can do. It's up to users to properly configure their brokers.
> Assuming that my understandings above are correct, operational b) type
records will still contain plain text passwords for some time.
If that happens you can run the "data compact" command to remove any stale
operational records that contain the plaintext password(s).
> Again, I've probably chosen wrong word here. By "mask" I've meant that
password hashes are stripped from the "bin/artemis data print" output. As
you can see in my example journal records above, they are replaced with ****
Passwords are stripped from the output regardless because passwords can
potentially be stored in plaintext. We do the same in broker logs as well.
Justin
On Mon, Apr 4, 2022 at 3:52 PM Vilius Šumskas <vi...@rivile.lt>
wrote:
> >> 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"?
>
> Sorry if my English is not that great, I will try to explain. You said
> earlier that when a user is created there are two types of records:
> a) surviving records which I suppose is this line:
> recordID=314669421;userRecordType=47;isUpdate=false;compactCount=0;PersistedUser
> [storeId=314669421, username=admin, password=****]
> b) operational records which as I understood is this line:
> operation@AddRecord;recordID=314669421;userRecordType=47;isUpdate=false;compactCount=0;PersistedUser
> [storeId=314669421, username=admin, password=****]
> Operational record repeats every time a user is added, deleted or updated.
>
> So for me a) is like a database storage for credentials, and b) is like an
> audit log how credentials changed during time.
>
> Correct me if I'm wrong on my understandings. My proposal was to not store
> hashes (or plaintext passwords) in b) type records.
>
> >> 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.
>
> For example, there could be cases where the instance is migrated from
> plaintext to hashed passwords. Assuming that my understandings above are
> correct, operational b) type records will still contain plain text
> passwords for some time.
>
> >> 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.
>
> Again, I've probably chosen wrong word here. By "mask" I've meant that
> password hashes are stripped from the "bin/artemis data print" output. As
> you can see in my example journal records above, they are replaced with
> ****
>
> --
> Vilius
>
RE: ActiveMQBasicSecurityManager configuration examples
Posted by Vilius Šumskas <vi...@rivile.lt>.
>> 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"?
Sorry if my English is not that great, I will try to explain. You said earlier that when a user is created there are two types of records:
a) surviving records which I suppose is this line:
recordID=314669421;userRecordType=47;isUpdate=false;compactCount=0;PersistedUser [storeId=314669421, username=admin, password=****]
b) operational records which as I understood is this line:
operation@AddRecord;recordID=314669421;userRecordType=47;isUpdate=false;compactCount=0;PersistedUser [storeId=314669421, username=admin, password=****]
Operational record repeats every time a user is added, deleted or updated.
So for me a) is like a database storage for credentials, and b) is like an audit log how credentials changed during time.
Correct me if I'm wrong on my understandings. My proposal was to not store hashes (or plaintext passwords) in b) type records.
>> 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.
For example, there could be cases where the instance is migrated from plaintext to hashed passwords. Assuming that my understandings above are correct, operational b) type records will still contain plain text passwords for some time.
>> 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.
Again, I've probably chosen wrong word here. By "mask" I've meant that password hashes are stripped from the "bin/artemis data print" output. As you can see in my example journal records above, they are replaced with ****
--
Vilius
Re: ActiveMQBasicSecurityManager configuration examples
Posted by Justin Bertram <jb...@apache.org>.
> 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 <vi...@rivile.lt>
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 <jb...@apache.org>
> Sent: Monday, April 4, 2022 7:22 PM
> To: users@activemq.apache.org
> 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 <vi...@rivile.lt>
> 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 <jb...@apache.org>
> > Sent: Wednesday, March 30, 2022 7:00 AM
> > To: users@activemq.apache.org
> > 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 <jb...@apache.org>
> > wrote:
> >
> > > I would say that's a bug.
> > >
> > >
> > > Justin
> > >
> > > On Tue, Mar 29, 2022 at 4:58 PM Vilius Šumskas
> > > <vi...@rivile.lt>
> > > 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 <jb...@apache.org>
> > >> Sent: Friday, March 25, 2022 5:14 PM
> > >> To: users@activemq.apache.org
> > >> 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
> > >> <vi...@rivile.lt>
> > >> 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 <jb...@apache.org>
> > >> > Sent: Thursday, March 24, 2022 9:43 PM
> > >> > To: users@activemq.apache.org
> > >> > 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
> > >> > <vi...@rivile.lt>
> > >> > 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
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
RE: ActiveMQBasicSecurityManager configuration examples
Posted by Vilius Šumskas <vi...@rivile.lt>.
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 <jb...@apache.org>
Sent: Monday, April 4, 2022 7:22 PM
To: users@activemq.apache.org
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 <vi...@rivile.lt>
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 <jb...@apache.org>
> Sent: Wednesday, March 30, 2022 7:00 AM
> To: users@activemq.apache.org
> 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 <jb...@apache.org>
> wrote:
>
> > I would say that's a bug.
> >
> >
> > Justin
> >
> > On Tue, Mar 29, 2022 at 4:58 PM Vilius Šumskas
> > <vi...@rivile.lt>
> > 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 <jb...@apache.org>
> >> Sent: Friday, March 25, 2022 5:14 PM
> >> To: users@activemq.apache.org
> >> 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
> >> <vi...@rivile.lt>
> >> 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 <jb...@apache.org>
> >> > Sent: Thursday, March 24, 2022 9:43 PM
> >> > To: users@activemq.apache.org
> >> > 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
> >> > <vi...@rivile.lt>
> >> > 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
> >> > >
> >> > >
> >> >
> >>
> >
>
Re: ActiveMQBasicSecurityManager configuration examples
Posted by Justin Bertram <jb...@apache.org>.
> 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 <vi...@rivile.lt>
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 <jb...@apache.org>
> Sent: Wednesday, March 30, 2022 7:00 AM
> To: users@activemq.apache.org
> 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 <jb...@apache.org>
> wrote:
>
> > I would say that's a bug.
> >
> >
> > Justin
> >
> > On Tue, Mar 29, 2022 at 4:58 PM Vilius Šumskas
> > <vi...@rivile.lt>
> > 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 <jb...@apache.org>
> >> Sent: Friday, March 25, 2022 5:14 PM
> >> To: users@activemq.apache.org
> >> 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
> >> <vi...@rivile.lt>
> >> 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 <jb...@apache.org>
> >> > Sent: Thursday, March 24, 2022 9:43 PM
> >> > To: users@activemq.apache.org
> >> > 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/latest
> >> > /se
> >> > curity.html#basic-security-manager
> >> >
> >> > On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas
> >> > <vi...@rivile.lt>
> >> > 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
> >> > >
> >> > >
> >> >
> >>
> >
>
RE: ActiveMQBasicSecurityManager configuration examples
Posted by Vilius Šumskas <vi...@rivile.lt>.
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 <jb...@apache.org>
Sent: Wednesday, March 30, 2022 7:00 AM
To: users@activemq.apache.org
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 <jb...@apache.org> wrote:
> I would say that's a bug.
>
>
> Justin
>
> On Tue, Mar 29, 2022 at 4:58 PM Vilius Šumskas
> <vi...@rivile.lt>
> 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 <jb...@apache.org>
>> Sent: Friday, March 25, 2022 5:14 PM
>> To: users@activemq.apache.org
>> 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
>> <vi...@rivile.lt>
>> 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 <jb...@apache.org>
>> > Sent: Thursday, March 24, 2022 9:43 PM
>> > To: users@activemq.apache.org
>> > 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/latest
>> > /se
>> > curity.html#basic-security-manager
>> >
>> > On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas
>> > <vi...@rivile.lt>
>> > 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
>> > >
>> > >
>> >
>>
>
Re: ActiveMQBasicSecurityManager configuration examples
Posted by Justin Bertram <jb...@apache.org>.
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 <jb...@apache.org> wrote:
> I would say that's a bug.
>
>
> Justin
>
> On Tue, Mar 29, 2022 at 4:58 PM Vilius Šumskas <vi...@rivile.lt>
> 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 <jb...@apache.org>
>> Sent: Friday, March 25, 2022 5:14 PM
>> To: users@activemq.apache.org
>> 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 <vi...@rivile.lt>
>> 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 <jb...@apache.org>
>> > Sent: Thursday, March 24, 2022 9:43 PM
>> > To: users@activemq.apache.org
>> > 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/latest/se
>> > curity.html#basic-security-manager
>> >
>> > On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas
>> > <vi...@rivile.lt>
>> > 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
>> > >
>> > >
>> >
>>
>
Re: ActiveMQBasicSecurityManager configuration examples
Posted by Justin Bertram <jb...@apache.org>.
I would say that's a bug.
Justin
On Tue, Mar 29, 2022 at 4:58 PM Vilius Šumskas <vi...@rivile.lt>
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 <jb...@apache.org>
> Sent: Friday, March 25, 2022 5:14 PM
> To: users@activemq.apache.org
> 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 <vi...@rivile.lt>
> 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 <jb...@apache.org>
> > Sent: Thursday, March 24, 2022 9:43 PM
> > To: users@activemq.apache.org
> > 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/latest/se
> > curity.html#basic-security-manager
> >
> > On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas
> > <vi...@rivile.lt>
> > 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
> > >
> > >
> >
>
RE: ActiveMQBasicSecurityManager configuration examples
Posted by Vilius Šumskas <vi...@rivile.lt>.
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 <jb...@apache.org>
Sent: Friday, March 25, 2022 5:14 PM
To: users@activemq.apache.org
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 <vi...@rivile.lt>
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 <jb...@apache.org>
> Sent: Thursday, March 24, 2022 9:43 PM
> To: users@activemq.apache.org
> 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/latest/se
> curity.html#basic-security-manager
>
> On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas
> <vi...@rivile.lt>
> 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
> >
> >
>
Re: ActiveMQBasicSecurityManager configuration examples
Posted by Justin Bertram <jb...@apache.org>.
> 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 <vi...@rivile.lt>
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 <jb...@apache.org>
> Sent: Thursday, March 24, 2022 9:43 PM
> To: users@activemq.apache.org
> 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/latest/security.html#basic-security-manager
>
> On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas <vi...@rivile.lt>
> 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
> >
> >
>
RE: ActiveMQBasicSecurityManager configuration examples
Posted by Vilius Šumskas <vi...@rivile.lt>.
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 <jb...@apache.org>
Sent: Thursday, March 24, 2022 9:43 PM
To: users@activemq.apache.org
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/latest/security.html#basic-security-manager
On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas <vi...@rivile.lt>
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
>
>
Re: ActiveMQBasicSecurityManager configuration examples
Posted by Justin Bertram <jb...@apache.org>.
> 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/latest/security.html#basic-security-manager
On Thu, Mar 24, 2022 at 11:01 AM Vilius Šumskas <vi...@rivile.lt>
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
>
>