Token exchange fails with IAS authentication - "Some parties were not in the token audience"

[roobyxiao]

Hello,
We are using SDM plugin version 1.9.0 with IAS (Identity Authentication Service) for user authentication. File upload fails during the content upload step with a token exchange error.

Error

com.sap.cloud.security.xsuaa.client.OAuth2ServiceException: Error requesting access token!
Http status code: 401
Response body: {
"error": "invalid_token",
"error_description": "Some parties were not in the token audience: 6d1db9be-1867-4755-9622-ef3461821294"
}

Stack trace shows the error occurs in:
at com.sap.cds.sdm.service.SDMServiceImpl.getFolderIdByPath(SDMServiceImpl.java:518)
at com.sap.cds.sdm.service.handler.SDMAttachmentsServiceHandler.createDocumentInSDM(SDMAttachmentsServiceHandle
r.java:422)

Reproduction

1. App uses IAS for user authentication (/bindings/auth label: identity)
2. SDM service binding at /bindings/sdm (XSUAA-based)
3. Upload file via OData: PUT /Entity_attachments(...)/content
4. SDM plugin attempts to exchange IAS token for XSUAA token → fails with 401

Question

Is IAS + SDM officially supported? If yes, what is the recommended configuration?

The SDM plugin seems to attempt user token exchange (named user flow) which fails because IAS tokens cannot be
exchanged for XSUAA tokens.

[github-actions]

🧪 Initial Analysis & Proposed Remediation

Summary & Root Cause Hypothesis
The issue describes a token exchange failure during a file upload operation involving the SDM (Storage and Document Management) plugin (version 1.9.0) in a CAP application. The application uses IAS (Identity Authentication Service) for user authentication, while the SDM service binding is XSUAA-based. The core error "Some parties were not in the token audience: 6d1db9be-1867-4755-9622-ef3461821294" indicates that when the SDM plugin attempts to exchange the IAS token for an XSUAA token (a "named user flow"), the XSUAA authorization server (associated with the SDM service) does not find its own clientid (6d1db9be-1867-4755-9622-ef3461821294) in the aud (audience) claim of the IAS token. This prevents the XSUAA service from issuing a new token for the target audience, resulting in a 401 Unauthorized error.

The root cause is likely an incomplete or incorrect configuration for token exchange between the IAS-authenticated application and the XSUAA-secured SDM service. Specifically, the XSUAA service's client ID is not present in the audience claim of the tokens issued by IAS, which is a prerequisite for a successful token exchange by the com.sap.cloud.security.xsuaa:token-client library used by the SDM plugin.

---

🥇 Prioritized Remediation Steps (with Code Fixes)

1. Configure XSUAA Audience in xs-security.json (High Priority):

   • Rationale: The "Some parties were not in the token audience" error directly points to an audience mismatch. For the XSUAA service to accept an incoming token (even for exchange) and validate it, its own clientid must be present in the aud claim of that token. This is typically achieved by declaring the necessary audiences in the xs-security.json file of the application's XSUAA instance, especially when dealing with cross-UAA token flows or identity providers like IAS.
   • Action & Required Change: Modify the xs-security.json file associated with your application's XSUAA service instance (the one that handles the identity binding for IAS and potentially proxies to SDM) to include the clientid of the XSUAA instance bound to the SDM service as a trusted foreign-scope-as-audience. This allows your XSUAA instance to correctly handle tokens that might be intended for other services. If the CAP application itself is the OAuth client for IAS and also the issuer of calls to SDM, its xs-security.json needs to be updated. The given client ID (6d1db9be-1867-4755-9622-ef3461821294) should be added to the foreign-scope-as-audience property, ensuring it's recognized when processing tokens.

   {
     "xsappname": "your-app-name",
     "tenant-mode": "dedicated",
     "scopes": [
       // ... existing scopes ...
       {
         "name": "$XSAPPNAME.attachments.create",
         "description": "Create attachments"
       }
     ],
     "attributes": [],
     "role-templates": [],
     "foreign-scope-as-audience": [
       "6d1db9be-1867-4755-9622-ef3461821294"
       // Add any other XSUAA client IDs for services your app might call via token exchange
     ],
     "oauth2-configuration": {
       "token-validity": 3600,
       "refresh-token-validity": 86400,
       "redirect-uris": [
           "https://*.localhost:8080/**",
           "https://*.your-app-domain.com/**"
       ],
       "system-attributes": [
         "xsuaa_default_tenant"
       ]
     }
   }

