[META] Authorization in the REST layer

[cwperks]

REST Requests destined for extensions never hit the Transport-layer of OpenSearch and are forwarded to the extension via the registered Rest handler in the REST Controller. In the current model of security, authorization is performed on authenticated requests via the action filter extension point and is run just-in-time before the action itself is executed on a Node.

This will not work for extensions. A new authz layer must be built within the REST handler wrapper (SecurityRestFilter) to block REST request forwarding to extensions for unauthorized requests.

Resolves:

• As a user, using basic http auth, my requests to extensions are controlled based on my permissions
• As a developer I can define the roles/permissions required in order to access my extension and my extension's APIs.
• As an extension developer, I can check a user's permission for resources managed by my extension
• As a user, when I run an extension I do not have to worry about it accessing data and configurations on the cluster to which it should not have permissions.
• As a user, when I run an extension, it should not allow me to access data and configurations on the cluster which I do not have permissions for.

Questions

• [Question] When does Authentication occur? How do we identify extensions? How do we perform the Authorization check? #2534
• [Question] When should user account roles be looked up? #2651
• [Question] Should request be pass through at Transport Layer once it is authorized at REST layer? #2867

List of items to complete

• Map extension routes to permission-able action names #2589
• Authorizing User against requested extension endpoint #2622
• When should user roles be looked up? [Question] Should authz information be provided in a(n) [encrypted] claim inside the access token given to extensions  #2621
• Authorize the REST requests coming from extension - Authorize rest requests #2753
• [Feature/Extensions] Implement PrivilegeEvaluator on REST Layer. #2751
• [Research] How should DLS/FLS be modified to work with the new authz mechanism - They shouldn't be affected.
• Implement end-to-end testing of the new named routes API and ensure backwards compatibility. #2928
• RestLayerPrivilegesEvaluator must have 100% branch code coverage #2929
• [Research] [BUG] Extension requests show "false" timeout for first few requests to extension due to unknown bug OpenSearch#8652
• Authorization in rest layer automated test for audit logging #3099
• Add test that confirms when Rest and Transport authorization checks overlap #3112

Documentation

• Document this feature on the official documentation website: [DOC] Add doc for Authorization in REST Layer documentation-website#4381

---

Background:

As part of ongoing effort to migrate plugins as extensions, it is essential that the end-user experience related to security remains the same. To ensure this, a solution needs to be implemented to put authorization checks into effect for extensions and associated requests.

Problem:

Current security model enforces authorization checks at Transport Layer. There is no authorization mechanism in place at REST Layer. Since Extensions will not communicate with the cluster at Transport Layer, it is essential to implement some form of authorization to apply security.

In order to implement this new model, following needs to be addressed:

