wulf-pulse/tasks/prd-auth-user-management.md

406 lines
14 KiB
Markdown
Raw Normal View History

# PRD: Authentication & User Management Module
## 1. Introduction/Overview
Pulse currently has no authentication system, leaving all routes and data publicly accessible. This PRD defines the implementation of a comprehensive authentication and authorization system using **Better Auth** with a **User Management Module** for super-admins.
### Problem Statement
- No authentication protects the application
- Sensitive admin sections and data are exposed
- No role-based access control (RBAC) exists
- No user management capabilities
### Solution
Implement Better Auth with:
- Magic link and Microsoft 365 OAuth authentication
- Role-based access control with custom role creation
- User management module for super-admins
- Session management with security controls
- Two-factor authentication (2FA)
- Audit logging
---
## 2. Goals
1. **Secure all application routes** - No unauthenticated access to any part of Pulse
2. **Implement RBAC** - Protect admin sections and sensitive data based on user roles
3. **Enable user management** - Super-admins can create, edit, deactivate users and manage roles
4. **Support enterprise auth** - Magic link and Microsoft 365 SSO
5. **Provide security controls** - Session timeout, password policies, 2FA, audit logging
6. **Match existing UI** - Use existing shadcn/ui components for consistency
---
## 3. User Stories
### Authentication
- **As a user**, I want to sign in with a magic link so I don't need to remember a password
- **As a user**, I want to sign in with my Microsoft 365 account for seamless enterprise access
- **As a user**, I want to enable 2FA to secure my account
- **As a user**, I want to see and manage my active sessions
### Authorization
- **As an admin**, I want certain sections protected so only authorized users can access them
- **As a super-admin**, I want to define custom roles with specific permissions
### User Management
- **As a super-admin**, I want to invite new users via email
- **As a super-admin**, I want to view all users and their roles
- **As a super-admin**, I want to edit user profiles and change their roles
- **As a super-admin**, I want to deactivate/reactivate users
- **As a super-admin**, I want to reset a user's password/sessions
- **As a super-admin**, I want to create and manage custom roles
- **As a super-admin**, I want to view audit logs of user actions
---
## 4. Functional Requirements
### 4.1 Authentication System
| ID | Requirement |
|----|-------------|
| AUTH-01 | System must support magic link authentication via email |
| AUTH-02 | System must support Microsoft 365 OAuth authentication |
| AUTH-03 | System must support two-factor authentication (TOTP) |
| AUTH-04 | System must redirect unauthenticated users to sign-in page |
| AUTH-05 | System must maintain secure sessions with configurable timeout |
| AUTH-06 | System must allow users to view and revoke their active sessions |
| AUTH-07 | Magic links must expire after 5 minutes |
| AUTH-08 | System must support account linking (magic link + Microsoft) |
### 4.2 Authorization & RBAC
| ID | Requirement |
|----|-------------|
| RBAC-01 | System must implement role-based access control |
| RBAC-02 | System must have default roles: `super-admin`, `admin`, `user` |
| RBAC-03 | Super-admins must be able to create custom roles |
| RBAC-04 | Roles must define permissions for resources (e.g., `tickets:read`, `admin:access`) |
| RBAC-05 | `/app/admin/*` routes must require `admin` or `super-admin` role |
| RBAC-06 | User management must require `super-admin` role |
| RBAC-07 | API routes must validate permissions before returning data |
### 4.3 User Management Module
| ID | Requirement |
|----|-------------|
| USER-01 | Super-admins must be able to view a list of all users |
| USER-02 | Super-admins must be able to invite new users via email |
| USER-03 | Super-admins must be able to edit user profiles (name, email) |
| USER-04 | Super-admins must be able to assign/change user roles |
| USER-05 | Super-admins must be able to deactivate users (soft delete) |
| USER-06 | Super-admins must be able to reactivate deactivated users |
| USER-07 | Super-admins must be able to delete users permanently |
| USER-08 | Super-admins must be able to force password reset / revoke sessions |
| USER-09 | Super-admins must be able to view user session history |
### 4.4 Role Management
| ID | Requirement |
|----|-------------|
| ROLE-01 | Super-admins must be able to view all roles |
| ROLE-02 | Super-admins must be able to create new roles with custom permissions |
| ROLE-03 | Super-admins must be able to edit existing role permissions |
| ROLE-04 | Super-admins must be able to delete custom roles (not default roles) |
| ROLE-05 | System must prevent deletion of roles assigned to users |
### 4.5 Security & Audit
| ID | Requirement |
|----|-------------|
| SEC-01 | Sessions must expire after 1 hour by default (configurable) |
| SEC-02 | Session timeout must be configurable per source IP/subnet (trusted networks can have longer sessions) |
| SEC-03 | Sessions must refresh on activity (sliding expiration) |
| SEC-04 | System must log authentication events (sign-in, sign-out, failed attempts) |
| SEC-05 | System must log user management actions (create, edit, delete, role changes) |
| SEC-06 | Audit logs must be viewable by super-admins |
| SEC-07 | Audit logs must be retained for 120 days by default |
| SEC-08 | System must automatically purge audit logs older than retention period |
| SEC-09 | System must rate-limit authentication attempts |
### 4.6 Microsoft 365 Configuration
| ID | Requirement |
|----|-------------|
| MS-01 | Super-admins must be able to configure Microsoft tenant ID in admin settings |
| MS-02 | System must validate tenant ID format before saving |
| MS-03 | System must support both specific tenant and 'common' (any Microsoft account) modes |
### 4.8 Session Policies (Trusted Networks)
| ID | Requirement |
|----|-------------|
| NET-01 | Super-admins must be able to define trusted networks using CIDR notation |
| NET-02 | Each network policy must have: name, CIDR range, session timeout (seconds) |
| NET-03 | System must validate CIDR notation format before saving |
| NET-04 | System must match client IP against policies in priority order |
| NET-05 | Default policy (1 hour) applies when no CIDR matches |
| NET-06 | Example: `10.0.0.0/8` = 8 hours, `192.168.1.0/24` = 24 hours |
### 4.9 Email Templates
| ID | Requirement |
|----|-------------|
| EMAIL-01 | Super-admins must be able to customize magic link email template |
| EMAIL-02 | Super-admins must be able to customize user invitation email template |
| EMAIL-03 | Templates must support variables: `{{name}}`, `{{link}}`, `{{expires}}`, `{{app_name}}` |
| EMAIL-04 | System must provide default templates that can be reset |
| EMAIL-05 | Templates must support HTML formatting |
### 4.7 Initial Setup & Bootstrap
| ID | Requirement |
|----|-------------|
| BOOT-01 | System must create a default super-admin account on first run |
| BOOT-02 | Default super-admin credentials must be set via environment variables |
| BOOT-03 | System must force immediate password/auth method change on first login for default account |
| BOOT-04 | Default account must be clearly marked as "setup account" requiring reconfiguration |
---
## 5. Non-Goals (Out of Scope)
- **Password-based authentication** - Only magic link and Microsoft 365 OAuth
- **Self-registration** - Users must be invited by super-admins
- **Multi-tenancy / Organizations** - Single tenant for now
- **API key authentication** - Not in initial scope
- **SAML SSO** - Only OAuth (Microsoft 365)
- **Email verification for existing users** - Users are invited, not self-registered
---
## 6. Design Considerations
### UI Components
Use existing shadcn/ui components from `/components/ui/`:
- `button`, `input`, `label`, `form` for auth forms
- `card` for sign-in/settings cards
- `table` for user/role lists
- `dialog` for confirmations
- `dropdown-menu` for user actions
- `badge` for role/status display
- `tabs` for settings sections
- `alert-dialog` for destructive actions
### Pages to Create
| Route | Description |
|-------|-------------|
| `/auth/sign-in` | Sign-in page (magic link + Microsoft) |
| `/auth/verify` | Magic link verification |
| `/auth/2fa` | Two-factor verification |
| `/app/admin/users` | User management list |
| `/app/admin/users/[id]` | User detail/edit page |
| `/app/admin/users/invite` | Invite user form |
| `/app/admin/roles` | Role management |
| `/app/admin/audit-log` | Audit log viewer |
| `/app/admin/settings` | App settings (Microsoft tenant, session policies, email templates) |
| `/settings` | User settings (profile, sessions, 2FA) |
### Component Structure
```
/components/auth/
├── sign-in-form.tsx # Magic link + Microsoft buttons
├── magic-link-form.tsx # Email input for magic link
├── two-factor-form.tsx # TOTP input
└── session-list.tsx # Active sessions
/components/admin/users/
├── user-table.tsx # User list with actions
├── user-form.tsx # Create/edit user
├── invite-user-form.tsx # Invite via email
├── role-badge.tsx # Role display
└── user-actions.tsx # Dropdown actions
/components/admin/roles/
├── role-table.tsx # Role list
├── role-form.tsx # Create/edit role
└── permission-picker.tsx # Permission selection
```
---
## 7. Technical Considerations
### Dependencies
```json
{
"better-auth": "^1.x",
"@daveyplate/better-auth-ui": "^1.x"
}
```
### Database Schema (PostgreSQL)
Better Auth will create these tables:
- `user` - User accounts
- `session` - Active sessions
- `account` - OAuth accounts (Microsoft)
- `verification` - Magic link tokens
Additional tables:
- `role` - Custom roles
- `permission` - Role permissions
- `audit_log` - Security audit trail
- `session_policy` - IP/subnet-based session timeout rules (CIDR notation)
- `app_settings` - Application settings (Microsoft tenant, etc.)
- `email_template` - Customizable email templates
### File Structure
```
/lib/
├── auth.ts # Better Auth server config
├── auth-client.ts # Better Auth client
└── permissions.ts # RBAC definitions
/app/api/auth/[...all]/
└── route.ts # Better Auth API handler
/middleware.ts # Route protection
```
### Environment Variables
```env
# Better Auth
BETTER_AUTH_SECRET= # Random secret for signing
BETTER_AUTH_URL= # Base URL (e.g., http://localhost:3000)
# Microsoft OAuth (Tenant ID configurable in admin UI)
MICROSOFT_CLIENT_ID=
MICROSOFT_CLIENT_SECRET=
# SMTP Configuration (for magic links)
SMTP_HOST= # SMTP server hostname
SMTP_PORT=587 # SMTP port (587 for TLS, 465 for SSL)
SMTP_USER= # SMTP username
SMTP_PASS= # SMTP password
SMTP_FROM= # From email address
SMTP_SECURE=false # Use SSL (true for port 465)
# Default Super-Admin (for initial setup)
DEFAULT_ADMIN_EMAIL= # Email for default super-admin account
DEFAULT_ADMIN_NAME= # Display name for default super-admin
# Session Configuration
SESSION_TIMEOUT_SECONDS=3600 # Default 1 hour
# Audit Log Retention
AUDIT_LOG_RETENTION_DAYS=120 # Default 120 days
```
### Integration Points
- Integrate with existing PostgreSQL database (`pg` package)
- Use existing `Toaster` from sonner for notifications
- Protect existing `/app/admin/*` routes
- Add user context to existing components via `useSession()`
---
## 8. Success Metrics
| Metric | Target |
|--------|--------|
| All routes protected | 100% of routes require authentication |
| Admin routes secured | `/admin/*` only accessible to admin/super-admin |
| User management functional | Super-admins can perform all CRUD operations |
| Auth methods working | Magic link and Microsoft 365 both functional |
| 2FA adoption | Available and working for all users |
| Audit logging | All auth and user management events logged |
---
## 9. Resolved Questions
| Question | Resolution |
|----------|------------|
| Email provider | Pure SMTP - configurable via environment variables |
| Microsoft tenant | Configurable in admin UI - supports specific tenant or 'common' |
| Initial super-admin | Default account via env vars, forced reconfiguration on first login |
| Session duration | 1 hour default, configurable per source IP/subnet for trusted networks |
| Audit log retention | 120 days default, automatic purge of older records |
## 10. Resolved Questions (Continued)
| Question | Resolution |
|----------|------------|
| Trusted network configuration | CIDR notation (e.g., `192.168.1.0/24`, `10.0.0.0/8`) |
| Email templates | Customizable by admins in settings |
---
## 11. Implementation Phases
### Phase 1: Core Authentication
- Install and configure Better Auth
- Set up magic link authentication
- Set up Microsoft 365 OAuth
- Create sign-in page
- Implement middleware for route protection
### Phase 2: RBAC & Permissions
- Define permission structure
- Implement admin plugin with roles
- Protect admin routes
- Add role checking to API routes
### Phase 3: User Management
- Create user list page
- Implement invite user flow
- Create user edit page
- Add deactivate/delete functionality
### Phase 4: Role Management
- Create role list page
- Implement role creation/editing
- Add permission picker UI
### Phase 5: Security Features
- Implement 2FA
- Add session management UI
- Create audit log system
- Add audit log viewer
---
## Appendix: Permission Structure
```typescript
// Suggested permission structure
const permissions = {
// Ticket permissions
tickets: ["read", "create", "update", "delete"],
// Configuration items
configItems: ["read", "create", "update", "delete"],
// Admin sections
admin: ["access", "sync", "dataBrowser", "analytics"],
// User management (super-admin only)
users: ["read", "create", "update", "delete", "invite"],
// Role management (super-admin only)
roles: ["read", "create", "update", "delete"],
// Audit logs
auditLog: ["read"],
} as const;
// Default roles
const defaultRoles = {
"super-admin": {
// All permissions
},
"admin": {
tickets: ["read", "create", "update", "delete"],
configItems: ["read", "create", "update", "delete"],
admin: ["access", "sync", "dataBrowser", "analytics"],
},
"user": {
tickets: ["read", "create", "update"],
configItems: ["read"],
},
};
```