Блог

Главная - Вопросы по программированию - Управление доступом на основе групп Azure B2C не показывает UserMessage

Управление доступом на основе групп Azure B2C не показывает UserMessage

#azure-ad-b2c #identity-experience-framework

#azure-ad-b2c #identity-experience-framework

Вопрос:

Я работал над внедрением управления доступом на основе групп для клиента B2C. Я настроил перехват API (POST), который принимает идентификатор объекта пользователя, проверяет, находится ли пользователь в разрешенных группах через Graph API и возвращает:

  • 200 OK при успешном завершении
  • Конфликт 409 при неудачном завершении

Ниже приведен объект, возвращаемый с 409:

 {
"version": "1.0.0",
"status": 409,
"userMessage": "User is not authorized for this application"
}

По какой-то причине это сообщение не отображается пользователю, а происходит перенаправление на
{{B2cUrl}}/#error=server_erroramp;error_description=AADB2C: User is not authorized for this application
Correlation ID: …8
Timestamp: …:03:39Z
amp;state=…

В моем пользовательском путешествии я включил следующий оркестр

 <OrchestrationStep Order="3" Type="ClaimsExchange">
   <ClaimsExchanges>
      <ClaimsExchange Id="RESTValidateProfile" TechnicalProfileReferenceId="REST-ValidateProfile" />
   </ClaimsExchanges>
</OrchestrationStep>

Как я могу получить сообщение об ошибке пользователя, отображаемое на странице входа для пользователя?

Ответ №1:

Вам необходимо вызвать технический профиль rest api из технического профиля проверки. Технический профиль проверки должен быть настроен на самоутверждающийся технический профиль (страница входа), чтобы затем он мог возвращать ему ошибку.

https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-rest-api-claims-validation#validate-the-user-input

В его текущем виде REST API вызывается после отправки страницы и запуска перенаправления. Поэтому любая ошибка просто отправляется обратно в приложение, поскольку в это время страница не отображается.

Комментарии:

1. Текущий поток представляет собой технический профиль в TrustFrameworkBase с расширением ValidationTechnicalProfile в зависимости от приложения. Это означает, что я не могу поместить технический профиль проверки в профиль, который уже есть в расширении. Как я мог решить эту проблему?

2. Почему вы не можете? Не соответствует вашему описанию. Возможно, используйте имена технических профилей, чтобы я мог понять контекст.

3. Извините, я пройду дальше: в TrustFrameworkBase в каждом TrustFrameworkExtension есть SelfAsserted-LocalAccountSignin-Email (зависит от приложения, их 6), есть логин-неинтерактивный, который используется в качестве технического профиля проверки. Моя групповая проверка зависит от приложения, поэтому ее необходимо поместить в TrustFrameworkExtensions, но поскольку login-Noninteractive уже используется в качестве профиля проверки, я не могу использовать REST-ValidateProfile групповой проверки в качестве профиля проверки в login-Noninteractive

4. Вы бы не вызывали это в login-noninteractive, вы бы назвали это техническим профилем проверки в SelfAsserted-LocalAccountSignin-Email. Но вы бы определили его и вызвали файл расширения, зависящий от приложения, если логика вызова REST также зависит от приложения. Вы можете добавить переопределение для SelfAsserted-LocalAccountSignin-Email в каждом файле, зависящем от приложения.

5. Спасибо за дальнейшее объяснение. Теперь у меня это работает.