Applying ‘Techncial User Propagation’ to API Management

1. Introduction:

In the previous blog, we explored how technical user propagation works in SAP Integration Suite / Cloud Integration using the OData V2, SOAP, and HTTP receiver adapters. In this installment, we turn our attention to API Management, where the on-premise proxy component plays a crucial role in securely bridging cloud-hosted APIs with on-premise systems. Much like Cloud Integration, the question of propagating a fixed technical identity comes up frequently here — but the mechanisms and configuration steps differ.

2. Quick recap on on-premise connectivity in API Management:

Before diving deeper, let’s briefly review how API Management handles connectivity to on-premise systems. Within the API Provider settings, API Management supports the concept of Principal Propagation. This means that when a request is forwarded to an on-premise system, the expectation is that a valid user session (or principal) already exists — typically established via mechanisms such as SSO / token exchange.

Under the hood, the On-premise proxy component in API Management uses the BTP Destination as the connectivity anchor. The authenticated user session is propagated to this destination, which in turn leverages the Cloud Connector to securely tunnel the call into the corporate network. Finally, at the backend system level, the X.509 certificate mechanism comes into play, mapping the propagated principal to the appropriate backend user. We described this process in our previous blog.

3. Concrete example – Entra ID & token exchange:

In practice, many customers authenticate users against Identity Provider systems such as Entra ID (formerly Azure AD). In this flow, Entra ID issues a JWT token where the user subject (often the user’s email ID) is included as a claim. This JWT is then presented to API Management, which, after an optional verification step, in turn exchanges it with XSUAA using the OAuth2 SAML Assertion flow. The result is an XSUAA-issued token that the on-premise proxy component in API Management can securely propagate downstream. This pattern is widely adopted and serves as the backbone of many user-centric API Management scenarios.

Note: There are many excellent SAP Community blogs that go into great detail about this token handshake and its variants. To keep our focus sharp, we won’t recap those here — instead, we’ll stay aligned with the specific objective of this blog: exploring how technical user propagation scenarios can be addressed in API Management’s On-Premise proxy component.

4. From user sessions to technical credentials:

While the model described above works seamlessly for user-centric flows, many integration patterns require a fixed technical credential instead. This is where customers start looking for approaches similar to the one we highlighted in Cloud Integration, where technical user propagation can be achieved by leveraging the ‘SAP-Connectivity-Technical-Authentication‘ header. With API Management’s on-premise proxy component, patterns are available to achieve secure technical identity propagation, which differ slightly from the one we highlighted for Cloud Integration.

5. Usage scenarios with API Management:

To make this blog post engaging, we would like to introduce multiple patterns of usage, since there is no single “gold standard” for implementing authentication in API Management. The right choice depends on the system landscape, security requirements, and integration goals. Below, we outline a few practical scenarios that illustrate different approaches. You are free to adjust the scenario based on your security needs:

1. JWT Bearer Token injection (Client credentials authentication):

In this scenario, the client is responsible for obtaining an access token itself. This typically involves the client exchanging its client credentials of API Management’s on-premise proxy component for a JWT access token and presenting it as part of the API call. API Management then processes this token and propagates the corresponding identity further downstream through the destination, Cloud Connector, and finally to the backend.

Note: While this approach is relatively straightforward, it places the responsibility of managing OAuth credentials and tokens directly on the client. Therefore, it should not be relied upon as the sole security mechanism. It is strongly recommended to validate the JWT on the API Management layer (or downstream) and ensure that it contains the expected claims (such as issuer, audience, scope, or custom claims like the target client_id) before granting access. This ensures that the token has not only been issued by BTP’s XSUAA but also carries the correct authorization context for your APIs.

Pre-requisite(s):

Make sure that you have created a service instance of the ‘API Management, API portal’ service with the ‘on-premise-connectivity’ service plan.

2. API Key injection (Credential abstraction for clients):

In this setup, the client application supplies an API Key when calling API Management in addition to any other security mechanism. Behind the scenes, the API Proxy is configured to exchange fixed technical credentials with the Identity Provider (BTP XSUAA) to obtain an access token. This approach helps ensure that the sensitive technical credentials — the ones that need to be propagated — remain hidden from the client, thereby strengthening security.

