[Extension] Authentication Backend for JIT Token Validation

[RyanL1997]

Problem:

To accomplish the objective of enabling extensions to act on behalf of a user, we have devised a just-in-time (JIT) Token to manage incoming request authentication. This JIT Token will be transmitted to the extension and subsequently returned to the security plugin for privilege validation concerning both the user and the extension. Consequently, it is necessary to develop an authentication backend to efficiently handle these validation processes.

Design

Here is a graph of how user requests processed through the security-extension feature [graph1]:

If we zoom up to step 4. & 5 in [graph1] then we get [graph2] as following:

This graph shows that during the creation of the JIT Token, the user's roles will be encrypted (see: #2620 ) and combined with other claims. Subsequently, this JIT Token will be sent to the extension for further processing.

Once the extension sends back this token to security plugin, which is step 6 in [graph1] then we get [graph3] as following:

Once the security plugin receives the JIT Token back, it will be forwarded into the authentication backend. The following tasks will be initiated:

• Decrypt roles / backend_roles fields inside of the JIT Token
• Two validations will happen:
  • Validation of extensions privilege - Service Gate (1st gate and we process to the next gate after the validation)
    • Similar to user roles this field is called governing policies, and the major difference is that you cannot map those policies to users. We need to do is to compare these policies with the specific actions from the request.
    • If the Service Gate validation fails, it will directly abort the target action, and it will not process to the User Gate.
  • Validation of user privilege - User Gate (2nd gate)
    • Decrypt roles / backend_role
    • Validate the privileges by using the roles concepts (like current role concept)

Appendix

[WIP] I will put link this section to some of the issues with more concepts of roles.yml.

[stephen-crawford]

[Triage] This is part of the Extensions project.

[RyanL1997]

Hi @cwperks, I have transferred the doc into this issue. Feel free to leave some thoughts.

[cwperks]

Hi @RyanL1997, thank you for adding the diagrams for this issue! These are good visualizations for what we've been discussing about creating the tokens in core/security plugin to pass to an extension and then what happens on the core/security plugin side of things if the extension uses the token to make a request to the cluster. Some of the diagrams on here may be subject to change based on the discussion on this issue: #2587

This comment in particular (#2587 (comment)) talks about how the mapping would work from the extension + user -> set of role/policies that would be used for privilege evaluation.

In short, the idea is to add a new services_mappings sub-section on a roles_mapping to map an extension + user to a set of role/policies to check at the service gate:

# All users of service <service_id> are mapped to act_an_original_user
act_as_original_user:
  reserved: false
  description: "Maps <service_id> extension to act_as_original_user"
  services_mappings:
   <service_id>:
      users: 
        - "*"

For the diagrams, I would update anywhere you show user roles to a different hypothetical example (userA mapped to role1, role2, role3 - you can keep these abstracted, they represent any roles the user is mapped to)

It looks like the set of user permissions used in the example was a set of permissions for AD service account:

extension/ad_svc:
    reserved: true
    index_permissions:
        - index_patterns:
            - '.opendistro-anomaly-results*'
            - '.opendistro-anomaly-detector*'
            - '.opendistro-anomaly-checkpoints'
            - '.opendistro-anomaly-detection-state'
        allowed_actions:
            - 'indices_all'

Service account / service account token is different than the just-in-time tokens that this issue discusses because for a service account token, the extension is not acting on behalf of another user. In this case, the extension is interacting with the cluster using its service account token and privilege evaluation would be the same as normal user privilege evaluation where there is no service gate.

[stephen-crawford]

Hi @RyanL1997, thank you for putting together these great diagrams. What you are looking at seems like a good option for handling our use scenario. One thing I wanted to clarify was our terminology. In the past, I have seen posts discussing both "On-behalf-of" and "just-in-time" tokens. Are these the same thing in the model you are proposing? I only know about "just-in-time" tokens from this post, but I have seen a fair bit about "on-behalf-of" tokens that would appear to overlap. Are these the same thing?

[RyanL1997]

Hi @scrawfor99, thanks for bringing this up. Yes, they are the same thing.

I think the term "on-behalf" is focusing on the functionality sides of this token. In other word, we would like to use this token do some of the validations of both user and extensions, so that the extension can perform some actions like the user does nowadays.

For the term "just-in-time", it is more related to its time-sensitive feature. For some traditional JWT token, you can always modify the nbf claim to issue a token for future usage. However, for our scenario, we want this token only be issued and used once the user sends out a request. After the entire request [graph1] is done, this token will be expired immediately. I believe this is the reason why we named it JIT.