DAB setup best practices

[ax365]

Hi everyone,

I've managed to get DAB configured in local development mode.
I'm able to call my stored procedure (defined in a Synapse dedicated pool) as a REST API. All good.

---

Now I'm looking into getting this deployed to a test environment, and eventually to production.

Apologies if the questions below are obvious, but these types of things haven't really been part of my usual routine.

There are a few "DAB topics" that I would like to have better understanding of:

• Best practices for hosting/deployment
• Best practices for .env file (in particular, connection-string --> authentication method)

---

Hosting:

I've reviewed this documentation:
https://learn.microsoft.com/en-us/azure/data-api-builder/deployment/hosting-options

A lot of the documentation online for DAB has StaticWebApps as the go-to option.

• But it's still in preview (and seems to have been in preview for a while)
• The client doesn't want to go-live with preview features
• How to make sense of this? Do we expect this option to be GA soon?

Apart from StaticWebApps, the client is most comfortable with AzureAppService:

• Unfortunately, the msdocs don't have an in-depth guide to get AzureAppService configured for DAB
• The msdocs only have in-depth guide for {AzureContainerApps, AzureContainerInstances, StaticWebApps}
• Is AzureAppService still a good option for DAB? Or should we look into the other hosting options instead?

---

The .env file:

• What is the recommended authentication method(s) for the connection string inside the DAB .env file for production purposes?
• How to deploy and maintain this .env file and have the sensitive information secure? It a bit concerning to have user/pw in there

For development purposes I've been able to utilize "Active Directory Interactive" but I don't expect this would be the correct choice when it's time to deploy to test and production level environments.

---

Hopefully can get some clarity on these questions.

Thanks for the time.

[ax365]

Regarding .env file, I've been trying to "add some muscle" to the stored procedure that DAB exposes as an API.

• So far, I've only been able to test with the "anonymous" access
• I'd like to only allow "authenticated" access and test this in localhost/development mode
• Come time for deployment to AppService, the plan is to use managed identity -- but this isn't feasible to test in localhost mode

---

I've been following the instructions from here:
https://learn.microsoft.com/en-us/azure/data-api-builder/authentication-azure

And since I'm testing in localhost mode for now, I'm using the authentication method "Active Directory Default".

I'm getting this error though:

Microsoft.Data.SqlClient.SqlException (0x80131904): 
Login failed for user '<token-identified principal>'. 
The server is not currently configured to accept this token.

Any idea what's missing?

[aaronburtle]

Hi there, thanks for the questions.

A lot of the documentation online for DAB has StaticWebApps as the go-to option.
But it's still in preview (and seems to have been in preview for a while)
The client doesn't want to go-live with preview features
How to make sense of this? Do we expect this option to be GA soon?

Unfortunately, we don't have any additional information regarding GA dates for DAB in StaticWebApps.

Is AzureAppService still a good option for DAB? Or should we look into the other hosting options instead?

AzureAppService is a good option for DAB. You can run DAB as either a native .NET application or as a Docker container image. You've probably reviewed these docs, but you can check here for more information on using AzureAppService: https://learn.microsoft.com/en-us/azure/app-service/

What is the recommended authentication method(s) for the connection string inside the DAB .env file for production purposes?

How to deploy and maintain this .env file and have the sensitive information secure? It a bit concerning to have user/pw in there

Our recommended method would be using managed identity which solves the 2nd problem you raise; username/pw in the connection string in the .env file.

I'm getting this error though:

Microsoft.Data.SqlClient.SqlException (0x80131904):
Login failed for user ''.
The server is not currently configured to accept this token.

This typically means that the server is not configured to accept AAD authentication. Some steps to check would be:

1. Ensure your sql server accepts AAD authentication. If using Azure SQL Database, make sure that an Azure AD admin is assigned and then restart the database. If using SQL Server, ensure AAD authentication is enabled.

2. Double check the authentication in the .env. Make sure you have AUTHENTICATION_PROVIDER=AzureAD set in your.env file and make sure you have the provider set as AzureAD in the authentication section of the runtime portion of the config file.

3. Double check your connection string to make sure it is setup for using Active Directly Default.

4. Make sure the AAD user has database permissions.

Please let me know if after you try these steps you are still having issues, we can try to debug further.

[ax365]

Thanks @aaronburtle,

That helps clarify pretty much everything. Update:

• I've now successfully deployed DAB using AzureAppService through a bicep template similar to this example How can we host DAB is azure webapp #2213 (comment)
• I've utilized a user-defined-managed-identity to connect to the database

---

The only part where I'm still unsure about is the JWT component.

• To be able to test various authentication configs locally and/or with the deployed app, I need to define the JWT issuer/audience in the dab-config.json file (under the authentication node)
• How do I create/setup this JWT issuer, etc.?