Service plan "reference-instance" unknown by java-security client

[lholthof]

In SAP BTP there is the feature to share the xsuaa instance which we consume to make an xsuaa instance available across different Kyma namespaces. It leads to xsuaa reference-instances of plan "reference-instance". The java-security client lib is not aware of this service plan, see ServiceBindingEnvironment and hence it logs a warning with message: "There is no xsuaa service configuration: no local scope check possible." in class HybridTokenFactory.

I understand that this leads to the situation that the appId is not validated. We are looking for this validation to happen as well as part of java-security library for instances of plan "reference-instance".

[liga-oz]

Hi @lholthof,

thanks for bringing this up, I wasn't aware that there's another service plan for Xsuaa available. Is there a documentation available describing this plan, which I could refer to?

Cheers, Liga

[lholthof]

Hi @liga-oz,

I learned about this in this internal how-to and I can confirm it is working for for us except the client is not aware of this plan.

Regards, Lukas

[mwdb]

@liga-oz : This is not a plan coming from xsuaa. It is a plan generated by service manager for sharing service instances within a subaccount.

Looks like the original plan gets lost in this case. This should be discussed with colleagues. This is the binding of a shared instance. { "VCAP_SERVICES": { "xsuaa": [ { "label": "xsuaa", "provider": null, "plan": "reference-instance", "name": "shared2", "tags": [ "xsuaa" ], "instance_guid": "8584c9fe-99da-47c1-b905-2fe2a6234588", "instance_name": "shared2", "binding_guid": "c2da23ea-a2ac-4ee6-a77c-228b1c567ad9", "binding_name": null, "credentials": { "tenantmode": "shared", ...

[Pavan89851]

We are also facing the same issue in java springboot 3.x with the error bean exception of reference-instance:

**"message":"Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanDefinitionStoreException: Failed to process import candidates for configuration class [com.sap.gs.lxlab.tpmapi.rest.TPMApiApplication]: No enum constant com.sap.cloud.security.config.ServiceConstants.Plan.REFERENCE-INSTANCE","thread_name":"main","@timestamp":"2023-08-23T13:26:45.231+0000","level":"WARN","logger_name":"org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext"}**

[finkmanAtSap]

I just want to give you a quick update: we are currently discussing how to handle this problem with the colleagues responsible for the creation of that service plan. As it is not an official service plan, we do not support it in the client libraries. When there is a plan for action, I will update you again with more information.

[lholthof]

@finkmanAtSap , do you have another update for us?

[finkmanAtSap]

Sorry for the long delay. We have found a solution that should hopefully work for you.

After discussing whether this should be changed by Service Manager or inside the client libraries, we have decided to treat it is an edge case that we do not code against as it is not an official XSUAA service plan. However, we want to enable consumers of the lib to still use the lib with reference-instance.

The problematic parts come from a part of the lib that decides for you which service configuration it uses based on the service plan. You can get around that in java-security by explicitly specifying which service configuration the library should use.

Here is a two-step guide for this:

1. Accessing the reference-instance service configuration Call this method to get the list of all service configurations:

https://github.com/SAP/cloud-security-services-integration-library/blob/main/java-api/src/main/java/com/sap/cloud/security/config/Environment.java#L60

By default, you can call Environments.getCurrent() to get an Environment implementation on which you can call the method. Retrieve your desired configuration from the list of XSUAA configurations. If you decide to identify your configuration in the list based on the value of its service plan (but maybe there is a less exotic property to identify it...?), you can do it like this: Environments.getCurrent().getServiceConfigurationsAsList().get(Service.XSUAA).stream().findFirst(config -> config.getProperty(SERVICE_PLAN).equals("reference-instance")

Follow the documentation at https://github.com/SAP/cloud-security-services-integration-library/tree/main/java-security#oauth2serviceserviceconfiguration-usage to pass your custom configuration to XsuaaTokenAuthenticator.

XsuaaTokenAuthenticator authenticator = new XsuaaTokenAuthenticator() .withServiceConfiguration(yourServiceConfig);

[finkmanAtSap]

We are also facing the same issue in java springboot 3.x with the error bean exception of reference-instance:

**"message":"Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanDefinitionStoreException: Failed to process import candidates for configuration class [com.sap.gs.lxlab.tpmapi.rest.TPMApiApplication]: No enum constant com.sap.cloud.security.config.ServiceConstants.Plan.REFERENCE-INSTANCE","thread_name":"main","@timestamp":"2023-08-23T13:26:45.231+0000","level":"WARN","logger_name":"org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext"}**

Currently, we not see why the spring modules of this lib would crash when reference-instance is present in the environment. Please give us a full stack trace where we can see which of our classes triggers the exception and the required information from the bug report template:

• [ ] log level increased to DEBUG debug logs provided
  • [ ] POM provided
  • [ ] dependency tree provided
  • [ ] code snippet provided (when applicable)

[lholthof]

Sorry for the long delay. We have found a solution that should hopefully work for you.

After discussing whether this should be changed by Service Manager or inside the client libraries, we have decided to treat it is an edge case that we do not code against as it is not an official XSUAA service plan. However, we want to enable consumers of the lib to still use the lib with reference-item.

The problematic parts come from a part of the lib that decides for you which service configuration it uses based on the service plan. You can get around that in java-security by explicitely specifying which service configuration the library should use.

Here is short a two-step guide for this:

1. Accessing the reference-instance service configuration Call this method to get the list of all service configurations:

https://github.com/SAP/cloud-security-services-integration-library/blob/896d550f19378efae5fa93e52e45bd98b4aab21c/env/src/main/java/com/sap/cloud/security/config/ServiceBindingEnvironment.java#L125

By default, you can call Environments.getCurrent() to get a ServiceBindingEnvironment object on which you can call the method. Retrieve your desired configuration from the list of XSUAA configurations. If you decide to identify your configuration in the list based on the value of its service plan (but maybe there is a less exotic property to identify it...?), you can do it like this: Environments.getCurrent().getServiceConfigurationsAsList().get(Service.XSUAA).stream().findFirst(config -> config.getProperty(SERVICE_PLAN).equals("reference-item")

Follow the documentation at https://github.com/SAP/cloud-security-services-integration-library/tree/main/java-security#oauth2serviceserviceconfiguration-usage to pass your custom configuration to XsuaaTokenAuthenticator.

XsuaaTokenAuthenticator authenticator = new XsuaaTokenAuthenticator() .withServiceConfiguration(yourServiceConfig);

Thank you for the detailed answer. The suggested workaround works fine for me.

[finkmanAtSap]

Closing as we do not expect the spring modules to require a workaround.