The authc service will now authenticate the user on the rest layer as well, meaning there will only be a single authentication process no matter what is then entry point to ES (for example, if a rest handler executes two internal requests... like some of the _cat APIs, there'll still be a single authentication process)
In addition, the audit logs will now log REST authentication failures such that the remote address and the rest endpoint will show up in the logs as well.
Original commit: elastic/x-pack-elasticsearch@07af440147
This fixes a bug when the UsernamePasswordToken is cached in the userContext and reused after it's cleared.
Original commit: elastic/x-pack-elasticsearch@9aab1d8530
SecuredString encapsulates handling of passwords and clearing them when done. This change
includes changing everywhere passwords are used. After authentication the authentication service will
clear the token - which will clear the password. This avoids using any passwords in String objects.
This also adds commentary to BCrypt to show how it changed from the original external resource. It moves utility methods to CharArrays.
Original commit: elastic/x-pack-elasticsearch@d0ffbae5c8
In InternalKeyService, we encode the signatures with base64. For things like scroll id, that need to be placed in URLs it's important that the signature will be URL safe.
Original commit: elastic/x-pack-elasticsearch@138d02d966
ApacheDSRule has been moved to `ExternalResource` which requires less code and implements `TestRule` instead of `MethodRule`. `TestRule` supports `ClassRule`s as well as ordinary `Rule`s. A class rule is exactly what we need for the ldap tests since we want to start the ldap server once before class and shut it down after all tests (after class). Also made sure that the static fields are cleaned up, otherwise `StaticFieldsInvariantRule` barfs.
Added `extends ElasticsearchTestsCase` where missing also.
Closeselastic/elasticsearch#80
Original commit: elastic/x-pack-elasticsearch@2143a2dcc6
Added `ShieldRestTests` that extends `ElasticsearchRestTests` allowing to run REST tests against es+shield. Tests won't be run by default as they require additional configuration (e.g. rest tests and spec location on file system). They can be activated via `-Dtests.rest=true`. Rest tests and spec location can be provided as follows:
```
-Dtests.rest.spec=/path/to/elasticsearch/rest-api-spec/api -Dtests.rest.suite=/path/to/elasticsearch/master/rest-api-spec/test
```
Some tests need to be blacklisted at this moment as follows:
```
-Dtests.rest.blacklist=scroll/*/*,mpercolate/*/*,msearch/*/*
```
Closeselastic/elasticsearch#79
Original commit: elastic/x-pack-elasticsearch@6f3e72dd87
`randomInt` includes 0, thus the tampered id could stay the same as the signed scroll ids in some cases which would make everything work and the test fail.
Also cleared the scroll from a finally block, otherwise when the test fails the scroll stays around which might make after test checks fail.
Original commit: elastic/x-pack-elasticsearch@6f6b0d844d
- Key service provides un/signing functionality
- will initially be used to un/sign scroll ids (for the scroll api)
Original commit: elastic/x-pack-elasticsearch@256e0e3c5d
The current IP filter kicks in after the SSL handler, which only
makes sense, if you check things like the SSL certificate. For
now it makes most sense to really put this at the first place.
Original commit: elastic/x-pack-elasticsearch@bbaed67a3c
- Formalized the notion of a client vs. node mode. Introduced an `AbstractShieldModule` that takes care of that
- For now, standarized on the `Shield` name across the board (e.g. change `SecurityModule` to `ShieldModule`)
- Introduces static methods to `ShieldPlugin` to resolve shield specific config files (on the way fixed the file resolving of the ldap group mapper)
- The n2n ip filtering is now resolved at the module level. If not enabled, null is injected and the netty handler is then not injected to the pipeline
- updated code base with the latest changes in es-core around how relevant http headers are registered and copied over to the transport request
- Added new known action in es-core `indices:admin/get`
Original commit: elastic/x-pack-elasticsearch@ca8d85dc81
The wrong path was used as default path. Also added logging information
for all files, so one can at least check the paths.
Original commit: elastic/x-pack-elasticsearch@893493fd17
- Also made sure that we fallback on system token only if the system has permission to the action.
- While at it, change the binding of the different services to run as a singletons
Closeselastic/elasticsearch#64
Original commit: elastic/x-pack-elasticsearch@3705b7365a
- Also fixed a bug where if ldap/esuers module is disabled, injection failed (now injecting the appropriate `null` values to `Realms`
- Also updated `SecurityFilter` with latest changes in es core (action filters API changed)
Original commit: elastic/x-pack-elasticsearch@71de64e6ad
The automaton support changed quite a bit in 4.10 which required determinizing all the automatons used in the Privilege
Original commit: elastic/x-pack-elasticsearch@96a82f0f5d
Removed the caching of the token on the request context. Caching is now handled by the InternalAuthenticationService
Original commit: elastic/x-pack-elasticsearch@d60bc7af67
- ShieldModule loads the SecuredTransportModule which is in turn responsible for loading the required transport related sub-modules
- Removed n2n module and incorporated n2n into the transport module
- Updated the docs to reflect the new settings for n2n ip filtering
Original commit: elastic/x-pack-elasticsearch@dd82306a04
When a http request arrives, we first verify that it carries an authentication token (if it doesn't we throw an authentication exception). Beyond that, any action request that arrives, if it doesn't have an authentication token we assume system user identity. The rationale behind it is that if a request comes in via the transport, then the sending peer authenticated with a client auth cert (the cert acts as the guarantee here that the actor can be assumed as System)... otherwise, the request can come from the local node and triggered by the system (e.g. gateway recovery)
The System user only has permissions to internal apis (it doesn't have full access/permission to all the apis). when a System identity is assumed, the authorization service will grant/deny the request based on whether the request is an internal api or not.
Aso fixed the known actions (to be insync with 1.x branch)
Closeselastic/elasticsearch#45
Original commit: elastic/x-pack-elasticsearch@be27cb0e1b
Paul Echeverri
Areek Zillur
Michael McCandless
Alexander Reelsen
uboness
c-a-m
javanna
Bill Hwang