Not sure I understood your need.
If you do nothing, your eSpaces will use their own USER entity table (this corresponds to having the User Provider eSpace property set to "(Current)").
When you create an eSpace and set it as User Provider, you are saying that eSpace (step 1) and all the ones that use it as User Provider (step 3) will share a given USER entity table, therefore having the same group of users and authentication mechanisms.
The fact that eSpaces reference the same system USER entity table may be confusing... In fact, the USER entity is a multitenant entity, that is, it is prepared to have partitioned data per eSpace. So despite all eSpaces having a reference to the USER entity, in fact when you query it, only the data that the eSpace is configured to see will be returned. If the eSpace has the User Provider eSpace set to "(Current)", queries and authentication mechanisms will apply only to the set of users that belong to that eSpace. If the eSpace is using another one as User Provider, the same applies for a different group of users.
Was this somehow clear? Cheers,
Ok, got it now! To support your need, the User entity has an attribute Extension_Id which you should use to reference a record of an entity that extends the User entity. The general idea is the following:
Check the attached oml for a sample. Hope this helps, cheers.
Well, the "best" solution actually depends on your business scenario.
Do all those eSpaces belong to the same portal? If so, you should consider using a unique User Provider for all users, and then use Permission Areas, or Roles, to segment users (Developer, Collaborator, Customer...). If they all belong to the same portal, I guess it would make no sense to keep them as separated users.
Have you tried Enterprise Manager? It already provides you with a user management back office, login architecture, roles, company hierarchy and some more stuff. You can use Permission Areas as Privileges in your eSpaces to do particular actions, and then create Roles in Enterprise Manager to group such Privileges. This way you can create a Developer Role which has different Privileges than a Customer Role. In your eSpaces you can then segment what each Role can do and in Enterprise Manager you can see and configure which users belong to each Role. You can learn more about Enterprise Manager in the Academy, specifically in the last two lessons of the Developer Course 2.
On the other hand, if you are attempting to create some sort of multitenant portal, where the same app would serve different user sets (for different companies, for instance), then there are different solutions for that scenario. Is this the case?