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
| Component |
Version |
connectivity-ztis |
5.32.0 |
java-spiffe-core |
0.8.17 |
| Runtime |
SAP BTP Cloud Foundry (Diego cell) |
| Java |
21 |
Steps to Reproduce
Steps to Reproduce
- Deploy a CF application using
ZeroTrustIdentityService for mTLS.
- Create a second CF service key for the same ZTIS service instance.
- Observe that
getDefaultSvid() may now return the SVID from the new service key rather than the application's own SVID.
- 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 via mvn dependency:tree
Code Examples
Stack Trace
No response
Log File
Log file
...
Affected Development Phase
Getting Started
Impact
No Impact
Timeline
No response
Describe the Bug
ZeroTrustIdentityServicedoes not configuresvidPicker, causing non-deterministic SVID selectionLibrary:
com.sap.cloud.sdk.cloudplatform:connectivity-ztisAffected version:
5.32.0(and likely earlier)SPIFFE library:
io.spiffe:java-spiffe-core:0.8.17Problem
ZeroTrustIdentityService.initX509Source()builds anX509SourceOptionswithout setting ansvidPicker:DefaultX509Source.setX509Context()(injava-spiffe-core) then falls back togetDefaultSvid(), which simply returns the first SVID in the list:The SPIRE agent does not guarantee ordering. The set of SVIDs served for a workload changes when:
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.Impact
ZeroTrustIdentityServiceentirely and manage theX509Sourcelifecycle themselves.Suggested Fix
Read
credentials.workload.spiffeIDfrom the ZTIS binding (already available in the binding credentials) and pass it as thesvidPickerpredicate toX509SourceOptions. 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.spiffeis already a transitive dependency ofconnectivity-ztis.Environment
connectivity-ztis5.32.0java-spiffe-core0.8.17Steps to Reproduce
Steps to Reproduce
ZeroTrustIdentityServicefor mTLS.getDefaultSvid()may now return the SVID from the new service key rather than the application's own SVID.Expected Behavior
Expected Behaviour
The
X509SourceOptionsshould be built with ansvidPickerthat 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
mvn --version: ...Dependency tree via
mvn dependency:treeCode Examples
// Your code hereStack Trace
No response
Log File
Log file
...Affected Development Phase
Getting Started
Impact
No Impact
Timeline
No response