diff --git a/docs/user-manual/en/security.md b/docs/user-manual/en/security.md index 4fd8616492..d573487b94 100644 --- a/docs/user-manual/en/security.md +++ b/docs/user-manual/en/security.md @@ -1198,8 +1198,15 @@ manager *may* still may have a couple of advantages depending on your use-case. All user & role data is stored in the 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. +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. +However, this is not possible with the `ActiveMQBasicSecurityManager` 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. User management is provided by the broker's management API. This includes the ability to add, list, update, and remove users & roles. As with all management @@ -1218,6 +1225,8 @@ the basic security manager. The configuration for the `ActiveMQBasicSecurityManager` happens in `bootstrap.xml` just like it does for all security manager implementations. +Start by removing `` section and add `` +configuration as described below. The `ActiveMQBasicSecurityManager` requires some special configuration for the following reasons: @@ -1231,10 +1240,10 @@ If, for example, the broker was configured to use the `ActiveMQBasicSecurityManager` and was started from scratch then no clients would be able to connect because there would be no users & roles configured. However, in order to configure users & roles one would need to use the -management API which would require the proper credentials. It's a catch-22. -Therefore, it is possible to configure "bootstrap" credentials that will be -automatically created when the broker starts. There are properties to define -either: +management API which would require the proper credentials. It's a [catch-22](https://en.wikipedia.org/wiki/Catch-22_(logic)) +problem. Therefore, it is essential to configure "bootstrap" credentials that +will be automatically created when the broker starts. There are properties +to define either: - a single user whose credentials can then be used to add other users - properties files from which to load users & roles in bulk @@ -1308,8 +1317,11 @@ For example: > **Note:** > -> Any `bootstrap` credentials will be set **whenever** you start the broker no -> matter what changes may have been made to them at runtime previously. +> Any `bootstrap` credentials will be reset **whenever** you start the broker +> no matter what changes may have been made to them at runtime previously, so +> depending on your use-case you should decide if you want to leave `bootstrap` +> configuration permanent or if you want to remove it after initial +> configuration. ## Mapping external roles Roles from external authentication providers (i.e. LDAP) can be mapped to internally used roles. The is done through role-mapping entries in the security-settings block: