Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Encapsulate request, auth, and action name #37495

Merged
merged 5 commits into from
Jan 18, 2019
Merged

Encapsulate request, auth, and action name #37495

merged 5 commits into from
Jan 18, 2019

Conversation

jaymode
Copy link
Member

@jaymode jaymode commented Jan 15, 2019

This change introduces a new class called RequestInfo that encapsulates
the common objects that are passed to the authorization engine methods.
By doing so, we give ourselves a way of adding additional data without
breaking the interface. Additionally, this also reduces the need to
ensure we pass these three parameters in the same order everywhere for
consistency.

@jaymode
Encapsulate request, auth, and action name
2e8fda8 
This change introduces a new class called RequestInfo that encapsulates
the common objects that are passed to the authorization engine methods.
By doing so, we give ourselves a way of adding additional data without
breaking the interface. Additionally, this also reduces the need to
ensure we pass these three parameters in the same order everywhere for
consistency.
@jaymode jaymode added >non-issue :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC labels Jan 15, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

tvernum
tvernum approved these changes Jan 16, 2019
View reviewed changes
Copy link
Contributor

@tvernum tvernum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@jaymode
Copy link
Member Author

jaymode commented Jan 16, 2019

@elasticmachine run gradle build tests 1; run gradle build tests 2; run sample packaging tests

@jaymode
Copy link
Member Author

jaymode commented Jan 17, 2019

@elasticmachine run gradle build tests 1

  MovAvgIT (suite) <<< FAILURES!
   > Throwable #1: java.lang.AssertionError: failure in bulk execution:
   > [2]: index [idx], type [type], id [ox1tXGgB7qPAYICEXfQU], message [ProcessClusterEventTimeoutException[failed to process cluster event (put-mapping) within 11s]]
   > [35]: index [neg_idx], type [type], id [bogus_doc_𝌽𝌫𝌕𝌂aa98], message [ProcessClusterEventTimeoutException[failed to process cluster event (put-mapping) within 11s]]
   > Expected: <false>
   >      but: was <true>

@jaymode
Copy link
Member Author

jaymode commented Jan 17, 2019

@elasticmachine run gradle build tests 1

@jaymode
Copy link
Member Author

jaymode commented Jan 17, 2019 

10:14:59 > Task :server:integTest FAILED
10:14:59 Tests with failures:
10:14:59   - org.elasticsearch.discovery.MasterDisruptionIT.testFailWithMinimumMasterNodesConfigured
10:14:59   - org.elasticsearch.cluster.coordination.Zen1IT.testMultipleNodeMigrationFromZen1ToZen2WithTwoNodes

@elasticmachine run gradle build tests 1

@jaymode
Copy link
Member Author

jaymode commented Jan 17, 2019

@elasticmachine run gradle build tests 1

1 similar comment
@jaymode
Copy link
Member Author

jaymode commented Jan 17, 2019

@elasticmachine run gradle build tests 1

@jaymode jaymode merged commit 9a240c6 into elastic:security_authz_engine Jan 18, 2019
@jaymode jaymode deleted the authz_engine_request_info branch January 18, 2019 02:33
jaymode added a commit to jaymode/elasticsearch that referenced this pull request Feb 1, 2019
@jaymode
Squashed commit of the following:
e5848b4 
commit 05b3a571658312fa4259b652d9b8478ecec278e7
Author: jaymode <jay@elastic.co>
Date:   Thu Jan 31 15:48:48 2019 -0700

    Move request interceptors to AuthorizationService

    This change moves the RequestInterceptor iteration from the action
    filter to the AuthorizationService. This is done to remove the need
    for the use of a role within the request interceptors and replace it
    with the AuthorizationEngine. The AuthorizationEngine interface was
    also enhanced with a new method that is used to determine if a users
    permission on one index is a subset of their permissions on a list
    of indices or aliases.

    Additionally, this change addresses some leftover cleanups.

commit 0e1c191
Merge: 3280607 b7de8e1
Author: jaymode <jay@elastic.co>
Date:   Thu Jan 31 08:56:45 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 3280607
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Tue Jan 29 14:17:37 2019 -0700

    Allow authorization engines as an extension (elastic#37785)

    Authorization engines can now be registered by implementing a plugin,
    which also has a service implementation of a security extension. Only
    one extension may register an authorization engine and this engine will
    be used for all users except reserved realm users and internal users.

commit d628008
Author: jaymode <jay@elastic.co>
Date:   Tue Jan 29 10:06:09 2019 -0700

    fix RBACEngine after restricted indices changes

commit 5074683
Merge: 74f2e99 3c9f703
Author: jaymode <jay@elastic.co>
Date:   Tue Jan 29 08:09:39 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 74f2e99
Merge: 7846ee8 899dfc3
Author: jaymode <jay@elastic.co>
Date:   Fri Jan 25 15:02:07 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 7846ee8
Merge: b9a2c81 a81931b
Author: jaymode <jay@elastic.co>
Date:   Thu Jan 24 07:52:08 2019 -0700

    Merge branch 'master' into security_authz_engine

commit b9a2c81
Author: jaymode <jay@elastic.co>
Date:   Tue Jan 22 09:48:11 2019 -0700

    Fix resolving restricted indices after merging

commit d98a77a
Merge: 83cde40 5c1a1f7
Author: jaymode <jay@elastic.co>
Date:   Tue Jan 22 09:09:23 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 83cde40
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Tue Jan 22 08:03:19 2019 -0700

    Add javadoc to the AuthorizationEngine interface (elastic#37620)

    This commit adds javadocs to the AuthorizationEngine interface aimed at
    developers of an authorization engine. Additionally, some classes were
    also moved to the core project so that they are ready to be exposed
    once we allow authorization engines to be plugged in.

commit 9a240c6
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Thu Jan 17 19:33:35 2019 -0700

    Encapsulate request, auth, and action name (elastic#37495)

    This change introduces a new class called RequestInfo that encapsulates
    the common objects that are passed to the authorization engine methods.
    By doing so, we give ourselves a way of adding additional data without
    breaking the interface. Additionally, this also reduces the need to
    ensure we pass these three parameters in the same order everywhere for
    consistency.

commit 6278eab
Merge: c555a44 4351a5e
Author: jaymode <jay@elastic.co>
Date:   Thu Jan 17 07:51:32 2019 -0700

    Merge branch 'master' into security_authz_engine

commit c555a44
Merge: 1362ab6 ecf0de3
Author: jaymode <jay@elastic.co>
Date:   Wed Jan 16 10:24:33 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 1362ab6
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Wed Jan 16 10:23:45 2019 -0700

    Replace AuthorizedIndices class with a List (elastic#37328)

    This change replaces the AuthorizedIndices class with a simple list.
    The change to a simple list does remove the lazy loading of the
    authorized indices in favor of simpler code as the loading of this
    list is now an asynchronous operation that is delegated to the
    authorization engine.

commit 0246442
Merge: 8ccdc19 a2a40c5
Author: jaymode <jay@elastic.co>
Date:   Tue Jan 15 10:49:12 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 8ccdc19
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Mon Jan 7 13:43:22 2019 -0700

    Introduce asynchronous RBACEngine (elastic#36245)

    In order to support the concept of different authorization engines, this
    change begins the refactoring of the AuthorizationService to support
    this. Previously, the asynchronous work for authorization was performed
    by the AsyncAuthorizer class, but this tied the authorization service
    to a role based implementation. In this change, the authorize method
    become asynchronous and delegates much of the actual permission checking
    to an AuthorizationEngine. The pre-existing RBAC permission checking
    has been abstracted into the RBACEngine. The majority of calls to
    AuthorizationEngine instances are asynchronous as the underlying
    implementation may need to make network calls that should not block
    the current thread, which are often network threads.

    This change is meant to be built upon. The basic concepts are introduced
    without proper documentation, plumbing to enable other
    AuthorizationEngine types, and some items we may want to refactor.
    For example, the AuthorizedIndices class is lazily loaded but this might
    actually be something we want to make asynchronous. We pass a lot of the
    same arguments to the various methods and it would be prudent to wrap
    these in a class; this class would provide a way for us to pass
    additional items needed by future enhancements without breaking the
    interface and requiring updates to all implementations.

    See elastic#32435
This was referenced Feb 1, 2019
Closed
Merged
Merged
jaymode added a commit to jaymode/elasticsearch that referenced this pull request Feb 4, 2019
@jaymode
Squashed commit of the following:
b15f680 
commit 3e60a91
Author: jaymode <jay@elastic.co>
Date:   Mon Feb 4 12:34:23 2019 -0700

    add licensing for authorization engine

commit 1c9a8e1
Author: jaymode <jay@elastic.co>
Date:   Mon Feb 4 12:17:54 2019 -0700

    fix inconsistency in parameter name/type

commit 34aa55a
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Mon Feb 4 11:45:01 2019 -0700

    Authorization engines evaluate privileges for APIs (elastic#38219)

    This commit moves the evaluation of privileges from a few transport
    actions into the authorization engine. The APIs are used by other
    applications for making decisions and if a different authorization
    engine is used that is not role based, we should still allow these APIs
    to work. By moving this evaluation out of the transport action, the
    transport actions no longer have a dependency on roles.

commit 54d7b4c
Merge: e5615d2 715e581
Author: jaymode <jay@elastic.co>
Date:   Mon Feb 4 08:06:14 2019 -0700

    Merge branch 'master' into security_authz_engine

commit e5615d2
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Mon Feb 4 07:53:37 2019 -0700

    Move request interceptors to AuthorizationService (elastic#38137)

    This change moves the RequestInterceptor iteration from the action
    filter to the AuthorizationService. This is done to remove the need
    for the use of a role within the request interceptors and replace it
    with the AuthorizationEngine. The AuthorizationEngine interface was
    also enhanced with a new method that is used to determine if a users
    permission on one index is a subset of their permissions on a list
    of indices or aliases.

    Additionally, this change addresses some leftover cleanups.

commit 0e1c191
Merge: 3280607 b7de8e1
Author: jaymode <jay@elastic.co>
Date:   Thu Jan 31 08:56:45 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 3280607
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Tue Jan 29 14:17:37 2019 -0700

    Allow authorization engines as an extension (elastic#37785)

    Authorization engines can now be registered by implementing a plugin,
    which also has a service implementation of a security extension. Only
    one extension may register an authorization engine and this engine will
    be used for all users except reserved realm users and internal users.

commit d628008
Author: jaymode <jay@elastic.co>
Date:   Tue Jan 29 10:06:09 2019 -0700

    fix RBACEngine after restricted indices changes

commit 5074683
Merge: 74f2e99 3c9f703
Author: jaymode <jay@elastic.co>
Date:   Tue Jan 29 08:09:39 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 74f2e99
Merge: 7846ee8 899dfc3
Author: jaymode <jay@elastic.co>
Date:   Fri Jan 25 15:02:07 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 7846ee8
Merge: b9a2c81 a81931b
Author: jaymode <jay@elastic.co>
Date:   Thu Jan 24 07:52:08 2019 -0700

    Merge branch 'master' into security_authz_engine

commit b9a2c81
Author: jaymode <jay@elastic.co>
Date:   Tue Jan 22 09:48:11 2019 -0700

    Fix resolving restricted indices after merging

commit d98a77a
Merge: 83cde40 5c1a1f7
Author: jaymode <jay@elastic.co>
Date:   Tue Jan 22 09:09:23 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 83cde40
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Tue Jan 22 08:03:19 2019 -0700

    Add javadoc to the AuthorizationEngine interface (elastic#37620)

    This commit adds javadocs to the AuthorizationEngine interface aimed at
    developers of an authorization engine. Additionally, some classes were
    also moved to the core project so that they are ready to be exposed
    once we allow authorization engines to be plugged in.

commit 9a240c6
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Thu Jan 17 19:33:35 2019 -0700

    Encapsulate request, auth, and action name (elastic#37495)

    This change introduces a new class called RequestInfo that encapsulates
    the common objects that are passed to the authorization engine methods.
    By doing so, we give ourselves a way of adding additional data without
    breaking the interface. Additionally, this also reduces the need to
    ensure we pass these three parameters in the same order everywhere for
    consistency.

commit 6278eab
Merge: c555a44 4351a5e
Author: jaymode <jay@elastic.co>
Date:   Thu Jan 17 07:51:32 2019 -0700

    Merge branch 'master' into security_authz_engine

commit c555a44
Merge: 1362ab6 ecf0de3
Author: jaymode <jay@elastic.co>
Date:   Wed Jan 16 10:24:33 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 1362ab6
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Wed Jan 16 10:23:45 2019 -0700

    Replace AuthorizedIndices class with a List (elastic#37328)

    This change replaces the AuthorizedIndices class with a simple list.
    The change to a simple list does remove the lazy loading of the
    authorized indices in favor of simpler code as the loading of this
    list is now an asynchronous operation that is delegated to the
    authorization engine.

commit 0246442
Merge: 8ccdc19 a2a40c5
Author: jaymode <jay@elastic.co>
Date:   Tue Jan 15 10:49:12 2019 -0700

    Merge branch 'master' into security_authz_engine

commit 8ccdc19
Author: Jay Modi <jaymode@users.noreply.github.com>
Date:   Mon Jan 7 13:43:22 2019 -0700

    Introduce asynchronous RBACEngine (elastic#36245)

    In order to support the concept of different authorization engines, this
    change begins the refactoring of the AuthorizationService to support
    this. Previously, the asynchronous work for authorization was performed
    by the AsyncAuthorizer class, but this tied the authorization service
    to a role based implementation. In this change, the authorize method
    become asynchronous and delegates much of the actual permission checking
    to an AuthorizationEngine. The pre-existing RBAC permission checking
    has been abstracted into the RBACEngine. The majority of calls to
    AuthorizationEngine instances are asynchronous as the underlying
    implementation may need to make network calls that should not block
    the current thread, which are often network threads.

    This change is meant to be built upon. The basic concepts are introduced
    without proper documentation, plumbing to enable other
    AuthorizationEngine types, and some items we may want to refactor.
    For example, the AuthorizedIndices class is lazily loaded but this might
    actually be something we want to make asynchronous. We pass a lot of the
    same arguments to the various methods and it would be prudent to wrap
    these in a class; this class would provide a way for us to pass
    additional items needed by future enhancements without breaking the
    interface and requiring updates to all implementations.

    See elastic#32435
jaymode added a commit that referenced this pull request Feb 5, 2019
@jaymode
Allow custom authorization with an authorization engine (#38358)
7ca5495 
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
jaymode added a commit to jaymode/elasticsearch that referenced this pull request Feb 6, 2019
@jaymode
Allow custom authorization with an authorization engine
832d6db 
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: elastic#37785, elastic#37495, elastic#37328, elastic#36245, elastic#38137, elastic#38219

Closes elastic#32435
jaymode added a commit that referenced this pull request Feb 6, 2019
@jaymode
Allow custom authorization with an authorization engine (#38228)
3a0c896 
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@tvernum tvernum tvernum approved these changes

@albertzaharovits albertzaharovits Awaiting requested review from albertzaharovits

Assignees
No one assigned
Labels
>non-issue :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@jaymode @elasticmachine @tvernum