[BUG] JWT signature validation fails for AuthorizedAASEnvironmentPreconfigurationLoader

[de-ich]

Describe the bug
Using authorized preconfiguration loader fails with message 'Signed JWT rejected: Invalid signature'.

To Reproduce
Steps to reproduce the behavior:

1. Run a keycloak instance, e.g. via the following docker-compose:

services:
  
  keycloak:
    image: keycloak/keycloak:24.0.4
    container_name: keycloak-jwt-test
    ports:
      - '8080:8080'
    environment:
      KC_HOSTNAME: localhost
      KC_SPI_INITIALIZER_ISSUER_BASE_URI: http://host.docker.internal:8080
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: keycloak-admin
    command: ["start-dev"]
    networks:
     - keycloak-network

networks:
  keycloak-network:
    name: keycloak-network
    driver: bridge

2. Create a BaSyx realm and a client 'workstation-1' with service-account-roles (example is based on the BaSyxSecured example from here).
3. Start an AAS environment using the following configuration (adjust the client secret):

docker-compose.yml

services:
  # AAS Environment
  aas-env:
    image: eclipsebasyx/aas-environment:2.0.0-milestone-03
    container_name: aas-env-jwt-test
    environment:
      - SERVER_PORT=8081
    volumes:
      - ./aas:/application/aas
      - ./basyx/aas-env.properties:/application/application.properties
      - ./basyx/rules/aas_env_rbac_rules.json:/application/rbac_rules.json
    ports:
      - '8081:8081'
    restart: always
    networks:
      - basyx-java-server-sdk

networks:
  basyx-java-server-sdk:
    name: basyx-java-server-sdk
    driver: bridge

aas-env.properties

server.port=8081
basyx.backend=InMemory
basyx.cors.allowed-origins=*
basyx.cors.allowed-methods=GET,POST,PATCH,DELETE,PUT,OPTIONS,HEAD
basyx.externalurl=http://localhost:8081
basyx.feature.authorization.enabled = true
basyx.feature.authorization.type = rbac
basyx.feature.authorization.jwtBearerTokenProvider = keycloak
basyx.feature.authorization.rbac.file = file:/application/rbac_rules.json
spring.security.oauth2.resourceserver.jwt.issuer-uri=http://host.docker.internal:8080/realms/BaSyx
basyx.environment=file:aas
basyx.aasenvironment.authorization.preconfiguration.token-endpoint=http://host.docker.internal:8080/realms/BaSyx/protocol/openid-connect/token
basyx.aasenvironment.authorization.preconfiguration.grant-type = CLIENT_CREDENTIALS
basyx.aasenvironment.authorization.preconfiguration.client-id=workstation-1
basyx.aasenvironment.authorization.preconfiguration.client-secret=nY0mjyECF60DGzNmQUjL81XurSl8etom

3. Start the docker container
4. Notice that the server does not start and produces the following stack trace instead:

2025-01-20 14:49:25 org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'preconfigurationLoaderInitializer' defined in URL [jar:nested:/application/basyxExecutable.jar/!BOOT-INF/lib/basyx.aasenvironment-core-2.0.0-milestone-03.jar!/org/eclipse/digitaltwin/basyx/aasenvironment/preconfiguration/PreconfigurationLoaderInitializer.class]: An error occurred while attempting to decode the Jwt: Signed JWT rejected: Invalid signature
2025-01-20 14:49:25     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1806) ~[spring-beans-6.1.11.jar!/:6.1.11]
2025-01-20 14:49:25     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:600) ~[spring-beans-6.1.11.jar!/:6.1.11]
2025-01-20 14:49:25     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:522) ~[spring-beans-6.1.11.jar!/:6.1.11]
2025-01-20 14:49:25     at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:337) ~[spring-beans-6.1.11.jar!/:6.1.11]
2025-01-20 14:49:25     at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) ~[spring-beans-6.1.11.jar!/:6.1.11]
2025-01-20 14:49:25     at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:335) ~[spring-beans-6.1.11.jar!/:6.1.11]
2025-01-20 14:49:25     at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:200) ~[spring-beans-6.1.11.jar!/:6.1.11]
2025-01-20 14:49:25     at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:975) ~[spring-beans-6.1.11.jar!/:6.1.11]
2025-01-20 14:49:25     at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:971) ~[spring-context-6.1.11.jar!/:6.1.11]
2025-01-20 14:49:25     at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:625) ~[spring-context-6.1.11.jar!/:6.1.11]
2025-01-20 14:49:25     at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:146) ~[spring-boot-3.3.2.jar!/:3.3.2]
...

Expected behavior
The server starts successfully.

BaSyx (please complete the following information):

• BaSyx Java SDK

Additional context
To me, the problem seems to be that the public key is not retrieved from the keycloak server (http://localhost:8080/realms/BaSyx/) but built from a fixed combination of modulus and exponent:

basyx-java-server-sdk/basyx.aasenvironment/basyx.aasenvironment-feature-authorization/src/main/java/org/eclipse/digitaltwin/basyx/aasenvironment/feature/authorization/AuthorizedAASEnvironmentPreconfigurationLoader.java

Line 108 in 0a7a5d5

String modulus = getStringFromFile("authorization/modulus.txt");

This leads to the fact that the AuthorizedAASEnvironmentPreconfigurationLoader should only work with only those exact keys that are specified in the sample realm (https://github.com/eclipse-basyx/basyx-java-server-sdk/blob/0a7a5d57926fe74eb6477661d3ccbed00c099538/examples/BaSyxSecured/keycloak/realm/BaSyx-realm.json).

[mdanish98]

Hi @de-ich ,

Thanks a lot for raising this issue.
We are analyzing this issue and will provide a fix soon.