2. Inspect BTP Service Bindings and IAS Trust Configuration (High Priority):

   • Rationale: Even with the xs-security.json updated, the underlying service bindings and trust configurations must be correct for the token exchange to function. Incorrect URLs, clientids, or missing trust setup between IAS and the XSUAA instance can lead to authentication failures. It's crucial to confirm that the XSUAA binding used by the SDM plugin has the correct clientid and that your application's XSUAA is configured to trust tokens from IAS.
   • Action & Command:
     1. Check VCAP_SERVICES (runtime config): During runtime, inspect the VCAP_SERVICES environment variable in your application instance. Confirm the clientid and url for both the xsuaa service (used for the SDM binding) and the identity service (IAS binding) are accurate and match what's expected. You can typically do this by SSHing into your application instance or viewing environment variables in the BTP Cockpit.
     2. Verify IAS Trust in BTP Cockpit: Navigate to your BTP Subaccount -> Security -> Trust Configuration. Ensure that your IAS tenant is configured as a trusted identity provider, and that the clientid of the XSUAA instance (if it acts as a client to IAS) is correctly registered or implicitly handled.
     3. Confirm XSUAA Client ID: Double-check the clientid of the XSUAA service instance that the SDM plugin is trying to interact with. This is the clientid that needs to be in the audience claim, and it should match the one added to xs-security.json in step 1.

3. Review mta.yaml for XSUAA & SDM Service Provisioning (Medium Priority):

   • Rationale: The mta.yaml (or equivalent deployment descriptor) defines how your XSUAA service instances are provisioned and bound to your application. An incorrect xs-security.json reference, missing dependencies, or misconfigured parameters in the mta.yaml can lead to an improperly provisioned XSUAA service that does not correctly support the required token exchange flows. Ensuring the XSUAA service is provisioned with the correct xs-security.json and linked correctly to the application and SDM service is vital.
   • Action & Required Change: Inspect the mta.yaml file (or manifest.yml for Cloud Foundry) for your application.
     • Verify xsuaa service definition: Ensure that the xsuaa resource is correctly defined, referencing your xs-security.json.
     • Check application dependencies: Confirm that your application module (app or srv module) has a dependency on both the identity (IAS) binding and the xsuaa service used for SDM.
     • SDM binding details: While the SDM service itself might be provisioned separately, ensure its binding to your application is correct and provides the necessary XSUAA credentials.

   # Example snippet from mta.yaml
   resources:
     - name: my-xsuaa-service  # This is your application's XSUAA instance
       type: org.cloudfoundry.managed-service
       parameters:
         service: xsuaa
         service-plan: application
         path: ./xs-security.json # Ensure this points to the updated xs-security.json
         config:
           xsappname: your-app-name
           tenant-mode: dedicated
           # Other xsuaa configuration if needed
     - name: sdm-xsuaa-binding # XSUAA instance for SDM (if separate or implicitly used by SDM)
       type: org.cloudfoundry.managed-service
       parameters:
         service: xsuaa
         service-plan: application
         # This service instance's clientid is the one from the error message.
         # You might not define this directly if SDM handles its own XSUAA internally,
         # but your application's xsuaa should be configured to recognize its clientid.
         # If SDM requires its own dedicated XSUAA instance to be bound, ensure it's here.
   
   modules:
     - name: your-cap-app
       type: java # or nodejs
       path: srv
       properties:
         # ... other properties ...
       requires:
         - name: my-xsuaa-service # Your app's XSUAA
         - name: sdm-binding      # Binding to the SDM service instance
           properties:
             SDM_URL: ~{sdm-binding/url}
             SDM_UAA_CLIENTID: ~{sdm-binding/uaa/clientid} # Or similar if SDM itself provides XSUAA config
         - name: identity-service # Your IAS binding

---

Risk Assessment
The proposed fixes primarily involve configuration changes. The risk is generally low to medium.

