Change default auth provider to `EntraID` from `StaticWebApps`

[JerryNixon]

Ensure EntraID is identical to StaticWebApp

The goal is to ensure AppService is identical to StaticWebApp because we want to stop using StaticWebApp and start using AppService.

https://github.com/Azure/data-api-builder/blob/ebbe98983bb02a0cd1f099dede20e691db3cd9a7/src/Config/ObjectModel/EasyAuthType.cs#L6-L10

⚠️ None of this should be done if they are not identical.

Modify the Engine default references to StaticWebApps

These references are scattered throughout the codebase. We're shifting to AppService as the default, so wherever StaticWebApps appears in code or comments, it should be updated. We're not removing support for StaticWebApps, just removing it as the default.

Comment example:
https://github.com/Azure/data-api-builder/blob/ebbe98983bb02a0cd1f099dede20e691db3cd9a7/src/Config/ObjectModel/AuthenticationOptions.cs#L9

Code example:
https://github.com/Azure/data-api-builder/blob/ebbe98983bb02a0cd1f099dede20e691db3cd9a7/src/Config/ObjectModel/AuthenticationOptions.cs#L14

Modify the CLI default references to StaticWebApps

This primarily applies to dab init. The goal is to ensure the CLI no longer defaults to StaticWebApps as the auth provider but to AppService. Users can still configure StaticWebApps, but they must do so manually.

Modify the JSON Schema

Update the schema to change the default value to AppService.

https://github.com/Azure/data-api-builder/blob/ebbe98983bb02a0cd1f099dede20e691db3cd9a7/schemas/dab.draft.schema.json#L275-L283

Also update the schema to restrict the provider property to only supported values (including StaticWebApps).

Modify DAB Validate

Update ValidateAuthenticationOptions to log a warning if the runtime host is set to StaticWebApps.

if (Enum.TryParse<EasyAuthType>(runtimeConfig.Runtime.Host.Authentication.Provider, ignoreCase: true, out var provider) &&
    provider == EasyAuthType.StaticWebApps)
{
    _logger.LogWarning("The 'StaticWebApps' authentication provider is deprecated.");
}

https://github.com/Azure/data-api-builder/blob/ebbe98983bb02a0cd1f099dede20e691db3cd9a7/src/Core/Configurations/RuntimeConfigValidator.cs#L713

Modify DAB Init

Ensure dab init generates a config functionally identical to before. However, the default provider should now be AppService instead of StaticWebApps.

https://github.com/Azure/data-api-builder/blob/ebbe98983bb02a0cd1f099dede20e691db3cd9a7/src/Cli/Commands/InitOptions.cs#L91-L92

[JerryNixon]

I asked Copilot if they were identical.

Based on the analysis of the codebase, both StaticWebApps and AppService authentication providers are implemented with similar logic. Here's a summary of the key points:

Key Files and Logic

1. Parsing Logic:

   • StaticWebApps: Defined in StaticWebAppsAuthentication.cs.
   • AppService: Defined in AppServiceAuthentication.cs.
   • Both handle the x-ms-client-principal header, decode it, and create a ClaimsIdentity.

2. Authentication Setup:

   • EasyAuthAuthenticationBuilderExtensions.cs: Adds schemes for both StaticWebApps and AppService using similar logic.

3. Core Authentication Handling:

   • EasyAuthAuthenticationHandler.cs: Processes authentication metadata for both StaticWebApps and AppService.
   • Uses a switch statement to call the appropriate parsing method based on the EasyAuthType.

4. Configuration and Defaults:

   • AuthenticationOptions.cs: Configures the default provider and related settings.
   • dab.draft.schema.json: Defines the schema for configuration, defaulting to StaticWebApps.

Conclusion

Switching the default auth provider from StaticWebApps to AppService should not result in different behavior since the implementation logic for both providers is identical. The parsing, authentication setup, and core authentication handling are all designed to handle both providers equivalently.

View More Results

If you need to review more details, you can view the full files and additional results on GitHub:

• StaticWebAppsAuthentication.cs
• AppServiceAuthentication.cs

Thus, changing the configuration to use AppService as the auth provider should have no impact on the engine's behavior.

This is just a starter, don't trust it.

[sander1095]

Also update the schema to restrict the provider property to only supported values (including StaticWebApps).

I created an issue for this in #2643, and just created a PR for it, too: #2646 . I vote to remove this sentence from this issue as this is already done when that PR is merged.

[sander1095]

@JerryNixon Can more information be provided on the reason for deprecating SWA auth? If someone chooses to host DAB in SWA, it makes sense (to me) to have the developer choose SWA as the auth provider, instead of App Service.

Also, SWA has DAB integration, whereas app Service does not. Currently it makes sense to have SWA as the default because of this integration. What is the reason for making app service the default?

---

Also, I am pretty sure there are small behavioral differences because of different auth handlers in code. Take a look at my comments in https://github.com/Azure/data-api-builder/pull/2610 for more info.

[JerryNixon]

A key step to this task is to validate what if any difference there are between the two types.

[anushakolan]

Shared the authentication differences between SWA and AppService with Jerry, we need to finalize on next steps on what should be the next auth provider based on the new data, which is open to discussion. So, moving this to hold.

[JerryNixon]

Change the behavior of dab init to default authentication provider to EntraId

[anushakolan]

Updated requirement to change the default auth to AppService