Есть ли что-то особенное в заявках на имя и фамилию B2C? Не могу прочитать их из OIDC ClaimsProvider.

Мой поставщик утверждений OIDC (Okta) предоставляет значения given_name и family_name моему приложению тестовой оснастки OIDC.

Мой поставщик утверждений Azure B2C использует те же области, что и мое тестовое приложение, но я не могу получить данные given_name и family_name для добавления в утверждение B2C,

Области действия, используемые при вызове Okta CP:

<Item Key="scope">openid profile email</Item>

Отображение OutputClaims в Okta CP:

<OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" DefaultValue="default value from input ClaimsProvider: email"/>
<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" DefaultValue="default value from input ClaimsProvider: givenName"/>
<OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name" DefaultValue="default value from input ClaimsProvider: surname"/>

Эта конфигурация, похоже, не соответствует значениям для этих двух утверждений. Он действительно получает значения имени и адреса электронной почты, поэтому я уверен, что объем работ соблюдается. Используя DefaultValues ​​для отладки, я вижу это в тестовом приложении Azure SAML.


SAML Login Success
Attribute   Value
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress  [email protected]
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name  Joe Blow
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname default value from input ClaimsProvider: givenName
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname   default value from input ClaimsProvider: surname
http://schemas.microsoft.com/identity/claims/userprincipalname  [email protected]

azure-ad-b2c azure-ad-b2c-custom-policy
person user594102    schedule 17.01.2021    source источник
comment
Вы пробовали с более чем одним пользователем. Конфигурация мне нравится по этой ссылке developer.okta.com/docs / reference / api / oidc / # token. Кроме того, вы можете быстро протестировать с помощью портала Azure для добавления поставщика OIDC и быстро протестировать перед внедрением в настраиваемые политики. Как только он заработает, вы можете перейти к настраиваемой политике, чтобы получить ответ B2C в RP как SAML.   -  person Rohit Prasad    schedule 18.01.2021
comment
Да, все пользователи предъявляют одинаковые претензии. Я создал федерацию Okta, где B2C - это SAML SP для Okta IDP, которая работает с утверждениями. Я также пробовал встроенный поток B2C_1_SignUpIn. Это действительно работает, но это не совсем тот же сценарий, потому что я пытаюсь передать два атрибута имени непосредственно от поставщика входных утверждений в выходное утверждение (пропуская создание пользователя B2C и используя B2C только в качестве маршрутизатора), как описано здесь   -  person user594102    schedule 18.01.2021
comment
Я провел еще один тест с Azure AD через OIDC, он дает еще меньше значений (только имя). Правильно ли я полагаю, что любые утверждения, представленные OIDC userinfo_endpoint, должны быть доступны в моем TechnicalProfile как OutputClaim?   -  person user594102    schedule 19.01.2021
comment
Вы имеете в виду, что получаете подробную информацию при использовании пользовательских потоков, но не в настраиваемой политике. Если возможно, не могли бы вы поделиться файлом User Journey, а также связанным с ним техническим профилем, чтобы вы могли правильно сориентироваться в его части решения.   -  person Rohit Prasad    schedule 19.01.2021
comment
Я загрузил политику в [TrustFrameworkExtensionsGW.xml] (githleyub.com/hkelley AzureADB2CGateway / blob / main /)   -  person user594102    schedule 20.01.2021