Migrate Airavata to Spring Boot, Simplify Data Models

[yasithdev]

…ecture

Migrate the Airavata platform from legacy Thrift/OpenJPA architecture to a modern Spring Boot application with clean service layer boundaries.

Key changes:

• Replace Thrift RPC with Spring Boot REST API (Swagger UI at /swagger-ui)
• Replace OpenJPA with Spring Data JPA (Hibernate) and MapStruct mappers
• Introduce interface-first service layer (FooService + DefaultFooService)
• Add generic CrudService/AbstractCrudService/EntityMapper infrastructure
• Restructure packages into domain boundaries: research/, execution/, compute/, storage/, status/, iam/, credential/, workflow/, protocol/
• Implement Temporal-based durable workflows (ProcessActivity: Pre/Post/Cancel)
• Add DAG-based task execution engine (ProcessDAGEngine)
• Consolidate compute backends into ComputeProvider interface (Slurm/AWS/Local)
• Consolidate storage operations into StorageClient interface (SFTP)
• Replace log4j with logback, Dozer with MapStruct
• Add Flyway for schema migrations
• Simplify distribution into single Spring Boot module
• Remove deprecated Python SDK, PHP SDK, and Thrift IDL definitions
• Streamline dev environment with Docker Compose and init scripts

In general, fix this by adding an explicit permissions block that grants only the minimal scopes required by the job, either at the workflow root (applies to all jobs) or inside the specific job. For this Maven build, the steps only need to read repository contents to check out code, so contents: read is sufficient.

The best minimal fix without changing functionality is to add a root-level permissions block after the on: section and before jobs: in .github/workflows/maven-build.yml, setting contents: read. This will apply to the build job and any future jobs that don’t override it, ensuring the GITHUB_TOKEN cannot write to the repository while preserving current behavior.

Concretely, in .github/workflows/maven-build.yml, insert:

permissions:
  contents: read

between lines 12 and 13 (after the push branches configuration and before jobs:). No imports or additional definitions are needed, as this is standard GitHub Actions YAML configuration.

In general, to fix this issue you should not use AutoAddPolicy or WarningPolicy for Paramiko’s missing host key policy. Instead, rely on the default RejectPolicy or explicitly set it, and (optionally) load known host keys from a trusted file so unknown hosts cause a controlled failure.

For this specific code, the minimal change that preserves existing functionality (connecting to the expected container host and failing loudly if something is wrong) is to replace paramiko.AutoAddPolicy() with paramiko.RejectPolicy(). This ensures that if the SSH server’s host key is not already known to the client, ssh.connect will raise an exception rather than silently trusting it. Since this is a test, such an exception is acceptable and desirable, indicating an unexpected environment change.

Concretely:

• In dev-tools/ansible/tests/test_base_role.py, at the creation of the SSHClient in _test_base_role, change line 65 from:
  • ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    to:
  • ssh.set_missing_host_key_policy(paramiko.RejectPolicy())
• No new imports are needed because paramiko is already imported.
• No other logic needs to change; if host key verification fails, the test will error out, which is appropriate.

In general, to fix this class of issue, you should avoid AutoAddPolicy and WarningPolicy and instead rely on Paramiko’s default RejectPolicy, or explicitly set RejectPolicy. If the host key changes or is unknown, the connection should fail rather than silently continuing.

In this specific file, the best minimal change is to stop using AutoAddPolicy and either (a) omit setting a policy at all (Paramiko defaults to RejectPolicy), or (b) explicitly set RejectPolicy so the intent is clear. Since we are only allowed to edit this snippet, we will replace the call on line 67:

ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())

with:

ssh.set_missing_host_key_policy(paramiko.RejectPolicy())

This preserves the rest of the behavior and only tightens host key handling. No new imports are necessary because the code already imports paramiko at the top, and RejectPolicy is available as paramiko.RejectPolicy. All changes are confined to dev-tools/ansible/tests/test_database_role.py within the shown region.

In general, to prevent SSRF when building URLs from user-provided input, you must either (1) map the untrusted value to a server-side whitelist or (2) strictly validate and normalize the value to an allowed format and then, ideally, verify the resulting URI’s host/prefix before issuing the request. Here, UserContext.gatewayId() is untrusted but used directly to construct the host part of the URL: "https://" + UserContext.gatewayId() + ".cybershuttle.org/... in AiravataFileService.fetchExperimentStorageFromAPI. We can keep existing functionality while adding server-side validation for gatewayID and rejecting malformed or unexpected values.