To make matters more interesting, in our walkthrough, we will not rely on a basic client credentials grant type. Instead, we will demonstrate a certificate-based token exchange, where API Management presents a client certificate to XSUAA (via OAuth2 with mutual TLS) to obtain the token. This pattern is increasingly popular in enterprise landscapes because it provides stronger binding between client identity and issued tokens (RFC 8705), without ever exposing the client secret, while still abstracting the complexity from the consuming client.

Pre-requisite(s):

a) Ensure that the Developer Hub is enabled and that you can create product subscriptions.

b) Ensure you have a service key enabled for X.509 certificate authentication. Copy the generated client_id. You can follow this guide to set it up, and then refer to step 3.3 in our previous article to create a PFX/P12 file that bundles the certificate and key together.

c) Ensure that the PFX file is uploaded to a keystore from the ‘Certificates’ section.

3. Client Certificate-based Authentication:

In this scenario, the consuming client application presents an external client certificate directly to the API Management runtime when invoking an API. The API Management host validates the certificate against its trust store and, based on pre-configured certificate-to-credential mapping, resolves the call to a fixed technical credential.

This design is particularly useful in system-to-system integrations where client identities are represented by certificates instead of (/in addition to) tokens or API Keys, as the certificate itself acts as the authentication factor. Internally, the mapped technical user is then propagated through to the BTP Destination, Cloud Connector, and ultimately to the backend system using the same mechanisms as in the earlier scenarios.

Note: This approach is especially appealing when clients cannot (or should not) handle OAuth flows, but are capable of securely storing and presenting a client certificate. However, it requires careful lifecycle management of certificates (renewal, rotation, and trust configuration) to ensure uninterrupted connectivity.

Pre-requisite(s):

Make sure you are configured for certificate-based authentication. You can then manage your clients’ certificate chains in the Trust Store as a convenient self-service feature. Ensure you can read the ‘ConnectionProperties‘ and ‘ClientProperties‘ property variables. You will need to create an operations ticket to do so.

Let’s examine each of these scenarios in detail. Please note that this is not a step-by-step guide; rather, we will focus on highlighting only the key steps.

6. Scenario#1 (Client credentials Authentication) – API Provider and Proxy configurations:

Let’s review the essential API Provider and Proxy configurations required to enable propagation of the ‘SAP-Connectivity-Technical-Authentication’ header.

1. Create an Extract Variable policy like so (typically on the ‘PreFlow’ step) to extract the JWT token from the Authorization request and store it in a variable to be referenced later.

2. After this step, use a Verify JWT policy to verify the signatures on the JWT as well as any standard and custom claims. Follow this blog series to learn more about JWT verification capabilities.

<!– Verify JWT TOken –>
<VerifyJWT async=”false” continueOnError=”false” enabled=”true” xmlns=”http://www.sap.com/apimgmt”>
<Algorithm>RS256</Algorithm>
<Source>sapapim.jwt</Source>
<PublicKey>
<Value ref=”jwt.publickey”/>
</PublicKey>
<Subject ref=”apim.subject”/>
<Issuer ref=”apim.issuer”/>
<Audience ref=”apim.issuer”/>
<AdditionalClaims>
</AdditionalClaims>
</VerifyJWT>

3. Next, create an AssignMessage policy like so to inject the ‘SAP-Connectivity-Technical-Authentication‘ header with the variable captured from the previous step, and make sure to remove the ‘Authorization‘ header.

<!– This policy can be used to create or modify the standard HTTP request and response messages –>
<AssignMessage async=”false” continueOnError=”false” enabled=”true” xmlns=’http://www.sap.com/apimgmt’>
<Remove>
<Headers>
<Header name=”Authorization”></Header>
</Headers>
</Remove>
<Set>
<Headers>
<Header name=”SAP-Connectivity-Technical-Authentication”>Bearer {sapapim.accessToken}</Header>
</Headers>
</Set>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
<AssignTo createNew=”false” type=”request”>request</AssignTo>
</AssignMessage>

