I'm working on a Salesforce org with about dozen communities and a handful of identity providers. 

Even when multiple communities share the same identity provider, they may have different security levels, causing the identity provider to provide different security identifiers for the same users based on which community this user is accessing.  We are trying to figure out how to make them work nicely together without causing any security breach, give users a good experience, and have some elegance in the solution. Now, let's look at some scenarios and ask some questions.  Sorry for the complexity, but this is based a real life challenge, modified to increase technical clarity and to hide irrelevant details. It's not something I conjure up to torture my brain and your :-)

Scenario I: 

I1.  Community C1 uses identity provider IdP1. 

I2.  Community C2 uses identity provider IdP2. 

I3.  IdP2 is different from IdP1, provider different user identifiers but the same email address in their SAML assertions. 

I4.  Currently, we create two different user records and two different contact records, one for C1, one for C2. 

I5.  We are urged to de-dup the two contact records.  If we do so, the two community user records will both look up to the same contact record.  Would that work? 

Scenario II: 

II1.  Let's continue to consider community C1 and C2 as described in I1-I4. 

II2.  We are wondering whether it's possible to create only one user record for the community user, so the user can login once and access two communities, C1 & C2. 

II3.  Instead of using the user identifiers from IdP1 & IdP2, how about we use the common email address as the federation ID? 

II4.  In our JIT handler newUser method, we can search for an existing user with the email ID.  If one exists, we return it.  That should work, right? 

II5.  For existing users that are already using user identifiers from IdP1 or IdP2, can we change the federation ID to email? 

Scenario III: 

III1.  Community C3 uses identity provider IdP3. 

III2.  Community C4 also uses identity provider IdP3. 

III3.  But C3 and C4 are at different security levels, so the identity provider two different user identifiers in its SAML assertions based on which community the user is trying to access. 

III4.  Currently, we create two different user records and two different contact records, one for C3, one for C4. 

III5.  We are urged to de-dup the two contact records.  We may as well create one user record also for both C3 and C4.  Would the idea described in II3-II5 work here also? 

Scenario IV.

IV1.  This is a continuation of scenario III. 

IV2.  Community C5 uses the same identity provider as C4.  It's also at the same security level as C4. 

IV3.  The identity provider is providing the SAME user identifiers for C4 and C5. 

IV4.  But C4 collects personal info of the user, while C5 collects business info of the user.  Each community collects their info in a post login screen. The way they do it is so weird that I want to spare you a headache, though I have drawn a diagram in case we get in a meeting to discuss this. 

IV5.  The business owner of C4 say it's important to never share the C4 contact info with other communities. 

IV6.  C4 is already in production and C5 is about to go to production.  And they are going to mess up each other.  

IV7.  Idea 1: Two users, two contacts.  Should I avoid the mess by creating two different contact records, one for C4 and one for C5?  Then what do I do with user record creation?  Do I have to create two users, consuming two licenses? 

IV8.  Idea 2: One user, two contacts.  Can I create one user, but add an additional contact look up field on the user object?  Would taht work? 

IV9.  Idea 3: One user, one contact.  Maybe it's best to use one user and one contact record for C4 and C5, then use FLS to hide the C4 specific fields. 

Of course, we are only talking about technical solutions.  Once there is a set of solution, I need to meet the security team to explain why it's secure and get approval.  Thanks in advance!  -- Charlie