azureazure-ad-b2cidentity-experience-framework

Linking federated user to local B2C user through email address


I'm working on a proof of concept hooking up a SaaS application with Azure B2C. The out of the box user flows all work nicely but really don't deliver the functionality that I require. So welcome for the azure-ad-b2c samples to guide om on creating custom policies that allow me to get the job done, up to a point. I also read a good blog post series from @rbrayb f.e. link-local-account-with-federated-account (thanks for those) which gave me a lot of information and a policy to start with.

Here comes the tricky part, at least for me :

First : The thing is that I am writing a multi-tenant SaaS application that will have a predefined (and configured) set of identity providers (AZureAD, Google, Auth0). Tenants will need to be able to use multiple IDP's because of collaboration within the application.

So, is there a way to have these policies redirect users to their IDP based on their email address using a domain hint or something?

Second: the policy relies on de external IDP oid claim to match the external and local created user. Though, in my scenario, it's possible that through user invitation from the application, this oid is unknown at the time of local user creation. I would like to use the email address to link the user. I tried altering some PartnerClaimType's but to no avail.

<OutputClaims>
    <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="oid"/>
    <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid"/>
    .
    .
    .
</OutputClaims>

So, Any direction on which claim transformations to alter?

Thanks for reading and I hope to get some guidance!


Solution

  • There are two samples to implement the email address part; here and here.

    You should use issuerUserId and:

    <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />
    

    But the IDP may have different names for these in the mapping i.e. "oid" and "iss".

    They may not even exist!

    Also there is a limit on the number of items in the identityProvider StringCollection. I think it's around 5?