Authentication & User Management Plan

Current State Analysis

What We Have

The API Gateway currently has:

1. No User/Physician Tables: The database models don’t include users or physicians tables yet

2. Case Tracking Only: We only have rn_requests (cases) with basic user identification:

   • user_id (text field)
   • user_identifier (text field)
   • user_crypt (text field - likely encrypted user data)
   • vendor_id (text field)

3. Session Storage: nest_sessions table exists (from NestJS legacy)

4. User Validation Logging: check_user_log table tracks validation attempts

What the Architecture Docs Describe

The architecture documentation mentions tables that don’t exist yet:

• users table with email, password_hash, tenant_id, request_count, role
• physicians table with email, password_hash, language, private_pool, vacation_mode
• tenants table for multi-tenancy

Legacy System Authentication

Looking at the existing rn_requests model, the legacy system appears to use:

• Anonymous or loosely-identified users (just text identifiers)
• Vendor-based identification (vendor_id)
• Possibly external authentication (Maccabi API, SAML)

Decision Points

Option 1: Start Fresh with Proper Auth (Recommended)

Implement a clean authentication system from scratch:

Pros:

• Modern JWT-based auth
• Proper user management
• Multi-tenancy support
• Role-based access control (patient, physician, admin)
• Clear security model

Cons:

• More work upfront
• Need to migrate any existing users

Implementation:

1. Create users, physicians, tenants tables
2. Implement JWT authentication
3. Add password hashing (bcrypt)
4. Add endpoints: /auth/login, /auth/register, /auth/refresh
5. Protect routes with auth dependencies

Option 2: Minimal Auth (Quick Start)

Keep the loose identification system for now:

Pros:

• Works with existing data
• Minimal changes
• Can add proper auth later

Cons:

• No security
• No proper user management
• Hard to scale

Implementation:

1. Use user_identifier as-is
2. Optional simple API key validation
3. Add proper auth later when needed

Option 3: Hybrid Approach

Start with basic structure, add features incrementally:

Pros:

• Balanced approach
• Can deploy faster
• Upgrade path clear

Cons:

• May need schema changes later

Implementation:

1. Create user tables NOW (even if minimal)
2. Implement basic JWT auth
3. Support both authenticated and anonymous users
4. Add features (multi-tenancy, RBAC) later

Recommendation

Go with Option 3: Hybrid Approach

Phase 1 (Now - MVP)

1. Add User Models:

   class User(Base):
       uuid: UUID (PK)
       email: str (unique)
       password_hash: str
       role: str  # 'patient', 'physician', 'admin'
       is_active: bool
       created_at: datetime
    
   class Physician(Base):
       uuid: UUID (PK)
       user_id: UUID (FK to users)
       language_preference: str
       private_pool: str
       vacation_mode: bool

2. Basic JWT Auth:

   • Login endpoint: POST /auth/login
   • Returns JWT token
   • Optional: Support anonymous case submission

3. Protected Routes:

   • Health endpoints: Public
   • AI endpoints: Optional auth (can be anonymous for demo)
   • Future case management: Require auth

Phase 2 (Later - Production)

1. Multi-tenancy (tenants table)
2. SAML/SSO for enterprise
3. Maccabi API integration
4. Request counting & rate limiting
5. Session management

Next Steps

1. Document the authentication strategy in docs
2. Create user/physician models
3. Write migration
4. Implement JWT utilities
5. Add auth endpoints
6. Add auth dependency for protected routes
7. Update tests

Questions to Answer

1. Do we want to support anonymous case submission?

   • Yes for demo/evaluation
   • No for production/HIPAA

2. What authentication methods?

   • JWT (yes - primary)
   • API keys (yes - for service-to-service)
   • SAML/SSO (later)
   • OAuth (maybe later)

3. Password requirements?

   • Min 8 characters
   • Require complexity?
   • 2FA later?

4. Email verification required?

   • Not for MVP
   • Add later for production

5. How to handle existing legacy data?

   • Keep user_identifier field in rn_requests
   • New cases use user_id FK to users table
   • Support both for backwards compatibility