• Low Risk: Verifying service bindings and trust configurations has no direct runtime impact unless changes are made.
• Medium Risk: Modifying xs-security.json or mta.yaml carries a medium risk. Incorrectly adding or removing audiences or misconfiguring service dependencies could lead to new authentication/authorization issues or deployment failures. However, these changes are critical to resolve the current non-functional token exchange. Thorough testing (unit, integration, and end-to-end) in a non-production environment is highly recommended after applying these changes.

Next Step: Reply with confirm remediation to approve moving forward (e.g., drafting a PR or creating task list). Reply with refine analysis for a deeper pass, or discard recommendations to remove them.

[yashmeet29]

Hi @roobyxiao,
Kindly, share the mta.yaml file of your application.

Regards,
Yashmeet

[roobyxiao]

Hi @yashmeet29 we use kyma and we dont have mta.yml, here's our app.yaml and instance
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ template "fullname" . }}
labels:
app: {{ template "name" . }}
chart: {{ .Chart.Name }}
release: {{ .Release.Name }}
heritage: {{ .Release.Service }}
annotations:
eureka/jacocoagent-injection: "true"
# eureka/jacocoagent-injection-for: {{ template "name" . }}
reloader.stakater.com/search: 'true'
secret.reloader.stakater.com/reload: {{ template "fullname" . }}-hana-sm,{{ template "fullname" . }}-redis,{{ template "fullname" . }}-btp-kafka,{{ .Release.Namespace }}-sdm
spec:
replicas: {{ .Values.scaling.minReplicas }}
selector:
matchLabels:
app: {{ template "name" . }}
release: {{ .Release.Name }}
template:
metadata:
labels:
app: {{ template "name" . }}
release: {{ .Release.Name }}
role: web
gitrepo: {{ .Values.eureka.envs.GIT_REPO }}
gitcommit: {{ .Values.eureka.envs.GIT_COMMIT }}
spec:
initContainers:
- name: mtx-sidecar
image: {{ .Values.image.repository }}-charts-mtx:{{ .Values.image.tag }}
restartPolicy: Always
ports:
- name: http
containerPort: 8182
protocol: TCP
env:
- name: SERVICE_BINDING_ROOT
value: /bindings
- name: PORT
value: '8182'
- name: TMPDIR
value: /tmp
- name: APPLICATION_NAME
value: mtx-sidecar
- name: APPLICATION_URI
value: mtx-sidecar
resources:
limits:
ephemeral-storage: 1G
memory: 500M
requests:
cpu: 500m
ephemeral-storage: 1G
memory: 500M
volumeMounts:
- name: service-manager
readOnly: true
mountPath: /bindings/service-manager/
- name: shared-mtx-volume
mountPath: /shared-cap
livenessProbe:
httpGet:
path: /health
port: http
scheme: HTTP
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 6
initialDelaySeconds: 120
readinessProbe:
httpGet:
path: /health
port: http
scheme: HTTP
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
imagePullPolicy: Always
{{- if .Values.slowTest.enabled }}
- name: jacoco
image: eureka-docker-prod.common.repositories.cloud.sap/eureka/jacoco-agent:dev
command: [ "sh", "-c", "cp -r /jacoco/* /copypath/" ]
volumeMounts:
- mountPath: /copypath
name: jacoco-volume
{{- end}}
imagePullSecrets:
- name: image-pull-secret
{{- if .Values.slowTest.enabled }}
- name: regsecret
{{- end}}
# applications
containers:
- name: {{ template "name" . }}
image: {{ index .Values "images" "assortment" }}
env:
- name: SERVICE_BINDING_ROOT
value: /bindings
- name: pod_name
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: application_name
value: {{ template "name" . }}
- name: MY_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: MY_CLUSTER
value: {{ .Values.cluster }}
- name: DOMAIN
value: {{ .Values.nsDomain }}
- name: SPRING_PROFILES_ACTIVE
value: cloud
# ⭐ SDM Repository ID
- name: REPOSITORY_ID
value: {{ .Values.sdm.repositoryId | quote }}
{{- if not .Values.slowTest.enabled }}
- name: malware_url
valueFrom:
secretKeyRef:
name: {{ .Release.Namespace }}-malware-scanner
key: url
optional: false
- name: malware_username
valueFrom:
secretKeyRef:
name: {{ .Release.Namespace }}-malware-scanner
key: username
optional: false
- name: malware_password
valueFrom:
secretKeyRef:
name: {{ .Release.Namespace }}-malware-scanner
key: password
optional: false
{{- end }}
{{range $key,$value:= .Values.env}}
- name: {{$key}}
value: {{$value | quote}}
{{end}}
ports:
- containerPort: {{.Values.service.port}}
resources:
{{ toYaml .Values.resources | indent 10 }}

    livenessProbe:
      httpGet:
        path: /actuator/health
        port: {{.Values.service.port}}
      initialDelaySeconds: 30
      periodSeconds: 10
      successThreshold: 1
      failureThreshold: 100
    readinessProbe:
      httpGet:
        path: /actuator/health
        port: {{.Values.service.port}}
      initialDelaySeconds: 30
      periodSeconds: 10
      successThreshold: 1
      failureThreshold: 100
    volumeMounts:
      - name: internal-auth-secret
        readOnly: true
        mountPath: /etc/secrets/internal-auth
      - name: service-manager
        readOnly: true
        mountPath: /bindings/service-manager/
      - name: auth-secret
        readOnly: true
        mountPath: /bindings/auth
      - name: redis
        mountPath: /etc/secrets/redis
      - name: shared-mtx-volume
        mountPath: /shared-cap
      - name: kafka
        readOnly: true
        mountPath: /bindings/kafka/
      - name: sdm
        readOnly: true
        mountPath: /bindings/sdm/
  volumes:
  - name: internal-auth-secret
    secret:
      secretName: {{ template "fullname" . }}-internal-auth
  - name: redis
    secret:
      secretName: {{ template "fullname" $ }}-redis
  - name: shared-mtx-volume
    emptyDir: { }

