Site admin role in a multi-tenancy environment

[Rex Bigger]

Hi,

I have a scenario where I need to have 5 sites running for 3 individual clients (A, B and C). 2 of the sites will be managed by their respective clients (A & B), the other 3 sites will be managed by the third client (C).

The System Host role should be able to see and administrate all 5 sites.

Client C should be able to see and administrate their 3 sites but have no visibility to the sites managed by A and B.

What needs to be setup in the roles structure to allow this model?

Rex..

[Xander Steinmann]

Hi Rex,

The best tip I can give you is to add a host field to all the structures the sites use, and create roles that have permissions on the different hosts. Also I usually create a separate role that has permissions on the structures so the users can see/publish the structures, and I also add the tabs to that role. And try to avoid using the SYSTEM_HOST if the sites have overlapping structures but not overlapping content. 

There is a lot of documentation available on https://dotcms.com/docs/latest/permissions; you will have to try out some stuff. Don't forget the "Login As" since it's a real time saver.

Kind regards and good luck,

Xander 

[John Michael Thomas]

Hi Rex,

This is a common situation, and we have some clients which host sites for hundreds of different clients on the same dotCMS instance, so it definitely can be done and managed.  Based on what you've outlined here, here's some suggestions for how to do this:

1. Create one Role for each client that gives View permissions to all content on the respective hosts that all users of that client need to see - but not to the content on any of the other hosts.
   
• For example, you'd have one Client A Role which gives view permissions to the root of their host, one Client B Role which gives view permissions to the root of their host, and one Client C Role which gives view permissions to the root of all 3 of their hosts.
  
2. Create appropriate Roles for each client which give add children, edit, publish, etc. permissions on each of that client's hosts.
   
• For example, if a client has marketing users and developers, create a Client A Marketing Role that gives permissions to add children and edit permissions on the /marketing folder on that client's host, and a Client A Developer Role with permissions to the /application folder on that client's host.
  
3. For each client user account created, assign the general client Role (from #1 above) and any other appropriate Roles for edit, etc. permissions (from #2 above).
   
• For example, if adding a marketing user for client A, you'd assign both the Client A Role and the Client A Marketing Role.
  
4. If you plan to use the same content types across different client hosts:
   
1. Assign those content types to the System Host (in the Content Type properties tab).
2. As Xander said, add a Host/Folder field to the content type (and make it a required field).
• This will force the content creators to choose a location for each content item they create, and since they'll only have permissions to folders on their own hosts, this will mean that each content item created in a specific location on that client's host, and will thus only be viewable by users with permissions to that client's host and folders.
  
• Note that if you plan to have separate Content Types for each client's site, then this whole step (#4) isn't necessary.
  

Of course the details may change depending on what you want to do - for example if you don't want to give all of a client's users the ability to view the whole client site, you might skip step #1 and just assign all view permissions in step #2.  But hopefully that will give you the idea and get you started.  If I misunderstood what you're trying to do, please post more details and I'll try to give you more specific suggestions.

[John Michael Thomas]

One other note: dotCMS Roles can control both access permissions (Which sites, folders, and pages/files a user has access to) and tool permissions (which tools a user has access to, such as the Site Browser, Content search, admin and maintenance tools, etc.).  And you can also separate the access permissions and tool permissions into separate Roles if you want to, which may make it easier to assign tool permissions to users from different clients.

For example, if you know that all 3 of your clients will have some users who are developers, some who are content creators, and some who are administrators, you could create 3 roles which assign the appropriate tools for each of these users, something like this:

• Developer: Site Browser, Templates, Containers, Content Types, Relationships, Query Tool (etc.)
  
• Content Creator: Site Browser, Content Search, Links
  
• Administrator: Site Browser, Configuration, Maintenance, Sites, Permissions
  

Then when you add a client user account, you can just assign one or more of these roles, rather than having to add the tool permissions to the client-specific Roles.  For example, if you were adding a marketing user for client A, you would add the following Roles:

• Client A
  
• Client A Marketing
  
• Content Creator
  

These kinds of Roles may not make sense if you only have 3 clients.  But they may make it easier to manage client accounts if you plan to expand the number of clients in the future.

On Tuesday, August 29, 2017 at 3:54:27 AM UTC-7, Rex Bigger wrote:

[Rex Bigger]

Thanks Xander / John,

Will take a look at these and mock something up. From your first message John, that does map to what I need to do - so will try that out.