3.7 KiB
Table of Contents
Staff operator portal
Primary problem
We don't have granular control over roles granted to "staff" users.
Auxilliary problems
- We don't support SSO / separate login path
- We don't automatically offboard staff
- Acting as a Staff requires an additional credential
Analysis
We've already implemented authorization checks using the IAM runtime, and can extend that for staff portal usage. The Metal API doens't have a clean separation between APIs for staff users and APIs for customers. In some cases, depending on how you auth an endpoint can respond differently.
The way you auth today with an Auth0 JWT or API key identifies you as the user that we have represented in the Metal DB. Additionally, you can supply a consumer token, and an additional header `x-packet-staff` to enable access to staff features and endpoints.
In the next iteration of the staff operator portal, we would like to be able to give staff users more fine-grained permissions, so they only have access to the resources and actions they need to carry out their jobs.
Miles and team have gone through and identified use cases and potential roles that we want users to be able to have.
The identity team's role in this is determining how best to structure the policy so that we can support the roles as well as changes to the roles with little intervention.
With EIS services, such as token exchange and permissions api, we have a much more dynamic system for dynamically creating and applying permissions.
By default authenticating to the Metal API should treat you as any other customer. If you want to perform the request as if you were a staff user, additional context would be necessary. Right now that additional context is the consumer token and packet staff header. With permissions API, we would no longer need the consumer token, and we could get by with just the packet staff header. The staff header purpose would just be to indicate to the backend that the user wants to act in the staff context.
SpiceDB supports passing additional context within access checks to perform a limited form of attribute-based access control. In our case, a sample schema may look like this: https://play.authzed.com/s/kAikrVuvYYJ7/schema
In this example we have a resource `metlins-foo` owned by a tenant `child0`, which is owned by the `root` tenant. There are two users `adammo` and `mason`. The user `adammo` is a member of the tenant that owns the instance resource, and as a result can view details of the instance without any additional context.
The user `mason` is a member of the root tenant, and if that user tries to view details they get a response back from spicedb indicating that the check is caveated. If the correct context is sent with the check, viewing details is allowed, otherwise it's denied.
This setup allows us to act as both customer and staff users without needing to change relationships on the fly.
Work to be done
In order to implement this for the staff portal, some additional work is necessary:
- Permissions API needs to add support for allowing caveated access checks
- The IAM Runtime spec needs support for that API
- Permissions API policy needs to be updated with caveated policy
- Relationships need to be published with required caveats
- Metal API needs to support passing additional context to the IAM runtime for the caveat checks