jbertram commented on code in PR #4001: URL: https://github.com/apache/activemq-artemis/pull/4001#discussion_r862975168
########## docs/user-manual/en/security.md: ########## @@ -1221,6 +1221,11 @@ management performed on the live broker will be reflected on the backup upon failover. Typically LDAP would be employed for this kind of use-case, but not everyone wants or is able to administer an independent LDAP server. +> **Note:** +> +> `ActiveMQBasicSecurityManager` works only with standalone broker +> configuration or with live/backup clusters. It won't work with multiple lives. + Review Comment: There's no substantive difference in your update vs. the previous version. This is the problematic bit: > ActiveMQBasicSecurityManager` is not suitable for clusters with multiple lives. This is calling out a limitation of the basic security manager that is also true of the default configuration (i.e. the JAAS security manager with the PropertiesLoginModule). However, since this limitation is not explicitly called out for the default configuration it makes it appear that this limitation is unique to the basic security manager. I think something like this would be much more clear. Feel free to include this text in your commit if you like. > All user & role data is stored in the broker's bindings journal (or bindings table if using JDBC). The advantage here is that in a live/backup use-case any user management performed on the live broker will be reflected on the backup upon failover. > > Typically LDAP would be employed for this kind of use-case, but not everyone wants or is able to administer an independent LDAP server. One significant benefit of LDAP is that user data can be shared between multiple live brokers (e.g. in a cluster). However, this is not possible with the basic security manager or, in fact, any other configuration potentially available out of the box. Nevertheless, if you just want to share user data between a single live/backup pair then the basic security manager may be a good fit for you. ########## docs/user-manual/en/security.md: ########## @@ -1221,6 +1221,11 @@ management performed on the live broker will be reflected on the backup upon failover. Typically LDAP would be employed for this kind of use-case, but not everyone wants or is able to administer an independent LDAP server. +> **Note:** +> +> `ActiveMQBasicSecurityManager` works only with standalone broker +> configuration or with live/backup clusters. It won't work with multiple lives. + Review Comment: There's no substantive difference in your update vs. the previous version. This is the problematic bit: > `ActiveMQBasicSecurityManager` is not suitable for clusters with multiple lives. This is calling out a limitation of the basic security manager that is also true of the default configuration (i.e. the JAAS security manager with the PropertiesLoginModule). However, since this limitation is not explicitly called out for the default configuration it makes it appear that this limitation is unique to the basic security manager. I think something like this would be much more clear. Feel free to include this text in your commit if you like. > All user & role data is stored in the broker's bindings journal (or bindings table if using JDBC). The advantage here is that in a live/backup use-case any user management performed on the live broker will be reflected on the backup upon failover. > > Typically LDAP would be employed for this kind of use-case, but not everyone wants or is able to administer an independent LDAP server. One significant benefit of LDAP is that user data can be shared between multiple live brokers (e.g. in a cluster). However, this is not possible with the basic security manager or, in fact, any other configuration potentially available out of the box. Nevertheless, if you just want to share user data between a single live/backup pair then the basic security manager may be a good fit for you. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
