[docs] Auth: remove references to pipeline-manager args

Karakatiza666 · gz · commit 1d7540943ef0 · 2025-11-19T01:26:05.000Z
Add docs for generic-oidc provider

Fix issuer-tenant does not accept boolean

Signed-off-by: Karakatiza666 &lt;bulakh.96@gmail.com&gt;
diff --git a/crates/pipeline-manager/src/config.rs b/crates/pipeline-manager/src/config.rs
@@ -695,7 +695,7 @@ pub struct ApiServerConfig {
     /// For example, "<https://acme-corp.okta.com/oauth2/default>" becomes "acme-corp".
     /// Useful for simple multi-user access without requiring custom tenant claims.
     #[serde(default)]
-    #[arg(long, env = "FELDERA_AUTH_ISSUER_TENANT")]
+    #[arg(long, action = clap::ArgAction::Set, default_value_t = false, env = "FELDERA_AUTH_ISSUER_TENANT")]
     pub issuer_tenant: bool,
 
     /// Allow individual user tenants based on the 'sub' claim.
diff --git a/docs.feldera.com/docs/get-started/enterprise/authentication/generic-oidc.md b/docs.feldera.com/docs/get-started/enterprise/authentication/generic-oidc.md
@@ -0,0 +1,113 @@
+# Generic OIDC Provider
+
+This guide explains how to configure any OIDC-compliant authentication provider for Feldera Enterprise.
+
+## Overview
+
+Feldera supports standard OIDC/OAuth2 authentication, allowing you to integrate with any OIDC-compliant identity provider such as Auth0, Keycloak, Azure AD, Google Identity, or other enterprise identity providers.
+
+## OIDC Application Setup
+
+### 1. Create OIDC Application
+
+In your OIDC provider's admin console:
+
+1. Create a new application or client
+2. Select **Single-Page Application (SPA)** as the application type
+3. Fill in application details:
+   - **Application name**: `Feldera` (or your preferred name)
+   - **Application description**: Optional description for your organization
+
+### 2. Configure Grant Types
+
+Enable the following OAuth 2.0 grant types:
+
+- **Authorization Code** grant type (required)
+- **Refresh Token** (recommended for long-lived sessions)
+- **PKCE** (Proof Key for Code Exchange) - highly recommended for security
+
+### 3. Configure Redirect URLs
+
+Add the following URLs to your OIDC application configuration:
+
+- **Sign-in redirect URI**: `https://<your-feldera-domain>/auth/callback/`
+- **Sign-out redirect URI**: `https://<your-feldera-domain>/`
+
+:::note
+
+**Important:** The trailing slash (`/`) in the callback URL **must be included**. Most OIDC providers require exact URL matching.
+
+:::
+
+### 4. Configure Scopes
+
+Ensure the following OpenID Connect scopes are allowed:
+
+- `openid` (required)
+- `profile` (recommended)
+- `email` (required)
+- `offline_access` (required)
+
+## Tenant Assignment (Optional)
+
+Feldera supports authorization through multiple tenant assignment strategies. By default, each user gets their own individual tenant based on the `sub` claim.
+
+### Multi-Tenant Access with Custom Claims
+
+To enable managed tenancy, configure your OIDC provider to include custom claims in the Access token:
+
+#### `tenants` Claim
+
+Configure your OIDC provider to include a `tenants` claim in the **Access token**:
+
+- **Claim name**: `tenants`
+- **Token type**: Access Token
+- **Value type**: Array of strings or comma-separated string
+- **Value**: List of tenant names the user can access
+
+**Example token claim:**
+```json
+{
+  "tenants": ["engineering", "data-science", "analytics"]
+}
+```
+
+When multiple tenants are configured, users can switch between tenants in the Web Console or specify the tenant using the `Feldera-Tenant` HTTP header.
+
+## Group-Based Authorization (Optional)
+
+To restrict access based on group membership, configure your OIDC provider to include a `groups` claim in the Access token:
+
+- **Claim name**: `groups`
+- **Token type**: Access Token
+- **Value type**: Array of strings
+- **Value**: List of group names the user belongs to
+
+**Example token claim:**
+```json
+{
+  "groups": ["feldera-users", "data-engineers", "admins"]
+}
+```
+
+When `authorizedGroups` is configured in Feldera, users must have at least one matching group to access the platform.
+
+## Configure Feldera
+
+After setting up your OIDC provider, configure Feldera using the Helm chart values; see [examples](index.mdx#Tenant%20Assignment%20use%20cases) for common authorization scenarios.
+
+### Configuration Parameters
+
+| Parameter | Description | Example |
+|-----------|-------------|---------|
+| `auth.clientId` | Your OIDC application's client ID | `abc123xyz456` |
+| `auth.issuer` | Your OIDC provider's issuer URL | `https://auth.example.com` |
+| `authorization.authAudience` | Expected audience claim value in Access tokens | `feldera-api` |
+
+:::tip
+
+Consult the [main authentication documentation](index.mdx#Configuration%20options) for complete configuration options.
+
+:::
+
+Refer to your provider's documentation for specific setup instructions while following the general OIDC configuration pattern outlined above.
diff --git a/docs.feldera.com/docs/get-started/enterprise/authentication/index.mdx b/docs.feldera.com/docs/get-started/enterprise/authentication/index.mdx
@@ -22,20 +22,19 @@ For API key authentication, the key is associated with the tenant through which
 We support multiple authorization use-cases through strategies to assign tenant to Feldera API and clients' users.
 
 As an orthogonal feature, the authorized-groups startup parameter can be used to limit access to the users who are a member of at least one of the groups in this list. The membership is determined based on the `groups` claim of an OIDC Access token.
-Users must belong to at least one of the specified groups to access Feldera. If `--authorized-groups` is not specified or empty, no group restrictions apply.
+Users must belong to at least one of the specified groups to access Feldera. If `authorizedGroups` is not specified or empty, no group restrictions apply.
 
 ## Tenant Assignment Strategies
 
 Feldera provides three different tenant assignment strategies to support different deployment patterns:
 
 ### Individual Tenancy (Enabled by default)
 
-Each authenticated user gets their own private tenant based on the `sub` claim of the OIDC Access token. Does not require authentication provider configuration. Configured with --individual-tenant startup flag.
+Each authenticated user gets their own private tenant based on the `sub` claim of the OIDC Access token. Does not require authentication provider configuration. Configured with `authorization.individualTenant` Helm value.
 
 ### Organization-wide Tenancy
 
-Users from the same organization share a tenant, derived from the issuer hostname of the authentication token. Does not require authentication provider configuration. Configured with --issuer-tenant startup flag.
-
+Users from the same organization share a tenant, derived from the issuer hostname of the authentication token. Does not require authentication provider configuration. Configured with `authorization.issuerTenant` Helm value.
 ### Managed Tenancy
 
 Multiple teams can use the same Feldera instance with complete tenant isolation. Each team's users should be assigned to corresponding tenant(s) with the proper configuration of the dynamic `tenants` claim in the OIDC Access token.
@@ -58,12 +57,6 @@ auth:
   enabled: false
 ```
 
-Direct pipeline-manager configuration:
-
-```bash
-pipeline-manager ... --auth-provider=none
-```
-
 ### Individual access
 
 Every user gets their individual tenant based on their `sub` claim.
@@ -82,12 +75,6 @@ authorization:
   authAudience: "feldera-api"
 ```
 
-Direct pipeline-manager configuration:
-
-```bash
-pipeline-manager ... --auth-provider=generic-oidc --individual-tenant=true
-```
-
 ### Organization-wide shared access
 
 All users in your organization share the same tenant based on the organization domain.
@@ -109,12 +96,6 @@ authorization:
   authAudience: "feldera-api"
 ```
 
-Direct pipeline-manager configuration:
-
-```bash
-pipeline-manager ... --auth-provider=generic-oidc --issuer-tenant=true --individual-tenant=false
-```
-
 ### Group-based whitelist with organization-wide shared access
 
 Users must belong to at least one of the specified groups to access Feldera. All authorized users share the organization tenant.
@@ -136,12 +117,6 @@ authorization:
   authAudience: "feldera-api"
 ```
 
-Direct pipeline-manager configuration:
-
-```bash
-pipeline-manager ... --auth-provider=generic-oidc --authorized-groups=feldera_engineering,feldera_qa --issuer-tenant=true --individual-tenant=false
-```
-
 ### Shared access within a user group (managed tenancy)
 
 Tenant assignment via `tenants` claim in JWT configured in your OIDC provider.
@@ -160,12 +135,6 @@ authorization:
   authAudience: "feldera-api"
 ```
 
-Direct pipeline-manager configuration:
-
-```bash
-pipeline-manager ... --auth-provider=generic-oidc --individual-tenant=false
-```
-
 ### Individual access to whitelisted user groups
 
 Each user gets their individual tenant, but only users belonging to specified groups can access Feldera.
@@ -187,12 +156,6 @@ authorization:
   authAudience: "feldera-api"
 ```
 
-Direct pipeline-manager configuration:
-
-```bash
-pipeline-manager ... --auth-provider=generic-oidc --individual-tenant=true --authorized-groups=feldera_engineering,feldera_qa
-```
-
 ## Configuration options
 
 ### Mapping Pipeline Manager Options to Helm Chart Values
@@ -207,7 +170,7 @@ Below is a comprehensive template showing all available authentication and autho
 # Authentication provider configuration
 auth:
   enabled: true                        # Enable/disable authentication
-  provider: "generic-oidc"             # Options: "none", "aws-cognito", "generic-oidc"
+  provider: "generic-oidc"             # Maps to: AUTH_PROVIDER; Options: "none", "aws-cognito", "generic-oidc"
   clientId: "your-client-id"           # Maps to: FELDERA_AUTH_CLIENT_ID
   issuer: "https://your-domain/oauth2/default"  # Maps to: FELDERA_AUTH_ISSUER
 
@@ -218,28 +181,19 @@ auth:
 # Authorization and tenant assignment configuration
 authorization:
   # Individual tenant mode - each user gets their own tenant (default: true)
-  # Maps to: --individual-tenant
-  individualTenant: true
+  individualTenant: true                # Maps to: FELDERA_AUTH_INDIVIDUAL_TENANT
 
   # Issuer-based tenant - derive tenant from auth issuer domain (default: false)
-  # Maps to: --issuer-tenant
-  issuerTenant: false
+  issuerTenant: false                   # Maps to: FELDERA_AUTH_ISSUER_TENANT
 
   # Group-based access control - restrict access to specific groups
-  # Maps to: --authorized-groups
   # Users must have at least one of these groups in their 'groups' claim
-  authorizedGroups:
+  authorizedGroups:                     # Maps to: FELDERA_AUTH_AUTHORIZED_GROUPS
     - "feldera-users"
     - "data-engineers"
 
   # OIDC audience claim validation (default: "feldera-api")
-  # Maps to: --auth-audience
-  authAudience: "feldera-api"
-
-# Advanced: Pass additional pipeline-manager arguments directly
-pipelineManager:
-  extraArgs:
-    - "--some-additional-flag=value"
+  authAudience: "feldera-api"           # Maps to: FELDERA_AUTH_AUDIENCE
 ```
 
 ### Environment Variables Reference
@@ -273,10 +227,10 @@ AWS_COGNITO_LOGOUT_URL=https://...
 Feldera resolves tenant assignment using the following priority order:
 
 1. **`tenants` claim** - Explicit tenant assignment via OIDC provider
-2. **Issuer domain `iss` claim** (when `--issuer-tenant=true`)
-3. **User `sub` claim** (when `--individual-tenant=true`)
+2. **Issuer domain `iss` claim** (when `issuerTenant: true`)
+3. **User `sub` claim** (when `individualTenant: true`)
 
-If no valid tenant is found and `--individual-tenant=false` the user will be denied authorization.
+If no valid tenant is found and `individualTenant: false` the user will be denied authorization.
 
 ## Provider-Specific Setup
 
