pipeline-manager: turn API keys into a named API object #1126
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lalithsuresh
force-pushed
the
api-key
branch
2 times, most recently
from
33c6f07
to
e5e2575
Compare
lalithsuresh
force-pushed
the
api-key
branch
4 times, most recently
from
47e5045
to
290fc9c
Compare
lalithsuresh
force-pushed
the
api-key
branch
from
989e0ca
to
55dfd3e
Compare
Signed-off-by: Lalith Suresh <lalith@feldera.com>
Signed-off-by: Lalith Suresh <lalith@feldera.com>
Signed-off-by: Lalith Suresh <lalith@feldera.com>
Our authz middleware used an Http Bearer Authentication scheme
and custom headers ("x-api-keys") for API keys.
Using API keys in this manner conflicts with some internal assumptions
Actix makes; Our `auth_validator()` works as it should end-to-end but
the Actix framework still logs an error that the request is unathorized,
because it could not find an authorization header with a bearer token in
it.
```
2023-12-10 22:39:42 DEBUG [manager] Error for Option<T> extractor: 401 Unauthorized
```
This could be confusing to users/operators, so I looked into ways to
avoid the custom header. The idea option would have been to keep the
`Bearer` scheme for OIDC JWT tokens and `Basic` for API keys, but
it's not clear from Actix's APIs how to support this. It seems to only
support one authentication scheme per middleware and it felt cumbersome
to implement customized schemes.
So for now, we go for a simple alternative. Both API keys and JWT tokens
use the `Bearer` scheme. API keys are prefixed with `apikeys:` whereas
JWT tokens are encoded as is.
This keeps the design simple, and users should be able to freely replace
a bearer token with an API key in their machine-to-machine workflows.
Signed-off-by: Lalith Suresh <lalith@feldera.com>
Signed-off-by: Lalith Suresh <lalith@feldera.com>
Signed-off-by: Lalith Suresh <lalith@feldera.com>
lalithsuresh
force-pushed
the
api-key
branch
from
55dfd3e
to
14b3923
Compare
gz
approved these changes
Dec 11, 2023
| .filter(|k| k.0 .0 == tenant_id) | ||
| .map(|k| ApiKeyDescr { | ||
| id: k.1 .0, | ||
| name: k.0 .1.clone(), |
There was a problem hiding this comment.
maybe these should be named arguments
lalithsuresh
force-pushed
the
api-key
branch
3 times, most recently
from
ac71027
to
30d079c
Compare
…ts for ApiKey-related strings Co-authored-by: Gerd Zellweger <gz@feldera.com> Signed-off-by: Lalith Suresh <lalith@feldera.com>
lalithsuresh
force-pushed
the
api-key
branch
from
30d079c
to
68f7bac
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds an API key object type. It introduces endpoints to create, list, get and delete API keys via the REST API.
The PR also reworks the (previously internal) differentiation between JWT tokens and API keys. Bearer tokens are now a JWT token obtained via an Oauth2/OIDC login workflow or an API key (
apikey:1234..). We no longer use a separate custom header for API keys.This PR also exposes security schemes via OpenAPI and allows Authorization via the swagger UI. So you can now copy in a JWT token or API key via the swagger UI, and the suggested curl commands will correctly use the supplied bearer token. We need to investigate whether this is sufficient to address #1084 (cc @Karakatiza666).
Fixes the backend side of #1103.
Fixes #1114.
See below for what gets added to the Swagger UI:
Authorize button:
Enter bearer token:
Issue authenticated calls:
Is this a user-visible change (yes/no): yes