Managing Users

Managing Users
As a user administrator you have the job of managing user access to catalogs. Not only does Cumulus let you define whether each catalog is shared by your workgroup, but also how each catalog is shared by each user. In this chapter, you will learn how to set up Client users, how to make catalogs available to Client users, and how to define specific user permissions.
User Management
The Cumulus user management enables you to create users and specify their access rights to catalogs and functions.
Cumulus permissions are based on an additive concept. This means that a new user does not have any permissions by default. This minimizes the risk of granting permissions accidently but implies that you have to grant any new user at least the minimum permissions a user needs to work with Cumulus.
Cumulus users are managed with the User Manager module of the Server Console.
The Users Catalog
The user management is based on a special Cumulus catalog. Its catalog name is $Users­ and its catalog file name is Users.­ccf. This manual refers to it as the Users catalog.
The Users catalog has to be managed by your Cumulus Server, meaning it has to be included in the Catalog Access list. It must not be shared nor published to the Internet.
It is possible to open the Users catalog with a Cumulus Client, but this is not recommended for user management. There is only one reason to open the Users catalog with a Cumulus Client: The user data are stored in record fields. If you want to have more fields than the default configuration offers, you can add record fields to the Users catalog. If you do this, always use the version of the Cumulus Client application that fits the version of your Cumulus Server.
Modes
Cumulus is intended to meet the needs of many different customers. This is why the Cumulus user management offers different modes. Whether you settle for user-based or role-based mode defines the method by which permissions are assigned. For both methods a simple and advanced view is offered for granting the permissions.
User- and Role-Based Mode
Cumulus provides two different modes for the method of managing users:
OR
the role-based mode where each user can be assigned to roles that include certain permissions (Note that this is an optional feature which may not be available with your Cumulus configuration.)
While the user-based mode is intended for a small number of users to be administered, the role-based mode is intended for a large number of users. You can create roles that you use to assign a common set of permissions and catalogs to multiple users. Organizing users by defining roles makes it easier to manage access rights. With this strategy, rather than assigning permissions to each user for each object, you assign permissions to a few roles and then add users to the appropriate role. When using Cumulus, users are granted permissions based on any roles to which they belong.
When you create a user account for a new user, you add that account to the appropriate role. Then, the user has the permissions associated with that role. Also, changing permissions is easier: rather than having to change permissions for each and any user individually, you simply change the permissions assigned to the role.
If you work with the role-based mode and you have a LDAP server, you can define mappings from LDAP groups to Cumulus roles. By using this mapping you no longer need an entry for this user in the User Manager. (See “Cumulus Roles”, for further information.)
You have to decide which mode you want to work with. Once you have switched to the role-based mode you cannot switch back to the user-based mode. Both modes offer the same range of functions – except that the role-based mode offers roles to “bundle” users. So in case you have Cumulus users that can easily be “bundled” or split into different groups, we recommend that you employ the role-based mode. And we do not recommend that you start with the user-based mode and then switch to the role-based mode, otherwise each user you have defined will be converted to be a role.
The user-based as well as the role-based mode works with the Users catalog and the User Manager module to manage users with this catalog.
Simple View and Advanced View
The user-based as well as the role-based mode can be used in either the simple or the advanced view. The simple view subsumes several permissions whereas the advanced view lets you assign permissions in a very granular manner. For more information, see “Simple View: Permissions", and “Advanced View: Permissions”.
The simple view enables you to set user or role permissions for a single catalog, or your entire Cumulus Server with just a few mouse clicks. You can switch to the advanced view when you need to make more granular changes. Both modes are always available, so you don’t have to choose just one.
User Manager
To work with the User Manager you need to have the appropriate Administrator permissions for the server: Global User Administrator.
The User Manager is one module of the Cumulus Server Console. To start the User Manager:
 
1.
From within the Cumulus Client, select File > Administration > Server Console, or connect to the Web Server Console via a Web browser.
2.
3.
Click the + icon on the left side of the User Manager entry. Then click on Users or External Users. The Users list is displayed.
 
User Types
The User Manager has two sections, corresponding to two user types: Users and External Users.
Basically, there is no difference between external and ‘normal’ users. This distinction is only a descriptive one. Both normal and external users can be created and configured manually. External users, however, can also be created automatically.
An external user is created automatically each time a collection link is sent to an email address so far unknown to Cumulus. The purpose of such a user is to allow Cumulus to monitor the usage of the collection link. Initially, automatically created external users have no permissions at all, and the only thing Cumulus knows about them is their email address.
The User Administrator may add more information to an external user and may grant any desired permission. Thus a user without any permissions can eventually be promoted to a full-fledged Cumulus user. Changing a user’s type from external to “normal” or vice versa is also possible any time. However, changing the User Type value does not affect the permissions a user is granted.
Creating Users
A new user does not have any permissions by default. We recommend that you create “typical” user accounts that fit the needs of your organization first and then duplicate these user accounts to set up the real users. However, when using this method, remember to keep such users up-to-date, e.g. when adding new catalogs. Create as many of these template users as you need.
TIP: Specific Initial User Settings
Administrators have no access to a user’s preference settings, so users must perform user setting changes on their own. If you want to provide specific initial User Settings for each newly created user, log in as the user that is used as a template for new users and configure the user settings as needed. New users created by duplicating this template user will then have the same initial user settings.
To add a new user to the Users list:
 
