OpenSearch/x-pack/qa/security-example-spi-extension/build.gradle

42 lines
1.5 KiB
Groovy
Raw Normal View History

apply plugin: 'elasticsearch.java-rest-test'
apply plugin: 'elasticsearch.esplugin'
esplugin {
name 'spi-extension'
Allow custom authorization with an authorization engine (#38358) For some users, the built in authorization mechanism does not fit their needs and no feature that we offer would allow them to control the authorization process to meet their needs. In order to support this, a concept of an AuthorizationEngine is being introduced, which can be provided using the security extension mechanism. An AuthorizationEngine is responsible for making the authorization decisions about a request. The engine is responsible for knowing how to authorize and can be backed by whatever mechanism a user wants. The default mechanism is one backed by roles to provide the authorization decisions. The AuthorizationEngine will be called by the AuthorizationService, which handles more of the internal workings that apply in general to authorization within Elasticsearch. In order to support external authorization services that would back an authorization engine, the entire authorization process has become asynchronous, which also includes all calls to the AuthorizationEngine. The use of roles also leaked out of the AuthorizationService in our existing code that is not specifically related to roles so this also needed to be addressed. RequestInterceptor instances sometimes used a role to ensure a user was not attempting to escalate their privileges. Addressing this leakage of roles meant that the RequestInterceptor execution needed to move within the AuthorizationService and that AuthorizationEngines needed to support detection of whether a user has more privileges on a name than another. The second area where roles leaked to the user is in the handling of a few privilege APIs that could be used to retrieve the user's privileges or ask if a user has privileges to perform an action. To remove the leakage of roles from these actions, the AuthorizationService and AuthorizationEngine gained methods that enabled an AuthorizationEngine to return the response for these APIs. Ultimately this feature is the work included in: #37785 #37495 #37328 #36245 #38137 #38219 Closes #32435
2019-02-05 15:39:29 -05:00
description 'An example spi extension plugin for security'
classname 'org.elasticsearch.example.SpiExtensionPlugin'
extendedPlugins = ['x-pack-security']
}
dependencies {
compileOnly project(':x-pack:plugin:core')
javaRestTestImplementation project(xpackProject('transport-client').path)
javaRestTestImplementation project(':x-pack:plugin:core')
javaRestTestImplementation project(':client:rest-high-level')
// let the javaRestTest see the classpath of main
javaRestTestImplementation project.sourceSets.main.runtimeClasspath
}
javaRestTest {
systemProperty 'tests.security.manager', 'false'
}
testClusters.all {
// This is important, so that all the modules are available too.
// There are index templates that use token filters that are in analysis-module and
// processors are being used that are in ingest-common module.
testDistribution = 'DEFAULT'
setting 'xpack.security.authc.realms.custom.custom.order', '0'
setting 'xpack.security.authc.realms.custom.custom.filtered_setting', 'should be filtered'
setting 'xpack.security.authc.realms.file.esusers.order', '1'
setting 'xpack.security.authc.realms.native.native.order', '2'
setting 'xpack.security.authc.realms.custom_role_mapping.role_map.order', '3'
setting 'xpack.security.enabled', 'true'
setting 'xpack.ml.enabled', 'false'
setting 'xpack.license.self_generated.type', 'trial'
user username: "test_user", password: "x-pack-test-password"
}