1. How can we authorize user requests REST requests for extensions? How will security be enforced in following scenarios?(Assuming that the cluster has Anomaly Detection extension installed,.)
   1. Scenario: (User has required permissions)
      1. User A has permissions to “cluster:admin/opendistro/alerting/monitor” defined in security plugin.
   2. Scenario: (User doesn’t have required permissions)
      1. User B does not have permissions to “cluster:admin/opendistro/alerting/monitor” .
   3. Scenario: (User has correct permissions but extensions does not have required permission)
      1. User C has required permission “cluster:admin/opendistro/alerting/monitor” and also access to the endpoint /createDetector. However, extension doesn’t have required permission to write anything to its index.
   4. Scenario: (User has smaller set of permissions than extensions)
      1. User D has cluster:admin/opendistro/alerting/monitor/search , but somehow has permission to /createCluster . AD extension has full permission cluster:admin/opendistro/alerting/monitor/* .

Note: AD extension has .. permission is liberally used in the scenario descriptions,. In the actual implementation, a service account will be used “on-behalf-of” extension. And extension will also send “on-behalf-of” user token, but this will be covered separately.

Proposed solutions:

Option 1: No authorization
This option is completely non-viable because:

• extensions actions will not be authorized (a free-roam system with no boundaries)
• It wiill be a downgrade in security model

Option 2: Extensions to have their own authorization model

This option is non-viable because we would to establish trust boundaries. Everything outside the OpenSearch process is untrusted, and extensions will be outside OpenSearch process.

• Extensions by default are untrusted entities. So no authorization decisions made by extensions should be trusted.

Option 3: Perform AuthZ checks at REST layer (Recommended)

• This implementation will allow all incoming request to be authorized before they are handed over to ActionHandler. (This step was previously done at Transport Layer before action execution)

Option 3a: Perform extensions specific AuthZ checks at REST layer, everything else at Transport Layer.

• Decent work, more complicated implementation
• Potential risk of actions not being checked at all
• Pros: TBD
• Cons: TBD

Option 3b: Duplicate AuthZ check in REST layer as well. This will run checks twice.

• Decent work
• Might be slow
• No change to existing workflow
• Pros: TBD
• Cons: TBD

Option 3c: Move AuthZ check from Transport layer to REST layer during API request handling

• Most work, most viable option in long-term, authz checks happen once only
• Current workflow will no longer exist
• What should happen to the checks that happen at Transport layer?
• What actions will no longer be checked?
• Pros: TBD
• Cons: TBD

Diagrams and Visualizations

Current Implementation

Current implementation model doesn’t have a concept of extensions associated.

sequenceDiagram
    actor Client;
    participant OpenSearch;
    participant SecurityRestFilter;
    participant SecurityInterceptor;
    participant Action Handler as Action Handler;

    Client->>OpenSearch: Request
    OpenSearch->>SecurityRestFilter: REST Request Received
    SecurityRestFilter->>SecurityRestFilter: If using client cert, AuthN
    SecurityRestFilter-->>OpenSearch: Continue request
    OpenSearch->>SecurityInterceptor: Transport Request Received
    SecurityInterceptor->>SecurityInterceptor: AuthN user via internal / external auth providers
    SecurityInterceptor->>SecurityInterceptor: Resolve AuthZ for user
    SecurityInterceptor-->>OpenSearch: Allow / deny request
    OpenSearch->>Action Handler: Send transport request to action handler
    Action Handler-->>OpenSearch: Result
    OpenSearch->>Client: Response

Loading

New Implementation

This diagram follows the setup of moving AuthZ checks up into REST Layer. There will not be any new interactions with Transport Layer.

sequenceDiagram
    actor Client;
    participant OpenSearch;
    participant SecurityRestFilter;
    participant SecurityInterceptor;
    participant Action Handler as Action Handler;

    Client->>OpenSearch: Request
    OpenSearch->>SecurityRestFilter: REST Request Received
    rect rgba(60, 0, 0, .3)
    SecurityRestFilter->>SecurityRestFilter: AuthN via client cert / internal / external providers
    SecurityRestFilter->>SecurityRestFilter: Resolve AuthZ for user
    SecurityRestFilter-->>OpenSearch: Allow / deny request
    end
    OpenSearch->>SecurityInterceptor: Transport Request Received
    SecurityInterceptor->>SecurityInterceptor: AuthN via internal / external providers
    SecurityInterceptor->>SecurityInterceptor: Resolve AuthZ for user
    SecurityInterceptor-->>OpenSearch: Allow / deny request
    OpenSearch->>Action Handler: Send transport request to action handler
    Action Handler-->>OpenSearch: Result
    OpenSearch->>Client: Response

Loading

• Pros:

  • Performs complete authz check for all requests (from user and extensions)

• Cons:

  • Doesn’t do early authz check before forwarding user request to extensions. Might result in extra bandwidth as all request will forwarded to extension nodes.

• Improvement:

  • Add an extra step to check whether user’s access is checked against requested endpoint extension endpoint.

New Request Flow

---
title: API Request Flow
---
flowchart TB
    Request((Request)) --> |An API Request is received Opensearch| OpenSearch
    OpenSearch --> |Identifies the handler to be called| RestController
    RestController --> |Request is meant for core| BaseRestHandler
    RestController --> |Request is meant for extension| ExtensionRestHandler
    BaseRestHandler & ExtensionRestHandler --> |Before handler is invoked, <br> request is intercepted by wrapper| Wrapper
    Wrapper --> |Perform authentication & authorization at REST Layer| Check{AuthN-AuthZ check}
    Check --> |Failure, 403 Unauthorized| Response((Response))
    Check -->|Success, proceed with original rest handler| OriginalRestHandler
    OriginalRestHandler --> |Process the request and form the response| OriginalRestHandler
    OriginalRestHandler --> |Return the response, 200 OK| Response

Loading