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

Multi project vs no project model #416

Open
kushsharma opened this issue Nov 15, 2023 · 0 comments
Open

Multi project vs no project model #416

kushsharma opened this issue Nov 15, 2023 · 0 comments

Comments

@kushsharma
Copy link
Member

Is your feature request related to a problem? Please describe.
Frontier structures hierarchy as Organization > Projects > Resources at the moment. So to onboard a customer in the system,

  1. Create a user account
  2. The user will create an organization
  3. User will create a project
  4. User will start using the system via resources

For tenant isolation in backend services, project id can be used as a tenant id. Because each backend service would require this project id to really execute the call, we will have to pass the id of the active project for which the operation needs to be performed. For example, to list all the order items from a shopping-production project, the call needs to tell the backend service, GET all the items under shopping-production project even though the user might have access to more than one project. To identify an active project from the list of N, Frontier already supports X-Project-Id header which needs to be passed from frontend. If this header is set, and user has access to this project, Frontier JWT gets populated by project_id claim of uuid of the project.

If there is no concept of a single active project and all projects should just work, the backend needs to handle the creation of project at application level and Frontier may not be involved at all.

This flow works fine for multi-project models but Frontier should also support working with no project or just at org level hierarchy.

Describe the solution you'd like
We can't really change the hierarchy model of Frontier, instead we can ease the project creation and management by making it transparent to user. The flow for bootstraping an org can be merged with bootstraping a project as well so when the org gets created by say acme name, we can create a project with the name acme-default automatically(ideally the frontend can make a call for this post org creation). Now all subsequent calls to backend service will only work with this project id.

The current jwt structure of Frontier has org_ids as one of the claim, this is a comma separated list of orgs user has access currently. But if we also want to figure out what all projects this user has access, it requires another call in Frontier. Although it's not a big deal but it would be nice to have them all in the jwt if needed. An additional claim would be:

{
  "membership": [
    {
      "id": ".. org id ...",
      "projects": [{"id":"... project id ..."}, { ... }],
    },
    { ... }
  ]
}

Adding this claim can blot jwt for users who may not need this so it can be made configurable from frontier configuration.

But after membership claim is added, org_ids claim will be redundant. We already have a config to disable it so it should be fine and we can keep this membership claim under a config as well. By default, it can be kept disabled.

Describe alternatives you've considered
For multi-project(or even no project model), backend services can use /v1beta1/users/{id}/projects to get all project list and then take whatever action they need. But if the user has access to multiple organizations, either org id just like project id needs to be sent via frontend to backend of their own or sytem would still need an organization selector just like project selector?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 2024
Development

No branches or pull requests

1 participant