Я использую Microsoft Graph API для установки пользовательского значения (строки) для пользователя. Я пытался использовать как открытые, так и расширения каталога для хранения данных, и оба, кажется, отлично работают на уровне API, поскольку я могу вернуть данные пользователю.
Что я пытаюсь сделать дальше, так это получить значение этого расширения в требовании пользовательской политики B2C. Мне не удалось найти документацию, показывающую, как получить значение открытого расширения в настраиваемой политике, хотя в документах указано, что оно поддерживается, поэтому я попытался сделать это с расширением каталога.
Имя расширения — extension_{appId}_myString, оно было создано с помощью этого HTTP-вызова:
POST https://graph.microsoft.com/v1.0/applications/graph-app-object-id/extensionProperties
{
"name": "myString",
"dataType": "String",
"targetObjects": [
"User"
]
}
Я добавил определение типа претензии следующим образом:
<ClaimType Id = "myString">
<DisplayName>This is my string</DisplayName>
<DataType>string</DataType>
<DefaultPartnerClaimTypes>
<Protocol Name = "OpenIdConnect" PartnerClaimType = "extension_myString" />
<Protocol Name = "OAuth2" PartnerClaimType = "extension_myString" />
</DefaultPartnerClaimTypes>
</ClaimType>
Мое определение пути пользователя:
<UserJourney Id = "SignIn">
<OrchestrationSteps>
<OrchestrationStep Order = "1" Type = "CombinedSignInAndSignUp" ContentDefinitionReferenceId = "api.selfasserted">
<ClaimsProviderSelections>
<ClaimsProviderSelection ValidationClaimsExchangeId = "LocalAccountSigninExchange" />
</ClaimsProviderSelections>
<ClaimsExchanges>
<ClaimsExchange Id = "LocalAccountSigninExchange" TechnicalProfileReferenceId = "LocalAccountDiscoveryUsingID" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order = "2" Type = "ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id = "AADUserReadWithObjectId" TechnicalProfileReferenceId = "AAD-UserReadUsingObjectId" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order = "3" Type = "SendClaims" CpimIssuerTechnicalProfileReferenceId = "JwtIssuer" />
</OrchestrationSteps>
<ClientDefinition ReferenceId = "DefaultWeb" />
</UserJourney>
Я добавил это выходное требование в технические профили шагов 1 и 2:
<OutputClaim ClaimTypeReferenceId = "myString" PartnerClaimType = "extension_myString" />
В моем техническом профиле AAD-Common есть элементы метаданных идентификатора клиента b2c-extensions-app и идентификатора объекта, и я могу успешно завершить процесс аутентификации и перейти на экран JWT, но значение моего расширения там не отображается.
Я не понимаю, сделал ли я что-то не так или просто пропустил еще одно место, в которое следует добавить пользовательское требование, чтобы оно отображалось в токене. Есть ли какой-то способ «распечатать» значение утверждения, чтобы увидеть, присутствует ли оно во время выполнения политики? По крайней мере, я знаю, что значение есть, и мне нужно только поместить его в токен.
Еще одна вещь, в которой я не уверен, — это создание значения расширения через Graph API. Я использовал учетные данные графического приложения для получения токена Graph API, а также использовал его идентификатор объекта для создания расширения каталога для пользовательского объекта. С другой стороны, есть приложение b2c-extensions-app, которое запрашивает данные во время выполнения пользовательской политики. Насколько я понимаю, оба приложения работают с одним и тем же экземпляром Active Directory, поэтому это не должно быть проблемой, но, возможно, я что-то неправильно понял.
Для настройки пользовательского утверждения в пользовательском профиле Azure B2C в соответствии с https://learn.microsoft.com/en-us/azure/active-directory-b2c/user-flow-custom-attributes?pivots=b2c-custom. -policy#create-a-custom-attribute-through-azure-portal, вы должны добавить к идентификатору типа утверждения префикс extension_, чтобы обеспечить правильное сопоставление данных.
Спасибо
Вы также добавили выходное требование в раздел проверяющей стороны?
Да, под тегом проверяющей стороны у меня есть технический профиль с именем PolicyProfile, и его OutputClaims содержат тег <OutputClaim ClaimTypeReferenceId = "extension_myString" />
Вы не можете. Открытые расширения поддерживаются API MS Graph. Политика B2C использует AAD Graph за кулисами, она может извлекать только старый тип атрибута расширения. Чтобы получить открытое расширение, вам нужно вызвать свой собственный API, который, в свою очередь, вызывает API MS Graph для получения этого открытого расширения.
Вместо использования открытого расширения используйте старый тип:
https://learn.microsoft.com/en-us/graph/api/resources/extensionproperty?view=graph-rest-1.0
Теперь это имеет смысл! Мне просто нужно выяснить, почему я не могу прочитать расширение каталога и увидеть его в токене. Вы хоть представляете, что мне не хватает?
Логика вашей политики в порядке, единственное, что может быть, это то, что вы должны создать расширение с тем же AppId/objectId, что и в AAD-Common. Также избавьтесь от DefaultPartnerClaimTypes в определении претензии.
Это работает, большое спасибо! Единственное, что странно, это то, что если я обновляю расширение через MS Graph API и запускаю политику сразу после получения статуса 204, политика все равно возвращает старое значение, хотя она уже была успешно обновлена. Есть ли какой-то механизм синхронизации за кулисами? Потому что я ожидаю, что новое значение будет отражено немедленно.
Он реплицируется через множество контроллеров домена в течение минуты. Если вы нажмете другой DC, где вы сделали обновление, вы получите старое значение обратно. Поведение ожидаемое.
Я также пробовал это, но безуспешно. Я думаю, это как-то связано с тем, как я создал расширение каталога через Graph API. Также нет никаких документов о том, как получить значения открытых расширений, хотя это должно поддерживаться: learn.microsoft.com/en -нас/график/…