Roadmap to v2.0

This page outlines planned work to bring Libra to version 2.0: strengthening authorization, improving operational control, and expanding fine-grained access control beyond tenant-scoped RBAC.

Keycloak UMA and PEP Proxy Replacement

Libra currently validates JWT tokens and enforces tenant-scoped RBAC. The plan is to add Keycloak UMA (User-Managed Access) support and position Libra as a drop-in replacement for Keyrock and the FIWARE PEP proxy:

  • UMA integration — Native support for Keycloak’s UMA 2.0 resource and permission APIs, enabling resource-level authorization decisions

  • PEP proxy parity — Replace Keyrock/FIWARE PEP proxy in existing FIWARE deployments without changing client expectations

  • Migration path — Gradual adoption; existing JWT + RBAC flows remain supported while UMA-based flows are introduced

Authorization Engine in Libra

Moving from pure RBAC checks to a dedicated authorization engine inside Libra:

  • Policy evaluation — Centralized policy engine that can combine RBAC, UMA, and future policy models

  • Extensibility — Pluggable authorization backends (Keycloak, custom policies) without changing the proxy core

  • Auditability — Clear policy decisions in audit logs for compliance and debugging

Management API

Libra currently exposes only health, readiness, info, and metrics. A dedicated Management API will enable operational control:

  • Configuration introspection — Query current config, cache stats, circuit breaker state, rate limit status

  • Runtime tuning — Adjust cache TTLs, circuit breaker thresholds, or rate limits without restart (where safe)

  • Admin operations — Invalidate cache entries, trigger JWKS refresh, or reset circuit breakers on demand

  • Authentication — Management endpoints protected by separate admin credentials or mTLS

Response Filtering

Today, access control is enforced at the request level (tenant + permission). Response filtering adds attribute-level control:

  • Query modification — Where possible, rewrite NGSI-LD queries to exclude entities or attributes the user has no permission to see (for example, filter out location for users without location permission)

  • Response filtering — For cases where query modification is insufficient, strip or redact attributes from responses before returning them to the client

  • Policy-driven — Filtering rules derived from the same authorization engine and tenant/permission model

Smart NGSI-LD Cache Improvements

The current cache is NGSI-LD aware with content-type keying, query normalization, and generational invalidation. Planned improvements:

  • Smarter invalidation — Better handling of batch operations, subscriptions, and temporal queries so cache stays consistent with minimal over-invalidation

  • Partial invalidation — Invalidate only affected entities or query patterns instead of broad generational flushes where feasible

  • Cache warming — Optional pre-population of frequently accessed entities or query patterns

  • Observability — Cache hit/miss metrics per resource type or endpoint pattern

API Stability and Documentation

The current REST surface is stable for proxied NGSI-LD and health endpoints. For v2.0:

  • OpenAPI specs — Full OpenAPI 3.x documentation for all public and management endpoints

  • Versioning — Clear API versioning strategy for future changes without breaking existing clients

  • Deprecation policy — Documented lifecycle for any endpoints or behaviors that will change

Lynx Ecosystem Integration

Tighter integration with Lynx for context and configuration:

  • Shared configuration — Lynx as a central store for authorization policies or tenant mappings

  • Context awareness — Better propagation of @context and JSON-LD context information when proxying to brokers

  • Unified identity — Align identity and tenant semantics with Lynx for consistent behavior across the FIWAREBox stack

Observability and Debugging

Improvements to help operators and developers troubleshoot production issues:

  • Structured tracing — OpenTelemetry or similar for distributed tracing across Libra and the broker

  • Request replay — Capture and replay problematic requests for debugging (with PII redaction)

  • Enhanced metrics — Per-tenant, per-endpoint, and per-permission metrics for capacity planning and anomaly detection