From c14d8e3446d4a0201371978ecef5eaeb41a1094a Mon Sep 17 00:00:00 2001 From: "pre-commit-ci[bot]" <66853113+pre-commit-ci[bot]@users.noreply.github.com> Date: Thu, 20 Oct 2022 03:28:19 +0000 Subject: [PATCH] [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci --- docs/source/rbac/tech-implementation.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/docs/source/rbac/tech-implementation.md b/docs/source/rbac/tech-implementation.md index 2a4c170a..ea6231f7 100644 --- a/docs/source/rbac/tech-implementation.md +++ b/docs/source/rbac/tech-implementation.md @@ -43,10 +43,8 @@ Prior to 3.0, tokens stored _roles_, which meant their scopes were resolved on each request. ::: - API tokens grant access to JupyterHub's APIs. The [RBAC framework](https://auth0.com/docs/manage-users/access-control/rbac) allows for requesting tokens with specific permissions. - RBAC is involved in several stages of the OAuth token flow. When requesting a token via the tokens API (`/users/:name/tokens`), or the token page (`/hub/token`), @@ -78,21 +76,17 @@ Figure 1. Resolving roles and scopes during API token request With the RBAC framework, each authenticated JupyterHub API request is guarded by a scope decorator that specifies which scopes are required in order to gain the access to the API. - When an API request is made, the requesting API token's scopes are again intersected with its owner's (yellow box in {ref}`Figure 2 `) to ensure that the token does not grant more permissions than its owner has at the request time (e.g., due to changing/losing roles). If the owner's roles do not include some scopes of the token, only the _intersection_ of the token's and owner's scopes will be used. For example, using a token with scope `users` whose owner's role scope is `read:users:name` will result in only the `read:users:name` scope being passed on. In the case of no _intersection_, an empty set of scopes will be used. - The parsed scopes are compared to the scopes required to access the API as follows: - if the API scopes are present within the set of parsed scopes, the access is granted and the API returns its "full" response - if that is not the case, another check is utilized to determine if subscopes of the required API scopes can be found in the parsed scope set: - - if found, the RBAC framework employs the {ref}`filtering ` procedures to refine the API response to access only resource attributes corresponding to the passed scopes. For example, providing a scope `read:users:activity!group=class-C` for the `GET /users` API will return a list of user models from group `class-C` containing only the `last_activity` attribute for each user model - - if not found, the access to API is denied {ref}`Figure 2 ` illustrates this process highlighting the steps where the role and scope resolutions as well as filtering occur in orange.