Shared user database for multi-tenant scenario

Topics: Administration, Customizing Orchard, Writing modules
Sep 25, 2012 at 7:25 PM

I know this was discussed a few times but I haven't found any solution. Does anybody implemented sharing of the user database?

I need this now and currently am thinking along the lines of all the tenants replicating the user list to themselves through a web service from the main tenant.

What do you think?

Sep 25, 2012 at 9:57 PM

I with you on that, but I also need more such as shared tags, shared menus, shared feeds, shared custom content types, and even shared widgets. It would be nice to work on a method of having this option for tenants on more than just users, although users would definately be a good start.


Sep 25, 2012 at 11:06 PM

If you need to share data, multitenancy is not what you should be using.

Sep 25, 2012 at 11:57 PM

For the most part it actually works just fine. Central module base, central theme base, shared media folder.

Our scenario is a local government. Each department, and to some degree each division, has their own responsibility of content. Some departments already have 150 pages of content on their own, combining that for 7 departments plus divisions would be an administrative nightmare. It is already bad enough for some departments to edit their content that I was needing to identify each page container in the content list, content picker list, and "Add to" dropdown list. Now if we throw in 30 people with no built-in auditing system all editing and accessing each others content it would be a mess since limiting each account to their own content is too restrictive per department/division when you have multiple people in the same organizational branch needing to modify each others content, but not that of other branches. Gerneralizing user accounts into roles does not help and trying to explain the problems that would create right now is giving me headache (such issues as forgotten passwords and still no true auditing to identify who modified what content).

Each site needs to have the same general look and feel, the same modules enabled, the same customizations of content types. They each have the same feeds they pull from that need to be created for each site, and some of the same widgets which need to be duplicated for each site. The main menu is for the most part the same except for a single drop-drown that is department/division specific. Tags right now are limited to each site and obviously will not bring up content with the same tags in the other sites, so that one would be a far more difficult a challenge. We are using Microsoft search server to crawl all sites to provide a single search engine since isolating search per site using the built-in search would not work for our needs at all.

We have need to bring up additional sites as particular divisions decide to they want to take more ownership on their specific content, so the multitenancy does actually work to alleviate some administration but does not currently solve many other issues that centralized data would solve.

Sep 26, 2012 at 1:05 AM

Seems like there is more in common than needs to be separated. Multi-tenancy looks like the wrong solution. Instead, look at how multi-blogs are implemented. The limitation of contents could be done by role and it looks like that would work reasonably well. I don't get why you say it wouldn't help. It sounds like precisely the reason why we have roles.

Sep 26, 2012 at 3:53 AM

Sorry for the confusion, I was not referring to those roles, I was referring to creating a single user account for multiple users to use so that they can be locked to only editing their own content and no one elses. Currently I cannot specify that level of grouping in Orchard roles as it is more about user groups being applied permissions instead of single users. As for multiple blogs, again that just creates a content mess and most of our content is static reference, not short-lived posts, and fits very well into a hierarchical structure with menus and breadcrumbs and the ability to add sub-content to parent-content. A blog really does not handle that except for a very shallow hierarchy. This isn't to say multiple blogs are not useful. One of our sites, City Council and Commissions, has a blog for each commission and committee. Our Community development department has a blog for each project. Each department has blogs for official press releases and general notices. The city manager has his own blog. We definitely use blogs to a great degree but they are not the solution for this problem.

In a government you have to view different departments and divisions like different companies and each company hates having another company being able to modify or create content within their space. However all of these companies have to present themselves as being under the same umbrella. They have to have a unified presentation to the public with consistent branding, consistent navigational structure to ease the visitor in finding the information. My first solution was having multiple sites, but I was reading about the performance benefits for of multitenancy and after experimenting with it I could see some usefulness. Multiple sites still presents the same problems of not being able to share data.

I am not criticizing multitenancy at all. I think it is a fine start to something that could be much better. I am certain Piedone feels the same way as do many others. Orchard is not at the level of being an EMC. It has very poor document management which is essential for that, but it is a fantastic base and very much handles things the way I was intending to build into an EMC.

Sep 26, 2012 at 5:21 AM

A single user account for multiple users is a very very very bad idea, and I really don't see what it buys you. Why won't you use a role instead, as this is exactly what they are for?

You didn't understand what I was saying about blogs. I was not suggesting that you use blogs and hack them into fitting your content model. What I was suggesting is that you look at how multiple blogs are implemented, and that you implement your own content based on a similar model.

Again, with properly implemented roles, you can prevent department A from ever seeing, let alone modify what department B is doing.

Multitenancy is designed to rigorously segregate the data of multiple sites running in a single instance, it's designed to allow multiple and completely distinct sites to cohabit and save resources. That is the exact opposite of what you are trying to do. It simply is not the right tool for you.

I'm just trying to help: if you go directly against what a feature has been designed for, you are going to fight the system all the way and be frustrated.

Sep 26, 2012 at 3:52 PM

I am not using a single user account for multiple users if you think that is what I was saying. I was describing the issue with permissions in that you can only set permissions to be restricting a user to their own content or everyones. In some cases the roles work, and I would really like that most be limited to Author or a custom role on a similar level of restriction, but we have some that like to use LiveWriter to enter their press releases and other blog posts. Unfortunately I cannot get the Author role to work with these individuals since it prevents them from using some of the functionality through LiveWriter such as delaying the publishing of a post and I have had to place them into the Editor role. I have tried creating a custom role but none of the permission permutations seem to work without basically giving them the same permissions as that of Editor.

I am not sure that I am grasping your concept of implementing content based on the blog model. Can you explain that one in a bit more detail? Are you suggesting that I create custom content types that would mimic pages on a department/division level and then restrict user permissions to those content types?

Sep 26, 2012 at 4:05 PM

My project here would only need user DB sharing. There would be multiple websites, otherwise completely separated in terms of content, enabled modules and theme. Think of it like a content network, a website group. This all is very typical for a multi-tenant scenario, apart from user sharing, so I think it's the way to go.

Sep 26, 2012 at 5:01 PM

I can understand the need of a common repository for storing user accounts. This could be implemented as a module which would override the current IMembershipService.

@ilektan, I think you need a dedicated Recipe which would setup a website with everything a division needs to start with, like content types, themes, modules, permissions, ...

Sep 26, 2012 at 5:15 PM

Yes, a recipe might work, still I would like to explore a way to access the data more directly than simply cloning it. I think there is too much need for separation of content with only a sharing of structure in what I am doing to cram all content into a single instance, although Bertrands suggestion has me interested, combining it with URL Rewrite for the illusion of separate domains. There is still some potential that each department/division might want a slight variation on theme such as color scheme. I suppose through javascript I could determine the host and then modify the colors on the fly.

Sep 26, 2012 at 5:41 PM

Thanks Sebastien! Will this be really sufficient? I've come up with this replication through a web service for the scenario of probably the lowest common denominator: using IRepository<UserPartRecord>. I wouldn't do that but there are modules at least accessing user data through ContentQuery and filtering through records (i.e. query.Where<UserPart, UserPartRecord>(...)) or even the same for parts attached to the User type.

Sep 26, 2012 at 6:34 PM

Varying the theme is really no problem: just make a custom implementation of IThemeSelector.