The scenario is this: we have added Microsoft iDP to our app. The user can click the Microsoft Account button and use their MSA account to sign-up\sign-in.
When the user signs up we'd like to validate the e-mail against our database. If the user's email is in our database, let them proceed and signup; otherwise we'd like to prevent them from signing up and display an error message. This would prevent creating a User in our Azure B2C AD.
I used the following TechnicalProfile:
<TechnicalProfile Id="REST-ValidateEmail">
<DisplayName>Validate Membership Email</DisplayName>
<Protocol Name="Proprietary"
Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ServiceUrl">{Settings:AzureAppServiceUrl}/api/User/ValidateEmail</Item>
<Item Key="AuthenticationType">None</Item>
<Item Key="SendClaimsIn">Body</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email"
PartnerClaimType="UserEmail" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
Then added REST-ValidateEmail to LocalAccountSignUpWithLogonEmail as a validation technical profile.
<ClaimsProvider>
<DisplayName>Local Account</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
<Metadata>
<!--Demo: disable the email validation in development environment-->
<!--Demo action required: remove in production environment-->
<Item Key="EnforceEmailVerification">False</Item>
</Metadata>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="extension_MembershipEmail"
PartnerClaimType="UserEmail" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="REST-ValidateEmail" />
<ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
Added Application Insights debugging to the custom policy. I see UserJourney(s) being logged in Azure Portal. However no matter what I do I can't see trace logs from the REST API validate method I wrote and no calls to REST-ValidateEmail. Looks like it's not being called at all.
From this comment:
This trick of calling external API from my custom policy didn't work because we can't intercept sign-in\sign-up calls from social media. I tried creating a REST API that will take email as an input claim in my custom policy(TrustFrameworkExtensions) and further hit Graph API to check that this email exists in B2C or not will work only for local accounts and not for social media accounts.
If this holds true my attempt to get this scenario working won't flourish.
Does this comment holds true? If yes, is there any other way of intercepting Sign-in\Sign-up actions when working with 3rd party iDPs?
Note 1:
Exploring a bit more of TrustFrameworkBase.xml file I see this technical profile SelfAsserted-Social. I guess I'll have to use it instead of LocalAccountSignUpWithLogonEmail.
Yep, Note 1 I added in the question above is the way to go.
Just tested the scenario using SelfAsserted-Social technical profile instead of LocalAccountSignUpWithLogonEmail.
It worked and the rest API was called as expected. I can see the traces and the e-mail attempted inside the app service's log stream.
When providing an invalid e-mail, the user is able to see the error message returned from the custom validation endpoint.
This is the overridden\complemented technical profile that goes in TrustFrameworkExtensions.xml:
<ClaimsProvider>
<DisplayName>Self Asserted</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="SelfAsserted-Social">
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="REST-ValidateEmail" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
来源：https://stackoverflow.com/questions/58276894/is-it-possible-to-validate-the-email-claim-from-social-identity-providers-idps