Phase 1: Customer Service - WebSocket Hub & Security Events

[MattiasGees]

Overview

Add WebSocket support to Customer Service for real-time updates to the frontend visualizer and audit trail.

Dependencies

• Phase 1: Customer Service - REST API Proxy to Ledger #32 (Customer Service REST API)

Tasks

• Create pkg/customer/websocket.go - WebSocket hub implementation
• Create pkg/customer/events.go - Security event types and emitter
• Add WebSocket endpoint at /ws
• Implement pub/sub for different event channels
• Emit security events during mTLS handshakes and API calls
• Add connection management (heartbeat, reconnection)

WebSocket Protocol

Client → Server

{"type": "subscribe", "channels": ["security_events", "transactions"]}
{"type": "unsubscribe", "channels": ["transactions"]}
{"type": "ping"}

Server → Client

{
    "type": "security_event",
    "timestamp": "2024-01-15T12:01:05Z",
    "event": "mtls_handshake",
    "source": "customer-service",
    "target": "ledger-service",
    "success": true,
    "svid": "spiffe://example.org/ns/trustbank/sa/customer",
    "duration_ms": 24
}

{
    "type": "transaction",
    "timestamp": "2024-01-15T12:01:06Z",
    "transaction": {"id": "uuid", "amount": 100.00, "status": "completed"}
}

Event Types

• mtls_handshake - When mTLS connection is established
• mtls_rejected - When mTLS connection is rejected
• db_auth - When X.509 DB auth occurs
• transaction_created - When transfer completes
• api_request - When API request is made (optional, verbose)

Testing Requirements

• Unit tests for WebSocket hub
• Test subscription/unsubscription
• Test event broadcasting
• Test connection cleanup on disconnect
• Integration test with actual WebSocket client
• Load test with multiple concurrent clients

Acceptance Criteria

• WebSocket connections stable over long periods
• Events broadcast to all subscribed clients
• Proper cleanup when clients disconnect
• Events include all necessary SPIFFE details
• 90%+ test coverage

Labels

phase-1 backend websocket