API Management Principal Propagation for BizHub Enterprise Application User to OData API Provider

[Bryan_Pierce1]

** * Updated Question ***

Here is an updated description of the scenario we are trying to find a solution for:

What is required (how) to allow users registered with API Management to call an API Proxy that uses an API Provider for an OData service in an ECC backend that propagates the user to the ECC system? No Cloud Integration involved. There is no existing IdP jwt already available from any other application login. 

*** Original Question ***

Hello. I am having difficulties developing a solution for a specific API Management use case. I've done a ton of studying and have a current theory of where my challenge lies but I'm not sure if it's correct, if maybe the use case is not possible, or if another solution is a better practice. 

We have a successful integration where a user that exists in BHE (Biz Hub Enterprise) calls API Management with Basic Authentication. This is passed to Cloud Integration where the call to the ECC backend (virtual host) uses Principal Propagation. The backend service from the iFlow receiver is an XI Proxy adapter call. The user successfully maps to the user in ECC and all is well. This is accomplished with a simple BasicAuth decode policy in the API Proxy. 

The intent now is to call an API Proxy that is connected through an API Provider and skip the Cloud Integration. The service is OData. We can call the OData service just fine directly into ECC. The challenge is using the BHE user to call the service, providing the correct credential information, and getting the Cloud Connector to accept this so it can convert to the x.509 certificate. Most everything I've read seems to lean to the idea that there needs to be a user token exchange either with an existing JWT from an IdP or by creating your own new JWT. Thing is, haven't been able to figure that out. I did create a generic OAuth service to get an access_token but this doesn't seem to be the user_token that's needed as well. 

My first question is, does this use case seem technically feasible. BHE user, not previously logged in (aka service user for a third party app), calling API Proxy that uses API Provider for OData call to ECC on premise via Principal Propagation.

Additional info:

• The current token service has been tried with client_credentials and password grant types (yes - I do understand that client_credentials doesn't have a subject and this could very be why this use case is no go).
• The Cloud Connector virtual host does have the check box selected for 'System Certificate for Logon'. 
• The API Provider is configured for Prin.Prop authentication.
• Calling the service with Basic Auth settings in Postman yields this error: "Invalid SAP-Connectivity-Authentication header value: Basic YXB..." which hints that I'm on the right track with the sap connectivity service help of https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/configure-principal-propagation-via-c... 
  • I'm not providing that header value - SAP is doing this somewhere in the chain. 
• Cloud Connector never shows the user hit for the call so I know the signal is never getting that far. It's rejecting in API Management somewhere. 
• Users exist fine in our Corporate IdP that is proxy from IAS. I don't think this is a user setup problem.

Not sure what else to provide as this seems to be a complex setup and has lots of moving pieces. 

Anyhow, end result is that users A, B, and C that exist in BHE can call the service and get mapped in ECC for the call. 

I can provide any other details if anyone is willing/knows maybe what to do or where to look. My gut says this is edging towards not possible but hoping there's API Policies that might get the job done. 

Thanks.

[Bryan_Pierce1]

Update. We finally were able to determine that the build as stated wasn't going to work. We found that I was using the wrong end point for retrieving the needed token. However, it was also not an option with a single call anyway. The resolution is to use two calls, which is typical, to make this happen. One for the OAuth token and then one for the service call. It does mean that 3rd party (internal to our org) callers have to build this into their applications but it will function. We have only prototyped the functionality but it seems to do the trick so we'll scale it up for the org use and call it good. 

[zain1]

Hi Bryan

[zain1]

How can we acheibe this can you share steps we need to make a call from external using api proxy to odata via prinicpal propagation