{{- if not .Values.slowTest.enabled }}
- name: auth-secret
secret:
secretName: {{ template "authSecretName" $ }}
{{- end }}
- name: service-manager
secret:
secretName: {{ template "fullname" . }}-hana-sm
- name: kafka
secret:
secretName: {{ template "fullname" $ }}-btp-kafka
- name: sdm
secret:
secretName: {{ .Release.Namespace }}-sdm
{{- if .Values.slowTest.enabled }}
- name: jacoco-volume
emptyDir: {}
{{- end }}
{{- if not .Values.slowTest.enabled }}
serviceAccountName: {{ template "fullname" . }}
{{- end }}

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
name: {{ .Release.Namespace }}-sdm
labels:
cci.sap.com/managed-by: mmp-management-biz
spec:
serviceOfferingName: sdm
servicePlanName: standard

apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
name: {{ .Release.Namespace }}-sdm
labels:
cci.sap.com/managed-by: mmp-management-biz
spec:
secretName: {{ .Release.Namespace }}-sdm
serviceInstanceName: {{ .Release.Namespace }}-sdm

[rashmiangadi05]

@roobyxiao
Thanks for the application.yml.
Since you are calling the odata api's
Generate the token as below
If you are using technical token
curl "<authorization_endpoint>" -X POST
-H "Content-Type: application/x-www-form-urlencoded"
-H "Accept: application/json"
-d "client_id="
-d "client_secret=<client_secret>"
-d "grant_type=client_credentials"
-d "resource=urn:sap:identity:application:provider:name:<api_name>"
-d "token_format=jwt"

api_name -> name supplied while creating dependency in ias

Same can be done in postman/bruno client

If you are generating user token
Step1: Get the Assertion Token

curl -X POST "<authorization_endpoint>"
-H "Content-Type: application/x-www-form-urlencoded"
-H "Accept: application/json"
-d "grant_type=password"
-d "username="
-d "password="
-d "client_id=<client_id>"
-d "client_secret=<client_secret>"
-d "scope=openid email profile"

Use the id_token recived from above as value in the below assertion.

Step2 : Get the user token
curl "<authorization_endpoint>" -X POST
-H "Content-Type: application/x-www-form-urlencoded"
-H "Accept: application/json"
-d "client_id"="<client_id>"
-d "client_secret"="<client_secret>" \
-d "grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer"
-d "assertion=<id_token recieved from assertion token>"
-d "resource=urn:sap:identity:application:provider:name:<api_name>"
-d "token_format=jwt"

