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


Гибкие федеративные учетные данные идентификации (предварительная версия)

Гибкие учетные данные федеративной идентификации являются усовершенствованной функцией Microsoft Entra Workload ID, которая улучшает существующую модель учетных данных для федеративной идентификации. В этой статье объясняется, как работают эти учетные данные, их преимущества и текущие ограничения.

Гибкие учетные данные федеративных идентификаторов позволяют использовать ограниченный язык выражений для сопоставления входящих subject утверждений и включения пользовательских утверждений, что помогает сократить нагрузку на управление и решать проблемы масштабируемости в федерации удостоверений рабочей нагрузки. Если вы хотите упростить проверку подлинности для внешних рабочих нагрузок с помощью Microsoft Entra, в этом руководстве приведены необходимые аналитические сведения и шаги по использованию этой мощной функции.

Зачем использовать гибкие федеративные идентификационные данные?

Текущее поведение учетных данных федеративного удостоверения в рамках федерации удостоверений для рабочей нагрузки требует явного сопоставления при сравнении определенных subject, issuerи audience в учетных данных федеративного удостоверения с subject, issuerи audience, содержащимися в токене, отправленном в Microsoft Entra. При сочетании с текущим ограничением в 20 федеративных учетных данных удостоверения для заданного приложения или управляемой удостоверенности, назначаемой пользователем, можно быстро достичь пределов масштабирования.

Гибкие учетные данные федеративного удостоверения расширяют существующую модель учетных данных федеративного удостоверения, позволяя использовать язык ограниченного выражения при сопоставлении с входящими утверждениями subject. Кроме того, его можно использовать для расширения модели авторизации учетных данных федеративного удостоверения за пределами subject, issuerи audience утверждений путем включения определенных разрешенных пользовательских утверждений в учетные данные федеративного удостоверения.

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

Как работают гибкие федеративные идентификационные данные?

Гибкие учетные данные федеративного удостоверения не изменяют базовые функциональные возможности, предоставляемые учетными данными федеративного удостоверения. Эти отношения доверия по-прежнему используются для указания того, какому токену из внешнего провайдера удостоверений должно доверять ваше приложение. Вместо этого они расширяют возможности федеративных учетных данных, предоставляя сценарии, которые ранее требовали нескольких федеративных учетных данных удостоверения, теперь могут управляться с помощью одной гибкой федеративной учетной записи. Ниже приведены некоторые примеры.

  • Репозитории GitHub с различными рабочими процессами, каждая из которых выполняется в другой ветви (или используется в разных ветвях). Ранее для каждой ветви, в которой могут выполняться рабочие процессы, требуются уникальные учетные данные федеративного удостоверения. С помощью гибких учетных данных федеративного удостоверения этим сценарием можно управлять с помощью единого федеративного идентификатора.
  • Планы Terraform Cloud run_phases, каждый из которых требует уникальной учетной записи для федеративного удостоверения. С помощью гибких учетных данных федеративного удостоверения можно управлять этим, используя единые гибкие учетные данные федеративного удостоверения.
  • Многоразовые рабочие процессы GitHub Actions, где можно использовать wildcards для проверки пользовательского утверждения GitHub job_workflow_ref.

Заметка

Поддержка гибких федеративных учетных данных удостоверения в настоящее время поддерживается для сопоставления с выданными токенами GitHub, GitLab и Terraform Cloud. Эта поддержка существует только для федеративных учетных данных удостоверений, настроенных в настоящее время на объектах приложений. Вы можете создавать гибкие федеративные учетные данные и управлять ими только с помощью Microsoft Graph или портала Azure.

Гибкая языковая структура учетных данных федеративного удостоверения личности

Гибкое выражение учетных данных федеративного удостоверения состоит из трех частей: поиска утверждений, оператора и сравниваемого значения. См. следующую таблицу для разбивки каждой части:

Имя Описание Пример
Поиск утверждений Поиск утверждений должен соответствовать шаблону claims[‘<claimName>’] claims['sub']
Оператор Часть оператора должна быть просто именем оператора, разделенным от поиска утверждений и сравнения по одному пробелу. matches
Сравнение Сравниваемая величина содержит то, с чем вы планируете сравнить утверждение, указанное в запросе, — оно должно содержаться в одинарных кавычках. 'repo:contoso/contoso-repo:ref:refs/heads/*'

В совокупности пример гибкого выражения удостоверяющих данных федеративной идентификации может выглядеть как следующий объект JSON:

"claims['sub'] matches 'repo:contoso/contoso-repo:ref:refs/heads/*'."

Настройка учетных данных федеративного удостоверения с помощью Microsoft Graph

