Я изо всех сил пытаюсь понять, как настроить Azure B2 C для мультитенантной аутентификации, в частности для получения доступа к адресу электронной почты пользователя, который входит в систему через внешний Azure AD (мы ' Мы заинтересованы в том, чтобы наши клиенты могли входить в систему либо через «Локальную учетную запись» (адрес электронной почты, управляемый B2 C), либо через свой собственный Azure AD).
Ключевая часть проблемы, на которой я Попытка привести к передаче адреса электронной почты вошедшего в систему пользователя через конечную точку REST, где нашему приложению нужно сделать некоторые внутренние действия, чтобы ввести дополнительные заявки c, указанные в приложении, которые используются позже. Помимо того, что наша конечная точка REST получает адрес электронной почты, все остальное работает.
У меня есть технический профиль "Common AAD", подобный этому:
<TechnicalProfile Id="Common-AAD">
<DisplayName>Work Account</DisplayName>
<Description>Login with your Work Account</Description>
<Protocol Name="OpenIdConnect"/>
<Metadata>
<Item Key="METADATA">https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration</Item>
<Item Key="client_id">my_client_id</Item>
<Item Key="response_types">code</Item>
<Item Key="scope">openid email profile</Item>
<Item Key="response_mode">form_post</Item>
<Item Key="HttpBinding">POST</Item>
<Item Key="UsePolicyInRedirectUri">false</Item>
<Item Key="DiscoverMetadataByTokenIssuer">true</Item>
<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
</Metadata>
<CryptographicKeys>
<Key Id="client_secret" StorageReferenceId="B2C_1A_AADAppSecret"/>
</CryptographicKeys>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="oid"/>
<OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid"/>
<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
<OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
<OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
<OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
<OutputClaim ClaimTypeReferenceId="signInName" />
<OutputClaim ClaimTypeReferenceId="otherMails" />
<OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
<OutputClaim ClaimTypeReferenceId="upn" PartnerClaimType="upn" />
</OutputClaims>
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
<OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
<OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
<OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
</OutputClaimsTransformations>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin"/>
</TechnicalProfile>
В оркестровке я Я приказываю B2 C передать кучу этих утверждений в REST API, размещенный в приложении, чтобы мы могли выполнять нашу внутреннюю обработку:
<TechnicalProfile Id="REST-GetProfile-Dev">
<DisplayName>Do some custom logic</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ServiceUrl">https://the-endpoint.com</Item>
<Item Key="AuthenticationType">None</Item>
<!-- REMOVE the following line in production environments -->
<Item Key="AllowInsecureAuthInProduction">true</Item>
</Metadata>
<InputClaims>
<!-- Claims sent to your REST API -->
<InputClaim ClaimTypeReferenceId="objectId" />
<InputClaim ClaimTypeReferenceId="email" />
<InputClaim ClaimTypeReferenceId="sub" />
<InputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
<InputClaim ClaimTypeReferenceId="userPrincipalName" />
<InputClaim ClaimTypeReferenceId="displayName" />
<InputClaim ClaimTypeReferenceId="otherMails" />
<InputClaim ClaimTypeReferenceId="upnUserName" />
<InputClaim ClaimTypeReferenceId="alternativeSecurityId" />
<InputClaim ClaimTypeReferenceId="upn" />
<InputClaim ClaimTypeReferenceId="signInName" />
<InputClaim ClaimTypeReferenceId="socialIdpUserId" />
<InputClaim ClaimTypeReferenceId="identityProvider" />
<InputClaim ClaimTypeReferenceId="authenticationSource" />
</InputClaims>
<OutputClaims>
<!-- bunch of app specific claims -->
</OutputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
Однако я никогда не могу получить адрес электронной почты , или что-нибудь, что содержит адрес электронной почты вошедшего в систему пользователя, проходящего через.
Я пытался отследить обработку, которая определена в файлах Custom Policy XML, и это сложно. Честно говоря, я исследовал это и пробовал добавлять всевозможные дополнительные утверждения к результатам различных этапов, но у меня это просто не работает.
Любая помощь в подробностях того, как получить адрес электронной почты был бы очень признателен пользователь, вошедший через внешний Azure AD, переданный на этап оркестрации REST.
Спасибо.
** Big Edit **
В ответ Джасу Сури, я все сбросил, применил приведенные ниже изменения, как было предложено, но я все еще не вижу этой работы.
Вот моя TrustFrameworkBase. xml: TrustFrameworkBase. xml
Вот мои TrustFrameworkExtensions. xml: TrustFrameworkExtensions. xml
Вот моя Проверяющая сторона (SignInSignUpMulti. xml) файл: SignInSignUpMulti. xml
Теперь, глядя на мой сценарий ios:
Когда я вхожу в систему с «локальной» учетной записью, я увидеть, как этот тип информации передается в мою конечную точку отдыха во время путь пользователя:
{
"objectId": "1e91bfba-17a1-43b6-a451-9896fc3c1061",
"signInNames.emailAddress": "email@example.com",
"displayName": "User DispName",
"signInName": "email@example.com",
"authenticationSource": "localAccountAuthentication"
}
Это идеально . Я могу взять эту информацию и собрать дополнительные требования для возврата, и все будет работать именно так, как я хочу.
Когда я вхожу в учетную запись AD, привязанную к my org, я получаю следующее:
{
"objectId": "a_guid",
"sub": "Not supported currently. Use oid claim.",
"userPrincipalName": "cpim_a_guid@TENANT.onmicrosoft.com",
"displayName": "ThisIs Correct",
"upnUserName": "14218711-5dd1-4a81-8e04-77bd08298aaf",
"alternativeSecurityId": "{\"type\":6,\"identityProvider\":\"https://login.microsoftonline.com/a_guid/v2.0\",\"key\":\"a_key\"}",
"identityProvider": "https://login.microsoftonline.com/a_guid/v2.0",
"authenticationSource": "socialIdpAuthentication"
}
Мне не хватает адреса электронной почты (или адреса для входа пользователей).
То же самое происходит, когда я пытаюсь войти в систему как внешний AD:
{
"objectId": "a_guid",
"sub": "Not supported currently. Use oid claim.",
"userPrincipalName": "cpim_a_guid@TENANT.onmicrosoft.com",
"displayName": "ThisIs Correct",
"upnUserName": "9c865de4-2898-4b18-998b-7fa151f6623d",
"alternativeSecurityId": "{\"type\":6,\"identityProvider\":\"https://login.microsoftonline.com/a_guid/v2.0\",\"key\":\"a_key\"}",
"identityProvider": "https://login.microsoftonline.com/a_guid/v2.0",
"authenticationSource": "socialIdpAuthentication"
}
Если я смогу решить, как пройти через адрес электронной почты или адрес для входа, я был бы очень счастлив.
Событие во время отладки, если я все равно заставлю пользователя войти в систему, я проверю User.Identity, и хотя я вижу утверждения о том, что мой rest api возвращается во время путешествия, у меня все еще нет претензий, похожих на адрес электронной почты, который я ожидаю (надеюсь) увидеть. Я определенно могу работать в любом случае - адрес электронной почты, переданный в REST API, или адрес электронной почты, указанный в последнем наборе утверждений, который получает приложение.
Любая помощь будет очень признательна.