4. Finally, ensure that the API Provider’s authentication setting is configured as None rather than Principal Propagation. This is the very configuration we applied for the SOAP Adapter scenario discussed in the previous blog post.

5. Let’s get down to testing now. The first step would be to get an access token from the authorization server’s (XSUAA) token endpoint.

curl –location –request POST ‘https://<subdomain>.authentication.<region>.hana.ondemand.com/oauth/token’
–header ‘Content-Type: application/x-www-form-urlencoded’
–user ‘<client_id>:<client_secret>’
–data-urlencode ‘grant_type=client_credentials’

6. Copy the access token from the result of the call above and invoke the API Proxy by presenting the Bearer token in the Authorization header.

curl –location –request GET ‘https://<apim_base_url>/<your_api_path>’
–header “Authorization: Bearer <access_token>”

✅ Assuming that the rest of your configurations are intact, the call should complete successfully and return the expected backend records.

7. To validate the token handshake and X.509 certificate generation, refer to the verification steps detailed in Step 4.1 in our linked blog post.

7. Scenario#2 (APIKey injection) – Proxy configuration:

In this scenario, the client credentials will not be exposed directly to the client. Instead, we inject the required client_id as a custom attribute within the Product Subscription. During runtime, this identifier is dynamically retrieved via a policy and used to obtain an access token from the authorization server

1. Log in to your Developer Hub, create a product subscription for your target API. Navigate to the Custom Attribute tab and create an attribute called ‘x_client_id’ and place the client_id copied from step 2.b. as the Value.

2. You may choose to follow the same workflow demonstrated in Scenario 1. In addition, an important step is to configure the Verify API Key policy, for example, in the PreFlow segment.

<!–Specify in the APIKey element where to look for the variable containing the api key–>
<VerifyAPIKey async=’true’ continueOnError=’false’ enabled=’true’
xmlns=’http://www.sap.com/apimgmt’>
<APIKey ref=’request.header.apikey’/>
</VerifyAPIKey>

3. Next, add an AccessEntity policy to get hold of a reference to the ‘application’s’ attributes.

<!– this policy can be used to retrieve all details of an entity(application, API Product, company, company developer, consumer key and developer) –>
<AccessEntity async=”true” continueOnError=”false” enabled=”true” xmlns=’http://www.sap.com/apimgmt’>
<!– the name of the type of entity to be retrieved –>
<EntityType value=”app”/>
<!– The value that identifies the specific entity whose profile should be retrieved. The ref attribute identifies the variable that provides the source of the identifier.
The type identifies the EntityType populated by the referenced variable –>
<EntityIdentifier ref=”request.header.apikey” type=”consumerkey”/>
</AccessEntity>

4. Then add an ExtractVariable policy to parse and extract the value of the custom attribute defined in the previous step.

<!– Extract content from the request or response messages, including headers, URI paths, JSON/XML payloads, form parameters, and query parameters –>
<ExtractVariables async=”true” continueOnError=”false” enabled=”true” xmlns=’http://www.sap.com/apimgmt’>
<!– the source variable which should be parsed –>
<Source>AccessEntity.name-of-the-AccessEntity-policy-here</Source>
<!– Specifies the XML-formatted message from which the value of the variable will be extracted –>
<XMLPayload>
<!– Specifies variable to which the extracted value will be assigned –>
<Variable name=”x-client-id” type=”string”>
<!– Specifies the XPath defined for the variable –>
<XPath>/App/Attributes/Attribute[Name=’x_client_id’]/Value/text()</XPath>
</Variable>
</XMLPayload>
</ExtractVariables>

5. After this step, we add a small script to construct the URL-encoded form payload in preparation for the token retrieval step. Notice that we have not used the client secret attribute at all.

function getFormElement(name,value){
return name + “=” + encodeURIComponent(value);
}

function createOAuthRequest(){
return getFormElement(“grant_type”,”client_credentials”)
+ “&” + getFormElement(“client_id”, context.getVariable(“x-client-id”)) ;
}

