Смягчающий сценарий, в котором заявка от внешнего IdP может быть либо строкой, либо строкой

Моя компания должна вступить в федерацию с несколькими внешними поставщиками идентификационной информации (используя стандартные отраслевые решения, такие как AD FS, F5 и т. Д.), Которые выдают групповые заявки.

Когда у пользователя несколько групп, эти IdP выдают ответ с утверждением в следующем формате:

"groups": ["Domain Users", "US Users", "Administrators"]

Но когда у пользователя всего одна группа:

"groups": "Domain Users"

Вот ClaimType b2cGroups, как определено в TrustFrameworkExtensions:

<ClaimType Id="b2cGroups">
    <DisplayName>Groups</DisplayName>
    <DataType>stringCollection</DataType>
    <AdminHelpText>User's groups.</AdminHelpText>
</ClaimType>

И OutputClaim во внешнем техническом профиле IdP:

<OutputClaim ClaimTypeReferenceId="b2cGroups" PartnerClaimType="groups" />

В текущей конфигурации B2C выдает фатальное исключение, когда у пользователя есть только одна группа:

The data type 'String' of the claim with id 'groups' does not match the DataType 'StringCollection' of ClaimType with id 'b2cGroups' specified in the policy.

Я могу изменить определение утверждения с stringCollection на string:

<ClaimType Id="b2cGroups">
    <DisplayName>Groups</DisplayName>
    <DataType>string</DataType>
    <AdminHelpText>User's groups.</AdminHelpText>
</ClaimType>

Но теперь, когда у пользователя несколько групп:

The data type 'StringCollection' of the claim with id 'groups' does not match the DataType 'String' of ClaimType with id 'b2cGroups' specified in the policy.

Исключение происходит во время выполнения самого технического профиля OIDC или SAML2, поэтому я не могу использовать преобразование утверждений для управления данными. Кажется, что B2C не снисходителен к этой потенциальной несогласованности в типах данных, что верно в теории, но на практике основные решения для федеративной идентификации (такие как AD FS, который также является продуктом MS) не придерживаются этого стандарта.

Это стало серьезной проблемой, которая, если ее не решить, заставит нас разорвать существующую инфраструктуру B2C и перейти на другое решение CIAM. Есть ли исправление или хитрость, которые я могу применить для устранения этой проблемы?


person Daniel Krasnove    schedule 02.04.2021    source источник


Ответы (1)


Единственный обходной путь - не возвращать заявку в техническом профиле IdP, а вместо этого вызывать API на следующем шаге, получать значение от IdP и всегда возвращать массив обратно в B2C.

person Jas Suri - MSFT    schedule 02.04.2021
comment
Я удалил претензию тем временем, но, если я правильно понимаю, единственный способ получить эту претензию - это организовать дополнительный метод получения ее от IdP, например, с помощью вызова отдельного API, предоставляемого клиентом? Я наблюдаю ту же проблему, когда у пользователя несколько имен, адресов электронной почты и т. Д. Похоже, AD FS выдает заявки, поскольку несколько клиентских IdP в AD FS демонстрируют одинаковое поведение. Нет ли собственного решения, использующего технический профиль AD FS OIDC / SAML2? К сожалению, мы не можем попросить всех наших клиентов, использующих AD FS, изменить свою конфигурацию только для нас. - person Daniel Krasnove; 03.04.2021
comment
Вы можете вызвать api прямо внутри своей настраиваемой политики B2C и передать значение группы в токен, который будет у вашего клиента. У B2C нет собственного решения для этого сценария, мы явно указываем тип данных утверждения. - person Jas Suri - MSFT; 03.04.2021
comment
Хм ... вот чего я боялся. Наши клиенты, IdP которых мы пытаемся объединить, не предоставляют API для получения утверждений, поэтому технический профиль RESTful использовать нельзя. - person Daniel Krasnove; 03.04.2021