Поделиться через


Настройка проверки подлинности симулятора для локального тестирования

Провайдер аутентификации для симулятора позволяет тестировать ролевые разрешения локально без необходимости настройки поставщика удостоверений. Используйте его во время разработки, чтобы убедиться, что правила разрешений работают правильно перед развертыванием в рабочей среде.

Выбор локального поставщика проверки подлинности

Во время разработки можно протестировать аутентификацию и авторизацию без настройки продакшн-поставщика удостоверений.

Provider Лучше всего подходит для Примечания.
Симулятор Быстрое тестирование разрешений Только для разработки. Обрабатывает каждый запрос как прошедший проверку подлинности. По умолчанию используется роль Authenticated; модифицируется с помощью X-MS-API-ROLE.
AppService Тестирование на основе утверждений Имитируйте EasyAuth на локальном сервере, отправляя X-MS-CLIENT-PRINCIPAL с пользовательскими утверждениями. Дополнительные сведения см. в разделе "Настройка проверки подлинности службы приложений".

Поток аутентификации

Поставщик симулятора обрабатывает все запросы как прошедшие проверку подлинности, позволяя сосредоточиться на тестировании правил авторизации:

Иллюстрация потока проверки подлинности симулятора, показывающая, как запросы автоматически обрабатываются как прошедшие проверку подлинности.

Phase Что происходит
Запрос прибывает Разработчик отправляет HTTP-запрос в DAB
Назначение ролей DAB назначает Authenticated (по умолчанию) или роль из заголовка X-MS-API-ROLE
Проверка разрешений DAB оценивает запросы с учетом разрешений сущности для этой роли.
Выполнение запроса Если это разрешено, DAB запрашивает базу данных и возвращает результаты.

Это важно

Поставщик симулятора предназначен только для разработки. Никогда не используйте его в рабочей среде, так как он обходит всю реальную проверку подлинности.

Предпосылки

Краткий справочник

Setting Ценность
Provider Simulator
Режим хоста development (обязательно)
Роль по умолчанию Authenticated (внедряется автоматически)
Заголовок переопределения роли X-MS-API-ROLE
Требуется токен нет
Поддержка утверждений Ограничения (только системные роли Anonymous/Authenticated, без произвольных утверждений)

Шаг 1. Настройка поставщика симулятора

Задайте поставщику проверки подлинности значение "Симулятор" и убедитесь, что режим разработки включен.

интерфейс командной строки (CLI)

# Enable development mode
dab configure \
  --runtime.host.mode development

# Set the Simulator provider
dab configure \
  --runtime.host.authentication.provider Simulator

Итоговая конфигурация

{
  "runtime": {
    "host": {
      "mode": "development",
      "authentication": {
        "provider": "Simulator"
      }
    }
  }
}

Замечание

Поставщик симулятора работает только в том случае, если mode задано значение development. В рабочем режиме DAB отклоняет поставщика симулятора и не запускается.

Шаг 2: Настройка прав доступа сущности

Определите разрешения для ролей, которые требуется протестировать. Можно протестировать системные роли (Anonymous, Authenticated) и пользовательские роли.

Пример: несколько ролей

# Allow anonymous read access
dab update Book \
  --permissions "Anonymous:read"

# Allow authenticated users full read access
dab update Book \
  --permissions "Authenticated:read"

# Allow authors to create and update
dab update Book \
  --permissions "author:create,read,update"

# Allow admins full access
dab update Book \
  --permissions "admin:*"

Итоговая конфигурация

{
  "entities": {
    "Book": {
      "source": "dbo.Books",
      "permissions": [
        {
          "role": "Anonymous",
          "actions": ["read"]
        },
        {
          "role": "Authenticated",
          "actions": ["read"]
        },
        {
          "role": "author",
          "actions": ["create", "read", "update"]
        },
        {
          "role": "admin",
          "actions": ["*"]
        }
      ]
    }
  }
}

Шаг 3. Тестирование различных ролей

Запустите построитель API данных и отправьте запросы для тестирования каждой роли.

dab start

Тестирование как аутентифицированное (по умолчанию)

Без специальных заголовков запросы оцениваются как Authenticated роль:

