Design Users Table For Single Sign In To Use Across Sub Domains

We have a site which has sub domains like: example.com - Main Site food.example.com fashion.example.com And each domain and sub domain has a different database, like this: ex

Solution 1:

The UserID you mentioned is only identical in a specific Users table in a single DB. It's actually not an identifier of any user in your domain. To identify users across multiple databases, you will need a domain-level ID for every user. A simple way is to add one more property (column) named UID or something like that to User class (table), of Global Unique Id (GUID, see https://msdn.microsoft.com/en-us/library/system.guid(v=vs.110).aspx) and use it as domain-level ID to identify users instead of UserId. This way you can freely store user information in multiple databases in your domain. So:

• You can hold only domain-level ID in every sub-domain's database and use that ID to query full user profiles from the main domain DB. Pros: costs less memory. Trade-off: in a distributed system, it takes longer to query user information from sub-domain because the information residing in main DB.
• You can hold full user information in all DB, including main's and subs'. Pro: faster queries. Cons: costs more memory and when a user information changes, you will have to synchronize it across all databases.

Solution 2:

1] You need to have separate user table in all three database because there is no referential integrity of foreign key.Here if any database goes down, then other domains will up and running.Trade-off is, database management needs more maintenance but performance will not hamper.

Alternatively you can produce following database plan.

1] Keep one database for all three domain(One main domain and two sub domain)

2] Create one user table having two status flag for food_order, fashion_order

3] Create order table for food and fashion separate

4] There are three possibility that user orders i)Food or ii)Fashion or iii)Food/Fashion both.

5] Keep update status flag as per order either Food or Fashion or Food/Fashion both.

Here trade-off is that, if your database goes down, then your all three website goes down.So Keep very good disaster recovery model of database.

Solution 3:

Some options:

1. Only store your users in the main DB. Then ...

   • use an encrypted cookie to store all the user information you care about. This cookie would be readable by all the other sub-domains.
   • OR only store the user_id in the cookie and use back channel communication over an API to get the users information from the main site.
   • OR use one of the many existing fairly standard user information sharing protocols to get user information into the other sites, where you can then store it in the current session store. Some examples include CAS and OAuth.

2. Store your user information in all the DBs. You would typically get the information to the other DBs by using one of...

   • regularly scheduled synchronization job
   • back channel communication when the user logs in
   • one of the fairly standard user information sharing protocols (as above)

With option 1, your main DB going down would impact all the other sites. With option 2, the non-main DBs are pretty much cached copies, and you need to deal with cache invalidation.

Which option you pick will mostly depend on your specific business needs.

Solution 4:

I think how you started off in your question is your best bet.

Your best bet is to have one users table, and three configuration tables. The one users table will be linked to the SSO functionality, which will validate users, their overall profile and credentialing information. Every service/website irrelevant of the domain which use the federated SSO validating the users cookies. I.e. pretend everything was the same, except you are using google web federation for SSO. The data stored in google you don't really care about (except maybe there are field that you do, maybe user name, etc...) No matter which domain you are on, the first thing you do is make a call to SSO, and see if the user is already logged in, if they aren't direct them there, and when they are done, they will get a redirect back to your subdomain.

If they are logged in, then no redirect, but you get the jwt token, which would allow converting saved userIds (or UID) to actual information.

Say for instanced a logged in user buys something from fashion.example.com. You could add a row to your orders table, which happens to have a column called "userId". If that site wanted to publish on the front page "user X ordered Y", after getting the order from the table, you would call the SSO service to get back a jwt with the users information using the SSO token. If for some reason you wanted to store configuration that is different by subdomain, then that subdomain would create its own "users" or "configuration" table, and the key would be linked to the UID in the SSO service. Whether there is a unique PK is up to you (with a FX to the UID) or if the PK is the UID.

This let's you completely separate the the domains from each other. And let's your subdomain decide if they need a "users" table or not.

You really have 4 domains, not 3, treat it as 1 SSO authentication domain and 3 sites. The SSO will have the auth table, and each site domain may or may not have its own user table if it needs to. That user table would have an FK to the SSO table, without needing to enforce an FX constraint. (FK constraint, if somehow could be enforced would actually be bad, because you wouldn't want an SSO service, to have to know about the subdomains when a user's account should be deleted, the fact these are all different database is already awesome.)

And because SSO/user management is really its own domain, that is exactly why there are SaaS solutions that support user management directly, for the explicit reason that this is actually complicated and reimplementing it should be avoided at all costs.

TL;DR. You really have 4 domains, not 3, treat it as 1 SSO authentication domain and 3 sites. The SSO will have the auth table, and each site domain may or may not have its own user table if it needs to.