samples icon indicating copy to clipboard operation
samples copied to clipboard

force-unique-email-across-social-identities does not seem to work how it is intended

Open luismendiola98 opened this issue 3 years ago • 4 comments
trafficstars

I was testing the force-unique-email-across-social-identities policy, but I was able to sign in with my google and twitter account (which both use the same email address) with out getting the error message that an account with the same email address is already registered. Am I missing something? Thank you for your assistance in advance.

luismendiola98 avatar May 18 '22 23:05 luismendiola98

Did you uncomment this step?

https://github.com/azure-ad-b2c/samples/blob/5c3dfeeff3c2cf105e1f4505b193a582a1b1abe2/policies/force-unique-email-across-social-identities/policy/TrustFrameworkExtensions.xml#L260

JasSuri avatar May 19 '22 07:05 JasSuri

I did and I got the same error as the person that created this issue. I see that you were able to point them in the right direction. It looks like they changed "strongAuthenticationEmailAddress" to "signInNames.emailAddress". I made this change, but I still did not get the error message expected for accounts with same email address. Is there more I need to add/edit to the files provided in this sample to make it work?

luismendiola98 avatar May 19 '22 16:05 luismendiola98

The sample is assuming that the social email/identifier is stored in strongAuthenticationEmailAddress.

By default, the email of social accounts aren't stored on the user at all, so nothing you change the above to would work, until you start to store the users social email first. Then whatever attribute you choose to store it in, is the attribute you should check for uniqueness.

changed "strongAuthenticationEmailAddress" to "signInNames.emailAddress". I made this change, but I still did not get the error message expected for accounts with same email address.

That would only work if when a social user is created, their email is stored in signInNames.emailAddress. AAD-UserWriteUsingAlternativeSecurityId creates the users profile for social account sign up. You need to map the users email claim from the Social IdP technical profile, then persist that to a uniquely constrained attribute (eg signInNames or strongAuthenticationEmailAddress) attribute using AAD-UserWriteUsingAlternativeSecurityId.

JasSuri avatar May 19 '22 17:05 JasSuri

Thank you for explaining how to make this sample work. I will go over the documentation once more to better understand the structure of the policy files so that I can make the necessary changes at the right places. I will let you know how it goes as soon as I make the changes.

luismendiola98 avatar May 19 '22 19:05 luismendiola98