Automates version bumps across all version source files: - Cargo.toml (PRIMARY - workspace.package.version) - debian/changelog (prepend new entry) - debian/control (update Version field) - scripts/build-package.sh (update VERSION variable) - frontend/package.json (update version field) - Stale references check after bump Usage: ./scripts/bump-version.sh <new_version> <old_version>
4.4 KiB
4.4 KiB
SSO Implementation Fix Plan
Issues Identified
- No SSO Login Button — LoginPage.tsx missing "Sign in with Azure" button
- No SSO Callback Route — App.tsx missing frontend route to handle SSO callback
- authStore No SSO Support — authStore.ts has no method to store SSO tokens
- Backend Returns JSON Not Redirect — azure_sso.rs callback returns JSON tokens instead of redirecting to frontend
- No SSO Session Cleanup — sso_sessions DashMap has no expiry/cleanup task (memory leak)
- No JWT Signature Verification — id_token decoded without verifying Azure AD signature
Phases
Phase 1: Backend SSO Fixes (Issues 4, 5) — COMPLETE ✅
- 1a: Add SSO session cleanup task in main.rs (purge sessions older than 10 minutes)
- 1b: Modify azure_sso.rs callback to redirect to frontend with tokens instead of returning JSON
- 1c: Add
sso_callback_urlto SecurityConfig in config.rs with serde default - 1d: Update settings.rs to include sso_callback_url in settings response
- 1e: Verify backend compiles with
cargo check
Phase 2: Frontend SSO Integration (Issues 1, 2, 3) — COMPLETE ✅
- 2a: Add SSO callback page component (SsoCallbackPage.tsx)
- 2b: Add SSO callback route to App.tsx (public route, no auth required)
- 2c: Add "Sign in with Microsoft Azure" button to LoginPage.tsx
- 2d: Add SSO-related types and API methods to frontend
- 2e: Verify frontend builds with TypeScript compilation
Phase 3: JWT Signature Verification (Issue 6) — COMPLETE ✅
- 3a: Add JWKS client dependency to pm-web/Cargo.toml
- 3b: Implement id_token signature verification in azure_sso.rs
- 3c: Verify backend compiles with
cargo check
Phase 4: Integration Testing and Verification — COMPLETE ✅
- 4a: Backend code review — all changes verified manually
- 4b: Frontend TypeScript compilation — passes cleanly
- 4c: SSO login flow reviewed end-to-end (backend redirect → frontend callback → auth store)
- 4d: SSO session cleanup verified (10-minute expiry, 60-second purge interval)
- 4e: Settings page SSO config unchanged (sso_callback_url added as read-only)
- 4f: Lessons captured below
Lessons Learned
- SSO callback must redirect, not return JSON — Browser OAuth2 flows require the backend to redirect to the frontend SPA, not return JSON tokens. The frontend must parse tokens from URL query parameters.
- URLSearchParams.get() already decodes — Don't double-decode with decodeURIComponent() when using URLSearchParams.
- JWKS caching prevents rate-limiting — Azure AD JWKS endpoint should be cached with TTL (1 hour) to avoid fetching on every SSO login.
- tokio::sync::Mutex over std::sync::Mutex — Axum handlers must be Send; std::sync::MutexGuard is not Send across await points.
- DashMap session cleanup — In-memory session stores (DashMap) need periodic cleanup tasks to prevent memory leaks. Pattern: tokio::spawn with interval + retain with time-based cutoff.
Host Self-Enrollment Implementation Plan
Phases
Phase 1: Database & Core Models
- 1a: Create SQL migration for
enrollment_requeststable - 1b: Define Rust data models for
EnrollmentRequestinpm-core - 1c: Add DB interaction methods (insert, list, delete) in
pm-core
Phase 2: Client-Facing API (pm-web)
- 2a: Implement
POST /api/v1/enrollto accept payloads and generatepolling_token - 2b: Implement
GET /api/v1/enroll/status/{token}to return pending/approved (PKI) statuses - 2c: Implement IP-based rate limiting for the
/enrollendpoint
Phase 3: Admin-Facing API (pm-web)
- 3a: Implement
GET /api/v1/admin/enrollmentsto list pending queue - 3b: Implement
POST /api/v1/admin/enrollments/{id}/approve(generate PKI viapm-ca, migrate tohoststable) - 3c: Implement
DELETE /api/v1/admin/enrollments/{id}/denyto purge request
Phase 4: Background Workers (pm-worker)
- 4a: Create a scheduled task to purge
enrollment_requestsolder than 24 hours
Phase 5: Frontend UI (pm-web/React)
- 5a: Add enrollment API methods and types to frontend
- 5b: Update
Hostsview to include "Pending Enrollments" filter and visual badge - 5c: Render pending hosts in the table with highlight styling
- 5d: Add Approve/Deny action buttons to pending host rows
- 5e: Implement "merge/overwrite" interactive modal for
fqdn/ip_addresscollisions on approval