curl -X GET "http://localhost:5000/api/Book"

Проверка в качестве анонима

Используйте X-MS-API-ROLE в качестве заголовка для тестирования Anonymous.

curl -X GET "http://localhost:5000/api/Book" \
  -H "X-MS-API-ROLE: Anonymous"

Тестирование как пользовательская роль

Используйте заголовок X-MS-API-ROLE, чтобы протестировать любую пользовательскую роль.

curl -X GET "http://localhost:5000/api/Book" \
  -H "X-MS-API-ROLE: author"

Замечание

При использовании эмулятора тестирование пользовательских ролей работает, так как DAB оценивает разрешения на основе значения заголовка X-MS-API-ROLE. Системные роли (Anonymous, Authenticated) всегда доступны. Если запрос настраиваемой роли возвращает ошибку 403, убедитесь, что имя роли точно соответствует разрешениям сущности.

Проверка действия, которое должно быть отклонено

Попробуйте выполнить действие, для которых роль не имеет разрешения:

# This should fail—Anonymous can only read
curl -X POST "http://localhost:5000/api/Book" \
  -H "X-MS-API-ROLE: Anonymous" \
  -H "Content-Type: application/json" \
  -d '{"title": "New Book", "author": "Test"}'

Ожидаемый ответ: 403 Forbidden

Сценарии проверки

Используйте симулятор для тестирования этих распространенных сценариев:

Scenario Проверка
Анонимный доступ Задайте значение X-MS-API-ROLE: Anonymous.
Прошедший проверку подлинности доступ Опустить заголовки (по умолчанию) или задать X-MS-API-ROLE: Authenticated
Доступ к пользовательской роли Задайте значение X-MS-API-ROLE: <role-name>.
Отказано в выполнении действия Запросите действие, на которое у роли нет разрешения
Ограничения полей Настройка разрешений на уровне поля и проверка полей ответа
Недостающая роль Установите X-MS-API-ROLE: nonexistent, чтобы проверить обработку ошибок

Ограничения

Поставщик симулятора имеет следующие ограничения:

Limitation Обходной путь
Нет пользовательских требований Используйте поставщика AppService с заголовком X-MS-CLIENT-PRINCIPAL
Без политик базы данных с утверждениями Тестирование политик с помощью поставщика AppService
Проверка токена отсутствует Переключитесь на Entra или пользовательского поставщика для производства
Только режим разработки Использование реального поставщика в рабочей среде

Подсказка

Если необходимо протестировать политики баз данных, использующие утверждения (например @claims.userId), вместо этого используйте поставщика AppService. Он позволяет предоставлять настраиваемые требования через заголовок X-MS-CLIENT-PRINCIPAL.

Переход в промышленную среду

Когда вы будете готовы к развертыванию, замените поставщика симулятора рабочим поставщиком:

  1. Переход mode с development на production
  2. Поменяйте provider с Simulator на выбранного вами поставщика (EntraID/AzureAD, AppService или Custom)
  3. Настройка необходимых параметров JWT (аудитории, издателя)
{
  "runtime": {
    "host": {
      "mode": "production",
      "authentication": {
        "provider": "EntraID",
        "jwt": {
          "audience": "api://<your-app-id>",
          "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0"
        }
      }
    }
  }
}

Полный пример конфигурации

{
  "$schema": "https://github.com/Azure/data-api-builder/releases/latest/download/dab.draft.schema.json",
  "data-source": {
    "database-type": "mssql",
    "connection-string": "Server=localhost;Database=Library;Trusted_Connection=true;TrustServerCertificate=true;"
  },
  "runtime": {
    "host": {
      "mode": "development",
      "authentication": {
        "provider": "Simulator"
      }
    }
  },
  "entities": {
    "Book": {
      "source": "dbo.Books",
      "permissions": [
        {
          "role": "Anonymous",
          "actions": ["read"]
        },
        {
          "role": "Authenticated",
          "actions": ["read"]
        },
        {
          "role": "author",
          "actions": ["create", "read", "update"]
        },
        {
          "role": "admin",
          "actions": ["*"]
        }
      ]
    }
  }
}