context.setVariable(“sapapim.tokenRequest”, createOAuthRequest());

6. We will follow this up with a ServiceCallout policy to make a POST request to the ‘.cert…‘ token endpoint. Notice that we are attaching the certificate of the service key retrieved in step 2.c. by referencing it from the keystore.

<ServiceCallout async=”false” continueOnError=”false” enabled=”true” xmlns=”http://www.sap.com/apimgmt”>
<Request clearPayload=”true”>
<Set>
<Payload contentType=”application/x-www-form-urlencoded”>{sapapim.tokenRequest}</Payload>
<Verb>POST</Verb>
</Set>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</Request>
<Response>sapapim.tokenResponse</Response>
<Timeout>30000</Timeout>
<HTTPTargetConnection>
<URL>https://<tenant-dentifier>.authentication.cert.<region>.hana.ondemand.com/oauth/token</URL>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>true</ClientAuthEnabled>
<KeyStore>KEYSTORE-NAME-GOES-HERE</KeyStore>
<KeyAlias>CERTIFICATE-NAME-GOES-HERE</KeyAlias>
</SSLInfo>
</HTTPTargetConnection>
</ServiceCallout>

7. Finally, retrieve the access token and attach it to the SAP-Connectivity-Technical-Authentication header, as demonstrated in step 3 of scenario 1.

8. To test this setup, modify the curl command from scenario 1 to add the APIKey header attribute, like so:

curl –location –request GET ‘https://<apim_base_url>/<your_api_path>’
–header “APIKey: <your_api_key>”

8. Scenario#3 (Client certificate-based authentication) – Proxy configuration:

The critical security step in this scenario is that the client presents its certificate, which API Management validates against the trusted certificates stored in its Trust Store. This validation ensures that only clients with a recognized and trusted certificate can establish communication, thereby guaranteeing both authenticity and trust in the interaction.

When the ‘ConnectionProperties’ and ‘ClientProperties’ attributes are enabled, as described in the prerequisites section, you can also access key certificate details such as the Issuer DN and Client CN. For this scenario, we assume that the API Administrator maintains an access control list mapping a predefined set of certificate Common Names to unique client_ids. This ensures that the technical identifier is propagated only when a matching client certificate is presented.

Let’s set this up.

1. Create a Key Value Map and maintain a table mapping the common name of the client to the designated client_id.

2. Construct a KeyValueMapOperations policy that dynamically retrieves the ‘tls.client.s.dn’ property from the presented certificate, looks up the Key Value Map created in the above step, and assigns the value of the client_id to a variable called ‘x_client_id’.

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<KeyValueMapOperations mapIdentifier=”TechnicalAuthenticationMap” async=”false” continueOnError=”false” enabled=”false” xmlns=”http://www.sap.com/apimgmt”>
<Get assignTo=”x_client_id” index=”1″>
<Key>
<Parameter ref =”tls.client.s.dn”/>
</Key>
</Get>
<Scope>environment</Scope>
</KeyValueMapOperations>

3. Repeat steps 5, 6, and 7 from Scenario 2 to generate an access token and assign it to the target header.

4. To test the invocation, adjust the curl command to pass the client certificate

curl –location –request GET ‘https://<apim_base_url>/<your_api_path>’
–header “Authorization: Bearer <access_token>”
–header “APIKey: <your_api_key>”
–cert <path_to_certificate>.pfx –cert-type P12 –pass <pfx_password>

👏Congratulations on getting this far!

9. Summary:

The three API Management scenarios illustrate different approaches for technical user propagation using the SAP-Connectivity-Technical-Authentication header. In the first approach, the client directly provides credentials to obtain an access token, exposing sensitive information. The second approach leverages API Management to propagate technical credentials internally, keeping them hidden from the client and simplifying integration. The third approach uses mutual TLS and X.509 certificates to securely propagate the technical user identity from API Management through the API Provider to the backend system, ensuring end-to-end authentication without exposing internal credentials.

