Users
Login management¶
CCH Tagetik is a highly structured application. For this reason, it is necessary to manage access to data for individual users and groups of users with the same responsibilities. This makes it possible to protect sensitive data and prevents data from being edited by unauthorised users.
Creating users¶
Users can be created either directly by CCH Tagetik or indirectly by means of external systems integrated with CCH Tagetik. Users’ personal details and rights are first added to the Repository database and then to the various application databases they are authorised to access. Further user restrictions on the various dimensions are subsequently detailed in the configuration of working environments on the various application databases.
User lists¶
The following user lists exist in CCH Tagetik:
| Type of lists | Characteristics |
|---|---|
| Centralised user list | - Saved in the Repository database. - Indicates the accessible databases and the functions available on each of them, for every user. |
| Application database table | - Saved in the individual application databases. - Only contains data on users authorised to access that specific database. - Indicates the user rights over elements of the data model. |
Integration of authentication systems¶
CCH Tagetik defines the authentication criteria, i.e. the requirements for user access to the system, in the Repository database. However, it can also be integrated with the following external authentication systems to inherit details and credentials:
| System | Description |
|---|---|
| Lightweight Directory Access Protocol (LDAP) | Communicates with Directory services, and particularly with the Windows Active Directory. Tagetik allows more than one LDAP Configuration to be defined, in order to be able to run LDAP authentication for users who are registered on the LDAP service in different domains. |
| Http Header Customizable (HHC) | This allows automatic user access to the application. The authentication data are read directly in the headers of the HTTP request. (Proprietary Tagetik authentication mechanism) |
| Remote Authentication Dial-In User Service (RADIUS) | This allows access with a username and password, and also the enabling of a token-based two-factor authentication system. |
| Internet X.509 Public Key Infrastructure (IPKI) Client Certificate | If there is more than one HTTPS connection, this allows access by requesting a client certificate to authenticate the user. Normally in HTTPS connections, only the server provides a certificate. When the server also requests a certificate from the client, there is two-way SSL authentication. |
| Kerberos | This allows automatic user authentication for users already authenticated in a Windows domain. |
| SAML | This allows automatic access for users already authenticated in another secure domain. |
| OpenID | This allows access for users with an ID represented by an URL provided by an identity provider. The user must already be registered on this site. |
For more details on interactions between CCH Tagetik and the LDAP system, see the documentation on that specific topic.
The Default authentication mechanism also automatically manages Sharepoint authentication. This is a proprietary CCH Tagetik mechanism and is based on symmetrical key encryption which allows users connected to the Sharepoint portal to access CCH Tagetik as well.
Reference users¶
To facilitate and speed up the creation and configuration of new users, pre-existing reference users can be used as a template. The functions and authorisations of the reference users will be added to the functions attributed to the user.
Area profiles¶
Area profiles are dummy users to whom roles and rights are attributed. Administrators can associate area profiles with users and thus restrict the number of functions that can be enabled for those users. The area profile function therefore gives a maximum limit of possible authorisations for the associated user. For example, users associated with the “Italy” area profile can be configured to have access to different functions and data compared with users associated with the “USA” area profile.
Users associated with an area profile in an application environment will inherit the rights of the area profile in the same environment for each individual dimension.
Operationally, the area profiles are a way of delegating user management. They can be used by peripheral administrators to control authorisations for specific groups of users.
Interaction Between User Authorization Levels¶
When a user has their own permissions and is assigned a Reference User or an Area Profile, CCH® Tagetik determines the effective permissions in the following order:
Basic level – User default permissions (Contributor role with the default restrictions defined for Category, Consolidation Scenario, Entity, and Collaborative Office, write and submission rights).
Reference User – For users linked to one or more Reference Users, all roles, accessible databases, and permissions assigned to the selected Reference User(s) in the Security > Reference Users and Area Profile tab are added (set union), provided that the Inherit roles from Reference User flag is enabled. A permission granted through a Reference User cannot be revoked simply by omitting it from the target user. To revoke this permission, remove it from the Reference User or disable the inheritance relationship.
Area Profile – If the user is associated with an Area Profile (Inherit Area Profile from another user enabled), the permission set resulting from one of the previous step is intersected with the permissions defined in the Area Profile. Any permission not included in the Area Profile is removed. The Area Profile therefore acts as the upper boundary for the user's effective permissions.
Dimension Restrictions (User Rights) – Restrictions defined at the individual database level through User Rights for Entity, Task, Category, Consolidation Scenario, and Analytical Dimension are applied in addition to those configured in the Area Profile. These restrictions can further reduce the user's visibility and editing rights, but they cannot extend access beyond the limits defined by the Area Profile, when present
Note: Although Area Profiles and Reference Users can be used together, it is generally recommended to use only one of these mechanisms when defining authorizations. This simplifies permission management and avoids unnecessarily complexity
User alignment¶
After the users have been created in the Repository database, they must also be copied into the application databases in which they are authorised to work. This operation is called alignment.
Rights over the data model, or the rights over the various dimensions and functions accessible to the user, will be defined subsequently.
If the user running the alignment is associated with an area profile, any users not associated with the same area profile will be excluded from the alignment.
The alignment operation also eliminates users not present in the Repository and locks users who are temporarily locked in the Repository.
User configuration process¶
The user configuration process typically follows these phases:
| Phase | Description | See |
|---|---|---|
| 1 | Create users in the Repository database or import users already registered on other authentication system | Add a user manually Import the user details from the LDAP system |
| 2 | Create any custom roles | Create a custom roles |
| 3 | Associate a role to each user | Associate one or several roles with a user |
| 4 | Align users on the working application database | Authorise a user to work on an application database |
| 5 | Set rights: assign specific rights in the context of the data model. | - |
User Creation and Deletion Log¶
To verify user creation or deletion operations, you can use the Metadata Log Report (see Metadata log report page), available at:
Repository > Audit > Report > Metadata Log Report.
The report displays a list of recorded operations and includes, for each of them:
The user who performed the action.
The date and time when the operation was executed.
The identifier of the object involved (for example, the user code that was created or deleted).
This information makes it possible to accurately monitor and verify all relevant administrative activities, ensuring full traceability of the changes applied.
Password security requirements¶
The system administrator defines the characteristics and requirements for passwords that can be set by the user. Those characteristics and requirements are listed in the table called Password rules page. CCH Tagetik also allows for more restrictive password management, using rules that require the following characteristics in order for the password to be considered secure:
- length must be at least eight characters
- must contain at least one number
- must contain at least one special character
- must never have been used before
- valid for a maximum of three months
To enable this type of management, activate the it.grupposervizi.easy.pwd.rule.security.enabled system property on the application server. The property also acts on passwords already in use. Once activated, the pre-existing passwords will be changed so that they meet the requirements defined by these rules.