[Extensions] Create a single secure index to store identity information for scheduled jobs

[cwperks]

In the plugin model for job scheduler, in order for plugins to provide a user context for a job run asynchronously they will store user info alongside job details and inject the roles of the user into the threadcontext at the time of job execution.

This issue seeks to deprecate the extra work that plugin developers need to perform by storing user info in a single secure index owned by the security plugin. Entries into this index will map 1-to-1 with job details across all job details indices and will have a reference to the corresponding job details entry. The reference would be job_id and job_index which would link to a single job details entry.

An entry in this index could look like:

{
    "_index": ".opendistro-security-scheduled-job-identity",
    "_id": "8LqHIIgBK2sqLDsF7ULP",
    "_score": 1.0,
    "_source":
    {
        "job_id": "7rqHIIgBK2sqLDsF6EIP",
        "job_index": ".hello-world-jobs",
        "created_time": 1684172959180,
        "last_update_time": 1684172959180,
        "user":
        {
            "name": "admin",
            "backend_roles":
            [
                "admin"
            ],
            "roles":
            [
                "own_index",
                "all_access"
            ],
            "custom_attribute_names":
            [],
            "user_requested_tenant": null
        }
    }
}

This index should have system index protection and it may also be beneficial to have the contents base64 encoded.

Ignore content below this line. The content below this line was for a prior design that has since been updated.

---

In the current proposal for Async Ops for Extensions (https://github.com/opensearch-project/security/issues/2574#issuecomment-1492111756), the new model of security for Job Scheduler includes providing a refresh token in the Job Definition for JS.

We need to define exactly what a refresh token is and how it differs from an access token.

Some properties of a refresh token:

- On its own it should not provide access to the cluster - It can be utilized to get a new access token and a new refresh token - Should it be one-time use?

Initial ideas for a refresh token looks very similar to the access token proposed in https://github.com/opensearch-project/security/issues/2573, but without an expiration claim and an additional claim that identifies this token as a refresh token.

Typically in OAuth 2.0 refresh tokens are opaque strings, but I don't think it would be possible here. The difficulty lies in how to provide the access token with roles and backend_roles given that roles lookup cannot be performed across all authentication backends.

Example payload:

Payload:
{
  "iat":1676908684,
  "sub":"<principal_identifier_token>",
  "r":"<encrypted_mapped_roles>", # r for roles
  "br": "<encrypted_backend_roles>", # br for backend_roles
  "aud": "extension/{extensionUniqueId}",
  "type": "refresh"
}

[stephen-crawford]

[Triage] This is part of the Extensions project.