Users, groups, roles and OUs

OpenCms manages rights in organizational units (OUs). Users can have different rights, group memberships and roles in different OUs. We discuss what OUs are and what is the difference between roles and groups.

1 Users in OpenCms

You are free to define as many users as you need in OpenCms, assign roles to them and add them to groups. But there are some predefined users in the root OU, that you should not deleted (or deleted only in rare cases).

Do not delete any predefined user!
Predefined users in OpenCms
Admin

The Admin user has the role "Root Administrator" assigned. He has all rights inside OpenCms. This user's data can be altered but be sure to always have a root administrator in your system!

Export

The export user is used internally by OpenCms for static export (of JSP-output for example). He is in the Guests group and has not to log in. If you want to get files statically exported, the user needs read permissions on the files. By the separation of Export user and Guest user you can block access to files for visitors of your website that are not logged in, but still have files exported. This may for example be useful in an intranet.

Guest

Users not logged in are treated as Guest user.

2 Groups and roles

In OpenCms you can define groups and add users to groups. Furthermore, each user has roles in OpenCms. Both, groups and roles are used to set the permissions of a user. But, the permissions of groups and roles are given with different focus:

  • Groups are used to control access to resources in the VFS.
  • Roles are used to control access to the system's functions according to the requirements of the respective role, e.g., control if the workplace can be accessed, if resources can be published, if user accounts can be managed, ...

The different focus of groups and roles also implies differences in their handling:

  • Roles are fixed while groups can be created or deleted
  • Group permissions can be set at all resources, role permissions are typically not added to resources, except in some /system/ folders.
  • Roles may outrival permissions set at groups or users, e.g., for the root administrator all permission settings are ignored, he always has all permissions.

Thus, when you think on designing your permission system in OpenCms:

  • Have a look at what a user should be able to do and assign it's role according to the tasks. An overview on the available roles is found here.
  • Think about which users should have access to which resources and use groups to allow or deny access.

2.1 Predefined groups in OpenCms

A default OpenCms installation ships with three predefined groups. They are special compared to user defined groups and used internally by OpenCms.

Do not delete any of the predefined groups!
Predefinied groups in OpenCms and their pecularities
Administrators

All members of the administrators group are automatically root administrators.

Users

Whenever you assign a role to a user, he is added to the users group. If you remove the role, he will also loose his group membership (even if you explicitely added him to the group before). Typically, all users should be in the users group. For example, the rights to read view and write content in the default site is granted to members of the Users group. The same holds for the /shared/ folder.

Guests

Guest and Export user are in this group. It is in particular used for all users that do not log in.

3 Organizational units for user management

Organizational units (OUs) are meant to make rights management in complex systems easier. All user management in OpenCms is permformed in OUs. By default, OpenCms has just one OU: The root OU, where all resources of the VFS belong to. Typically, you do not need to add more OUs.

If you do not need to equip a user with a special role only for special (sub-)sites of your OpenCms installation, stick to the one root OU and do not care about OUs at all. Only when you use OpenCms to handle, for example, many sites, or various subsites that should be managed by different users, then setting up serveral sub OUs will be your choice.

For each sub OU you can specify users and groups and assign roles to users. Furthermore, you can restrict the resources that belong to an OU.

In essence, OUs allow you to:

  • assign roles of users only for parts of your website(s)
  • decentralize user management

But how do users choose their OU? If you have more than one OU, the login dialog changes and users have to select the OU on login.

3.1 Root vs. sub OUs

The root OU differs from sub OUs wrt. the available roles. OpenCms system management is always tied to the root OU, thus the respective roles are only available in this OU. In particular, in sub OUs you can not assign the roles:

  • Root administrator
  • Database manager
  • Workplace manager