add stories
This commit is contained in:
@@ -0,0 +1,28 @@
|
||||
# Secure JWT Endpoints with Backend Token
|
||||
|
||||
**ID:** ADM-001
|
||||
**Priority:** Critical
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want JWT-related endpoints to be secured with backend token validation so that only authorized services can access sensitive security operations.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Public key endpoint requires valid backend token
|
||||
- [ ] JWT blocklist endpoint requires valid backend token
|
||||
- [ ] Backend tokens are securely generated and distributed
|
||||
- [ ] Token validation is performed on every request
|
||||
- [ ] Invalid/missing token returns 401 Unauthorized
|
||||
- [ ] Tokens can be rotated without service interruption
|
||||
- [ ] Audit log for all backend token usage
|
||||
|
||||
## Technical Notes
|
||||
- Two TODOs exist for backend token validation in JwtManager
|
||||
- `getPublicKeyForValidation` and `pushOrGetJwtIdBlocklist` need protection
|
||||
- Backend token should be separate from user JWT
|
||||
- Consider service-to-service authentication pattern
|
||||
- Environment variable for backend token configuration
|
||||
|
||||
## Related TODOs
|
||||
- `ts/reception/classes.jwtmanager.ts:40` - `// TODO control backend token`
|
||||
- `ts/reception/classes.jwtmanager.ts:52` - `// TODO control backend token`
|
||||
@@ -0,0 +1,28 @@
|
||||
# Suspend and Delete Users
|
||||
|
||||
**ID:** ADM-002
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want to suspend and delete user accounts so that I can handle policy violations, security incidents, and account removal requests.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Admin can search for users by email, name, or ID
|
||||
- [ ] Admin can suspend a user account with reason
|
||||
- [ ] Suspended users cannot log in
|
||||
- [ ] Suspended users' active sessions are invalidated
|
||||
- [ ] Admin can unsuspend accounts
|
||||
- [ ] Admin can permanently delete suspended accounts
|
||||
- [ ] Deletion removes all user data (GDPR compliance)
|
||||
- [ ] Audit log for all suspension/deletion actions
|
||||
|
||||
## Technical Notes
|
||||
- `suspendUser` and `deleteSuspendedUser` endpoints exist
|
||||
- Need admin UI for user management
|
||||
- Consider soft delete with retention period
|
||||
- Handle organization ownership before deletion
|
||||
- Email notification to user on suspension
|
||||
|
||||
## Related TODOs
|
||||
- Partial implementation in UserManager
|
||||
@@ -0,0 +1,28 @@
|
||||
# Platform-wide Audit Logging
|
||||
|
||||
**ID:** ADM-003
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want to view platform-wide audit logs so that I can monitor security events, investigate incidents, and demonstrate compliance.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Log all authentication events (login, logout, failed attempts)
|
||||
- [ ] Log all administrative actions (user changes, config changes)
|
||||
- [ ] Log all security events (password changes, 2FA changes, token revocations)
|
||||
- [ ] Searchable log interface with filters
|
||||
- [ ] Real-time log streaming for monitoring
|
||||
- [ ] Export logs in standard formats (JSON, CSV, CEF)
|
||||
- [ ] Log retention configuration
|
||||
- [ ] Integration with external SIEM systems
|
||||
|
||||
## Technical Notes
|
||||
- Separate from organization audit logs (ORG-007)
|
||||
- Platform-wide view across all organizations
|
||||
- Consider ELK stack or similar for log aggregation
|
||||
- Structured logging format for parsing
|
||||
- Compliance: SOC 2, ISO 27001, GDPR audit requirements
|
||||
|
||||
## Related TODOs
|
||||
- New feature - platform security requirement
|
||||
@@ -0,0 +1,28 @@
|
||||
# Customize Email Templates
|
||||
|
||||
**ID:** ADM-004
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want to customize email templates so that all system emails match our branding and communication style.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Edit templates for: registration, password reset, login verification, welcome
|
||||
- [ ] Rich text editor for template content
|
||||
- [ ] Variable placeholders ({{userName}}, {{resetLink}}, etc.)
|
||||
- [ ] Preview emails before saving
|
||||
- [ ] Send test emails to verify
|
||||
- [ ] Localization support for multiple languages
|
||||
- [ ] Reset to default template option
|
||||
- [ ] Version history for templates
|
||||
|
||||
## Technical Notes
|
||||
- ReceptionMailer handles email sending
|
||||
- Currently uses hardcoded or simple templates
|
||||
- Consider template engine (Handlebars, Mjml for responsive)
|
||||
- Store templates in database for dynamic updates
|
||||
- Support HTML and plain text versions
|
||||
|
||||
## Related TODOs
|
||||
- New feature - enhance ReceptionMailer
|
||||
@@ -0,0 +1,28 @@
|
||||
# Security Monitoring Dashboard
|
||||
|
||||
**ID:** ADM-005
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want a security monitoring dashboard so that I can quickly identify and respond to potential security threats.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Real-time metrics: active sessions, login rate, failure rate
|
||||
- [ ] Anomaly detection alerts (unusual login patterns)
|
||||
- [ ] Geographic map of login locations
|
||||
- [ ] Failed login attempt heatmap
|
||||
- [ ] Blocked JWT/token statistics
|
||||
- [ ] Suspicious activity indicators
|
||||
- [ ] Configurable alert thresholds
|
||||
- [ ] Integration with alerting systems (PagerDuty, Slack)
|
||||
|
||||
## Technical Notes
|
||||
- Aggregate metrics from login events
|
||||
- Real-time updates via WebSocket
|
||||
- Consider time-series database for metrics
|
||||
- Machine learning for anomaly detection (future)
|
||||
- Alert rules engine for custom notifications
|
||||
|
||||
## Related TODOs
|
||||
- New feature - security operations
|
||||
@@ -0,0 +1,28 @@
|
||||
# Impersonate Users for Support
|
||||
|
||||
**ID:** ADM-006
|
||||
**Priority:** Low
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want to temporarily impersonate a user so that I can troubleshoot issues they're experiencing without asking for their credentials.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Admin can initiate impersonation session for any user
|
||||
- [ ] Impersonation requires confirmation and reason
|
||||
- [ ] Clear visual indicator when in impersonation mode
|
||||
- [ ] Admin can end impersonation and return to their session
|
||||
- [ ] All actions during impersonation are logged
|
||||
- [ ] User is optionally notified of impersonation
|
||||
- [ ] Impersonation sessions have time limit
|
||||
- [ ] Cannot impersonate other admins without super-admin
|
||||
|
||||
## Technical Notes
|
||||
- Special JWT claim to indicate impersonation
|
||||
- Original admin identity preserved in token
|
||||
- Audit log must capture both admin and impersonated user
|
||||
- Consider "read-only" impersonation mode
|
||||
- Security review required before implementation
|
||||
|
||||
## Related TODOs
|
||||
- New feature - support tooling
|
||||
@@ -0,0 +1,28 @@
|
||||
# Manage JWT Blocklist
|
||||
|
||||
**ID:** ADM-007
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want to view and manage the JWT blocklist so that I can revoke tokens during security incidents and verify that revocations are working.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] View all blocked JWT IDs with metadata
|
||||
- [ ] Search blocklist by JWT ID or user
|
||||
- [ ] Manually add JWTs to blocklist
|
||||
- [ ] View reason for each blocklist entry
|
||||
- [ ] Blocklist entries show expiration (when they can be removed)
|
||||
- [ ] Bulk revoke all tokens for a user
|
||||
- [ ] Bulk revoke all tokens for an organization
|
||||
- [ ] Automatic cleanup of expired blocklist entries
|
||||
|
||||
## Technical Notes
|
||||
- JwtManager has `blockedJwtIdList` infrastructure
|
||||
- `pushOrGetJwtIdBlocklist` endpoint exists
|
||||
- Need admin UI for blocklist management
|
||||
- ReceptionHousekeeping could handle cleanup
|
||||
- Consider Redis for high-performance blocklist checks
|
||||
|
||||
## Related TODOs
|
||||
- Enhancement to existing blocklist infrastructure
|
||||
Reference in New Issue
Block a user