User-Level Message Structure Security Permissions

[oto-macenauer-absa]

Feature Description

Implement role-based access control (RBAC) for EventGate that restricts specific users to produce only messages matching predefined structural constraints. This allows fine-grained control over what data each producer can submit, preventing accidental or malicious submission of messages outside their authorized domain.

Example: User user1 is limited to producing messages only when source_app is app1 or app2.

Problem / Opportunity

Current Pain Points:

• Any authenticated user can produce messages to any topic with any source_app value
• No mechanism exists to enforce data ownership or application isolation at the producer level
• Risk of data pollution, cross-tenant contamination, or privilege escalation
• Increases compliance burden in regulated environments (financial, healthcare, etc.)

Who Benefits:

• Multi-tenant deployments requiring data isolation
• Organizations with strict data governance requirements
• Security teams implementing least-privilege access
• Enterprise deployments with segregated applications/teams

Acceptance Criteria

• Token handler validates user permissions against message structure during request processing
• API endpoint accepts user permission configuration (e.g., mapping user → allowed field values)
• Token validation fails with 403 Forbidden if message violates user's constraints
• Configuration supports multiple fields per user (e.g., source_app, tenant_id, environment)
• Configuration supports wildcards or regex patterns for field values
• Audit logs capture permission violations with user, timestamp, and constraint details
• Unit tests cover valid/invalid scenarios for multiple permission types
• Documentation includes permission configuration examples

Proposed Solution

High-level approach:

1. Extend access.json configuration to include permission mappings: user → {field_name: [allowed_values]}
2. Enhance HandlerToken to deserialize and cache user permissions during authentication
3. Modify HandlerTopic to validate incoming message fields against cached permissions before dispatch
4. Return 403 with descriptive error if validation fails
5. Log all permission checks (success/failure) via existing trace logging

Example config structure:

{
  "users": {
    "user1": {
      "source_app": ["app1", "app2"],
      "environment": ["dev", "uat"]
    },
    "user2": {
      "source_app": ["*"],
      "tenant_id": ["tenant_123"]
    }
  }
}

Dependencies / Related

• Related to data governance and security hardening
• May influence API documentation and client authentication flows
• Consider compatibility with existing token/access.json structure

Additional Context

This feature prioritizes security without breaking existing API contracts. Initial implementation should focus on exact string matching for fields, with regex support as a future enhancement. Consider the performance impact of validation on high-throughput scenarios.