99 lines
5.5 KiB
Markdown
99 lines
5.5 KiB
Markdown
# Implementation Plan: Multi-User Authentication and Authorization
|
|
|
|
**Branch**: `016-multi-user-auth` | **Date**: 2026-01-26 | **Spec**: [`specs/016-multi-user-auth/spec.md`](spec.md)
|
|
**Input**: Feature specification from `specs/016-multi-user-auth/spec.md`
|
|
|
|
**Note**: This template is filled in by the `/speckit.plan` command. See `.specify/templates/commands/plan.md` for the execution workflow.
|
|
|
|
## Summary
|
|
|
|
Implement a robust authentication system supporting local users (username/password) and corporate SSO (ADFS via OIDC/OAuth2) simultaneously. The system will enforce Role-Based Access Control (RBAC) to restrict plugin access. Data will be persisted in a dedicated SQLite database (`auth.db`), and sessions will be managed via stateless JWTs. A CLI tool will be provided for initial admin provisioning. The login interface will provide dual options (Form + SSO Button) to ensure administrator access even during ADFS outages.
|
|
|
|
## Technical Context
|
|
|
|
**Language/Version**: Python 3.9+ (Backend), Node.js 18+ (Frontend)
|
|
**Primary Dependencies**:
|
|
- Backend: FastAPI, Authlib (ADFS/OIDC), Passlib[bcrypt] (Password hashing), PyJWT (Token management), SQLAlchemy (ORM for auth.db)
|
|
- Frontend: SvelteKit (UI), standard fetch API (JWT handling)
|
|
**Storage**: SQLite (`auth.db`) for Users, Roles, Permissions, and Mappings.
|
|
**Testing**: pytest (Backend), vitest/playwright (Frontend)
|
|
**Target Platform**: Linux server (Dockerized environment)
|
|
**Project Type**: Web Application (FastAPI Backend + SvelteKit Frontend)
|
|
**Performance Goals**: <100ms auth verification overhead per request.
|
|
**Constraints**: Must run in existing environment without external DB dependencies (hence SQLite).
|
|
**Scale/Scope**: ~10-100 concurrent users, ~5-10 distinct roles.
|
|
|
|
## Constitution Check
|
|
|
|
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
|
|
|
|
- [x] **I. Semantic Protocol Compliance**: All new modules will use `[DEF]` anchors and `@RELATION` tags.
|
|
- [x] **II. Causal Validity**: Contracts (OpenAPI/Pydantic models) will be defined before implementation.
|
|
- [x] **III. Immutability of Architecture**: No changes to existing core architecture invariants; adding a new `AuthModule` layer.
|
|
- [x] **IV. Design by Contract**: All auth functions will define `@PRE`/`@POST` conditions.
|
|
- [x] **V. Belief State Logging**: Auth events will be logged using the standard belief scope logger.
|
|
- [x] **VI. Fractal Complexity Limit**: Auth logic will be modularized (Service, Repository, API layers).
|
|
- [x] **VII. Everything is a Plugin**: While core auth is middleware, the *management* of users/roles will be exposed via a System Plugin or dedicated Admin API, respecting the modular design.
|
|
- [x] **VIII. Unified Frontend Experience**: Login and Admin UI will use standard Svelte components and i18n.
|
|
|
|
## Project Structure
|
|
|
|
### Documentation (this feature)
|
|
|
|
```text
|
|
specs/[###-feature]/
|
|
├── plan.md # This file (/speckit.plan command output)
|
|
├── research.md # Phase 0 output (/speckit.plan command)
|
|
├── data-model.md # Phase 1 output (/speckit.plan command)
|
|
├── quickstart.md # Phase 1 output (/speckit.plan command)
|
|
├── contracts/ # Phase 1 output (/speckit.plan command)
|
|
└── tasks.md # Phase 2 output (/speckit.tasks command - NOT created by /speckit.plan)
|
|
```
|
|
|
|
### Source Code (repository root)
|
|
|
|
```text
|
|
backend/
|
|
├── src/
|
|
│ ├── api/
|
|
│ │ ├── auth/ # New: Auth endpoints (login, logout, refresh)
|
|
│ │ ├── admin/ # New: Admin endpoints (users, roles)
|
|
│ │ └── dependencies.py # Update: Add get_current_user, get_current_active_user
|
|
│ ├── core/
|
|
│ │ ├── auth/ # New: Core auth logic
|
|
│ │ │ ├── jwt.py # Token handling
|
|
│ │ │ ├── security.py # Password hashing
|
|
│ │ │ └── config.py # Auth settings
|
|
│ │ └── database.py # Update: Support for multiple DBs (auth.db)
|
|
│ ├── models/
|
|
│ │ └── auth.py # New: SQLAlchemy models (User, Role, Permission)
|
|
│ ├── schemas/ # New: Pydantic schemas for Auth
|
|
│ │ └── auth.py
|
|
│ └── services/
|
|
│ └── auth_service.py # New: Auth business logic
|
|
└── tests/
|
|
└── auth/ # New: Auth tests
|
|
|
|
frontend/
|
|
├── src/
|
|
│ ├── lib/
|
|
│ │ ├── auth/ # New: Frontend auth stores/logic
|
|
│ │ └── api/ # Update: Add auth headers to requests
|
|
│ ├── routes/
|
|
│ │ ├── login/ # New: Login page
|
|
│ │ └── admin/ # New: Admin dashboard (Users/Roles)
|
|
│ └── components/
|
|
│ └── auth/ # New: Auth components (ProtectedRoute, Login form)
|
|
```
|
|
|
|
**Structure Decision**: Web application structure with separated backend (FastAPI) and frontend (SvelteKit). Auth logic is centralized in `backend/src/core/auth` and `backend/src/services`, with a new persistent store `auth.db`. Frontend will implement a reactive auth store.
|
|
|
|
## Complexity Tracking
|
|
|
|
> **Fill ONLY if Constitution Check has violations that must be justified**
|
|
|
|
| Violation | Why Needed | Simpler Alternative Rejected Because |
|
|
|-----------|------------|-------------------------------------|
|
|
| [e.g., 4th project] | [current need] | [why 3 projects insufficient] |
|
|
| [e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient] |
|