api_name -> name supplied while creating dependency in ias

Use this token and make odata calls to your application.

We have an IAS application deployed to cloud foundry and I tried the same approach to call odata api's and its working fine.

Let me know if you want to have a call.

Regards,
Rashmi

[roobyxiao]

@rashmiangadi05
Thanks for the reply, may i konw your i number?

[ashishjain14]

Hi @roobyxiao : We will not be able to share i number on public github.

[roobyxiao]

@rashmiangadi05 can i have a look at how you configure sdm dependency in ias?
2 more questions

1. sdm only support cloud foundry?
2. in your case, you fetch the token manually then call the application. In my application, we have to create an appliation in ias, then exchange the id token with this application?

[rashmiangadi05]

@rashmiangadi05 can i have a look at how you configure sdm dependency in ias? 2 more questions

1. sdm only support cloud foundry?
2. in your case, you fetch the token manually then call the application. In my application, we have to create an appliation in ias, then exchange the id token with this application?

We do not add sdm dependency in ias.

1. SDM only supports cloud foundry but I dont think so nothing related to that you are getting 401.
2. Even I have created an IAS application in its mta added sdm dependency as a resource (no dependency in IAS).
   IAS application is deployed to cloud foundry and then I login to my application where my token is used internally and SDM code is invoked.

Below is the mta

_schema-version: 3.3.0
ID: migration_sample
version: 1.0.0-SNAPSHOT
description: "A simple CAP project."
parameters:
enable-parallel-deployments: true
modules:

• name: migration_sample-srv
  type: java
  path: srv
  parameters:
  instances: 1
  buildpack: sap_java_buildpack_jakarta
  routes:
  - route: "${default-url}"
  - route: "${default-host}.cert.${default-domain}"
  properties:
  SPRING_PROFILES_ACTIVE: cloud,sandbox
  JBP_CONFIG_COMPONENTS: "jres: ['com.sap.xs.java.buildpack.jre.SAPMachineJRE']"
  JBP_CONFIG_SAP_MACHINE_JRE: '{ version: 21.+ }'
  AMS_DCL_ROOT: ams/dcl
  CDS_MULTITENANCY_APPUI_TENANTSEPARATOR: "-"
  REPOSITORY_ID: "MIGRATION-REPO-001"
  build-parameters:
  builder: custom
  commands:
  - mvn clean package -DskipTests=true --batch-mode
  build-result: target/*-exec.jar
  provides:

  • name: srv-api # required by consumers of CAP services (e.g. approuter)
    properties:
    srv-url: ${default-url}
    srv-cert-url: '${protocol}://${default-host}.cert.${default-domain}'
    requires:
  • name: migration_sample-ias
    parameters:
    config:
    credential-type: X509_GENERATED
    app-identifier: srv
  • name: migration_sample-db
  • name: sdi-rashmi
  • name: migration_sample-destination
  • name: mtx-api
    properties:
    CDS_MULTITENANCY_SIDECAR_URL: ~{mtx-cert-url}
  • name: migration_sample-sms
  • name: app-api
    properties:
    CDS_MULTITENANCY_APPUI_URL: ~{url}
    deployed-after:
  • migration_sample-ams-policies-deployer

• name: migration_sample
  type: approuter.nodejs
  path: app/router
  requires:

  • name: migration_sample-ias
    parameters:
    config:
    credential-type: X509_GENERATED
    app-identifier: approuter
  • name: srv-api
    group: destinations
    properties:
    url: ~{srv-cert-url}
    forwardAuthCertificates: true
    forwardAuthToken: true
    strictSSL: true
  • name: mtx-api
    group: destinations
    properties:
    name: mtx-api # must be used in xs-app.json as well
    url: ~{mtx-url}

  build-parameters:
  builder: custom
  commands:
  - npm install
  - mkdir -p resources
  - cp -r ../admin-books/webapp resources/admin-books
  - cp -r ../browse/webapp resources/browse
  - cp -r ../appconfig resources/appconfig
  - cp ../index.html ./index.html
  requires:
  - name: migration_sample-srv
  parameters:
  keep-existing-routes: true
  disk-quota: 256M
  memory: 256M
  host: ${space}-dmsmigration
  routes:
  - route: hdm-consumer-1-${default-uri}
  provides:

  • name: app-api
    properties:
    app-protocol: ${protocol}
    app-uri: ${default-uri}
    url: ${default-url}
    properties:
    TENANT_HOST_PATTERN: ^(.*)-${default-uri} # testing only, use custom domain with wildcard for production

• name: migration_sample-ams-policies-deployer
  type: javascript.nodejs
  path: .
  build-parameters:
  builder: custom
  commands:
  - npx cds build --for ams
  build-result: srv/src/gen/policies
  parameters:
  buildpack: nodejs_buildpack
  no-route: true
  no-start: true
  tasks:
  - name: deploy-dcl
  command: npm start
  memory: 512M
  requires:

  • name: migration_sample-ias
    parameters:
    config:
    credential-type: X509_GENERATED
    app-identifier: ams-policy-deployer

• name: migration_sample-mtx
  type: nodejs
  path: mtx/sidecar
  requires:

  • name: migration_sample-ias
    parameters:
    config:
    credential-type: X509_GENERATED
    app-identifier: mtx
  • name: migration_sample-db
  • name: sdi-rashmi
    build-parameters:
    builder: custom
    build-result: gen
    commands:
    • npm run build
      requires:
    • name: migration_sample-srv
      parameters:
      instances: 1
      memory: 256M
      disk-quota: 512M
      routes:
    • route: "${default-url}"
    • route: "${default-host}.cert.${default-domain}"
      provides:
  • name: mtx-api
    properties:
    mtx-url: ${default-url}
    mtx-cert-url: ${protocol}://${default-host}.cert.${default-domain}

resources:

• name: migration_sample-ias
  type: org.cloudfoundry.managed-service
  requires:

  • name: app-api
    parameters:
    service: identity
    service-name: migration_sample-ias
    service-plan: application
    config:
    provided-apis:
    • name: migration_sample-ias-api
      description: API exposed by the application
      display-name: migration_sample
      oauth2-configuration:
      token-policy:
      access-token-format: "jwt"
      redirect-uris:
      • http://localhost:5000/login/callback?authType=ias
      • {app-api/app-protocol}://*{app-api/app-uri}/login/callback
        post-logout-redirect-uris:
      • {app-api/app-protocol}://*{app-api/app-uri}/*/logout.html
        authorization:
        enabled: true
        xsuaa-cross-consumption: true
        multi-tenant: true

