Настройка поставщика без проверки подлинности

Поставщик сообщает построителю Data API (DAB) не проверять и не валидировать веб-токены JSON (JWT). Каждый запрос выполняется в качестве anonymous роли. В DAB нет исключений.

Замечание

Функции построителя данных 2.0, описанные в этом разделе, находятся в предварительной версии и могут измениться до общедоступной доступности. Дополнительные сведения см. в статье "Новые возможности" версии 2.0.

Используйте этот поставщик, если вы хотите, чтобы DAB обрабатывал каждый запрос как anonymous, даже если другая служба перед DAB выполняет проверку подлинности или применяет политику доступа.

Это важно

Поставщик Unauthenticated никогда не преобразует исходную идентичность в идентичность DAB. Если вам требуется DAB для проверки токенов, активации роли authenticated, использования пользовательских ролей или передачи утверждения пользователей в подчиненные политики, используйте проверяющего провайдера, например EntraId, Custom или AppService.

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

Unauthenticated При использовании поставщика DAB полностью пропускает валидацию токена и оценивает разрешения следующим образом:anonymous

Phase Что происходит
Запрос клиента Клиент отправляет запрос в DAB напрямую или через другую службу.
Вышестоящие элементы управления Фронтенд, шлюз или прокси-сервер может аутентифицировать вызывающего или осуществить грубую проверку доступа перед пересылкой запроса.
Перенаправляющий запрос Запрос достигает DAB
Обработка DAB DAB не проверяет JWTs и всегда обрабатывает запрос как anonymous
Авторизация DAB оценивает разрешения сущности для роли anonymous.

Когда следует использовать этот поставщик

Используйте Unauthenticated в следующих сценариях:

Сценарий Хорошо подходит? Почему
Управление API или шлюз сначала проверяет подлинность пользователей Да Фронтенд может ограничивать доступ, в то время как DAB по-прежнему авторизует запросы только для роли anonymous
Внутренний сервис внутри границы частной сети Да Сетевой доступ контролируется вне DAB, и DAB может оставаться anonymous-только
Быстрая локальная настройка без настройки проверки JWT Да Самый простой способ приступить к работе
DAB, являющийся доступным непосредственно браузерам или общедоступным клиентам Нет DAB не проверяет токены идентификации
Требуется authenticated или настраиваемая активация ролей внутри DAB Нет Только anonymous активен с этим поставщиком

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

Setting Ценность
Поставщик Unauthenticated
Требуется токен Нет
Активная роль DAB anonymous
Поддерживает проверку JWT Нет
Поддерживает authenticated роль Нет
Поддержка пользовательских ролей Нет

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

Задайте поставщика проверки подлинности на Unauthenticated.

CLI

dab configure \
  --runtime.host.authentication.provider Unauthenticated

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

{
  "runtime": {
    "host": {
      "authentication": {
        "provider": "Unauthenticated"
      }
    }
  }
}

Замечание

Поставщик Unauthenticated используется по умолчанию для новых конфигураций в DAB 2.0. Выполнение dab init создает рабочую конфигурацию без каких-либо параметров JWT.

Шаг 2. Настройка разрешений сущности для anonymous

Поскольку DAB обрабатывает все запросы с anonymous, ваши сущности должны разрешить доступ к роли anonymous для любой операции, которую вы хотите разрешить.

Пример конфигурации

{
  "entities": {
    "Book": {
      "source": "dbo.Books",
      "permissions": [
        {
          "role": "anonymous",
          "actions": ["read"]
        }
      ]
    }
  }
}

Если сущность предоставляет доступ только к authenticated или пользовательской роли, запросы завершаются ошибкой, так как эти роли никогда не активируются, когда настроен Unauthenticated.

Это важно

Если Unauthenticated активен, authenticated и пользовательские роли, определенные в разрешениях сущностей, никогда не активируются. Если конфигурация содержит эти роли, DAB выдает предупреждение при запуске.

Шаг 3. При необходимости выместите другую службу перед DAB

Другая служба по-прежнему может выполнять проверку подлинности вызывающих абонентов или применять правила доступа с грубой проверкой подлинности, прежде чем запрос достигнет DAB. Это не изменяет поведение DAB:

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

Этот шаблон хорошо работает, когда окружающая платформа контролирует, кто может получить доступ к DAB, в то время как DAB намеренно остается anonymous-только.

То, что этот поставщик не делает

Поставщик не:

  • Проверка маркеров носителя
  • активируйте роль authenticated
  • Активировать пользовательские роли из утверждений
  • сделать утверждения доступными для политик базы данных
  • выполнение авторизации для конкретного пользователя внутри DAB

Если вам нужны эти возможности, используйте поставщика, предоставляющего удостоверение DAB.

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

{
  "$schema": "https://github.com/Azure/data-api-builder/releases/latest/download/dab.draft.schema.json",
  "data-source": {
    "database-type": "mssql",
    "connection-string": "@env('SQL_CONNECTION_STRING')"
  },
  "runtime": {
    "host": {
      "authentication": {
        "provider": "Unauthenticated"
      }
    }
  },
  "entities": {
    "Book": {
      "source": "dbo.Books",
      "permissions": [
        {
          "role": "anonymous",
          "actions": ["read"]
        }
      ]
    }
  }
}

Связанный контент

  • Last updated on