User permission configuration - Introduction

This chapter outlines the mechanisms for permission assignment and permission check provided by FirstSpirit and their precise application. The following pages only deal with permission assignment for the generated site (i.e. user permission assignment) and not with project permission assignment (i.e. editorial permissions) or permission assignments for workflow execution. (For further information on permission assignment see Permissions in FirstSpirit (→Documentation FirstSpirit SiteArchitect).)

FirstSpirit strictly differentiates between editorial permissions and user permissions. While editorial permissions apply to all operations which can be executed by an editor (e.g. create/change/delete pages), the user permissions only apply to the “visitor” of the generated site and are, therefore, always linked to the used personalization system. If FirstSpirit DynamicPersonalization is used as the personalization system (not mandatory), a very close relation can be established (see Authorization checks using FirstSpirit).

Within the scope of editorial permissions FirstSpirit specifies the number of operations (create/change/delete/release, etc.). These operations can be provided with permissions for persons or groups. Person/Group management is also carried out by FirstSpirit (even if an LDAP system can be connected). Therefore, the operations and groups are (relatively) fixed within the scope of editorial permissions.

In contrast to the editorial permissions which relate to processes in the FirstSpirit project, the user permissions exclusively relate to the generated and deployed site. The application of a login page usually indicates that user permissions are used in a project.

Within the context of user permissions, FirstSpirit defines neither the operation nor the group structure, since each project implemented with FirstSpirit has completely different user permission requirements. Usually it is sufficient to interpret user permissions as “Permission to view an object”. However, the “Change” or “Print” operations may also be relevant in addition to the “View” operation. In this case, a distinction has to be made between the “View” and “Print” operations within the scope of user permissions.

Please note that there is a relation between editorial permissions and user permissions in exactly two cases:

1. Page preview:
   In this case the editor is also a user – the editorial permissions “View” and the user permissions “View” coincide with each other and have to be linked appropriately.
2. Changing data of the live site:
   In this case the user is also an editor – the user permissions “Change” and the editorial permissions “Change” also have to be linked appropriately.

The link is usually created via an additional login request, i.e. the user logs in as an editor or vice versa.

In addition, the following login option is available:

• SSO: If an SSO module is used, the transition from editor to user takes place transparently without a password request (login module: FS SSO).