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
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
Our two transport impls depend on the SSLService at this point. Although we bind the SSLService only if ssl is enabled, it gets loaded anyway as it's a required dependency for the transports. We need to declare the dependency nullable and bind a null service manually when ssl is off.
Also resolved a couple of compiler warnings in SSLService and renamed some of its variables for better readability.
Closeselastic/elasticsearch#359
Original commit: elastic/x-pack-elasticsearch@2c99b2052e
As netty uses different bootstraps for sending/receiving requests, having a
single interface for filtering incoming/outgoing messages does not make a
lot of sense.
This commit changes from a TransportFilter interface to a InboundTransportFilter
interface, which is only able to filter incoming messages - which is all we do
anyway right now.
Original commit: elastic/x-pack-elasticsearch@545ff24136
Previously the userdel command always returned success regardless
of whether the user exists or not. When the user does not exist, a
message is now shown indicating that the user was not found.
Closeselastic/elasticsearch#346
Original commit: elastic/x-pack-elasticsearch@fb45d844ca
The rest tests were configured with transport and http settings for ssl. This
changes that to the shield.ssl settings.
Original commit: elastic/x-pack-elasticsearch@19b96f7fa3
There is no need to use TempraryFolder rules in our tests, since we depend on randomized runner which creates a globalTempDir() whose cleaning is already managed by the infra. Any other dir or file should be created under the global temp dir by specifying also its desired duration (SUITE or TEST).
Closeselastic/elasticsearch#337
Original commit: elastic/x-pack-elasticsearch@7456882d18
- The Permission class changed such that now there isn't a single `check` method that all permission types must implement. Instead, each permission type has its own (if at all) check method that is relevant to what the permssion is supposed to check.
- Moved the indices resolving logic outside of the indices permission class to the authorization service. Also, the authroization service has all the logic on how to check each one of the indices against a compound/merged permission view over all the user's roles. This fixes a critical bug where if a user had more than one role, its permission wouldn't be checked appropriately (they were checked separately which introduced invalid results)
- Cleaned up and got rid of unused code
- System role is no longer implementing Permission (no need for that)
- Additional tests were added with different users/roles configuration to try an capture such bugs
Fixeselastic/elasticsearch#304
Original commit: elastic/x-pack-elasticsearch@5c9a581019
This wraps logging statements in if checks. It also removes from the documentation specific logging examples.
Original commit: elastic/x-pack-elasticsearch@3ca7cdd4f4
This adds debugging statements and debugging documentation to help troubleshoot problems with ldap role establishment. This also adds ldap profiles for esvm
Original commit: elastic/x-pack-elasticsearch@a1f1cbd830
* Configuring the transport pipeline has changed due to adding profiles in 1.4
* Lots of tests needed to be changed in order to not leave thread pools around
* ApacheDs leaves a thread lingering around, thus a ThreadLeakFilter needed to be added
Original commit: elastic/x-pack-elasticsearch@de35362fc4
Also added a ShieldBuild class to return
* Shield version
* Shield build hash
* Shield build timestamp
Also added a '/_shield' endpoint which returns those fields.
Original commit: elastic/x-pack-elasticsearch@38928d1ef6
Now it logs the failure on debug and on trace it also logs the full stack trace. There's no point in logging it on info as a lot of the failures that will be logged are just fine (e.g. esusers will fail to authenticate and log the failure, but LDAP will succeed). This logging should only be applied for debugging purposes... for normal logging we have the audit logs
While at it, also cleaned up the Ldap realm code... change java.lang.SecurityException to shield's LdapException
Closeselastic/elasticsearch#281
Original commit: elastic/x-pack-elasticsearch@d5f0ad2efb
- Changed the behaviour of esusers realm so that whenever the `users` or the `users_roles` file are updated, the realm's cache expunges
- Changed LDAP realm such that when the `role_mapping.yml` file is updated, the realm's cache expunges
Also, cleaned up unused code (mainly around esusers and the different stores)
Original commit: elastic/x-pack-elasticsearch@3f093207da
Fixes a bug where the wrong exception and wrong error status code (500) were returned when the user sent the wrong username/password. This fixes this beahviour to return an `AuhthenticationException` with a 401 status code.
Fixeselastic/elasticsearch#271
Original commit: elastic/x-pack-elasticsearch@0a120caeae
We now moved from the logic of checking `indices:` and `cluster:` prefixes to determine whether an action is an indices or a cluster action... instead we use the index/cluster privielge `all` privilege to determine that (which is more accurate in the context of shield, as it enables us to move actions between the two categories while keeping their logical name intact)
Also updated the docs to reflect that template related actions are infact cluster actions.
Original commit: elastic/x-pack-elasticsearch@8027334105
Added `shield.user` setting so that the clients won't need to go through the unnatural and tedious process of configuring the `Authorization` header directly (that also requires the user to applicat the base64(username:password) logic.
Now, the user can just set the following settings to bind a user to the client:
```yaml
shield.user: 'username:password'
```
Original commit: elastic/x-pack-elasticsearch@94be3abd92
Enforcing means that cluster actions will not be evaluated (as a fallback) by Index permissions. This enables us to move what typically would be considered indices actions and put them under the cluster privileges (a good example for this are all the template management APIs... we want to enforce cluster admin privileges over them).
Original commit: elastic/x-pack-elasticsearch@ee870954f2
Also added a logstash configuration for simple performance
testing (useful for comparing different hash functions)
Original commit: elastic/x-pack-elasticsearch@c9f08fbb12
Now the passwords are hashed in-memory using SHA2 by default (instead of original bcrypt). Also, it's now possible to configure the in-memory hashing algorithm.
Original commit: elastic/x-pack-elasticsearch@e2d1b3116b
Now, there are two types of supported patters:
- wildcards (default) - simple wildcard match where `*` indicates zero or more characters and `?` indicates a single character (`\` can be used as an escape charachter)
- regular expressions - can be "enabled" by wrapping the pattern in `/` (e.g. `/foo.*/`). The regex syntax is based on lucene's regex syntax (not Java's Pattern).
Closeselastic/elasticsearch#253
Original commit: elastic/x-pack-elasticsearch@edd912122d
javanna
Alexander Reelsen
uboness
c-a-m
jaymode
Paul Echeverri