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
This change adds the AlertActionManager and AlertActionEntry. The old AlertActionManager has become the AlertActionRegistry.
This means that now the results of Alerts are queued up in a job queue and executed in separate threads.
The AlertActionManager is a composite member of the AlertManager.
Change the BasicTest to just run on a single node to fix the action registration if the action happens on a different node.
Threads are not directly constructed but now the threadpool is used.
The ClusterStateListener in AlertManager is responsible now for starting the job queue.
Original commit: elastic/x-pack-elasticsearch@a73c6b60f8
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
- nuked TrailLicense
- Move license expiry enforcement logic to LicensesService
- clean up ESLicenseManager
- make notification scheduling logic as lazy as possible
- make sure to notify from cluster changed only if needed
- added tests for notification
Original commit: elastic/x-pack-elasticsearch@e31b682f41
* Using cluster state listener to clear alerts when .alerts index is removed. (when running on multiple nodes the .alerts index is scattered so indices listener doesn't work).
* Remove the starting / loading thread and move the initial loading to cluster state listener.
Original commit: elastic/x-pack-elasticsearch@b8f41db2ea
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
Martijn van Groningen
Areek Zillur
uboness
Igor Motov
Brian Murphy
Paul Echeverri
Bill Hwang
Alexander Reelsen