Гибкие федеративные учетные данные идентификации (предварительная версия)
Гибкие учетные данные федеративной идентификации являются усовершенствованной функцией 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}}"
Связанное содержимое
- Внедрение гибких удостоверений федеративной идентичности
- Настройка управляемого удостоверения, назначаемого пользователем, для доверия внешнему поставщику удостоверений
- Как создать, удалить, получить или обновить учетные данные федеративной идентичности в регистрации приложения.
- Ознакомьтесь с документацией по GitHub Actions, чтобы узнать больше о настройке рабочего процесса GitHub Actions для получения токена доступа от поставщика удостоверений Microsoft и доступа к защищенным ресурсам Microsoft Entra.
- Узнайте о формате утверждения .