Support for SAP-Connectivity-Technical-Authentication header

[gregorwolf]

Is your feature request related to a problem? Please describe.

The release 2.15.0 of SAP Cloud connector adds a new Authentication Type - Technical User Propagation. It can be used by setting the HTTP Header SAP-Connectivity-Technical-Authentication instead of the SAP-Connectivity-Authentication header which is already supported in the SAP Cloud SDK.

Describe the solution you'd like

Provide a possibility to decide on a by request level if either SAP-Connectivity-Technical-Authentication or SAP-Connectivity-Authentication should be sent.

Impact / Priority

Affected development phase: Production

Impact: Inconvenience

Additional context

Getting support for the Technical User Propagation would allow us to get rid of destinations using basic authentication which we currently need to use when our CAP endpoint is called by the Job Scheduling service.

[newtork]

Provide a possibility to decide on a by request level if either SAP-Connectivity-Technical-Authentication or SAP-Connectivity-Authentication should be sent.

How would you differentiate when to use one over the other? What information would need to be present at runtime?
Where is the technical user token coming from at runtime?

[FrankEssenberger]

One way would be that the destination service offers something as a sub-option when PrincipalPropagation is chosen. However, as long this is not there I also do not see a good way. I would not like to use some destination property for that. I will reach out to the destination service colleagues.

[manolvalchev]

This feature is being released in a step-wise approach. First in cloud connector, then in Destination service, etc. Kindly be patient, and stay tuned watching the What's New for SAP Business Technology Platform - Connectivity

[gregorwolf]

Thank you @manolvalchev is the rollout also in some roadmap?

[FrankEssenberger]

Once we have the feature available on our internal cloud foundry and destination service instance we will start the implementation from the SDK side.

[manolvalchev]

Thank you @manolvalchev is the rollout also in some roadmap?

@gregorwolf, not yet - perhaps in future

[gregorwolf]

The blog post Technical User Propagation – SAP BTP To S4 On Premise provides now an example on how:

• the access_token is retrieved using the connectivity credentials from the XSUAA Token endpoint
• this token is added to the backend request

What is the status regarding the destination configuration?

[manolvalchev]

@gregorwolf , as for modelling/managing a destination configuration of that auth type, it's already rolled out: check the official docu.

[FrankEssenberger]

Then I will remove the blocked label and increase priority in our backlog for this ticket so that we will support this also from the SDK side.

[Showkath]

Hi @FrankEssenberger , @jjtang1985 ,

As reported by @gregorwolf, I would like to add my votes for this issue.Need support for Technical User Propagation. Eliminating basic authentication and hard-coded credentials is crucial for enhancing security, especially when interacting with SAP Backend Onpremise systems. This feature complements overall security practices, and its implementation is vital for our project. Your prioritization would greatly expedite progress.

Thanks,
Showkath.

[sebastianesch]

Hi @FrankEssenberger,

are there any updates regarding the timeline for this feature?

Kind regards,
Sebastian

[sebastianesch]

I'm able to get this to work with the SAP Cloud SDK via a workaround. After fetching a Destination of Type PrincipalPropagation I can modify the destination and add the headers in a call via executeHttpRequestWithOrigin.

But it would be much more convenient, if SAP Cloud SDK would use the Destination Type OAuth2TechnicalUserPropagation to do this in the background instead.

Example from a CAP Action Handler:

const destination = await getDestination({ destinationName: 'S4_PP', jwt: request.user.tokenInfo.jwt })

// modify destination fetched from subaccount
destination.authentication = 'NoAuthentication'
delete destination.proxyConfiguration.headers['SAP-Connectivity-Authentication']

const bupaServiceResult = await executeHttpRequestWithOrigin(
    destination,
    {
        method: 'GET',
        url: bupaService.path + `/A_BusinessPartner('${request.data.BusinessPartner}')?$select=BusinessPartner,Customer,Supplier,BusinessPartnerCategory,BusinessPartnerName`,
        headers: { 
            // Use executeHttpRequestWithOrigin to add custom headers to HTTP request that overwrite defaults
            custom: {
                'SAP-Connectivity-Technical-Authentication': `Bearer ${request.user.tokenInfo.jwt}`
            }
        }
    },
    {
        fetchCsrfToken: false
    }
)

Edit: The Proxy-Authorization Header returned by the destination service can be used. You just have to remove the SAP-Connectivity-Authentication header and add the SAP-Connectivity-Technical-Authentication header.