Today it is possible to configure 3 realms in shield - `esusers`, `ldap` and `active_directory`. These realms are created once based on the configuration. There are several problems with this approach:
- Taking `ldap` as an example, it is currently not possible to have multiple `ldap` realms configured (where one serving as a fallback for the other). While the `ldap` realm itself enables defining multiple ldap URLs, it has the limitation that the fallback LDAP must have the exact same configuration as the primary LDAP (+ there's the limitation that all URLs must either us SSL or not... there cannot be a mix of SSL URL and a normal URL)
- The realms are created and bound internally by guice. This will limit the configurability at runtime of the realms which we might want to introduce in shield 2.0.
This commit changes the way realms are managed & configured. Instead of having guice bind the realms themselves. A new realm factory construct will be introduced. The realm factory will represent a realm type and guice will bind these factories. At load time, we'll read the configuration and based on the types of the configured realms, the relevant factories will create the realms based on the settings. This means that potentially we can expose the realms as a dynamic configuration and rebuild the realm chain at runtime.
A nice side effect of this approach is that the multiple URLs feature that is currently supported by both `ldap` and `active_directory` can be dropped. Instead, the users will just need to configure multiple `ldap`/`active_directory` realms.
Closes: elastic/elasticsearch#370
Original commit: elastic/x-pack-elasticsearch@3232f153bb
Changed the scope of the guava dependency to prevent wrong imports and always use the shaded ones.
This required a change in the forbidden API signatures, as that tool alwyas try load the class and fail
if the class cannot be found.
Original commit: elastic/x-pack-elasticsearch@90a245423a
uboness
Alexander Reelsen