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.

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

[Extension] Authentication Backend for JIT Token Validation #2619

Closed
Tracked by #2573
RyanL1997 opened this issue Mar 31, 2023 · 5 comments
Closed
Tracked by #2573

[Extension] Authentication Backend for JIT Token Validation #2619

RyanL1997 opened this issue Mar 31, 2023 · 5 comments
Assignees
Labels
triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable.

Comments

@RyanL1997
Copy link
Collaborator

RyanL1997 commented Mar 31, 2023

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]:
Extensions for security
If we zoom up to step 4. & 5 in [graph1] then we get [graph2] as following:
OpenSearch_JIT_Extension drawio
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:
OpenSearch_JIT_Extension drawio (1)
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.

@github-actions github-actions bot added the untriaged Require the attention of the repository maintainers and may need to be prioritized label Mar 31, 2023
@RyanL1997 RyanL1997 changed the title Authentication Backend for JIT Validation [Extension] Authentication Backend for JIT Validation Mar 31, 2023
@RyanL1997 RyanL1997 changed the title [Extension] Authentication Backend for JIT Validation [Extension] Authentication Backend for JIT Token Validation Mar 31, 2023
@stephen-crawford stephen-crawford added triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable. and removed untriaged Require the attention of the repository maintainers and may need to be prioritized labels Apr 3, 2023
@stephen-crawford
Copy link
Contributor

[Triage] This is part of the Extensions project.

@RyanL1997
Copy link
Collaborator Author

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

@cwperks
Copy link
Member

cwperks commented Apr 4, 2023

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
Copy link
Contributor

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
Copy link
Collaborator Author

RyanL1997 commented Apr 4, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable.
Projects
Status: Done
Development

No branches or pull requests

3 participants