You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(auth): make token header and prefix configurable via flags and env
- Introduced `AuthTokenHeader` and `AuthTokenPrefix` fields to EnvConfig
- Default token extraction uses `Authorization` header with `Bearer ` prefix
- Updated TokenClientFactory to dynamically parse token using configured header and prefix
- Added new CLI flags: `--auth-token-header` and `--auth-token-prefix`
- Updated Makefile to support overriding header and prefix via `AUTH_TOKEN_HEADER` and `AUTH_TOKEN_PREFIX`
- Improved error messages and testability of token parsing logic
- Added Ginkgo unit tests for TokenClientFactory.ExtractRequestIdentity with and without prefixes
- Cleaned up README:
- Replaced all `X-Forwarded-Access-Token` references with `Authorization: Bearer`
- Documented how to override token header and prefix via CLI, env, or Makefile
Signed-off-by: Eder Ignatowicz <ignatowicz@gmail.com>
@@ -381,17 +381,16 @@ The BFF supports two authentication modes, selectable via the --auth-method flag
381
381
- In this mode, user identity is passed via the kubeflow-userid and optionally kubeflow-groups headers.
382
382
- This is the default mode and works well with mock clients and local testing.
383
383
-`user_token`: Uses a user-provided Bearer token for authentication.
384
-
- The token must be passed in the `X-Forwarded-Access-Token` header.
385
-
- Useful when the frontend is fronted by an auth proxy (e.g., Istio + OIDC) that injects a valid Kubernetes token.
386
-
384
+
- The token must be passed in the `Authorization` header using the Bearer schema (e.g., `Authorization: Bearer <token>`).
385
+
- This method works with OIDC-authenticated flows and frontend proxies that preserve standard Bearer tokens.
387
386
388
387
#### 4. How BFF authorization works?
389
388
390
389
Authorization is performed using Kubernetes access reviews, validating whether the user (or their groups) can perform certain actions.
391
390
There are two review mechanisms depending on the authentication mode:
392
391
- Internal mode (auth-method=internal):
393
392
Uses SubjectAccessReview (SAR) to check whether the impersonated user (from kubeflow-userid and kubeflow-groups headers) has the required permissions.
394
-
- User token mode (auth-method=user_token): Uses SelfSubjectAccessReview (SSAR), leveraging the Bearer token provided in the X-Forwarded-Access-Token header to check the current user's permissions directly.
393
+
- User token mode (auth-method=user_token): Uses SelfSubjectAccessReview (SSAR), leveraging the Bearer token provided in the `Authorization` header to check the current user's permissions directly.
395
394
396
395
##### Authorization logic
397
396
* Access to Model Registry List (/v1/model_registry):
@@ -402,6 +401,25 @@ Uses SubjectAccessReview (SAR) to check whether the impersonated user (from kube
402
401
- Checks for get on the specific service (identified by model_registry_id) in the namespace.
403
402
- If authorized, access is granted.
404
403
404
+
##### Overriding Token Header and Prefix
405
+
406
+
By default, the BFF expects the token to be passed in the standard Authorization header with a Bearer prefix:
407
+
408
+
```shell
409
+
Authorization: Bearer <your-token>
410
+
```
411
+
If you're integrating with a proxy or tool that uses a custom header (e.g., X-Forwarded-Access-Token without a prefix), you can override this behavior using environment variables or Makefile arguments.
412
+
413
+
```shell
414
+
make run AUTH_METHOD=user_token AUTH_TOKEN_HEADER=X-Forwarded-Access-Token AUTH_TOKEN_PREFIX=""
415
+
```
416
+
This will configure the BFF to extract the raw token from the following header:
417
+
418
+
```shell
419
+
X-Forwarded-Access-Token: <your-token>
420
+
```
421
+
422
+
405
423
#### 5. How do I allow CORS requests from other origins
406
424
407
425
When serving the UI directly from the BFF there is no need for any CORS headers to be served, by default they are turned off for security reasons.
Copy file name to clipboardExpand all lines: clients/ui/bff/cmd/main.go
+2Lines changed: 2 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -33,6 +33,8 @@ func main() {
33
33
flag.TextVar(&cfg.LogLevel, "log-level", parseLevel(getEnvAsString("LOG_LEVEL", "INFO")), "Sets server log level, possible values: error, warn, info, debug")
34
34
flag.Func("allowed-origins", "Sets allowed origins for CORS purposes, accepts a comma separated list of origins or * to allow all, default none", newOriginParser(&cfg.AllowedOrigins, getEnvAsString("ALLOWED_ORIGINS", "")))
35
35
flag.StringVar(&cfg.AuthMethod, "auth-method", "internal", "Authentication method (internal or user_token)")
36
+
flag.StringVar(&cfg.AuthTokenHeader, "auth-token-header", getEnvAsString("AUTH_TOKEN_HEADER", config.DefaultAuthTokenHeader), "Header used to extract the token (e.g., Authorization)")
37
+
flag.StringVar(&cfg.AuthTokenPrefix, "auth-token-prefix", getEnvAsString("AUTH_TOKEN_PREFIX", config.DefaultAuthTokenPrefix), "Prefix used in the token header (e.g., 'Bearer ')")
0 commit comments