[2.x] Adds On-Behalf-Of authentication mechanism and service account capability

[DarshitChanpura]

Description

Backport On-behalf-of Authentication and Service account into the 2.x branch.

Category: New Feature

Issues Resolved

• Related to [META] Service Accounts #2944
• Related to [META] On-Behalf-Of Authentication #2573
• Pre-requisite PR: [2.x] Adds changes related to OnBehalfOf and Service Accounts feature OpenSearch#10258

Testing

Integration testing

Check List

• New functionality includes testing
• New functionality has been documented
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[RyanL1997]

The manual testing with the build of opensearch-project/OpenSearch#10258 succeed:

➜  ~ curl -XPOST "https://localhost:9200/_plugins/_security/api/generateonbehalfoftoken" --insecure -u 'admin:admin' --data '
{
  "reason":"Testing",
  "service":"extension123",
  "durationSeconds":"600"
}' -H 'Content-Type: application/json' | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   462  100   382  100    80    758    158 --:--:-- --:--:-- --:--:--   920
{
  "user": "admin",
  "authenticationToken": "eyJhbGciOiJIUzUxMiJ9.eyJpc3MiOiJvcGVuc2VhcmNoIiwiaWF0IjoxNjk1OTIzNzU1LCJzdWIiOiJhZG1pbiIsImF1ZCI6ImV4dGVuc2lvbjEyMyIsIm5iZiI6MTY5NTkyMzc1NSwiZXhwIjoxNjk1OTI0MzU1LCJlciI6IjczU1JBZjlueStqR3AxczFLSjk4d1VOeXJDckY0TWcydW1pSU4vN0c5YkE9In0.op-l1zhpwz93zvYYzLEuGXFLH5ZGf_5wvMbd4SNtAtWClTmDrP7tepfC7X5yxuymnirZwHtYNk0eams_NQOJew",
  "durationSeconds": 600
}

[scrawfor99]

I would recommend splitting this into two PRs: one that does OBO changes and one that does service account changes.

I am not as familiar with the OBO changes since I did not write them originally but here is what is required for service accounts:

1. Implement IdentityPlugin in OpenSearchSecurityPlugin
2. Create an SecurityPluginTokenManager or something similar that implements the TokenManager interface.
   This should be able to issue a service account token and an on behalf of token
3. Connect the IdentityPlugin method to the Token Manager so that when a new extension is registered and the transport action registering its security settings is called, we also issue it a new service account token.
4. Inside the token manager, the service account issuance process should register a new internal user account for the extension if one does not already exist.
5. When an extension attempts to use a service account token it will be using it as the authentication header for its request so all the changes relating to using it should go through the normal auth process of an internal user account.
   The only differences are that a enabled equals false service account should fail to perform any requests.
   As part of the threat model mitigation we also need to block any actions which are not. being explicitly performed on the system index associated with the service account being used. This requires issuance of system indices etc. for extensions which is not currently being done. I think we can wait on this but I would ask @peternied and @cwperks. Since they should know the decision there.
6. Test service accounts are issued properly by using the fake rest handler with a service account token generated in a mocked scenario. We don't need to test the transport deliverance inside the security plugin because that is outside of the scope.

[RyanL1997]

Thanks @scrawfor99! Alright then, I will do the backport of OBO separately.

[scrawfor99]

Left comments on the original changes to give some direction.

[scrawfor99]

So the way Craig set this up, the idea is to register a set of extension security settings when an extension is installed/registered as part of the core initialization process. To make this work with service accounts the general idea would be to make sure that a service account is only able to operate on the indices listed in the reserved_indices list and affiliated with themselves--this should use a mapping or some other mechanism.

[DarshitChanpura]

I have removed BACKEND_ROLES setting for now. In SecurityIndexAccessEvaluator we check by looking up extension settings by username (should match extension name), and then matching the requested index with extension's reserved index to determine whether access should be granted

[scrawfor99]

I think @RyanL1997 is doing this?

[DarshitChanpura]

This link will only go live after it has been published. I would recommend just redirecting them to website. @RyanL1997 thoughts?

[RyanL1997]

I'm fine to redirect that to the homepage of our documentation website, at least for now. So it will be https://opensearch.org/docs/latest/

[RyanL1997]

Or should we wait until the doc team publish the work so that we can use aa more accurate url?

[DarshitChanpura]

@RyanL1997 @scrawfor99 Should this be closed as there is a separate effort on-going for this?

[DarshitChanpura]

I'll be closing this out in lieu of ongoing efforts to merge Service accounts and OBO related changes separately. Please re-open if this is picked back up.