ZeroTrustIdentityService does not configure svidPicker, causing non-deterministic SVID selection

Inizia da ZeroTrustIdentityService.initX509Source() e verifica come vengono utilizzate le credenziali di binding ZTIS e X509SourceOptions. Conferma il comportamento di selezione degli SVID quando sono disponibili più SVID; il lavoro è completato quando la selezione si basa su credentials.workload.spiffeID invece che sull’ordine della lista, con un errore chiaro quando non esiste alcun SVID corrispondente.

Describe the Bug

ZeroTrustIdentityService does not configure svidPicker, causing non-deterministic SVID selection

Library: com.sap.cloud.sdk.cloudplatform:connectivity-ztis
Affected version: 5.32.0 (and likely earlier)
SPIFFE library: io.spiffe:java-spiffe-core:0.8.17

Problem

ZeroTrustIdentityService.initX509Source() builds an X509SourceOptions without setting an svidPicker:

X509SourceOptions.builder()
    .spiffeSocketPath(socketPath)
    .initTimeout(DEFAULT_SOCKET_TIMEOUT)
    .build();  // no .svidPicker(...) → falls back to getDefaultSvid()

DefaultX509Source.setX509Context() (in java-spiffe-core) then falls back to getDefaultSvid(), which simply returns the first SVID in the list:

if (picker == null) {
    svidUpdate = update.getDefaultSvid();   // first in list — non-deterministic
} else {
    svidUpdate = picker.apply(update.getX509Svids());
}

The SPIRE agent does not guarantee ordering. The set of SVIDs served for a workload changes when:

• A new CF service key is created for the ZTIS service instance — the ZTIS service broker registers a new SPIRE workload entry with the same selectors (CF space/app), making it visible to the running sidecar.
• Another service on the same Diego cell has a workload entry with overlapping selectors.

When this happens, getDefaultSvid() silently returns a different SVID — one belonging to another service key or workload. The mTLS handshake then either fails or presents the wrong identity to the remote service.

// Desired behaviour inside ZeroTrustIdentityService
String expectedSpiffeId = binding.getCredentials().get("workload.spiffeID");

X509SourceOptions.builder()
    .spiffeSocketPath(socketPath)
    .initTimeout(DEFAULT_SOCKET_TIMEOUT)
    .svidPicker(svids -> svids.stream()
        .filter(s -> s.getSpiffeId().toString().equals(expectedSpiffeId))
        .findFirst()
        .orElseThrow(() -> new IllegalStateException(
            "No SVID found for SPIFFE ID: " + expectedSpiffeId)))
    .build();

Impact

• Silent mTLS identity mismatch — the wrong certificate is presented to the remote service with no warning.
• Failures are transient and environment-dependent: they only reproduce after a new service key is created or a co-located workload registers overlapping selectors, making them hard to diagnose.
• Workaround requires consumers to bypass ZeroTrustIdentityService entirely and manage the X509Source lifecycle themselves.

Suggested Fix

Read credentials.workload.spiffeID from the ZTIS binding (already available in the binding credentials) and pass it as the svidPicker predicate to X509SourceOptions. This is a non-breaking addition — the picker only applies when multiple SVIDs are present; when only one SVID is served, the predicate still matches correctly.

No new dependencies are required; io.spiffe is already a transitive dependency of connectivity-ztis.

Environment

Steps to Reproduce

Steps to Reproduce

1. Deploy a CF application using ZeroTrustIdentityService for mTLS.
2. Create a second CF service key for the same ZTIS service instance.
3. Observe that getDefaultSvid() may now return the SVID from the new service key rather than the application's own SVID.
4. The mTLS handshake with the remote service fails or presents the wrong identity.

Expected Behavior

Expected Behaviour

The X509SourceOptions should be built with an svidPicker that selects the SVID matching the SPIFFE ID from the ZTIS service binding credentials (credentials.workload.spiffeID). The SPIFFE spec explicitly requires that workload API clients select SVIDs by their known SPIFFE ID; accepting the first arbitrarily is a misuse of the Workload API.

Screenshots

No response

Used Versions

• Java and Maven version via mvn --version: ...
• SAP Cloud SDK version: ...
• Spring Boot or CAP version: ...

Dependency tree here

Code Examples

// Your code here

Stack Trace

No response

Log File

Affected Development Phase

Getting Started

Impact

No Impact

Timeline

No response