Backend For Frontend - Secure Calling Third-Party APIs

@Mark_Wonsil recently introduced me to the concept of Backend For Frontend (BFF). I want to learn more about this and how to implement this methodology into Epicor when using third-party APIs. That is, I don’t want to expose my authorization credentials in any way.

From what others have said, I believe I need to implement my own API that somehow stores my secure credentials to access my third-party API. What I don’t understand is that this just adds another API in the chain. I will have to put in my credentials for the new API into Epicor somewhere to allow it to pull down the creds for my third-party API. Adding layers of APIs surely isn’t the answer.

I think that I am missing something critical here.
Do I have to write my own API to securely use a third-party API with Epicor?
If so, what do I use to write the API and are there any examples to get me started?
If I don’t have to write an API, then there must be one out there I can use (for free)?
How does adding another API call protect the credentials?

Thanks for your time and patience!

You’ve hit upon an important point. From a guest on the most recent Google Cloud Security podcast, they call this the “bottom turtle problem.” From their book:

This brings to mind the famous anecdote about a woman who
interrupted a philosopher’s lecture to tell him the world rested on a
turtle’s back. When the philosopher asked her what the turtle rested
on, she said: “It’s turtles all the way down!” Finding the bottom turtle,
the solid foundation on which all other security rests, is the goal of the
SPIFFE and SPIRE projects

The ultimate goal is to not have the secrets at all. Right now, the path is using managed identities. When we use a service like Azure or AWS, we can let them manage the identities/secrets. In your case, you would create a Key Vault and your application. You would assign a managed identity to your app and that allows the app to read credentials in the key vault. When your API spins up, it grabs the credentials for the 3rd party from the vault.

Now, the user of the API also needs to authenticate to Entra ID. Here are the ways:

You set up security for your API to allow a group of users to call it. So now you have an authenticated user who has permissions to call the API and the API has the 3rd party credentials to call their API. The credentials are never seen by the client.

The next goal is to get the 3rd party to not use secrets but that’s a turtle for another day.

1 Like

I still don’t see how it’s better. There are credentials at some point, and they have to be passed.

1 Like

Thanks for the softball. In a meeting, but working on a reply to this common misconception.

1 Like

I can’t find the appropriate meme for what I’m feeling.

David Cronenberg Neon Rated GIF by NEON

1 Like

Technically, managed identities are server-to-server authentication using certificates

3 Likes

So big government keeps us safe? :laughing:

OK, it’s Friday afternoon, let’s try to answer this.

Yes, there are always secrets - but they do not always have to be passed. The password (something we know) has been with us for a very long time - way before computers.

image

Even longer, going back to the Roman Army using watchwords.

The problem with secrets? They are hard to keep. Humans cough them up to malicious sites, social engineering, checking them into source code, etc. Even Microsoft has had a bad stretch of not being able to keep tokens a secret lately!

So, the goal is to not to use secrets. The answer, as @Olga pointed out, is to use public key cryptography. In this scenario, the client makes a request to the server. The server sends a random challenge phrase. The client encrypts the challenge with its private key and sends it to the server. The server decrypts the challenge with the clients public key. If they are the same, then we know the client has the private key used upon setup.

Server to server authentication is done with digital certificates. Again, each side has secrets but they are not transmitted. Web certificates are tied to the fully qualified domain name so they cannot be used on other machines even if stolen.

The reason the BFF is useful is you cannot trust a client with others’ secrets.

But Mark, aren’t we just trusting our API server to keep the secret?

Well, we kick the can a little further down the road here. The ideal situation is the secret is not at the server but kept in a vault. In order for the API server to get the secret, there’s a pair of digital certificates that allows the API server to retrieve that secret. The API server will retrieve it each time it needs it. (A better practice would be that the secret gets rotated each time it’s used much like Microsoft does with Local Adminstrator Password Solution - LAPS.) Obviously, one has to balance the risk appetite with the effort. But using a BFF that gets the credentials from secret store is enough juice that’s worth the squeeze.

As for humans, here’s some nice weekend reading on how passwordless works for our users by passing challenges across multiple channels while using public key cryptography behind the scenes. No passing around secrets.

4 Likes

Thank you for the clarification, Mark. I think I understand the concept now. I can see how the secret is never passed as long as the certificates are in place.

I think we are nearing an actual usable solution! Given the statements above, where do I start? I have my third-party API that needs to have user/pass or basic auth passed to gain access. I want to do this the right way. Is my next step to learn how to create an API and key vault? Where do I build such an app? Is there a template to follow?

This should get you started. Since you’re cloud already, I assume that you’re not opposed to using Azure. It’s actually a little more secure in the event your local network is popped, this API will be segmented.

Once written, you call this API from Kinetic instead of the service.

1 Like

BTW, the next cool thing might be Distributed IDs (DIDs) which also use PKI but there is no central authority.

Completely a thought experiment, but couldnt you just write a webservice to receive the calls, change the headers (mainly the auth), and forward it on to actual server\endpoint?

You could encrypt the creds, or just have a dummy set passed in as your service would be providing the creds to Epicor anyway via the header.

Instead of what service? Right now, I am using functions and a UBAQ with a Post-Processing BPM on GetList. If I figure out how to build this API, can’t I just call it from my function?

Although our Epicor is Cloud DT, we don’t have Azure. From your link:

  • Step 1: Start by going to the Azure portal and logging in with your credentials.
    Though we do use Microsoft 365, I don’t think we have Azure.

Good question! Where (what language) would I write the webservice? Would it run locally on our server?

Also, from the instructions on setting up the Key Vault I see this:

STEP 5. In the creation process, select a subscription, specify a resource group, enter a name for the Key Vault, choose a region, and set the pricing tier.

Does that mean there is no free option?

I’m actually working up a sample project…stay tuned.

As for Key Vault

Dude,this is a close to free as you’re going to get! :rofl:

2 Likes

Does anyone know if Last Pass can be used as a secrets vault similar to how Azure’s Key Vault works?

We don’t have a sub to Azure, so we surely don’t have access to Key Vault.

All it takes is a credit card. :person_shrugging: The cost will be less than $1 USD/month. Microsoft will be losing money on the transaction fee. :rofl:

PowerShell has a Vault interface that supports these providers:

SecretManagement and SecretStore are Generally Available

I believe for LastPass, 1Password, BitWarden, Hashicorp, etc. you’ll need an Enterprise license. :thinking:

2 Likes

6 posts were split to a new topic: A Discussion on Password Managers and Keeping Secrets

Sorry @Mark_Wonsil didn’t mean to hijack your thread.

I think you can self host Hashicorp for “free” (as if hosting anything is ever free…)

2 Likes

Interesting read, so it sounds nd like “Kensentme” is no longer ner going to cut it… :grin:. Thanks asking @NateS and thanks for the information @Mark_Wonsil