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

Support for per-share bearer token configs #162

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

atgabe
Copy link

@atgabe atgabe commented Jun 15, 2022

At the moment authorization is everything or nothing, with a single bearer token providing access to the entire server. This PR expands authorization to support per-share bearer token configs.

  • changes the authorization.bearerToken property to authorization.universalBearerToken, and adds an authorization.shares array to configure additional tokens unique to a share
  • adds an AuthManager trait and two implementations (BearerTokenAuth and NoAuth) to handle authorization
  • expands unit tests to cover per-share authorization cases

There are certainly other approaches to this feature, so let me know if an alternative approach is deemed preferable.

Gabe Cicione and others added 2 commits June 15, 2022 19:07
- changes the `authorization.bearerToken` property to `authorization.universalBearerToken`, and adds an `authorization.shares` array to configure additional tokens unique to a share
- adds an AuthManager trait and two implementations (BearerTokenAuth and NoAuth) to handle authorization
- expands unit tests to cover per-share authorization cases

Signed-off-by: Gabe Cicione <gabe.dev@apple.com>
@zhuansunxt
Copy link
Collaborator

An alternative approach on this is to introduce Recipient as a first class concept, each with its own token and support fine-grained Share <-> Recipient access control. @atgabe Do you think that approach satisfy your needs?

@atgabe
Copy link
Author

atgabe commented Sep 6, 2022

@zhuansunxt yup, that approach would work for our use case and sounds like it more closely mirrors the Databricks strategy. Is that approach in development elsewhere or a change you'd like to see on this PR?

@zhuansunxt
Copy link
Collaborator

@atgabe It would be great to submit an issue and use it to describe the general approach (like an RFC) so we can agree on design decisions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants