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
Every test class was previously running against its own SUITE cluster composed of a single node due to misconfiguration.
Also there were some repetitions and bugs in the settings: first of all unicast wasn't properly configured, also the plugin wasn't registered properly in the transport client, thus the "shield.user" settings wasn't properly converted into the basic auth header. For the very same reason the settings used for authc wasn't randomized for transport client.
Extracted out all the needed configuration to the `ShieldSettingsSource` class, that takes care of the unicast configuration, loading of the plugin and all of the configuration files and parameters.
Used the global cluster whenever possible, that has the following characteristics:
- unicast discovery
- ssl configured and enabled at the transport level
- ssl configured but disabled at the http level (REST tests use the same cluster and don't support SSL at this time)
- single user configured with an allow_all role
- auditing enabled or not is randomized
- the setting used to do basic auth is randomized between reuest.headers.Authorization and our own shield.user for both node and transport client
Test classes that need to override defaults settings can do so by declaring scope=SUITE and overriding the nodeSettings method. Also roles, users and users_roles have specialized methods to be overridden that just return the content of the whole file if it differs from the default. Note that given that ssl is properly configured although disabled for http, tests that need it on can just enable it without any additional configuration.
Closeselastic/elasticsearch#31
Original commit: elastic/x-pack-elasticsearch@fa6f162497
Although it is nice to be alerted through assert as soon as we upgrade the es core dependency, this can be done only in test code, in production code it prevents us from supporting any future version once the code gets released.
Replaced the assert with a TODO.
Original commit: elastic/x-pack-elasticsearch@b0d59c2fd3
@NotThreadSafe is not a valid standard java annotation. Removed unused method and empty @param javadoc annotation
Original commit: elastic/x-pack-elasticsearch@3583bcfa66
- Remove synchronized
- Add STOPPING state
- Expose alert state in stats api
- Let the test framework disable alerting before closing the test cluster
Original commit: elastic/x-pack-elasticsearch@5794f5fd8f
The goal of TESTING.asciidoc is not to repeat what's already in the elasticsearch core test cheatsheet, but only add what is different in shield.
Original commit: elastic/x-pack-elasticsearch@51ad3894d2
This bug was caused by the fact that we serialize the user and don't re-authenticate on each node anymore. With auto create index, we ended up overriding the user in the context with system due to wrong checks (we would check the headers instead of the context). This bug was revealed by our REST tests.
Also refactored the method for readability and removed check for token.
Original commit: elastic/x-pack-elasticsearch@2aa260b46c
This will allow in the future to make this a dynamic setting,
which can also be shared accress the cluster instead of having
to use (and distribute) files.
Another change is, that the order of `deny` and `allow` now does not matter
anymore. Allow will win over deny.
The last change is that `all` now is `_all` in order to align with the
rest of Elasticsearch
Documentation has been updated accordingly.
Original commit: elastic/x-pack-elasticsearch@daa0b18343
Nuked the security filter and separated the different filter to their own constructs:
- Added a shield action package & module that is responsible for binding the shield action filter (and later will hold all shield actions)
- Added a shield rest package & module that is responsible for binding the shield rest filter and registering all the rest actions
- Moved the client & server transport filters to the transport package
General cleanup:
- Code formatting
- moved `ShieldPlugin` to the top level package `org.elasticsearch.shield`
Original commit: elastic/x-pack-elasticsearch@d652041860
Now, on first successful authentication, we put the user in the message header so it'll be send with any subsequent cluster internal requests (e.g. shard level search) to avoid re-authentication on every node in the cluster. We can do that now, as with multi-binding transport we can guarantee isolation of the internal cluster from client communication. While it's generally safe for transmission, the user header that is sent between the nodes is still signed using the `system_key` as yet another security layer.
As part of this change, also added/changed:
- A new audit log entry - anonymous access for Rest request.
- Changed how system user is assumed. Previously, system user was assumed on the receiving node when no user was associated with the request. Now the system user is assumed on the sending node, meaning, when a node sends a system originated request, initially this request won't be associated with a user. Shield now picks those requests up and attaches the system user to the role and then sends it together with the request. This has two advantages: 1) it's safer to assume system locally where the requests originate from. 2) this will prevent nodes without shield from connecting to nodes with shield. (currently, the attached users are signed using the system key for safety, though this behaviour may be disabled in the settings).
- System realm is now removed (no need for that as the system user itself is serialized/attached to the requests)
- Fixed some bugs in the tests
Closeselastic/elasticsearch#215
Original commit: elastic/x-pack-elasticsearch@3172f5d126
Incorporate Feedback:
- verify signature for signed licenses whenever it is read from cluster state
- encrypt trial licenses with default pass phrase when storing it
- moved toSignature & fromSignature to License
Make LicenseManager a Utility class
Refactor:
- renamed LicenseManager to LicenseVerifier
- LicensesMetaData now holds a list of license objects (for signed licenses) and a set of encoded strings (trial licenses)
- minor test cleanup
incorporate feedback
incorporated feedback
switch to a stronger secret key gen algo; clean up build files & LicensesMetaData
cosmetic changes to LicenseSigner
incorporate LicnesesMetaData feedback
Original commit: elastic/x-pack-elasticsearch@0510091d2d
In order to run on different certs per port, we needed to adapt
the logic of starting up.
Also different profiles can now be applied to the N2NAuthenticator, so that
a different profile can allow/deny different hosts.
In addition minor refactorings have been done
* Group keystore/truststore settings instead of using underscores
* Change to transport profile settings instead of using specific shield ones
Documentation has been updated as well
Closeselastic/elasticsearch#290
Original commit: elastic/x-pack-elasticsearch@ad1ab974ea
There is a circular dependency in core 1.4.0 that cause plugins to fail depending on their constructors injection. We have ClusterService in InternalAuthorizationService that triggers this problem, solved for now replacing the dependency with a Provider. The original bug is already fixed in core: https://github.com/elasticsearch/elasticsearch/pull/8415 .
The problem manifested when enablieng a tribe node having shield installed on that node at the same time.
Closeselastic/elasticsearch#363
Original commit: elastic/x-pack-elasticsearch@ac339ef247
Martijn van Groningen
Areek Zillur
uboness
Paul Echeverri
javanna
Alexander Reelsen
Brian Murphy
c-a-m