Skip to content

Releases: eclipse-ecsp/api-gateway

1.5.0-M3.1

03 Mar 11:46

Choose a tag to compare

whats changed

Fix: Request Body Validation at API Gateway

Component: api-gatewayIgniteRouteLocator, RequestBodyFilter

Problem:
RequestBodyFilter rejected requests with a generic Invalid request payload error when the
SchemaValidator failed to initialise due to unresolvable $ref nodes in the stored schema.
Additionally, validation error messages did not indicate which field failed or why, making it
difficult for API consumers to correct their payloads.

Fix:
IgniteRouteLocator now constructs the SchemaValidator from the enriched schema document
(including components) produced by the api-registry-common fix. RequestBodyFilter reports
per-field validation failures with the field path and the specific constraint violation message
(e.g., address.street is invalid because type mismatch).

Impact:
Request body validation works correctly for schemas with nested references, and validation error
responses contain actionable, field-level detail for API consumers.

Bug Fix: requestBodyValidation flag always evaluating to false

Problem

RequestBodyFilter used @Value("${requestBody.validation}") for field injection, but the filter
is instantiated directly via new RequestBodyFilter(config) in RequestBodyValidator.apply().
Since it is not a Spring-managed bean, the @Value injection never occurred and
requestBodyValidation always defaulted to false, meaning request body schema validation was
silently skipped regardless of the configured property value.

Changes

  • RequestBodyFilter — Removed @Value injection; added requestBodyValidation as a
    constructor parameter.
  • RequestBodyValidator — Added @Value("${requestBody.validation}") field injection (valid
    here as it is a @Component) and passes the resolved value to RequestBodyFilter at
    construction time.

Impact

Request body schema validation is now correctly enabled or disabled based on the
requestBody.validation property value.

Bug: Scope Override Fix for API Route Registration

Problem

The scopes.override.enabled / scopes.scopesMap configuration had no runtime effect.

ApiRoutesLoader.enabledOverrideScope() – the merged scope list was assigned to a
local variable and never written back, so the original annotation scope was always
registered in the FilterDefinition.

Changes

api-registry-common/src/main/java/org/eclipse/ecsp/security/ScopeTagger.java

  • ApiRoutesLoader reads operation.getSecurity(), the overridden scopes are correctly
    picked up and stored in the route's FilterDefinition, which JwtAuthFilter enforces
    at request time.
// After (correct – update the mutable OpenAPI model)
if (operation.getSecurity() != null) {
    operation.getSecurity().forEach(sr ->
            sr.replaceAll((name, existingScopes) -> scopesList));
}

Configuration (unchanged):

scopes:
  override:
    enabled: true
  scopesMap:
    test-controller-updateById:
      - SelfManage
      - ManageTest

Full Changelog: 1.5.0-M3...1.5.0-M3.1

1.5.0-M3

26 Feb 10:16

Choose a tag to compare

whats changed

  1. #203 : added error response for client acccess validation failure:
{
  "code": "api.gateway.error",
  "message": "Access denied"
}
  1. configurable correlationId header name using below property
api:
  gateway:
     correlation-id-header: correlationId

Full Changelog: 1.5.0-M2...1.5.0-M3

1.5.0-M2.2

26 Feb 07:40

Choose a tag to compare

What's Changed

Fix for application not starting up and throwing UnsatisfiedDependencyException and APPLICATION FAILED TO START errors post Spring boot 4.0.3 and Spring 7.0.5 upgrade

Full Changelog: 1.5.0-M2.1...1.5.0-M2.2

Spring Boot 4.0.3 and Spring 7.0.5 upgrade

25 Feb 11:45

Choose a tag to compare

What's Changed

Bump spring boot version to 4.0.3
Bump spring version to 7.0.5
Bump netty version to 4.2.9.Final
Bump to latest versions of ecsp.utils, sql-dao and nosql-dao which use Spring Boot 4.0.3 and Spring 7.0.5
Use hypersistence.utils.hibernate.71.version latest version of 3.15.2
Bump hibernate-core version to 7.1.8.Final

Full Changelog: 1.5.0-M1.4...1.5.0-M2.1

1.5.0-M2

24 Feb 10:18
c6da89c

Choose a tag to compare

What's Changed

Client Access Control - New Feature

The Client Access Control feature provides fine-grained authorization for API routes, allowing you to restrict which clients can access specific services and routes based on their identity extracted from JWT tokens.

Overview

Client Access Control validates incoming requests using:

  1. JWT Claim Extraction - Extracts client identity from configurable JWT claims
  2. Rule-Based Access Control - Matches requests against whitelist/blacklist rules with wildcard support
  3. Real-Time Configuration - Automatically updates configurations via Redis Pub/Sub events
  4. YAML Override - Allows local YAML configuration to override database settings

Configuration

JWT Claim Extraction

Configure the JWT claims to extract client identity from in application.yml:

