106 lines
3.7 KiB
Markdown
106 lines
3.7 KiB
Markdown
|
|
# Table of Contents
|
|
|
|
1. [Staff operator portal](#org992e17b)
|
|
1. [Primary problem](#org538f8d6)
|
|
2. [Auxilliary problems](#org4412c9f)
|
|
3. [Analysis](#org9b704f7)
|
|
4. [Work to be done](#orgcad9c50)
|
|
|
|
|
|
<a id="org992e17b"></a>
|
|
|
|
# Staff operator portal
|
|
|
|
|
|
<a id="org538f8d6"></a>
|
|
|
|
## Primary problem
|
|
|
|
We don't have granular control over roles granted to "staff" users.
|
|
|
|
|
|
<a id="org4412c9f"></a>
|
|
|
|
## Auxilliary problems
|
|
|
|
- We don't support SSO / separate login path
|
|
- We don't automatically offboard staff
|
|
- Acting as a Staff requires an additional credential
|
|
|
|
|
|
<a id="org9b704f7"></a>
|
|
|
|
## 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.
|
|
|
|
|
|
<a id="orgcad9c50"></a>
|
|
|
|
## 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
|
|
|