Azure AD B2C - резервное значение LookupValue

В настоящее время я работаю над изменением политики HRD в соответствии с нашими потребностями. У меня есть утверждение domainParameter, которое содержит часть домена электронной почты для входа пользователя. Я использую преобразование LookupValue для сопоставления разных доменов. У нас есть несколько групп, которые будут использовать нашу политику, некоторые из которых имеют несколько доменов, в которых их пользователи могут регистрироваться. Итак, наш поиск показывает примерно следующее:

<ClaimTransformation Id="GroupLookup" TransformationMethod="LookupValue">
    <InputClaims>
        <InputClaim ClaimTypeReferenceId="domainParameter" TransformationClaimType="inputParameterId" />
    </InputClaims>
    <InputParameters>
        <InputParameter Id="company1.domain1" DataType="string" Value="company1" />
        <InputParameter Id="company1.domain2" DataType="string" Value="company1" />
        <InputParameter Id="company2.domain1" DataType="string" Value="company2" />
        <InputParameter Id="errorOnFailedLookup" DataType="boolean" Value="false" />
    </InputParameters>
    <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="domainGroup" TransformationClaimType="outputClaim" />
    </OutputClaims>
</ClaimsTransformation>

Это, очевидно, отлично работает, когда домен является одним из перечисленных доменов, однако мы также хотим разрешить локальным учетным записям регистрироваться / входить и группировать их в группу под названием local, хотя имя не имеет значения. Из того, что я могу найти, я не могу понять, каким образом можно назначить утверждению конкретное значение, если оно не сможет выполнить поиск. Я могу получить ошибку при поиске, изменив этот параметр, но, присвоив ему значение, я не вижу способа сделать это. Я пробовал использовать атрибут DefaultValue в «domainGroup» как в InputClaim, так и в OutputClaim, и ни один из них не работал. Я также не вижу опции для селекторов с подстановочными знаками в LookupValue.

Кто-нибудь знает, как это сделать? Я просматривал документацию пару дней и пока не нашел ничего ценного.


azure-ad-b2c azure-ad-b2c-custom-policy
person D3_JMultiply    schedule 17.11.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Если поиск завершился неудачно, результат преобразования ваших утверждений равен нулю. Нет, он не может быть установлен напрямую на что-то другое, но может быть косвенно:

В этом примере я объясняю, как, когда результат вашего метода ClaimsTransform равен нулю, мы выполняем логическое сравнение, а окончательное значение isKnownCustomer - ЛОЖЬ. Это отправляет пользователя на страницу входа в локальную учетную запись.

Возможности преобразования определены здесь

https://docs.microsoft.com/en-us/azure/active-directory-b2c/string-transformations#lookupvalue

В образце подробно объясняется, как я заставляю его выполнять запрошенную вами логику. «Мы также хотим разрешить локальным учетным записям регистрироваться / входить ... если поиск не проходит»

https://github.com/azure-ad-b2c/samples/blob/master/policies/home-realm-discovery-modern/readme.md

«Первый шаг пользовательского пути представляет собой страницу для сбора адресов электронной почты пользователей. На странице используется проверка ввода, поэтому предоставляется действительный адрес электронной почты.

На следующем этапе пути выполняется несколько преобразований выходных утверждений, чтобы проверить, известен ли домен.

Сначала преобразование выходных утверждений, называемое ParseDomain, извлекает имя домена электронной почты для предоставленного адреса электронной почты и копирует его в domainParameter утверждение.

Используя преобразование выходных утверждений DomainLookup, domainParameter сравнивается со списком известных доменных имен. Если имя домена совпадает, DomainLookup выведет заявку knownDomain = True, иначе будет null.

Чтобы вернуть окончательное значение True или False в зависимости от того, был ли домен известен, вызывается преобразование выходных утверждений CheckDomainParameterValue, которое сравнивает knownDomain с dummyTrue (внутри которого содержится значение True). Наконец, мы получаем иск isKnownCustomer, который равен либо True, либо False. Это предотвращает наличие нулевого значения в случае knownDomain.

Шаги 3 и 4 обрабатывают сценарий, в котором домен был неизвестен, и имитируют шаги для входа через локальную учетную запись ».

person Jas Suri - MSFT    schedule 18.11.2020
comment
Я думаю, вы неправильно поняли, что я ищу. Люди уже правильно отправляются на локальную страницу регистрации, когда они входят в домен, который не найден. Сам РЛР работает нормально. Мы добавляем к токену дополнительное утверждение, называемое группами. Поскольку у нас есть несколько партнеров, учетные записи этих партнеров нуждаются в разных разрешениях в нашем приложении по сравнению с теми, кто регистрируется из более широкого мира. Нам нужно, чтобы заявка domainGroup была заполнена, потому что затем мы добавляем значение заявки в список строк, аналогично тому, как домен добавляется в список поставщиков. - person D3_JMultiply; 18.11.2020
comment
По моему мнению, возможность присвоения значения в случае неудачного поиска должна быть основным требованием для любой подобной системы. Игнорируйте аспект HRD, поскольку он уже работает. Что нам нужно, так это какой-то способ сказать Установите значение утверждения для этих значений, если утверждение соответствует этим элементам, в противном случае установите для него это значение. Если вы думаете об этом, как о большинстве языков программирования, то, что нам нужно, похоже на оператор switch с предложением по умолчанию. Если что-то подобное недоступно в политиках, для меня это серьезное упущение в функциональности. - person D3_JMultiply; 18.11.2020
comment
Почему бы не инициализировать domainGroup в точке аутентификации localAccount, используя значение по умолчанию в SelfAsserted-LocalAccountSignin-Email? <OutputClaim ClaimTypeReferenceId="domainGroup" AlwaysUseDefaultValue="true" DefaultValue="foo" /> . Этот технический профиль выполняется, только если domainGroup имеет значение null. - person Jas Suri - MSFT; 18.11.2020
comment
Я думал об этом, и, вероятно, именно так я и закончу, но если я это сделаю, мне нужно переместить преобразование, которое добавляет группу в список, через преобразование AddItemToStringCollection, пока после этого на каком-то этапе, который запускается как на предоставленных, так и на локальных учетных записях. Вот что я пытаюсь понять. - person D3_JMultiply; 18.11.2020
comment
Хорошо, в итоге я просто добавил новый OrchestrationStep в путь пользователя. Размещение любых OutputClaimsTransformations в SelfAsserted-LocalAccountSingin-Email вызывало внутреннюю ошибку сервера, поэтому мне пришлось добавить его на отдельный шаг оркестровки. - person D3_JMultiply; 18.11.2020