Enable B2B scenarios and support custom claims from SWA auth jwt in policies

[stephlocke]

Per the docs Accessing user information in Azure Static Web Apps - Client principal data custom auth providers can provide additional claims.

We're currently looking at this as a route to support Microsoft Entra with exposed additional fields to support a B2B scenario which will involve filtering on a Company claim as well as user ID to determine what item-level records users can interact with. We considered roles but it seems impractical to create new roles and routes with hardcoded filters whenever a new customer is onboarded.

The current SWA auth helper object drops the additional claims portion of the client principal. It would be great it the custom claims became consumable

data-api-builder/src/Core/AuthenticationHelpers/StaticWebAppsAuthentication.cs

Line 28 in 8ea24db

public class StaticWebAppsClientPrincipal

e.g.

{
  "clientPrincipal": {
    "userId": "0cbfbbdb11befc27f7b81b5ba1fc451b",
    "userRoles": [
      "anonymous",
      "authenticated"
    ],
    "claims": [
      {
        "typ": "company",
        "val": "0cbfbbdb11befc27f7b81b5ba1fc451b"
      }
    ],
    "identityProvider": "aad",
    "userDetails": "stephlocke"
  }
}

enabled a policy like @item.companyId in @claims.groups

[stephlocke]

We briefly discussed the idea of using roles to hold the company and route people.

Doing this would require passing the additional user role to the policy for query transformation and/or creating a policy per role with a hardcoded transformation string, requiring reload of a very large config file.

So I considered what if the databases were segregated by company rather than the rows being segregated by company. I was thinking this could work with database segregation, ie, programmatically generating a child config for a role so we could end up with:

• Endpoints:
  • example.com/api/contoso/todo
  • example.com/api/tailwind/todo
• Databases:
  • exampleDb.sqlserver.windows.net/contoso
  • exampleDb.sqlserver.windows.net/tailwind
• DAB config files:
  • dab-config.json

{
  "data-source-files": [
    "dab-config-contoso.json",
    "dab-config-tailwind.json"
  ],
  "runtime": {
    "rest": {
      "enabled": true
    } }}

• dab-config-contoso.json

{
  "data-source": {
    "database-type": "cosmosdb_nosql",
    "connection-string": "@env('COSMOS_CONNECTION_STRING')",
   "database-name": "contoso",
  },
  "entities": {
    "Book": {
      "source": {  "object": "dbo.Books" },
      "permissions": [
        { "role": "contoso", "actions": [ "*" ] }
      ]}}}

• dab-config-tailwind.json

{
  "data-source": {
    "database-type": "cosmosdb_nosql",
    "connection-string": "@env('COSMOS_CONNECTION_STRING')",
   "database-name": "tailwind",
  },
  "entities": {
    "Book": {
      "source": {  "object": "dbo.Books" },
      "permissions": [
        { "role": "tailwind", "actions": [ "*" ] }
      ]}}}

• A client in the FE:
  • Sets the routing for the api based on X-MS-API-ROLE by doing at minimum string interpolation
  • Passes the auth token and the X-MS-API-ROLE to the specific endpoint

graph TD;
  U[User] -->|Authenticated| FE[Front-end];
  FE --> |Creates route client| DAB;
  DAB --> |Uses route| DB[Customer specific DB];

Loading

However, reading some of the docs, there are some barriers to this:

1. Single custom role allowed which blocks from being able to admin/free-user/read-only type custom roles to manage as well

A request can have only one role. Even if the token indicates multiple roles, the x-ms-api-role value selects which role is assigned to the request.

2. Changes would still be made to the top-level config by specifying child-configs which could trigger downtime during reload.

• It'd be great to get a doc on how changes to config files are handled btw

3. Entities must be globally unique meaning we couldn't route to same tables in different locations
4. Data sources can't be given their own path / route