1.
Click the Create button.
OR
Select your “typical” user and click the Duplicate button.
IMPORTANT!  
Check whether this user’s properties are up-to-date – especially the catalogs that she/he is allowed to access.
The Input window appears.
2.
The Unique User ID option is activated by default. Deactivate this option only if an external UUID (e.g. provided by LDAP) is to be used exclusively instead of the UUID provided by the Cumulus built-in authenticator. (For more information on the Unique User ID, see “User Identification".)
3.
Activate Login Active if you want to allow the user to work with Cumulus as soon as you have closed the user’s properties window.
4.
Built-in – The Cumulus built-in authentication will be used exclusively. Advantage: Independent from the operating system you are using.
With this authentication method only, different options for changing the password are available.
System – The user password will be authenticated by the Operating System. Advantage: No need to administrate a separate Cumulus password.
LDAP – If you are employing LDAP (Lightweight Directory Access Protocol) the user password will be authenticated by LDAP. Advantage: No need to administrate a separate Cumulus password. (See “LDAP Authentication Method”, for details on how to use this method with Cumulus.)
5.
NOTE: Don’t forget to inform your new user about this login name and password.
6.
Enter the data for the new user in the corresponding fields of the General and Additional Fields sections. (See “Overview: User Properties – General & Additional Fields”, for more information on the sections and fields).
7.
If working in role-based mode: Assign the user to a role. On the Role tab click the Add button to get a list of available roles. Select the role(s) you want to assign to the user and click OK.
NOTE: Due to the additive permissions concept, the permissions a user has got are the sum of the permissions given to all roles the user is assigned to.
8.
Click OK to save the defined properties.
Duplicating, Editing and Deleting Users
For duplicating, editing and deleting users select the user’s entry and then click the appropriate button. Duplicating a user works the same way as creating a new user except that when duplicating the properties of the duplicated user are copied for the new user – all properties except the login name.
User Properties
A Cumulus user’s properties include her/his contact information and, in the user-based mode, the permissions she/he has for functions and catalogs. The User Properties window has several tabs that provide access to the information stored on a user. These tabs are:
General – Login information and basic personal information
Additional Fields – Additional contact information on the user
Tab provided in Simple View mode only:
Permissions – Global permissions and catalog permissions
Tabs provided in Advanced View mode only:
Catalog Accesss – Cumulus catalogs the user is allowed to access
Catalog Permissions – Permissions the user has on these catalogs
Server Permissions – Permissions the user has for functions and objects managed by the Cumulus Server.
Tab provided if Cumulus is running in role-based mode:
Roles – Roles the user is assigned to
The following overview describes the General and Additional Fields sections only.
NOTE: The Password never expires option overwrites the maximum password age set for Cumulus users’ passwords in the Cumulus Server Settings (see “Overview: Cumulus Server Settings").
User Identification
Cumulus uses a Unique User ID (UUID) for user identification as well as for checking a user’s record and category permissions. A UUID consists of a definition of the authenticator and a unique ID from the authenticator. The authenticator is required to provide a unique ID.
By default, the user will always be identified by the UUID provided by the Cumulus built-in authenticator and stored in the Users catalog. The Unique User ID option on the General tab of the user’s Properties window is activated,
If you employ a different authenticator (e.g. LDAP), it might provide own UUIDs. If you want to use these UUIDs, you must deactivate the Unique User ID option in the Cumulus user’s properties.
NOTE: Changing the Authentication Method!
If you change the authenticator and use its UUIDs, the permissions set for a user are no longer valid. They must be set again for the ’new’ user (identified by the UUID of the other authenticator.)
Simple View: Permissions
In simple view the user or role permissions are subsumed to global permissions or permissions on catalog base.
You can either grant a user global permissions or grant “individual” permissions for catalogs. Once you grant a user the global permission, the user has this permission for any catalog – no matter whether the permission is given for the catalog or not.
Global Permissions are:
Permissions for Individual Catalogs area:
IMPORTANT!
Minimum Permissions
In simple view the minimum permissions required for a user to work with Cumulus are: Read for at least one catalog. Or if catalog specific permissions are not required, Global Permission Read Metadata.
TIP:  
You can use the simple view in conjunction with the advanced view – make “broad stroke” permissions settings in simple view and then fine tune them exactly as you need in advanced view.
Advanced View: Permissions
Cumulus provides an enhanced permissions management. Each user’s or role’s properties include several permission sections:
Catalog Access – Cumulus catalogs the user is allowed to access.
Catalog Permissions – Permissions the user has for these catalogs.
Server Permissions – Permissions the user has for functions and objects managed by the Cumulus Server.
NOTE: Permission changes made to the account of a connected user will not take effect until that user logs out and back in again. Keep this in mind whenever you’re testing permissions options on your Server.
If you don’t log out of your test account, you might think your changes are not taking effect.
IMPORTANT! Minimum Permissions
In advanced view the minimum permissions required for a user to work with Cumulus are: the Application Permissions Open Catalog with any Cumulus Client, View Item for Records and access to at least one catalog, one Record View Set and one Category View Set.
Catalogs
The permissions for a user’s access to catalogs are defined in the Catalogs section of the Properties window for the user or role.
You can allow a user to have access to all catalogs that are managed by the Cumulus Server or restrict the access to selected catalogs.
Access to All Catalogs
If the Restrict Catalog Access option is not enabled, the user is allowed to access all catalogs that are managed by the Cumulus Server and enabled for sharing. In this case
Restricted Access to Selected Catalogs
If the Restrict Catalog Access option is activated, you can set the permissions either for all of the allowed catalogs at once, or for each of the allowed catalogs individually.
Before you consider activating the Restrict Catalog Access option, you should be aware of the following. In this case, each newly created catalog which you want this user to have access to must be added to the list of catalogs.
IMPORTANT!
Restrict Catalog Access Option
Any user should have access to at least one shared catalog!
Catalog Permissions
A user’s permissions for catalogs are defined in the Catalog Permissions section of the Properties window for the user. The catalog permissions refer to the catalogs defined in the Catalogs section of the Properties window.
A user’s permissions for catalogs can be set collectively for all allowed catalogs or individually for selected catalogs. However, note that the permissions individually set for selected catalogs are always added to the permissions that are set for all allowed catalogs.
Once you have clicked on the Catalog Permissions section of a user’s properties, you select the catalog you want to set the permissions for. Set the permission for All Allowed Catalogs first and then select the catalog for which you want to set the permissions individually.
Application Permissions
The Application Permissions define the user’s general permissions for functions on catalogs, records, categories and assets as well as the user’s permissions when accessing Cumulus via Web.  
NOTE: If you give one of these permissions for All Allowed Catalogs, the user will have this permission for all catalogs managed by your Cumulus Server.
IMPORTANT! Minimum Application Permissions
The minimum Application permission required for a user to work with Cumulus is Open Catalog.
With Enterprise or the Extended Permissions add-on, these Application permissions can be expanded by individual Record or Category permissions. If you want to make use of this feature, you can follow two different concepts:
For more information on individual Record or Category permissions, see the Client User Guide.
The following section describes which permission is needed to perform which function.
Permissions for Entire Catalog
These permissions govern the user’s access to the selected catalog itself.
Open Catalog with any Cumulus Client – needed to gain access to the catalog in order to open it; e.g with a Cumulus Client application to get the catalog displayed in the Catalog Access window. “Any Cumulus Client” includes the Cumulus Client application, Cumulus Web Client, Sites, HELIOS Companion, and any individually programmed application based on Cumulus Java Classes.
NOTE: The catalog access can be restricted to certain Cumulus Client versions and variations. See “Client Groups”, for further information. If you have set up any Client Groups, the options for the Catalog Permissions will be enhanced with an entry Open Catalog with for each defined group.
Modify Catalog Category Permissions – needed to define permissions for categories that represent catalogs (optional.)
Manage Catalog Triggers – needed to create, edit and delete own triggers for catalogs.
Permissions for All Records and Categories
These permissions govern the user’s access to the records or categories of the selected catalog.
View Item – With Enterprise or the Extended Permissions add-on only: allows a user to see all records/categories – even if Live Filtering is active.
Create Item – needed to catalog assets/create categories and to import records/categories.
Modify ItemsFor records: needed to modify records (manually or via automation) and to update records (as this includes modifying the records). This permission is also needed for checking assets in or out with any version control system, e.g. Cumulus Vault.
A user who is allowed to modify records, may additionally be allowed to change the asset reference that is included in the record. The permission for modifying the asset reference must be given explicitly by assigning the Modify Item Reference permission.
For categories: needed to rename, modify and move categories and for the synchronization and auto-cataloging functions.
Delete Items – needed to delete records/categories.
Modify Item Permissions – With Enterprise or the Extended Permissions add-on only: needed to edit individual record/category permissions.
Manage Item Triggers – needed to create, edit and delete own triggers for records/categories.
Asset Permissions
Certain functions require accessing the assets directly. The following permissions grant this access for the assets cataloged to the selected catalog:
Delete Assets – needed to delete assets.
Transfer Assets – needed for any function where accessing the asset directly is required but where the Cumulus Client (native or Web) user cannot access the assets directly. In other words, this permission is needed for Server/Client asset transfer and for Cumulus Web Client, and Sites. If Server/Client asset transfer is employed, this permission is needed to get a preview displayed. With any version control system, e.g. Cumulus Vault, this permission is also needed for copying, moving or previewing assets.
Asset Versioning – needed to use any version control system, e.g. Cumulus Vault. Along with this permission the Modify Records permission is always needed to check assets out or in.
Web Permissions (needed for Cumulus Internet Solutions only)
These permissions govern the user’s access to assets when the user employs a Cumulus Internet Solution as client to work with the selected catalog.
Collect Asset for CD– needed with Cumulus Web Client to have the function Collect for CD-ROM available in the Collections Basket.
Download Asset – needed with Cumulus Web Client and Sites. Along with this permission the Transfer Asset permission is always needed to download assets.
Show Original Asset– needed with Cumulus Web Client and Sites to have the original asset displayed with the Show Original command. Along with this permission the Transfer Asset permission is always needed to have the original assets displayed.
Email Assets – needed with Cumulus Web Client for e-mailing assets. Along with this permission the Transfer Asset permission is always needed to email assets.
Subtable Permissions
The Application Permissions also define a user’s permissions for Table fields. The User Comments feature is based on such a subtable. This means that the permissions for this feature are managed with the permissions granted for the corresponding field: User Comment Thread. To make full use of the User Comments feature, a user needs the view, create, modify and delete permissions.
Tracking an asset’s usage history is also based on a Table field: Asset Usage History. If you want a user to be able to see an asset’s usage history, you have to grant the view permission to that user.
Administrator Permissions
The Administrator Permissions refer to administrative functions for catalogs.
NOTE: If you grant one of these permissions for All Allowed Catalogs, the user will have this permission for all catalogs managed by your Cumulus Server.
View Catalog Settings – The user is allowed to view the selected catalog’s settings in the Catalog Settings window of the central Cumulus Preference window.
Modify Catalog Settings – The user is allowed to make modifications for the selected catalog in the Catalog Settings window of the central Cumulus Preference window. A user who is allowed to modify the catalog’s settings, may additionally be allowed to set up and modify a central asset location for the selected catalog. The permission for modifying the central asset location must be given explicitly by assigning the Modify Central Asset Location permission. The permission for setting up mirroring for the catalog must be given explicitly by assigning the Manage Mirroring permission.
NOTE: Canto recommends that you allow only one user to have access to this or have one person responsible per catalog. If several users have the permission for modifying the Catalog Settings you might get into trouble when they modify at the same time, as the first user accessing the Catalog Settings and saving changes blocks those with access to the Catalog Settings from saving their changes.
Manage Log Files – The user is allowed to start the Log Manager module and set up a log file for the selected catalog.
Monitor Activity – The user is allowed to start the Activity Monitor module and to view the list of users connected to the selected catalog. The user is also allowed to disconnect users from the selected catalog.
Trigger Administrator – needed to create, edit and delete all triggers of all users
Additional Permissions
This section gives you the possibility to include permissions that are used by additional EJaPs, Internet solutions and solutions based on Cumulus Java Classes. For details as to which permission should be included, ask the producer or programmer of the additional software.
Set, Action, Query and Template Permissions
For the selected catalog, you can restrict the user’s access to selected items of one type (sets, actions, queries and templates). If you restrict the user’s access to a selection of shared items of this type, the items not selected will not be available for the user.
NOTE: If you grant one of these permissions for All Allowed Catalogs, the user will have this permission for all catalogs managed by your Cumulus Server.
If the Restrict Access option is not enabled, the user is allowed to access all shared items of the selected type that are enabled for sharing.
To restrict a user’s access to a selection of shared items only, enable the Restrict Access to option. Use the Add button to set up the selection.
If the Restrict Access option is enabled, you have to add items. Otherwise the user has no access to any item of the selected type in the catalog.
Before you consider activating the Restrict Access option, you should be aware of the following: each newly created item which you want this user to have access to must be added to the list.
If the user is working with a multi-catalog collection (a collection that includes records from more than one catalog), the new impact of the Restrict Access option has the following consequences when selecting sets, actions, queries and templates: The user can only choose items that are available for him/her for all catalogs included in the collection. In other words, only such items that belong to the intersection of the permissions that the user has for all catalogs included in the collection. If the user opens another catalog in an existing collection, the selection of available sets, actions, queries and templates might change.
NOTE: Be careful when using this permission feature. Erroneous configurations for Record and Category View Sets can prevent the user from seeing any records/categories.
IMPORTANT! Restrict Access Option
A user needs at least access to one Record View Set, one Category View Set and one Asset Handling Set. Without these permission granted, a user cannot open a catalog.
TIP: Checking Assigned Sets, Templates etc.
The Server Console Action menu offers a Check Users Catalog­ function for the User Manager item. This function searches for settings (sets, templates etc.) that are assigned to users (or roles) in the Users catalog but no longer available with your Cumulus installation. If any settings are found that are assigned but not available, the function lets you remove the assignments from all users (or roles) in the catalog.
Migration
The permissions for sets, actions, queries and templates are new since Cumulus 6.5. You have to add these permissions to the properties of each user of your former Cumulus 6 installation.
In Cumulus 7, this Restrict Access option for the items listed above has been moved from Server Permissions to Catalog Permissions. This enhances the impact of the option: now the restricted access can be set on a catalog-by-catalog basis.
The only Restrict Access option available under Server Permissions belongs to Collections­ Permissions because collections can span across catalogs.
Server Permissions
A user’s permissions referring to the Cumulus Server are defined in the Server Permissions section of the Properties window for the user. The permissions defined in this section do not refer to any catalog but to the settings managed by the Cumulus Server.
User Permissions
These permissions define what the user is allowed to modify on her/his own user settings in the User Settings window of the central Cumulus Preference window.
The permissions refer to the different sections of the User Settings window.
 
If you are working in role mode, the User Permissions section additionally provides the possibility to replace certain user settings of all users belonging to a role with the settings of a defined user. Thus you can easily achieve that all users belonging to a certain role have, for example, identical search and sort settings.
All you have to do is to create a new user, specify his/her user settings according to your ideas, then take this user to have the appropriate settings applied to all other users belonging to the role. Changing the settings of your template user, affects the settings of these users accordingly as soon as they log in (again).
If certain user settings are replaced by the settings of a specific user, the members of the role are no longer allowed to change their respective user setting by themselves. If, for example, the Replace Search & Sort Settings with settings of is activated (as seen in the screenshot above), the Modify Search & Sort User Settings option is deactivated automatically.
IMPORTANT! Be careful with users belonging to more than one role!
If different roles have defined user settings replacement for the same parts of the user settings, but from different template users and with different values, the result for a user belonging to several roles is a purely random replacement!
Run-as Permissions
The Run-as permissions define as which other user(s) a user may act.
You can allow a user to have access to all catalogs that are managed by the Cumulus Server or restrict the access to selected catalogs.
Unrestricted run-as permissions are required for the (technical) admin user in Sites in order to make the send personalized collection feature and the send upload link feature work. (The Sites admin user is set via the Sites Configurator.)
The Run-as function (File > Administration > Connect to Server As) is useful e.g. for substitution purposes, or for an administrator who needs to test the configuration of users or roles.
Administrator Permissions
You can assign the following administrator permissions:
User Administrator Permissions
You can assign the following user administrator permissions:
Browse for Users – The user is allowed to employ the Add User button to search for users when setting up Triggers with Mail Notification for other users and – optional only – individual permissions for records/categories and Permissions Templates. With Enterprise this permission is also required to be able to search for users with the Restrict Edit to the following Users and Roles or the Restrict field visibility to the following users and roles options in the properties of a record or category field.
Keep in mind that the effective permissions may differ from the assigned permissions! For example, assigning read-write permission to a top-level department results in read-write permissions for all subordinate departments, no matter what permissions they are assigned to individually. If Global User Administrator is activated, the Effective Permission is always Read Write.
NOTE:  
Department-specific user administrator permissions only operate if Global User Administrator permissions is deactivated.
Additional Permissions
This section gives you the possibility to include permission that are used by additional EJaPs, Internet solutions and solutions based on Cumulus Java Classes. For details as to which permission should be included, ask the producer or programmer of the additional software.
Set, Action, Query and Template Permissions
These permissions define how the user is allowed to work with:
The permissions you can set for all these items are similar. For each type you can define whether the user is allowed to manage her/his own sets, actions, queries and templates. The permission manage­ includes creating, viewing, modifying and deleting.
 
NOTE: Collection Permissions
The permission Manage User Collections is also required for saving the contents of the Collection Basket pane or the Cumulus Web Client / Sites Collection Baskets.
For shared items you can grant the following permissions to a user (or role):
You can set these permissions for all shared items.
Live Filtering™
Optional feature! May not be available with your Cumulus configuration.
You can have certain users to have a “filtered view” on a catalog. The view of a user or a user group can be limited to preselected categories and/or records. For example the asset access for the sales staff can be limited to final, approved material, while the work in progress in the Marketing department should not be visible.
If you want to restrict a user or a role to seeing and working with only certain categories and/or records, you can do so by means of Categories and/or Records Live Filter. These filters are defined via saved search queries. If you restrict the access to a catalog by means of a Live Filter, the user’s access to the catalog is restricted to the search result of the query employed as filter. Each time the user opens the catalog, a search employing the selected query is performed. That way the user gets a current result of the search query you defined to work with.
Live Filtering works and must be specified for each catalog individually.
As a prerequisite to make Live Filtering work with a specific catalog, the user’s View Items permission for Records or Categories must not be set for the this catalog (see below, step 4 and step 5).
To restrict the access to a catalog through filters:
 
1.
2.
Select the Catalog Permissions tab.
3.
Via the Permissions for menu, select the catalog for which you want to activate the Live Filtering.
NOTE: You cannot activate Live Filtering if All allowed catalogs is selected in the Permissions for menu.
4.
5.
In the Permissions for All Records and Categories section, deactivate the View Item permission for records and/or categories, depending on the kind of Live Filter you want to apply.
6.
 
7.
To restrict the access to selected categories, enable the Use Category Live Filtering option. Then select the query to be used. For a centrally stored shared query use the Use Query button. For any other exported query use the Use File button.
8.
To restrict the access to selected records, enable the Use Record Live Filtering option. For this option you can select one of the following ways of filtering records:
Automatically Use Resulting Categories for Record Live Filtering
The user will only see the records that are assigned to categories that have been found by the query used for Category Live Filtering.
Use Record Query
The user will only see the records found by the selected record query. For a centrally stored shared query use the Use Query button. For any other exported query use the Use File.
9.
Click the Use Query or Use File button to open a window for selecting the corresponding query or file.
NOTE: If you cannot open the default folder for storing queries, check the folder’s properties. If they are set to Hidden, this folder cannot be addressed by the Select dialog. You either have to change the folder properties or save the queries to another location that you can access.
10.
Select the query you want to apply as filter and click OK/Select. The query is saved with the filter and the search conditions of the query are displayed. Note that the data of the query is saved with the filter and if you change the query later on, the filter will not be changed accordingly.
NOTE: If you want to use an exported query file, make sure that the query you select matches the corresponding Live Filtering option:
– For
Live Filtering Categories, use a category query (i.e., saved with the Find Categories window).
– For Live Filtering Records, use a record query (i.e., saved with the Find Records window).
It is a good idea to give the queries meaningful names.
For Live Filtering Records additional options are offered. Under Live Filtering Options, you can define if the records displayed for the user include records from categories above and/or below the found categories. This is important only if your defined Record Live Filtering includes categories as a filtering condition (either based on the result of Category Live Filtering or using a record query that searches in the Categories record field).
11.
Click OK to save the user’s properties.
To undo a Live Filtering restriction, disable the corresponding option. The query will not be active any more. If you want all records/categories to be available for the user/role again on the next log in, you must additionally activate the View Items permission for records and/or categories.
Live Filtering and the Additive Permissions Concept
Remember that Cumulus permissions are based on an additive concept. By default, Live Filtering works in accordance with this concept.
Multiple Roles
If a user is assigned to multiple roles, her/his permissions are the sum of the permissions of these multiple roles. So if assigned to multiple roles with different Live Filtering restrictions, the user has access to the sum of the search results defined by the queries applied to those roles.
Queries and View Permissions
A user who is allowed to open a catalog but not to view its records or categories will nevertheless be able to see the records/categories found by the queries assigned to her/him by Live Filtering.
Individual Permissions for Records and Categories Precede Queries
A user who by individual permissions for records/categories is allowed to view records/categories will always see them – regardless of the results of Live Filtering queries. Individual permissions for records /categories have priority.
Working with the Role-Based Mode
Optional feature! May not be available with your Cumulus configuration.
Before you start working with the role-based mode, you should set up a role concept that fits the company needs.
You can create roles that you use to assign a common set of permissions and catalogs to multiple users. A role includes:
Switching to Role-Based Mode
Once you have decided to work with the role-based mode, you have to switch to this mode.
NOTE:  
This switch cannot be undone.
 
1.
Highlight the User Manager entry in the left panel of the Server Console.
2.
Select Actions > Switch to Role-Based Mode. A warning is displayed.
3.
Click Yes. A message informs you that you have to disconnect from the Server in order to have the role-based mode activated.
4.
5.
Select Server > Disconnect.
6.
Select Server > Connect. Log on to the Cumulus Server again as Cumulus Administrator or the user who has the permission (User Administrator). Now the role-based mode of the User Manager is active.
If the you have switched to role-based mode of the User Manager, the User Manager entry in the Server Console offers a new option: Roles
To reveal the Roles click the + icon on the left side of the User Manager entry. Then click on the entry Roles. The list of roles will be displayed.
The first step when working with the role-based mode is creating roles.
Creating New Roles
To create a new role:
 
1.
2.
NOTE: If you want to use the automatic role mapping between LDAP groups and Cumulus roles, the role name needs to match the value of an attribute of the corresponding LDAP group. (For details on how to map roles and LDAP groups, see “Cumulus Roles".)
NOTE: The Department section is displayed only if you have set up departments. Departments is an optional feature which may not be available with your Cumulus configuration.
3.
4.
by clicking the Add button to assign users managed by the Cumulus User Manager, or
5.
Click OK to save the defined properties.
Duplicating, Editing and Deleting Roles
For duplicating, editing and deleting roles select the role’s entry and then click the appropriate button. Duplicating a role works the same way as creating a new role except that when duplicating, the properties of the duplicated role are copied for the role user.
Actions for User Manager
The Actions menu for the User Manager module provides several administration utilities.
Importing User Data
Use Actions > Import XUSR Files to import the user data provided by Cumulus Web Publisher Pro or Internet Client Pro.
Client Groups
Client Groups are a means to restrict access to Cumulus to certain applications (e.g. Cumulus Client, Web Client, Sites, etc) or versions of applications.
For each defined Client Group an entry Open Catalog with is added to the available Catalog Permissions of a user or role.
Additionally, you may Force Read Only Catalog Access for any defined client group. If the user opens a catalog with a Cumulus product that is contained in such a client group, only read access is possible, regardless of any other permissions set for the user.
NOTE: Force read Only Catalog Access and Cumulus Sites
The force read only option is especially interesting if applied to client groups that include Cumulus Sites in their definition. Unlike any other Cumulus Client, Cumulus Sites does not require a Cumulus license when accessing a catalog in read only mode. Thus, visitors from the internet may browse your Cumulus catalogs without generating additional charges.
To work with Client Groups:
 
1.
2.
Select Actions > Edit Client Groups.
Use the appropriate buttons for creating, duplicating, editing, renaming or deleting a Client Group. A Client Group is defined by its name and the application products that are assigned to it.
Click the Add button in the Products window to add a product.
A list offers a range of Cumulus products that can be included. The list will also offer other products if they are registered and activated with the Cumulus Server.
NOTE: Updating!
Remember to update the products assigned to Client Groups as well.
Departments
Optional feature! May not be available with your Cumulus configuration.
IMPORTANT!  
If you have the Department feature activated in addition to your already running Cumulus system, you must restart the Cumulus Server in order to make this feature available to the users.
With Cumulus departments, users and roles may be grouped together, e.g. according the organizational structure of a company. Then specific administrators (sub-administrators) may be defined who are in charge of the users/roles of a department, or several departments, but can not interfere with users/roles of departments they are not in charge of.
Sub-administrators can grant or revoke permissions to the role(s) assigned to the department(s) they are in charge of, but only if they have the respective permissions themselves. For example, there might be a role called ”picture editor” with the permission of editing metadata and which belongs to the department “Research”. The administrator in charge can revoke the editing metadata permissions from the picture editor role only if the administrator role (or any other role he or she acts in) itself has the editing metadata permission.
Defining departments does in no way interfere with user permissions and catalog access, which is controlled as always by the role(s) assigned to a user, nor does it influence the assignment of users to roles or vice versa.
The department feature is available in role-based mode only.
To create departments:
 
1.
2.
In the left pane of the Server Console, click on User Manager, then select Actions > Edit Departments.
A dialog appears allowing to create new departments and to edit or remove existing ones.
3.
Click Create to add a new department, then enter a name for the new department and click OK
4.
Checking the Users Catalog
This utility scans the Users catalog for inconsistencies. It checks whether all catalogs, sets and templates that are assigned to users/roles are available. If an item is found that is assigned but not available, it is recognized as invalid and you will be asked whether the according assignments should be deleted. You can have Cumulus do this item for item or just ask you once for all items. Be careful when deleting assignments for catalogs: Cumulus considers catalogs as available only if they are opened with the Cumulus Server.
Copying User Settings
When the Users entry is selected in the User Manager module, the Actions menu offers another option: Copy User Settings. This option allows you to copy user settings from one user to another. The User Settings for the Cumulus application as set in the Preferences window are then copied.
 
1.
In the left panel of the Server Console window, click the entry User Manager and reveal its options. Then click on Users.
2.
Select Actions > Copy User Settings. A dialog opens to select the user you want to serve as template.
3.
4.
Click Find. The found users are listed. (Note that by default the result list can include a maximum of 50 entries.)
5.
Select the user you want to use as template and click OK.
The next step is to collect the users/roles you want to apply the settings to.
6.
Click Add User or Add Role to find those you want to inherit the settings.
Clicking Add User opens a dialog to find and select users.
Enter search criteria to find the desired user by her/his name. (The Cumulus built-in authentication will search login name, first, middle and last name.) Then click Find. The found users are listed. (Note that by default the result list can include a maximum of 50 entries.)
Clicking Add Roles opens a dialog that lists the roles.
7.
Select the users/roles you want to inherit the settings and click OK. They are transferred to the list of the Collect Users window.
8.
Click OK to apply the settings to the users addressed in the window.
LDAP Authentication Method
This section describes the way the LDAP Authenticator plug-in for the Cumulus Server works.
If you want to employ LDAP for user authentication with your Cumulus installation, you need profound LDAP knowledge to configure the set up for the co-operation between your existing LDAP server configuration and the Cumulus user management properly. In order to employ LDAP for user authentication with your Cumulus installation, you don’t need to change your existing LDAP schema or contents to add information needed for Cumulus.
The Cumulus LDAP Authenticator can be used in the following scenarios:
The user is already included in the $Users catalog of Cumulus and the E-Mail Address field of her/his properties should be filled using an existing LDAP server configuration.
The LDAP Authenticator is part of the Cumulus Server installation. It is configured through the LDAP.xml file in the conf folder (located in the Cumulus Server installation folder). The Server installation provides two example files that are pre-configured for ActiveDirectory and OpenDirectory LDAP schemes. It is best to start making a copy of the example that fits your LDAP installation and rename it to LDAP.xml. The provided pre-configured files contain detailed comments on the configuration items. If you use any other LDAP scheme than ActiveDirectory and OpenDirectory (e.g. eDirectory), you have to adapt the structure to the structure of your LDAP scheme.
The LDAP.xml file contains the LDAP host name and also the distinguished name (DN) of a user that is allowed to read the necessary LDAP information. The file also contains the password of this user in clear text so you should set up file permissions so that the LDAP.xml cannot be read by unauthorized users.
You can also specify whether to use Secure Socket Layer (SSL) communication with the LDAP server.
User Password Authentication
The LDAP Authenticator can check the user password for authentication. The LDAP Authenticator is used only if the field Authentication Method in a user’s properties is set to LDAP. Then LDAP will check the password a user logs in with, against a login name that matches the Login Name field of the user’s properties stored in the $Users catalog. With the role-based mode of the User Manager, it is always used if the user has no record in the $Users catalog.
The LDAP Authentication module uses the simple LDAP authentication method.
To employ the LDAP authentication method for a user’s password you have to configure the following items of the LDAP.xml file:
<ns:authenticator>
        <ns:search>
The example LDAP.xml files are syntactically correct for ActiveDirectory and OpenDirectory LDAP schemes. However, they contain placeholders. In order to make your version of the LDAP.xml work, you have to replace these placeholders with real values only. If you use any LDAP scheme other than ActiveDirectory and OpenDirectory, you have to adapt the structure to the structure of your LDAP scheme also.
User Fields
Optional feature! May not be available with your Cumulus configuration.
The LDAP Authenticator can provide field values for the user record (user properties) to be used in any client application for customized solutions. In the LDAP.xml file you can specify which field corresponds to which LDAP user node attribute. The field can be either an existing field from the $Users catalog in Cumulus or you can define your own field by specifying a new unique ID for it. (To specify a new unique ID, you should use the function provided by your operating system, e.g. for Linux use the command uuidgen -t or for Mac OS X use the command uuidgen.)
In any Cumulus Internet solution, you can display the field value using the standard <cumulus:fieldValue> JSP tag with the unique ID of the field.
If the user has a record in the $Users catalog of Cumulus, the field values from this record have precedence over values from the LDAP Authenticator.
To have LDAP Authenticator providing field values you have to configure the following items of the LDAP.xml file:
<ns:authenticator>
        <ns:search>
        <ns:fields>
The example LDAP.xml files provide one by one mappings of LDAP attribute values to Cumulus field values. The examples include those attributes included in a standard ActiveDirectory and OpenDirectory LDAP installation that have corresponding Cumulus fields in the $Users catalog. If you want your mapping to include another attribute from a user node, you have to add it as a new field element to your LDAP.xml file. If you use any LDAP scheme other than ActiveDirectory and OpenDirectory, you have to adapt the structure to the structure of your LDAP scheme and replace the pre-configured field elements by field elements fitting your LDAP scheme.
Cumulus Roles
Optional feature! May not be available with your Cumulus configuration.
If you work with the role-based mode of the User Manager, you can define mappings from LDAP groups to Cumulus roles. By using this mapping you no longer need an entry for this user in the User Manager (a user record in your $Users catalog). All you need is to define Cumulus roles and assign permission to them. Assigning users to these roles is done using the role mapping of the LDAP Authenticator. All role assignments done by the LDAP Authenticator module are added to the roles already assigned to the user through a record in the $Users catalog.
The LDAP Authenticator supports different kinds of role mappings:
To have LDAP Authenticator supporting role mapping you have to configure the following items of the LDAP.xml file:
<ns:authenticator>
        <ns:search>
        <ns:roles>
                <ns:role-mapping>
The example LDAP.xml files are syntactically correct for ActiveDirectory and OpenDirectory LDAP schemes. However, they contain placeholders for the names of Cumulus roles and LDAP groups. In order to make your version of the LDAP.xml work, you have to replace these placeholders with real values only. If you use any LDAP scheme other than ActiveDirectory and OpenDirectory, you also have to adapt the structure to the structure of your LDAP scheme.
Automatic mapping can be used if the names of your Cumulus roles correspond to attribute values of your LDAP groups. The easiest way is to use the cn attribute of the LDAP group node to match the Cumulus role name.
Manual role mapping is based on rules that define which LDAP group memberships are mapped to a Cumulus role membership. These rules are defined using <ns:role-mapping> elements.
The membership conditions inside a <ns:role-mapping> element are combined by “and”. A user will be assigned to a role only if the user fulfils all conditions. See also the following example:
If you want to use “or” combinations, you simply add new <ns:role-mapping> elements for the same Cumulus role name. All role mapping elements are combined using “or”. A user will be assigned to a role if the user fulfils the conditions of at least one <ns:role-mapping> element. See also the following example:
Security Aspects
The LDAP.xml configuration file needs to specify a user that is able to read the LDAP server's information. This user only needs read access to the LDAP parts you specify in your LDAP.xml file (typically the users node and possibly the groups node). As you also need to specify this user's password in the LDAP.xml file, you need to make sure the file cannot be read by any unauthorized user.
The LDAP Authenticator module does not make any changes to the LDAP server. It only reads information from it.