Apigee API Proxy managing backend service access tokens

[dturkel]

I have a situation where my customer would like to put Apigee proxies in front of Salesforce API services.

The customer will have multiple containers making API calls which will go through Apigee and ultimately Salesforce APIs.

We would like to provide a single Salesforce User ("Integration User") along with a Connected App to provide access.

We would like Apigee to manage the Salesforce access token(s) and refresh process for that leg of the transactions -- either managing a pool up to the limit of concurrent logins for the Integration User/Connected App combo.

In this way the client application/containers don't need to implement any shared cache of Salesforce access tokens.  They would simply be concerned with the "standard" oauth tokens/pattern for Apigee, and Apigee would worry about authenticating and constraints for the downstream service.

Is this technically possible, and if so, what what are the building blocks in the Apigee configuration that would make this possible? I'm trying to communicate with the customer's Apigee implementation team, but lack the in depth Apigee and OAuth knowledge to be specific with what I'm looking for.  This post was the most similar I could find, but was a little vague: https://www.googlecloudcommunity.com/gc/Apigee/Backend-OAuth-token-expiry-management/m-p/163592#M664...

[dchiesa1]

What you describe is technically possible.  I think you're on target that you'd need to build an OAuth facade in Apigee. Essentially configure Apigee to be the client to Salesforce.  That means at the right time, Apigee would have to send all the calls to get the right Salesforce authentication tokens. Then your API Proxy in Apigee could cache those credentials for re-use later.  The client apps (within containers) would then send some sort of simplified  Apigee-specific credentials to APigee, and Apigee would map those to bonafide salesforce credentials before connecting to the SFDC endpoint. 

You COULD build all of that, and it would work. But, you might want to delegate all that to a pre-built connector layer. Apigee Integration includes a connector to connect into Salesforce, and as far as I  am aware, it does all the credential management for you.  This would be a "buy it, don't build it" kind of solution to your problem.

@Former Community Member might have some more commentary.

[Former Community Member]

@dchiesa1 is right. There are two ways to accomplish this pattern. dchiesa1 has already explained one approach. Here is the other.

Apigee provides Apigee Integration, an orchestration engine that provides access to connectors. One of the connectors available is the Salesforce connector.  

The principle of the approach has two portions:

• You delegate authn/authz to backend applications to Connectors. A connection (instance of a connector) is set up by someone with permissions to Salesforce one and reused by other  applications (Apigee Integration in this case).
• A developer then uses Apigee Integration to interact with Salesforce (query, insert update etc.) or other such applications and this business process itself can be exposed as an API through Apigee.

[dturkel]

Thank you, @Former Community Member and @dchiesa1 for your replies.

I think I had previously seen a different product/component that included some generic functionality, and may have discounted what you describe above as the same thing.  If what you reference above provides the centralized management of connections to Salesforce it may be exactly what we're looking for.   Will investigate further.  Thanks!

[Former Community Member]

It is possible you saw Apigee Extensions which worked with Apigee Edge. The options I provided are relevant for Apigee X.

[dturkel]

I did some playing around with the approach @Former Community Member suggested an eval version of Apigee.  I ran into some problems with this... first was that there didn't seem to be a way to indicate a sandbox or even a "My Domain" URL for authentication... so I couldn't even get my Connection to validate.  The other issue after reviewing how the "Integrations" worked is that these are more appropriate for simpler interactions with Salesforce; in my case Apigee is proxying for any-and-all Salesforce APIs (REST/REST Composite, Bulk, etc.).  I didn't see a reasonable way to do that with the Integrations toolset.

[Former Community Member · Accepted solution]

You are correct, we don't support custom domains yet. This is on the roadmap, I will update this page when we have it. 

Please do tell me more about your use case with the Salesforce API and why Integration doesn't support it. 

NOTE: For straightforward proxying all Salesforce APIs, Apigee is the right tool for the job. Integration is more for not having to write code to interact with Salesforce. 

[dturkel]

Even if custom domains is unsupported immediately, there also didn't seem to be a way to indicate if the instance was a Sandbox instance (https://test.salesforce.com).  Generally, either https://login.salesforce.com or https://test.salesforce.com can substitute for using the My Domain.

While technically it appears using the Integration product could do the function of integrating to any RESTful API using the the REST API task (and the many others that are offered), I would only use it if I had a few or "manageable" number of integrations I was building.  In my client's case, they are trying to put a broad access policy/governance in place supporting large swaths of the available Salesforce APIs, allowing consumers to pick any API resource as needed.  They are not trying to add any orchestration or value on top of the raw Salesforce APIs, allowing the consumers to use them as documented by Salesforce.

[Former Community Member]

Understood, thanks for letting us know @dturkel