1. Introduction:In the previous blog, we explored how technical user propagation works in SAP Integration Suite / Cloud Integration using the OData V2, SOAP, and HTTP receiver adapters. In this installment, we turn our attention to API Management, where the on-premise proxy component plays a crucial role in securely bridging cloud-hosted APIs with on-premise systems. Much like Cloud Integration, the question of propagating a fixed technical identity comes up frequently here — but the mechanisms and configuration steps differ.2. Quick recap on on-premise connectivity in API Management:Before diving deeper, let’s briefly review how API Management handles connectivity to on-premise systems. Within the API Provider settings, API Management supports the concept of Principal Propagation. This means that when a request is forwarded to an on-premise system, the expectation is that a valid user session (or principal) already exists — typically established via mechanisms such as SSO / token exchange.Under the hood, the On-premise proxy component in API Management uses the BTP Destination as the connectivity anchor. The authenticated user session is propagated to this destination, which in turn leverages the Cloud Connector to securely tunnel the call into the corporate network. Finally, at the backend system level, the X.509 certificate mechanism comes into play, mapping the propagated principal to the appropriate backend user. We described this process in our previous blog.3. Concrete example – Entra ID & token exchange:In practice, many customers authenticate users against Identity Provider systems such as Entra ID (formerly Azure AD). In this flow, Entra ID issues a JWT token where the user subject (often the user’s email ID) is included as a claim. This JWT is then presented to API Management, which, after an optional verification step, in turn exchanges it with XSUAA using the OAuth2 SAML Assertion flow. The result is an XSUAA-issued token that the on-premise proxy component in API Management can securely propagate downstream. This pattern is widely adopted and serves as the backbone of many user-centric API Management scenarios.Note: There are many excellent SAP Community blogs that go into great detail about this token handshake and its variants. To keep our focus sharp, we won’t recap those here — instead, we’ll stay aligned with the specific objective of this blog: exploring how technical user propagation scenarios can be addressed in API Management’s On-Premise proxy component.4. From user sessions to technical credentials:While the model described above works seamlessly for user-centric flows, many integration patterns require a fixed technical credential instead. This is where customers start looking for approaches similar to the one we highlighted in Cloud Integration, where technical user propagation can be achieved by leveraging the ‘SAP-Connectivity-Technical-Authentication’ header. With API Management’s on-premise proxy component, patterns are available to achieve secure technical identity propagation, which differ slightly from the one we highlighted for Cloud Integration.5. Usage scenarios with API Management:To make this blog post engaging, we would like to introduce multiple patterns of usage, since there is no single “gold standard” for implementing authentication in API Management. The right choice depends on the system landscape, security requirements, and integration goals. Below, we outline a few practical scenarios that illustrate different approaches. You are free to adjust the scenario based on your security needs:1. JWT Bearer Token injection (Client credentials authentication):In this scenario, the client is responsible for obtaining an access token itself. This typically involves the client exchanging its client credentials of API Management’s on-premise proxy component for a JWT access token and presenting it as part of the API call. API Management then processes this token and propagates the corresponding identity further downstream through the destination, Cloud Connector, and finally to the backend.Note: While this approach is relatively straightforward, it places the responsibility of managing OAuth credentials and tokens directly on the client. Therefore, it should not be relied upon as the sole security mechanism. It is strongly recommended to validate the JWT on the API Management layer (or downstream) and ensure that it contains the expected claims (such as issuer, audience, scope, or custom claims like the target client_id) before granting access. This ensures that the token has not only been issued by BTP’s XSUAA but also carries the correct authorization context for your APIs.Pre-requisite(s):Make sure that you have created a service instance of the ‘API Management, API portal’ service with the ‘on-premise-connectivity’ service plan.2. API Key injection (Credential abstraction for clients):In this setup, the client application supplies an API Key when calling API Management in addition to any other security mechanism. Behind the scenes, the API Proxy is configured to exchange fixed technical credentials with the Identity Provider (BTP XSUAA) to obtain an access token. This approach helps ensure that the sensitive technical credentials — the ones that need to be propagated — remain hidden from the client, thereby strengthening security.To make matters more interesting, in our walkthrough, we will not rely on a basic client credentials grant type. Instead, we will demonstrate a certificate-based token exchange, where API Management presents a client certificate to XSUAA (via OAuth2 with mutual TLS) to obtain the token. This pattern is increasingly popular in enterprise landscapes because it provides stronger binding between client identity and issued tokens (RFC 8705), without ever exposing the client secret, while still abstracting the complexity from the consuming client.Pre-requisite(s):a) Ensure that the Developer Hub is enabled and that you can create product subscriptions.b) Ensure you have a service key enabled for X.509 certificate authentication. Copy the generated client_id. You can follow this guide to set it up, and then refer to step 3.3 in our previous article to create a PFX/P12 file that bundles the certificate and key together.c) Ensure that the PFX file is uploaded to a keystore from the ‘Certificates’ section.3. Client Certificate-based Authentication:In this scenario, the consuming client application presents an external client certificate directly to the API Management runtime when invoking an API. The API Management host validates the certificate against its trust store and, based on pre-configured certificate-to-credential mapping, resolves the call to a fixed technical credential.This design is particularly useful in system-to-system integrations where client identities are represented by certificates instead of (/in addition to) tokens or API Keys, as the certificate itself acts as the authentication factor. Internally, the mapped technical user is then propagated through to the BTP Destination, Cloud Connector, and ultimately to the backend system using the same mechanisms as in the earlier scenarios.Note: This approach is especially appealing when clients cannot (or should not) handle OAuth flows, but are capable of securely storing and presenting a client certificate. However, it requires careful lifecycle management of certificates (renewal, rotation, and trust configuration) to ensure uninterrupted connectivity.Pre-requisite(s):Make sure you are configured for certificate-based authentication. You can then manage your clients’ certificate chains in the Trust Store as a convenient self-service feature. Ensure you can read the ‘ConnectionProperties’ and ‘ClientProperties’ property variables. You will need to create an operations ticket to do so. Let’s examine each of these scenarios in detail. Please note that this is not a step-by-step guide; rather, we will focus on highlighting only the key steps.6. Scenario#1 (Client credentials Authentication) – API Provider and Proxy configurations:Let’s review the essential API Provider and Proxy configurations required to enable propagation of the ‘SAP-Connectivity-Technical-Authentication’ header.1. Create an Extract Variable policy like so (typically on the ‘PreFlow’ step) to extract the JWT token from the Authorization request and store it in a variable to be referenced later.<!– Extract content from the request or response messages, including headers, URI paths, JSON/XML payloads, form parameters, and query parameters –>
<ExtractVariables async=”true” continueOnError=”false” enabled=”false” xmlns=’http://www.sap.com/apimgmt’>
<Header name=”Authorization”>
<Pattern ignoreCase=”true”>Bearer {sapapim.jwt}</Pattern>
</Header>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
<Source>request</Source>
</ExtractVariables>2. After this step, use a Verify JWT policy to verify the signatures on the JWT as well as any standard and custom claims. Follow this blog series to learn more about JWT verification capabilities.<!– Verify JWT TOken –>
<VerifyJWT async=”false” continueOnError=”false” enabled=”true” xmlns=”http://www.sap.com/apimgmt”>
<Algorithm>RS256</Algorithm>
<Source>sapapim.jwt</Source>
<PublicKey>
<Value ref=”jwt.publickey”/>
</PublicKey>
<Subject ref=”apim.subject”/>
<Issuer ref=”apim.issuer”/>
<Audience ref=”apim.issuer”/>
<AdditionalClaims>
</AdditionalClaims>
</VerifyJWT>3. Next, create an AssignMessage policy like so to inject the ‘SAP-Connectivity-Technical-Authentication’ header with the variable captured from the previous step, and make sure to remove the ‘Authorization’ header.<!– This policy can be used to create or modify the standard HTTP request and response messages –>
<AssignMessage async=”false” continueOnError=”false” enabled=”true” xmlns=’http://www.sap.com/apimgmt’>
<Remove>
<Headers>
<Header name=”Authorization”></Header>
</Headers>
</Remove>
<Set>
<Headers>
<Header name=”SAP-Connectivity-Technical-Authentication”>Bearer {sapapim.accessToken}</Header>
</Headers>
</Set>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
<AssignTo createNew=”false” type=”request”>request</AssignTo>
</AssignMessage> 4. Finally, ensure that the API Provider’s authentication setting is configured as None rather than Principal Propagation. This is the very configuration we applied for the SOAP Adapter scenario discussed in the previous blog post.5. Let’s get down to testing now. The first step would be to get an access token from the authorization server’s (XSUAA) token endpoint.curl –location –request POST ‘https://<subdomain>.authentication.<region>.hana.ondemand.com/oauth/token’
–header ‘Content-Type: application/x-www-form-urlencoded’
–user ‘<client_id>:<client_secret>’
–data-urlencode ‘grant_type=client_credentials’6. Copy the access token from the result of the call above and invoke the API Proxy by presenting the Bearer token in the Authorization header.curl –location –request GET ‘https://<apim_base_url>/<your_api_path>’
–header “Authorization: Bearer <access_token>”✅ Assuming that the rest of your configurations are intact, the call should complete successfully and return the expected backend records.7. To validate the token handshake and X.509 certificate generation, refer to the verification steps detailed in Step 4.1 in our linked blog post.7. Scenario#2 (APIKey injection) – Proxy configuration:In this scenario, the client credentials will not be exposed directly to the client. Instead, we inject the required client_id as a custom attribute within the Product Subscription. During runtime, this identifier is dynamically retrieved via a policy and used to obtain an access token from the authorization server1. Log in to your Developer Hub, create a product subscription for your target API. Navigate to the Custom Attribute tab and create an attribute called ‘x_client_id’ and place the client_id copied from step 2.b. as the Value. 2. You may choose to follow the same workflow demonstrated in Scenario 1. In addition, an important step is to configure the Verify API Key policy, for example, in the PreFlow segment. <!–Specify in the APIKey element where to look for the variable containing the api key–>
<VerifyAPIKey async=’true’ continueOnError=’false’ enabled=’true’
xmlns=’http://www.sap.com/apimgmt’>
<APIKey ref=’request.header.apikey’/>
</VerifyAPIKey>3. Next, add an AccessEntity policy to get hold of a reference to the ‘application’s’ attributes.<!– this policy can be used to retrieve all details of an entity(application, API Product, company, company developer, consumer key and developer) –>
<AccessEntity async=”true” continueOnError=”false” enabled=”true” xmlns=’http://www.sap.com/apimgmt’>
<!– the name of the type of entity to be retrieved –>
<EntityType value=”app”/>
<!– The value that identifies the specific entity whose profile should be retrieved. The ref attribute identifies the variable that provides the source of the identifier.
The type identifies the EntityType populated by the referenced variable –>
<EntityIdentifier ref=”request.header.apikey” type=”consumerkey”/>
</AccessEntity>4. Then add an ExtractVariable policy to parse and extract the value of the custom attribute defined in the previous step.<!– Extract content from the request or response messages, including headers, URI paths, JSON/XML payloads, form parameters, and query parameters –>
<ExtractVariables async=”true” continueOnError=”false” enabled=”true” xmlns=’http://www.sap.com/apimgmt’>
<!– the source variable which should be parsed –>
<Source>AccessEntity.name-of-the-AccessEntity-policy-here</Source>
<!– Specifies the XML-formatted message from which the value of the variable will be extracted –>
<XMLPayload>
<!– Specifies variable to which the extracted value will be assigned –>
<Variable name=”x-client-id” type=”string”>
<!– Specifies the XPath defined for the variable –>
<XPath>/App/Attributes/Attribute[Name=’x_client_id’]/Value/text()</XPath>
</Variable>
</XMLPayload>
</ExtractVariables>5. After this step, we add a small script to construct the URL-encoded form payload in preparation for the token retrieval step. Notice that we have not used the client secret attribute at all. function getFormElement(name,value){
return name + “=” + encodeURIComponent(value);
}