• name: sdi-rashmi
  type: org.cloudfoundry.managed-service
  parameters:
  service: sdm-sdmgoogleworkspacedev-rashmicap
  service-plan: standard

• name: migration_sample-db
  type: org.cloudfoundry.managed-service
  parameters:
  service: service-manager
  service-plan: container

• name: migration_sample-destination
  type: org.cloudfoundry.managed-service
  parameters:
  service: destination
  service-plan: lite
  config:
  HTML5Runtime_enabled: true
  init_data:
  instance:
  existing_destinations_policy: update
  destinations: []

• name: migration_sample-sms
  type: org.cloudfoundry.managed-service
  parameters:
  service: subscription-manager
  service-plan: provider
  config:
  applicationType: application
  appName: migration_sample-${org}-${space}
  appCallbacks:
  dependenciesCallbacks:
  url: ~{srv-api/srv-cert-url}/mt/sms/subscriptions/tenants/{app_tid}/dependencies
  subscriptionCallbacks:
  url: ~{srv-api/srv-cert-url}/mt/sms/subscriptions/tenants/{app_tid}
  async:
  subscribeEnable: true
  unSubscribeEnable: true
  timeoutInMillis: 300000 # Increase if your deployments are taking longer than that
  displayName: Rashmi Migration App
  description: Rashmi Migration App
  category: "Application Development and Automation"
  iasServiceInstanceName: migration_sample-ias
  requires:

  • name: srv-api
    processed-after:
  • migration_sample-ias

If still you face issue. Kindly create SNOW incident BC-CP-CF-SDM-CLT is the component.

Regards,
Rashmi

[yashmeet29]

Hi @roobyxiao,
We will track this with SNOW ticket that is created for this issue, so closing this.

Regards,
Yashmeet