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

Общие сведения о проверке подлинности и авторизации серверной части

  • Статья

Пример рабочей нагрузки разработчика Fabric содержит следующие потоки проверки подлинности на стороне серверной части.

Проверка подлинности и авторизация запросов из Fabric в рабочую нагрузку

Структура заголовка авторизации

Заголовок авторизации использует определенный формат маркера:

SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"

Этот формат включает два разных маркера:

  • subjectToken: делегированный маркер, представляющий пользователя, от имени которого выполняется операция.
  • appToken: маркер, характерный для приложения Fabric.

Обоснование использования заголовка двойного токена состоит из трех раз:

  • Проверка. Рабочая нагрузка может проверить, получен ли запрос из Fabric, проверяя appTokenзначение .

  • Контекст пользователя: subjectToken предоставляет контекст пользователя для выполняемого действия.

  • Обмен данными между службами: рабочая нагрузка может получить маркер subjectTokenOBO от имени (OBO), позволяющий ему вызывать другие службы с маркером пользователя.

Проверка подлинности

Основные проверки подлинности, выполняемые для SubjectAndAppToken:

  • Проверка и синтаксический анализ значения заголовка авторизации выполняется в методе AuthenticateControlPlaneCall . Маркер должен начинаться с префикса SubjectAndAppToken1.0 и включать два токена — subjectToken и appToken.

  • Проверка свойств маркера записи: subjectToken оба и appToken проверяются для распространенных свойств маркера Microsoft Entra в методе ValidateAadTokenCommon . К этим свойствам относятся подпись маркера, время существования токена, аудитория маркеров (аудитория приложений рабочей нагрузки) и версия токена (1.0) и издатель.

  • Проверка свойств appToken: appToken не должно иметь утверждение, но должно иметь scp idtyp утверждение с приложением в качестве значения. Мы также проверяем это tid утверждение в идентификаторе клиента издателя рабочей нагрузки.

    Пример утверждений appToken:

    {
"aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123",
"iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"iat": 1700047232,
"nbf": 1700047232,
"exp": 1700133932,
"aio": "E2VgYLjBuv2l+c6cmm/iP/bnL2v+AQA=",
"appid": "11112222-bbbb-3333-cccc-4444dddd5555"
"appidacr": "2",
"idp": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"idtyp": "app",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"rh": "0.ACgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZAAA.",
"sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff",
"uti": "5bgMXs3uMUSAHCruRjACAA",
"ver": "1.0"
}

  • Проверка свойств subjectToken: убедитесь, что subjectToken содержит scp утверждение с FabricWorkloadControl областью действия, что в маркере отсутствует idtyp утверждение, и что он имеет то же appid самое, что и в маркере appToken.

    Пример утверждений subjectToken:

    {
"aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123",
"iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"iat": 1700050446,
"nbf": 1700050446,
"exp": 1700054558,
"acr": "1",
"aio": "ATQAy/8VAAAAUgWRMRnBo4VGHvrKRykUXOXBNKS1cHnBxLrYkZJJGSjAVyJGBecbLdSud1GUakER",
"amr": [
    "pwd"
],
"appid": "11112222-bbbb-3333-cccc-4444dddd5555"
"appidacr": "2",
"ipaddr": "46.117.19.50",
"name": "john doe",
"oid": "bbbbbbbb-1111-2222-3333-cccccccccccc",
"rh": "0.ASgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZANQ.",
"scp": "FabricWorkloadControl",
"sub": "X0Wl85UA-uOmdkQz5MoT-hEgYZXDq9FYdS8g2bFUaZA",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff",
"unique_name": "user1@constso.com",
"upn": "user1@constso.com",
"uti": "_llZwmJoSUiHv-kw6tfDAA",
"ver": "1.0"
}

См. раздел IAuthenticationService.

Примечание.

Все проверки в нашем примере кода предназначены для маркеров версии 1.0.

Авторизация

После подтверждения того, что запрос поступает из службы Fabric (через appToken), Fabric проверил, что у пользователя есть необходимые разрешения для выполнения действия на основе метаданных разрешений Fabric.

Проверка подлинности и авторизация запросов из рабочей нагрузки в Fabric

Запросы на управление рабочей нагрузкой

API управления рабочей нагрузкой — это специальные API Fabric, поддерживающие рабочие нагрузки с помощью управления жизненным циклом элементов Fabric. Эти API используют тот же формат заголовка авторизации SubjectAndAppToken1.0.

SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"

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

  • subjectToken: маркер, делегированный пользователем (полученный через поток OBO), представляющий пользователя, от имени которого выполняется операция. Fabric проверяет, есть ли у пользователя необходимые разрешения для выполнения необходимых действий.

  • appToken: маркер, характерный для приложения рабочей нагрузки. Fabric проверяет, что этот маркер получен из приложения Microsoft Entra рабочей нагрузки, к которой принадлежит соответствующий элемент Fabric, и находится на клиенте издателя рабочей нагрузки.

См. ValidatePermissions метод в AuthorizationHandler.

Общедоступные API

Чтобы вызвать общедоступные API Fabric, рабочая нагрузка должна получить стандартный токен Microsoft Entra OBO с соответствующими областями API и передать его в качестве маркера носителя в заголовке авторизации запроса.

См. статью FabricExtensionController.

Проверка подлинности и авторизация запросов из рабочей нагрузки FE в рабочую нагрузку BE

Заголовок авторизации

Заголовок авторизации в запросе, отправляемом из рабочей нагрузки FE в рабочую нагрузку BE, использует стандартный маркер носителя.

Проверка подлинности

Метод AuthenticationControlPlaneCall в рабочей нагрузке BE отвечает за проверку маркера. Основные проверки выполняются:

  • Время существования маркера: гарантирует, что маркер находится в пределах допустимого периода использования.

  • Подпись. Проверяет подлинность маркера.

  • Аудитория: проверяет, соответствует ли аудитория маркера рабочей нагрузке приложению Microsoft Entra.

  • Издатель: проверяет издателя маркера.

  • Допустимые области. Проверяет области, к которым разрешен доступ маркера.

Авторизация достигается путем вызова метода ValidatePermissions . Этот метод вызывает resolvePermissions API в конечной точке управления рабочей нагрузкой Fabric для соответствующего элемента Fabric и проверяет наличие у пользователя необходимых разрешений для операции.

Длительные операции — маркер обновления

Авторизация достигается путем вызова метода ValidatePermissions . Этот метод вызывает resolvePermissions API в конечной точке управления рабочей нагрузкой Fabric для соответствующего элемента Fabric и проверяет наличие у пользователя необходимых разрешений для операции.

Если рабочие нагрузки включают длительные операции, например как часть JobScheduler, может возникнуть ситуация, когда время существования токена недостаточно. Дополнительные сведения о том, как пройти проверку подлинности длительного выполнения процессов OBO.