function createOAuthRequest(){
return getFormElement(“grant_type”,”client_credentials”)
+ “&” + getFormElement(“client_id”, context.getVariable(“x-client-id”)) ;
}

context.setVariable(“sapapim.tokenRequest”, createOAuthRequest());6. We will follow this up with a ServiceCallout policy to make a POST request to the ‘.cert…’ token endpoint. Notice that we are attaching the certificate of the service key retrieved in step 2.c. by referencing it from the keystore.<ServiceCallout async=”false” continueOnError=”false” enabled=”true” xmlns=”http://www.sap.com/apimgmt”>
<Request clearPayload=”true”>
<Set>
<Payload contentType=”application/x-www-form-urlencoded”>{sapapim.tokenRequest}</Payload>
<Verb>POST</Verb>
</Set>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</Request>
<Response>sapapim.tokenResponse</Response>
<Timeout>30000</Timeout>
<HTTPTargetConnection>
<URL>https://<tenant-dentifier>.authentication.cert.<region>.hana.ondemand.com/oauth/token</URL>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>true</ClientAuthEnabled>
<KeyStore>KEYSTORE-NAME-GOES-HERE</KeyStore>
<KeyAlias>CERTIFICATE-NAME-GOES-HERE</KeyAlias>
</SSLInfo>
</HTTPTargetConnection>
</ServiceCallout>7. Finally, retrieve the access token and attach it to the SAP-Connectivity-Technical-Authentication header, as demonstrated in step 3 of scenario 1.8. To test this setup, modify the curl command from scenario 1 to add the APIKey header attribute, like so:curl –location –request GET ‘https://<apim_base_url>/<your_api_path>’
–header “APIKey: <your_api_key>”8. Scenario#3 (Client certificate-based authentication) – Proxy configuration:The critical security step in this scenario is that the client presents its certificate, which API Management validates against the trusted certificates stored in its Trust Store. This validation ensures that only clients with a recognized and trusted certificate can establish communication, thereby guaranteeing both authenticity and trust in the interaction.When the ‘ConnectionProperties’ and ‘ClientProperties’ attributes are enabled, as described in the prerequisites section, you can also access key certificate details such as the Issuer DN and Client CN. For this scenario, we assume that the API Administrator maintains an access control list mapping a predefined set of certificate Common Names to unique client_ids. This ensures that the technical identifier is propagated only when a matching client certificate is presented. Let’s set this up.1. Create a Key Value Map and maintain a table mapping the common name of the client to the designated client_id. 2. Construct a KeyValueMapOperations policy that dynamically retrieves the ‘tls.client.s.dn’ property from the presented certificate, looks up the Key Value Map created in the above step, and assigns the value of the client_id to a variable called ‘x_client_id’. <?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<KeyValueMapOperations mapIdentifier=”TechnicalAuthenticationMap” async=”false” continueOnError=”false” enabled=”false” xmlns=”http://www.sap.com/apimgmt”>
<Get assignTo=”x_client_id” index=”1″>
<Key>
<Parameter ref =”tls.client.s.dn”/>
</Key>
</Get>
<Scope>environment</Scope>
</KeyValueMapOperations>3. Repeat steps 5, 6, and 7 from Scenario 2 to generate an access token and assign it to the target header.4. To test the invocation, adjust the curl command to pass the client certificatecurl –location –request GET ‘https://<apim_base_url>/<your_api_path>’
–header “Authorization: Bearer <access_token>”
–header “APIKey: <your_api_key>”
–cert <path_to_certificate>.pfx –cert-type P12 –pass <pfx_password>👏Congratulations on getting this far!9. Summary:The three API Management scenarios illustrate different approaches for technical user propagation using the SAP-Connectivity-Technical-Authentication header. In the first approach, the client directly provides credentials to obtain an access token, exposing sensitive information. The second approach leverages API Management to propagate technical credentials internally, keeping them hidden from the client and simplifying integration. The third approach uses mutual TLS and X.509 certificates to securely propagate the technical user identity from API Management through the API Provider to the backend system, ensuring end-to-end authentication without exposing internal credentials. Read More Technology Blog Posts by SAP articles