Identities created from external source allow duplicate email addresses

[onionhammer]

Re: https://github.com/Azure-Samples/active-directory-b2c-advanced-policies/blob/51798b065ef524be87c0f41339708ab4159bd54a/B2CPolicies/Final/b2ccharm.onmicrosoft.com_B2C_1A_base.xml

I'm not sure what mechanism B2C is using to validate that the user registering is not already registered, but this policy does not seem to persist the "signInNames" value for the record, this means someone who registers as an external user with "my.user@mycompany.com" can also register the same email "my.user@mycompany.com" and create two records in the directory with the same email address but different identity providers.

@rojasja

[onionhammer]

Record created with internal idp:

...snip...
  "odata.type": "Microsoft.DirectoryServices.User",
  "objectType": "User",
  "objectId": "1a526ff3-698c-471c-a220-0c336bfe066d",
  "deletionTimestamp": null,
  "accountEnabled": true,
  "signInNames": [
    {
      "type": "emailAddress",
      "value": "my.user@mycompany.com"
    }
  ],
  "assignedLicenses": [],
  "assignedPlans": [],

Record created with external idp:

  "objectId": "37fa11b0-4423-44cb-8273-2be58deee081",
  "deletionTimestamp": null,
  "accountEnabled": false,
  "signInNames": [],
  "assignedLicenses": [],
  "assignedPlans": [],
  "city": null,
  "companyName": null,

SignInNames is an empty array from the external idp.

[gsacavdm]

@omer-iqbal can you help with this?

[omer-iqbal]

The signInNames property is reserved for local accounts. Any email addresses stored in this property can be used with a password to sign the user in, without having to go to the social IDP. Therefore, the email addresses of social IDP users are stored in another property (otherMails) that is currently exposed through AD Graph.

Depending on a user's setting, an app's permissions or the IDP, a user's email address may never be sent in the token by the IDP. These policies are designed to work with the user id provided by the social IDP as the primary identifier, and without email address being sent in the token. That is why email is not relied upon.

Another aspect is that some social IDPs permit unverified email addresses on accounts, which could be sent in the token. Therefore, even if available, the default policies do no rely on email addresses since a malicious user can create a social IDP account with another user's email without verification and use it to take over another account.

However, if business rules require, these policies can be modified to check whether an email is verified by IDP and then rely on it for the kind of scenarios you mention. But that could adversely impact the number of users that can successfully sign up and sign in.

[onionhammer]

However, if business rules require, these policies can be modified to check whether an email is verified by IDP and then rely on it for the kind of scenarios you mention. But that could adversely impact the number of users that can successfully sign up and sign in.

Thanks for the reply @omer-iqbal

Are there any examples/snippets on how we might accomplish this? We're not currently using any social logins, we're only using local accounts and an external (oracle) identity provider for employees.