The least invasive, best fix within the provided snippets is:

1. Introduce a validation method in UserContext that enforces a strict pattern for gatewayID, e.g., only lowercase letters, digits, and hyphens, with reasonable length limits and no leading/trailing hyphens. This prevents host header injection or weird subdomain tricks such as embedding dots, ports, or schemes ("evil.com:8080", "foo.bar", "../../etc/hosts", etc.).
2. Use that validation in gatewayId() so that any invalid gatewayID claim causes an immediate, controlled failure (e.g., IllegalArgumentException), instead of being used in URL construction.
3. Optionally, add a log message around the validation failure for diagnostics, but we’ll keep behavior consistent with the existing getClaim method, which already throws IllegalArgumentException on missing claims.

We only need changes in UserContext:

• Add imports for java.util.regex.Pattern and org.slf4j.Logger / LoggerFactory, if we choose to log. To keep changes minimal and avoid modifying logging configuration, we can skip adding logging and rely on the thrown exception, so no new imports are strictly required.
• Modify gatewayId() to call a new private method getValidatedGatewayId() (or do the validation inline) that checks the raw claim value against a safe regex like ^[a-z0-9-]{1,63}$. This ensures the resulting hostname gatewayId + ".cybershuttle.org" is syntactically safe and cannot introduce new domains, ports, or schemes.

With this fix, AiravataFileService.fetchExperimentStorageFromAPI continues to call UserContext.gatewayId() exactly as before, but now the method guarantees that the value is sanitized. If a malicious X-Claims header attempts to inject a dangerous gatewayID, the code will throw an error instead of making the SSRF-capable request.

---

In general, the correct fix is to avoid any custom TrustManager that accepts all certificates. Instead, rely on the platform’s default TrustManager (using the default trust store), or, if you must trust specific self‑signed/internal certificates, build a KeyStore containing only those certificates and initialize a TrustManagerFactory from it, as shown in the background example. This preserves TLS server authentication while still allowing custom trust roots.

In this file, the simplest secure fix without changing the intended functionality is:

• Remove the insecure createTrustAllSSLContext implementation that uses a trust‑all X509TrustManager.
• Replace it with a secure version that delegates to the default system trust managers. This maintains the ability to create an SSLContext for HTTPS use, but it will perform proper certificate validation according to the system trust store.

Concretely, in RestClientConfiguration.java:

• Replace the body of createTrustAllSSLContext() (lines 122–139) with code that:
  • Obtains a TrustManagerFactory using TrustManagerFactory.getDefaultAlgorithm().
  • Initializes it with the default KeyStore by passing null to tmf.init(null).
  • Creates an SSLContext for "TLS" and initializes it with the trust managers from the factory.
• Keep the method signature unchanged to avoid affecting other code that may call it.
• No new imports are needed: KeyStore, SSLContext, TrustManagerFactory, and TrustManager are already imported.

This preserves the external API (createTrustAllSSLContext()) but changes its behavior from “trust everything” to “use default certificate validation”.

---

In general, the fix is to stop disabling CSRF protection and instead configure it appropriately for this stateless JWT-based API. Because the app uses bearer tokens and stateless sessions, server-side CSRF tokens don’t align perfectly with how the API is meant to be consumed; however, we can still avoid explicitly turning CSRF off and instead restrict CSRF enforcement to methods where it makes sense, or declare the API as not using cookie-based authentication for state‑changing calls. The minimal, least-invasive change—while satisfying the security requirement and not altering the authorization model—is to remove the explicit csrf.disable() call and rely on Spring Security’s default CSRF behavior, or explicitly configure CSRF in a safe way.

Given the constraints (only this snippet can be changed, no new dependencies), the best fix with minimal behavior change is:

• Remove csrf.disable() from the filter chain configuration.
• Replace it with a neutral CSRF configuration block that leaves CSRF enabled but doesn’t introduce extra behavior in this file. For instance, a simple http.csrf(csrf -> { }); keeps CSRF enabled under Spring defaults. This will re-enable CSRF protection for mutating HTTP methods, which is the desired security posture. If other parts of the system depend on CSRF being off, they should be updated explicitly, but that is outside the scope of this snippet.

Concretely:

• In WebSecurityConfiguration.securityFilterChain, change line 48 from http.csrf(csrf -> csrf.disable()) to http.csrf(csrf -> { }).
• No new imports or methods are required; we only adjust the lambda passed to csrf.