Sat rbac capabilities v2

http/webconfig_server.go

@@ -291,14 +291,11 @@ func (s *WebconfigServer) AuthValidationMiddleware(next http.Handler) http.Handl
 		} else if authToken := getLoginTokenFromRequest(r); authToken != "" {
 			if LoginToken, err := ValidateAndGetLoginToken(authToken); err != nil {
 				log.Error(err.Error())
-				//http.Error(w, "invalid auth token", http.StatusUnauthorized)
-				//Cheking and Setting DEV PROFILES to allow and display ALL the TABS
-				//ctx = context.WithValue(ctx, CTX_KEY_TOKEN, LoginToken)
-				permissions := getPermissions()
-				ctx = context.WithValue(ctx, CTX_KEY_PERMISSIONS, permissions)
-				//return
+				http.Error(w, "invalid auth token", http.StatusUnauthorized)
+				ctx = context.WithValue(ctx, CTX_KEY_TOKEN, LoginToken)
+				return
 			} else {
-				//THIS IS LOGIN TOKEN SUCCESS CASE
+				// THIS IS LOGIN TOKEN SUCCESS CASE
 				r.Header.Set(AUTH_SUBJECT, LoginToken.Subject)
 
 				// Add UI token & permissions to request context

openspec/changes/sat-rbac-capabilities-v2/.openspec.yaml

@@ -0,0 +1,5 @@
+schema: spec-driven
+created: 2026-05-14
+status: proposed
+applies_to:
+  - openspec/specs/auth/auth-contract.md

openspec/changes/sat-rbac-capabilities-v2/design.md

@@ -0,0 +1,150 @@
+# SAT RBAC v2 Design
+
+## Overview
+
+This document describes the architectural approach to implementing SAT RBAC v2 capability names and authorization logic in xconfadmin while maintaining full backward compatibility with legacy SAT behavior.
+
+## Design Principles
+
+1. **Routing-Based Selection**: If the `Authorization` header is present, select the SAT path; otherwise, if Xerxes token is present (header `token` or cookie `token`), select the Xerxes path.
+2. **SAT Mode Detection**: On the SAT path, if SAT contains xconf-prefixed capabilities, authorize via SAT v2; otherwise, use legacy SAT unchanged.
+3. **Deny-by-Default for SAT v2**: Any request that cannot be classified into (domain, access) requirements is denied.
+4. **Route-Based Classification**: Domain and access level are determined from HTTP method and API route/path, not from request entity type.
+5. **Backward Compatibility**: Existing SAT tokens without xconf-prefixed capabilities continue to work exactly as before.
+
+## Authorization Routing Selection
+
+The authorization system follows routing-based selection (Option C):
+
+```
+┌─────────────────────────────────┐
+│ Request arrives with credentials │
+└─────────────────┬───────────────┘
+                  │
+    ┌──────────────────────────────┐
+    │ Authorization header present?│
+    └──────────────┬───────────────┘
+       │
+         ┌─────────┴─────────┐
+        YES                  NO
+         │                    │
+   ┌───────────▼──────────────┐   ┌────────────────────────────┐
+   │ Route to SAT auth path   │   │ Xerxes token present       │
+   │ (deterministic selection)│   │ (header/cookie `token`)?   │
+   └───────────┬──────────────┘   └──────────────┬─────────────┘
+         │                                 │
+     ┌─────────▼──────────┐           ┌──────────┴──────────┐
+     │ Has xconf: prefix? │          NO                    YES
+     └─────────┬──────────┘           │                     │
+         │                      │            ┌─────────▼─────────┐
+      ┌────────┴───────┐              │            │ Authorize via     │
+      │                │              │            │ Xerxes permissions │
+     NO               YES             │            └───────────────────┘
+      │                │              │
+ ┌────▼──────────┐  ┌──▼────────────────────────┐  ┌──────────────────────┐
+ │ Authorize via │  │ Authorize via SAT RBAC v2 │  │ Return 401           │
+ │ legacy SAT    │  │ (domain + access check)   │  │ Unauthorized          │
+ │ (unchanged)   │  └───────────────────────────┘  └──────────────────────┘
+ └───────────────┘
+```
+
+## Request Classification
+
+### Route-to-Domain Mapping
+
+Request domain is determined by matching the HTTP route/path against an ordered ruleset. The first matching rule determines the domain.
+
+Classification rules SHALL match on stable route substrings and/or route templates. The following is a representative seed set of patterns:
+- `/queries/firmware`, `/firmware` → **core**
+- `/dcm`, `/telemetry` → **core**
+- `/tagging` → **tagging**
+- `/roundrobinfilter` → **system**
+- `/metrics` → **metrics**
+
+The ruleset ordering is critical because the first match wins. More specific routes must appear before more general patterns.
+
+**Note on Mapping Scope**: This seed set represents initial patterns. The authoritative route-to-domain classification will be maintained in a central mapping registry in code and extended iteratively as new endpoints are added. SAT v2 authorization remains deny-by-default for any request that cannot be classified.
+
+### Access-Level Determination
+
+Access level (readonly or readwrite) is determined by the following precedence:
+
+1. **Route Override**: If the request path contains the segment `/filtered`, treat as readonly (these are filtered search endpoints that use POST).
+2. **HTTP Method**: Otherwise, classify by HTTP method:
+   - GET, HEAD → **readonly**
+   - POST, PUT, PATCH, DELETE → **readwrite**
+
+Post-based read endpoints (e.g., /filtered searches) are explicitly classified as readonly via the override pattern to avoid misclassification based on method alone.
+
+## Integration Architecture
+
+### Authorization Middleware Position
+
+The authorization logic is invoked after credential validation, with deterministic routing by credential type:
+
+```
+Request
+  │
+  ├─> Credential Extraction & Validation
+  │     (Xerxes token, SAT token, etc.)
+  │
+  ├─> If Authorization header exists -> SAT path
+  │     ├─> SAT v2 detection (xconf: prefix)
+  │     ├─> SAT RBAC v2 OR legacy SAT authorization
+  │     └─> Allow/Deny Decision
+  │
+  ├─> Else if Xerxes token exists -> Xerxes authorization
+  │
+  ├─> Else -> 401 Unauthorized
+  │
+  └─> Handler Execution (if authorized)
+```
+
+### Capability Matching
+
+Given a classified request (domain, access), SAT RBAC v2 checks whether the SAT token contains a matching capability:
+
+- Request (core, readonly) requires any of: xconf:core:readonly, xconf:core:readwrite
+- Request (core, readwrite) requires: xconf:core:readwrite
+- Request (tagging, readonly) requires any of: xconf:tagging:readonly, xconf:tagging:readwrite
+- Request (tagging, readwrite) requires: xconf:tagging:readwrite
+- Request (system, readonly) requires any of: xconf:system:readonly, xconf:system:readwrite
+- Request (system, readwrite) requires: xconf:system:readwrite
+- Request (metrics, readonly) requires: xconf:metrics:readonly
+- No readwrite functionality exists for the metrics domain (no xconf:metrics:readwrite).
+
+### Unclassifiable Requests
+
+If a request cannot be classified into (domain, access) requirements—for example, if a new API route is added but the classification rules are not yet updated—the request is denied with 403 Forbidden.
+
+This deny-by-default approach ensures that new endpoints are secure by default and prevents accidental authorization leakage.
+
+## Backward Compatibility
+
+Legacy SAT tokens (without xconf-prefixed capabilities) continue to work exactly as before:
+
+1. If no xconf: capabilities are detected, the authorization flow immediately falls back to legacy SAT logic.
+2. Legacy SAT behavior (appType-based authorization, existing capability names) is unchanged.
+3. No new validation rules are applied to legacy SAT tokens.
+4. Operators can mix legacy and SAT v2 tokens in the same deployment; each is authorized according to its own rules.
+
+## HTTP Status Code Semantics
+
+The auth middleware uses the following status codes:
+
+- **401 Unauthorized**: Sent when credential extraction or validation fails (missing token, invalid signature, expired token, etc.). No authenticated identity is available.
+- **403 Forbidden**: Sent when the request is authenticated but not authorized for the requested operation. This includes:
+  - SAT v2 capability mismatch (e.g., readonly SAT v2 token attempting a write)
+  - Unclassifiable SAT v2 requests (route/domain mapping missing)
+  - Any other authorization denial after successful authentication
+
+## Future Extensibility
+
+### Phase 2: Tenant/Partner Enforcement
+Once domain-to-capability mapping is stable, Phase 2 will add tenant or partner scoping to authorization. Tenant/partner enforcement will be implemented using separate SAT claims (e.g., partner scope) and/or request metadata (e.g., tenantId header), independent of capability strings. The capability strings themselves (e.g., `xconf:core:readwrite`) will remain unchanged.
+
+### Metrics Domain
+The metrics domain is read-only. The only supported capability for the metrics domain is `xconf:metrics:readonly`. No write capability exists for the metrics domain.
+
+### Additional Domains
+As new domain areas emerge, new capability names (e.g., xconf:foo:readonly) can be added without affecting existing capabilities or fallback logic.

openspec/changes/sat-rbac-capabilities-v2/proposal.md

@@ -0,0 +1,70 @@
+Status: Proposed
+Applied to: openspec/specs/auth/auth-contract.md
+
+## Why
+
+xconfadmin must introduce SAT RBAC v2 capability names while preserving all legacy SAT behavior for backward compatibility. SAT token shape is unchanged (capabilities list), but capability values now include a new xconf-prefixed namespace. We need a clear and deterministic routing-based authorization selection contract that supports SAT v2 when present on the SAT path, falls back to legacy SAT semantics on the SAT path when no xconf capability is present, and uses Xerxes authorization on its own path.
+
+This change documents the transition contract so implementation can safely evolve without breaking existing SAT clients.
+
+## What Changes
+
+- Define SAT RBAC v2 capability namespace and names:
+  - xconf:core:readonly / xconf:core:readwrite
+  - xconf:tagging:readonly / xconf:tagging:readwrite
+  - xconf:system:readonly / xconf:system:readwrite
+  - xconf:metrics:readonly
+- Define SAT RBAC v2 detection:
+  - SAT v2 SHALL be detected by the presence of at least one capability with prefix "xconf:"
+- Define routing-based authorization selection:
+  - If `Authorization` header is present:
+    - Run existing SAT validation logic.
+    - If SAT is valid:
+      - If SAT contains any capability starting with "xconf:", authorize using SAT RBAC v2.
+      - Else, authorize using legacy SAT behavior unchanged.
+    - Else, return 401 Unauthorized.
+  - Else, if token header/cookie `token` is present:
+    - Run existing Xerxes validation and authorization.
+  - Else, return 401 Unauthorized.
+- Define initial SAT v2 domain mapping seed set:
+  - Core: firmware, firmware rules, firmware templates, features, feature rules, telemetry, dcm
+  - Metrics: penetration metrics, future metrics APIs
+  - System: download location round robin filter
+  - Tagging: all tagging APIs
+- Define SAT v2 request classification:
+  - SAT v2 authorization SHALL classify requests by API route/path into one of {core, tagging, system, metrics}.
+  - SAT v2 domains are not equivalent to Xerxes entity types; classification is based on admin functionality (route/path), not entity.
+  - Classification SHALL use an ordered ruleset where the first matching rule determines the domain.
+  - Classification rules SHALL match on stable route substrings and/or route templates (when available) (e.g., /queries/firmware, /firmware, /dcm, /telemetry, /tagging, /roundrobinfilter, /metrics), with precedence determined by rule order.
+- Define SAT v2 access classification:
+  - SAT v2 access level SHALL be determined using the following precedence:
+    1. If the route matches a known read-only override pattern (e.g., path contains the segment "/filtered"), access SHALL be treated as "readonly".
+    2. Else, HTTP method SHALL determine access:
+       - GET, HEAD → readonly
+       - POST, PUT, PATCH, DELETE → readwrite
+  - Certain endpoints use POST for read operations (e.g., filtered search APIs). These MUST be explicitly classified as readonly.
+- Define SAT v2 deny-by-default behavior:
+  - If a request cannot be classified into (domain, access) requirements, SAT v2 authorization SHALL deny with 403.
+- Define HTTP status semantics (Option A):
+  - 401 Unauthorized only for missing/invalid authentication.
+  - 403 Forbidden for authenticated-but-not-authorized requests, including unmapped SAT v2 operations/domains.
+
+## Non-Goals
+
+- No tenant or partner enforcement in this phase (phase 2).
+- No changes to legacy SAT capability names or authorization semantics.
+- No appType field in SAT RBAC v2.
+- No redesign of Xerxes authentication or permission model.
+
+## Capabilities
+
+### Modified Capabilities
+- `auth`: Authorization outcome semantics clarified to use 401 for authentication failures and 403 for authorization denials, including SAT v2 unmapped operations.
+- `auth`: SAT RBAC v2 capability-name model, detection by `xconf:` prefix, ordered route/path classification, access classification, and routing-based selection contract across SAT and Xerxes credential paths.
+
+## Impact
+
+- Affected specs: openspec/specs/auth/auth-contract.md.
+- Affected implementation areas (future apply phase): SAT validation/authorization middleware and API domain-to-capability mapping logic.
+- API behavior impact: no endpoint shape changes; authorization outcomes become explicitly specified for SAT v2 capability evaluation.
+- Compatibility impact: legacy SAT behavior remains unchanged unless SAT v2 capabilities are explicitly present.