Чтобы обеспечить поддержку гибких функций федеративного удостоверения, ресурс federatedIdentityCredentials расширяется за счёт нового свойства claimsMatchingExpression. Помимо этого, свойство subject теперь допускает значение NULL. Свойства claimsMatchingExpression и subject являются взаимоисключающими, поэтому нельзя определить оба в учетных данных федеративного удостоверения.

  • audiences: аудитория, которая может отображаться во внешнем токене. Это поле является обязательным и должно иметь значение api://AzureADTokenExchange для идентификатора Microsoft Entra. В нем указано, что платформа удостоверений Майкрософт должна принимать в заявке aud входящего токена. Это значение обозначает Microsoft Entra ID в вашем внешнем поставщике удостоверений и не имеет фиксированного значения для всех поставщиков удостоверений — возможно, вам потребуется создать новую регистрацию приложения в вашем поставщике, чтобы она служила целевой аудиторией этого токена.
  • issuer: URL-адрес внешнего поставщика удостоверений. Должен соответствовать заявке издателя внешнего токена, который подлежит обмену.
  • subject: идентификатор внешней рабочей нагрузки программного обеспечения в поставщике внешних удостоверений. Как и значение аудитории, оно не имеет фиксированного формата, так как каждый IdP использует свой собственный идентификатор — иногда GUID, иногда идентификатор с разделителями двоеточия, иногда произвольные строки. Значение здесь должно соответствовать утверждению sub в токене, представленном сервису Microsoft Entra ID. Если определена subject, claimsMatchingExpression должен иметь значение NULL.
  • name: уникальная строка для идентификации учетных данных. Это свойство является альтернативным ключом, и значение можно использовать для ссылки на учетные данные федеративной идентификации через операции GET и UPSERT.
  • claimsMatchingExpression: новый сложный тип, содержащий два свойства, value и languageVersion. Значение используется для определения выражения, а languageVersion — для указания версии используемого языка выражений гибких федеративных удостоверений личности (FFL). languageVersion всегда должно иметь значение 1. Если определена claimsMatchingExpression, subject должен иметь значение NULL.

Функциональность гибкого языка выражения учетных данных федеративных удостоверений личности

Гибкие учетные данные удостоверений личности федеративной идентификации в настоящее время поддерживают использование нескольких операторов среди активированных издателей. Отдельные кавычки интерпретируются как escape-символы в гибком языке выражения учетных данных федеративного удостоверения.

Оператор Описание Пример
matches Позволяет использовать однозначные знаки (обозначаемые ?) и многозначные знаки (обозначаемые *) подстановочными знаками для указанного утверждения. “claims[‘sub’] matches ‘repo:contoso/contoso-repo:ref:refs/heads/*’”
“claims[‘sub’] matches ‘repo:contoso/contoso-repo-*:ref:refs/heads/????’”
eq Используется для явного сопоставления с указанным утверждением “claims[‘sub’] eq ‘repo:contoso/contoso-repo:ref:refs/heads/main’”
and Логический оператор для объединения выражений с несколькими утверждениями “claims[‘sub’] eq ‘repo:contoso/contoso-repo:ref:refs/heads/main’ and claims[‘job_workflow_ref’] matches ‘foo-org/bar-repo /.github/workflows/*@refs/heads/main’”

URL-адреса издателя, поддерживаемые утверждения и операторы по платформе

В зависимости от используемой платформы вам необходимо реализовать различные URL-адреса издателя, требования и операторы. Чтобы выбрать выбранную платформу, используйте следующие вкладки.

Поддерживаемые URL-адреса издателя: https://token.actions.githubusercontent.com

Поддерживаемые утверждения и операторы для каждого утверждения:

  • Утверждение sub поддерживает операторов eq и matches
  • Претензия job_workflow_ref поддерживается операторами eq и matches

Поставщики Azure CLI, Azure PowerShell и Terraform

Поддержки явных гибких учетных данных для федеративной идентификации пока что нет в Azure CLI, Azure PowerShell и провайдерах Terraform. Если вы пытаетесь настроить гибкие федеративные учетные данные при помощи любого из этих средств, возникнет сообщение об ошибке. Кроме того, если настроить гибкие федеративные учетные данные удостоверения с помощью Microsoft Graph или портала Azure и попытаться прочитать эти гибкие федеративные учетные данные удостоверения с помощью любого из этих средств, появится ошибка.

В Azure CLI можно использовать метод az rest для отправки запросов к REST API, чтобы создавать и управлять гибкими учетными данными федеративной идентичности.

az rest --method post \
    --url https://graph.microsoft.com/beta/applications/{objectId}/federatedIdentityCredentials
    --body "{'name': 'FlexFic1', 'issuer': 'https://token.actions.githubusercontent.com', 'audiences': ['api://AzureADTokenExchange'], 'claimsMatchingExpression': {'value': 'claims[\'sub\'] matches \'repo:contoso/contoso-org:ref:refs/heads/*\'', 'languageVersion': 1}}"