api:
  gateway:
    client-access-control:
      enabled: true
      claim-names:
        - client_id      # Try first (standard OAuth2 claim)
        - azp            # Try second (authorized party claim)
        - appid          # Try third (Azure AD claim)
      skip-paths:
        - /actuator/**
        - /swagger-ui/**

Access Rules

Rules use wildcard patterns to match services and routes:

  • service:* - Allow all routes in service
  • service:route-path - Allow specific route
  • !service:route - Deny specific route (negation rule with ! prefix)

Rule Evaluation Order:

  1. Check for matching negation rules (deny) - if found, deny request
  2. Check for matching allow rules - if found, allow request
  3. If no rules match, deny by default

Database Configuration

Client configurations are managed via Api-Registry CRUD APIs:

# Create client configurations
POST /api/registry/client-access-control
{
  "clientId": "mobile-app", 
  "tenant": "tenant-a",
  "isActive": true,
  "allow": [
    "user-service:*",
    "!payment-service:refund",
    "order-service:/orders"
  ]
}
# Get all active clients
GET /api/registry/client-access-control?includeInactive=false
# Filter with pagination
POST /api/registry/client-access-control/filter?page=0&size=20
{
  "clientId": "mobile",
  "tenant": "tenant-a",
  "isActive": true  
}
# Update configuration
PUT /api/registry/client-access-control/{id}
# Delete (soft delete by default)
DELETE /api/registry/client-access-control/{id}?permanent=false

YAML Override

Override database configurations for specific clients in application.yml:

api:
  gateway:
    client-access-control:
      overrides:
        - clientId: local-test-client
          tenant: dev
          active: true
          allow:
            - user-service:*
            - order-service:*

Precedence: YAML configuration takes precedence over database configuration for matching clientId.

Real-Time Refresh

Configurations are automatically refreshed when:

  • Redis Events: Api-Registry publishes CLIENT_ACCESS_CONTROL_UPDATED events on create/update/delete
  • Polling Fallback: Gateway polls Api-Registry every 60 seconds if Redis is unavailable
  • Startup: All configurations loaded at gateway startup

Metrics

Prometheus metrics exposed at /actuator/prometheus:

# Request validation
client_access_control_requests_checked_total{client_id}
client_access_control_requests_allowed_total{client_id,service,route}
client_access_control_requests_denied_total{client_id,service,route,reason}
# Cache performance
client_access_control_cache_hit_total{client_id}
client_access_control_cache_miss_total{client_id}
client_access_control_cache_size
# Performance
client_access_control_validation_duration_seconds{client_id}
client_access_control_config_refresh_duration_seconds
# YAML overrides
client_access_control_yaml_override_hit_total{client_id}

Other Changes

Full Changelog: 1.5.0-M1.4...1.5.0-M2

Spring Boot 4.0.2 and Spring 7.0.3 upgrade

20 Feb 07:34

Choose a tag to compare

What's Changed

Bump spring boot version to 4.0.2
Bump spring version to 7.0.3
Bump lombok version to 1.18.42
Bump spring-cloud-dependencies version to 2025.1.1
Use spring-cloud-starter-gateway-server-webflux and spring-cloud-gateway-server-webflux version 5.0.1
Bump springdoc-openapi version to 3.0.1
Bump netty version to 4.2.9.Final
Bump to latest versions of ecsp.utils, sql-dao and nosql-dao which use Spring Boot 4.0.2 and Spring 7.0.3
Use hypersistence.utils.hibernate.71.version latest version of 3.15.1
Use new testcontainers - testcontainers-junit-jupiter, testcontainers-mongodb, testcontainers-postgresql with version 2.0.3

Full Changelog: 1.4.0...1.5.0-M1.5

1.5.0-M1.4

17 Feb 03:34
1c822b8

Choose a tag to compare

What's Changed

  • Bump spring boot version from 3.5.9 to 3.5.10
  • Bump netty version from 4.1.129.Final to 4.1.131.Final

Other Changes

Full Changelog: 1.5.0-M1.3...1.5.0-M1.4

1.5.0-M1.3

09 Feb 05:42

Choose a tag to compare

What's Changed

  • Added retry logic in api-gateway for fetching routes and rate limits when operations encounter errors.

Other Changes

Full Changelog: 1.5.0-M1.2...1.5.0-M1.3

1.5.0-M1.2

02 Feb 07:18

Choose a tag to compare

Whats Changed

  • Simplified Redis connection checks in RouteRefreshFallbackScheduler and EventSubscriber to improve reliability when determining connection status.
  • Ensure the registry emits an event to the gateway once it becomes available so routes are populated even if the registry starts after the gateway.

Full Changelog: 1.5.0-M1.1...1.5.0-M1.2

1.5.0-M1.1

27 Jan 08:34

Choose a tag to compare

What's Changed

Fix Redis cluster reconnection failing to resolve node IPs after cluster recovery

Other Changes

Full Changelog: 1.5.0-M1...1.5.0-M1.1