Users & Groups
The administration of users in imperia is based on the group concept. This concept has been established from the fact that many employees in a company perform similar tasks and must therefore have the same access rights.
A group is a set of several permissions that can be assigned to a user. With this group concept, user administration becomes easier as there is no need to permit every single function for new users.
Thereby, the administration of access permission will be easier: by simply changing the permissions assigned to a group, access permissions are changed for all users who can adopt the group.
There are two levels of access permissions:
Access permissions to content: Those permission are connected to categories and are edited in the Categories Manager.
Access permissions to functions: Those permissions are connected to functions and are granted in the Controller Permissions.
To access the group management dialog use the System > Groups menu.
As a system administrator you are able to see all available groups. A user is allowed to see only the groups that he/she is assigned to. More information on this topic in the chapter Change Group.
You have the following action options:
Restrict the group list with the help of a filter based on the initial letters. To do this, select the entry with the desired initial letters from the drop-down list:
Search for specific groups by entering a search term in the Search the group list input field. The search always takes place in the currently displayed (possibly filtered) group list and is started while you are still entering the search term.
- Create a new group. Proceed as described under Create group,
- Edit the permissions of existing groups. Proceed as described under Edit group,
- Delete existing groups. Proceed as described under Delete group.
The number of groups that can be created depends on the purchased license.
In the Group Management click the button Create new group.
The detail area for the group settings opens below the group list:
Enter a name for the group.
- Also, you may write Comments to the group. For example, describe its functionality.
- Under Read permissions choose which groups have the permissions to see this group listed. By default, this checkbox is activated, so that every user can see every group.
Under Wrie permissions choose which groups have the permissions to edit this group. By default, this checkbox is not activated. If you want to give the rights only to specific groups, activate the corresponding radio button and then select the desired groups from the drop-down list.
Click Save to save your changes.
The new group will be listed in the group management.
Click on the desired group in the Group Management.
The detail area for the group settings opens below the group list:
In addition to the information under Create group, you can see which users have been assigned the selected group or the superuser group.
Optionally access the user data from here by clicking Edit. Proceed as described in Create user.
- If necessary, restrict the display of the list to the active users by clicking the Show only active users checkbox.
Edit permissions of a group#
In the following, you will learn how to grant the group access to the various modules of the imperia system. You can also find more detailed information in the introduction of this chapter and the chapter Controller Permissions).
In the Group Management run the Permissions option in the dropdown list behind the desired group.
In the detail area below the list you can now assign the access rights for the group.
There are two possibilities:
a. Select the individual modules and set the permissions for the selected group (here the example "Categories"):
You will then be directed to the permissions of the module (here "Categories"), where you can specify the permissions for the selected group:
b. Click Mass permissions management to set the access rights for all or several permission classes (modules).
All modules are now selected.
- Set permissions on specific classes by unchecking the boxes in front of the modules you don't want.
- Copy permissions from available groups:
- First select the desired class or all classes.
- Specify the desired group whose access rights are to be copied for the permission classes. To do this, click in the input field and select a group from the drop-down list.
- Click Copy and confirm the security prompt that appears. A summary of the operation is displayed.
- If a limited amount of groups is licensed, it is not recommended to delete groups, but to edit existing ones.
- For technical reasons once assigned group IDs are not released when you delete the associated group. This means that the total number of groups will increase even if groups are deleted.
If an existing group is deleted, all users that can adopt that group loose the permissions associated with it.
In the Group Management, click Delete at the end of the line of the desired group.
To access the user management dialog use the System > Users menu.
You have the following action options:
Restrict the user list using the filters in the Last name, First name and Login fields based on the initial letters. To do this, select the entry with the desired initial letters from the drop-down list:
Filter the user list by the status of the users (active/inactive/all).
- Search for specific users by entering a search term in the Search the group list input field. The search always takes place in the currently displayed (possibly filtered) user list and is started while you are still entering the search term.
- Create a new user. Proceed as described under Create user,
- Edit an existing user. Proceed as described under Edit user,
- Delete existing users. Proceed as described under Delete user.
The first user on imperia's system is always the superuser (with ID 1). This user is a special case because he is not subjected to access restrictions and his permissions cannot be limited.
In the User Management, click Create new user.
The detail area on the right now shows the fields for the user data.
Enter the User information:
- Assign a user name. The user logs in with this name.
- Enter the first name, last name and e-mail address of the new user.
- Set a password: By default, the password must consist of at least five alphanumeric characters. You can make a change to this setting in
- Basically, the system language is preset with the default setting. Read the chapter System Language. However, this can be set individually here. Select a system language for the user from the Language drop-down list.
- With the Active option you can (de)activate the user's profile (only as superuser). Please also read the chapter Delete user.
Set the Group membership: Select the groups to which the user should belong. The user can change the group afterwards.
Decide under Setup user administration in the View Permissions area who is allowed to see this user.
- Define who is allowed to change the user data under Write Permissions. If you want to give the permissions only to specific groups, activate the corresponding radio button and then select the desired groups in the drop-down list.
- Click Save to save the settings.
The new user will be displayed in the User Management.
For further general settings for all users, please refer to the chapter System configuration.
- Documents store the ID of the last author.
- For technical reasons once assigned user IDs are not released when you delete the associated user. This means that the total number of groups will increase even if groups are deleted. The IDs are assigned automatically by the system.
- If a user is deleted from the system, it is not allowed to use the deleted user's name!
- Instead of deleting a user, deactivate his/her profile, see section Create user.
In the User Management, click Delete at the end of the line of the desired user.
Confirm the security prompt that appears.
LDAP stands for 'Lightweight Directory Access Protocol', and is essentially a distributed database on the network, based on client/server principle. An LDAP client opens a connection to an LDAP server and retrieves or provides information that should be included in the list.
The way this is done is determined by the protocol (currently version 3 of LDAP). In this context LDAP is also designated as X.500 Lite. X.500 is an international standard for directories, but with a much more complicated built than LDAP.
To use LDAP in imperia an LDAP Perl module must be installed. You can download it at
http://perl-ldap.sourceforge.net/. In some Linux distributions, it is included, but must be installed.
Since the term database has already been mentioned in this documentation - for example in chapter Document Storage and similarities are not to be dismissed as well, below we compare the LDAP properties with the properties of databases and file systems.
|LDAP||databases and file systems|
|read and write access||LDAP defines content optimized for read access.||However databases provide both options to optimize read (e.g. MySQL) or write access (Oracle).|
|LDAP does not have transaction mechanisms.||With databases this often is an important safety aspect regarding data loss.|
|data structure||LDAP as well as file systems use tree structure for data storage. Files can be viewed as a node in a tree and often have a size of several giga- or megabytes.LDAP, however, is designed to ensure that a node in its directory tree requires a rather small amount of memory. A typical example of an entry would be user data, which in most cases should not exceed one megabyte.|
|data access within a node||With LDAP that is not possible, because the smallest read and write unit is the attribute, that will expand later.||With file systems direct access to separate bytes is possible. This means that the byte is the smallest read and write unit in a file system.|
|groups and user management||In addition to groups and user management, imperia offers the ability to connect to an LDAP system...||...this allows an existing group and user database to be used in imperia. In this case, administration and maintenance of this directory is no longer carried out by imperia.|
site/modules/core/Dynamic/Authenticator you will find different plug-ins that can be used for the user administration.
With the integration of LDAP directory service some of the standard package imperia features will be limited:
The administration and maintenance of group and user information may no longer be performed in full in imperia.
With LDAP connection, as with imperia's user management, the transitive group structure does not resolve. Although, this is irrelevant in regard to most directory services, as they resolve the transitive group management themselves. The access and modification permissions to other users do not change within the first LDAP implementation. This means: A read access to all other users and groups to a single user cannot be denied.
When using ActiveDirectory, the LDAP server for Microsoft® is currently supporting only one Windows® domain.
Connection to a Directory Service#
There are two ways to connect a directory service in imperia:
- This procedure grants imperia's server its own access to a directory service, through which it is able to read user and group information.
- Information about a user that imperia needs, but cannot be stored in the directory service is stored in the file system of imperia's server.
- In this method imperia uses the access of a logged in user to connect with a directory service.
- This guarantees that every user can see the information, which he has access to because of his account.
- The disadvantage is that the user has to log in every time and imperia has to save the password in a cookie. This has some security risk, despite the encoding.
There are several methods to login to imperia via an LDAP connection:
- This is the default imperia authentication plug-in.
- In this case, an imperia account is required to connect to the directory service.
- Furthermore, you must specify a password field in the LDAP configuration. If this is stored encoded in the LDAP server, the LDAP configuration
password-encryptionkeyword must be set accordingly.
- If a user is logged in to a Kerberos server, he or she can log in automatically using the Kerberos plug-in through the relevant ticket.
- This plug-in requires a program installation on the client, which is part of the delivery package of imperia.
- When the program starts users are logged in in imperia without having to enter username and password. When imperia's log in screen is called users are automatically redirected to the menu. The Kerberos plug-in only works with imperia's account method for connecting to a directory server.
- This is the primary authentication plug-in for directory access to imperia.
- A user types in his or her password for the directory service to log on to imperia.
- You may also configure if the request data should be started with the user account or a standard imperia account.
Required Configuration for LDAP#
The configuration of an LDAP connection must be done manually in two files:
The following variables must be set:
"UMLIGHT_PLUGIN" = "LDAPLight" "DATABASE_STORAGE_PLUGIN" = "LDAP"
and optionally the authentication plug-in to be used (LDAP, Kerberos, etc.):
"AUTH_PLUGIN" = "LDAP"
Information for the directory service and the LDAP access, as well as imperia's access to the directory service, must be set in this configuration file. Since imperia 9.1 the Scope value can also be configured.
In LDAP.conf - Example you can find examples of PAM and ADIR schemes configuration.
Information about the Directory Service#
server ldap.server.net port 1234 version 3
If the variable
version is not set, the LDAP protocol version 2 will automatically be used.
Information about LDAP Access#
Information about LDAP access with which imperia accesses the directory service is optional, in case the
anonymous account does not have enough read permission to identify an imperia user. For further access, outside of the identification phase, the LDAP connection supports two other methods.
bind_dn cn=Admin, 0=Imperia password secret
If an imperia user password is set, it will be used to read out the user and group information from the directory service.
If an imperia user password is not set, the LDAP defined accout or an
anonymous accountwould be used.
In case LDAP users are not able to access their data, you might set an
administrative account as an variable in LDAP.Config (possible values are
bindmode = admin
By that the administrative account for the loading of the LDAP-user information.
List of User Container#
This is a list of containers in which the possible users are included:
user_dn_1 ou=Development, o=Imperia, c=de user_dn_2 ou=Sales, o=Imperia, c=de user_dn_3 ou=Distribution, o=Imperia, c=de
In order for the search to be effective within a container, it is limited to one level. In the above mentioned example it is not enough to enter the following:
user_dn_1 o=Imperia, c=de
In the LDAP.conf, it is possible to set scope to subtree.
List of Attributes#
This list contains all user attributes, which are stored in the directory service. Define the names under which the attributes are stored.
USERFIELDS id * uid login * cn name sn comment description fname fn password userPassword telnumber telephonenumber END_USERFIELDS
The attributes are bracketed as a list between the keywords USER FIELDS and END_USERFIEDS. The fields marked with asterisk (
uid) are required.
Furthermore, you have to make sure that the text representation of the LDAP attribute for
id is a positive number and the
login field for the imperia user is unambiguous.
Apart from the
id, the imperia-defined data input fields for users can be set as attributes. These fields are:
name comment fname login password language homepage addlinkmenu addtextmenu adddescmenu addtexticon bgcolor street city zip country telnumber cellular faxnumber background email
Fields that cannot be stored in the directory service are stored in the file system of imperia's server.
Unless the original password is used, instead of the LDAP plug-in's, the password field is not really used by imperia. In this case, you should also set a password encryption, see Information about LDAP access.
- Instead of a unique numeric user or group ID, the so-called binary SIDs are used in the directory service of Microsoft ® (Active Directory). These are generally accepted in imperia, but the ADIR grouping scheme must be set.
- imperia requires that the respective RIDs and SIDs are unambiguous within the assumed by imperia users groups.
This setting affects only the default authentication plug-in (password):
Currently, the methods
MD5 are implemented.
To register (bind) to an LDAP server, a password encoding is necessary before transfer, since it cannot be transmitted in plain text.
The implemented standard processes are
SASL. To use
SASL you need LDAP protocol version 3.
LDAP Filter for Valid imperia Users#
This filter is used to identify valid (existing) imperia users.
Objects (DIT) that meet this first condition will be recognized as imperia users.
List of group Containers#
This is a list of all containers from the directory service, in which the possible groups are included:
group_dn_1 ou=Roles, o=Imperia, c=de
comment can be set here. The
id field is the only required one and it has to be numeric.
When using ADIR grouping schemes, the same exception as with the UID applies.
List of group Attributes#
This is a list of all group attributes, which are stored in the directory service. This list, as the list of users, must be entered within tags:
GROUPFIELDS id gid name name comment description END_GROUPFIELDS
LDAP Filter for group Identification#
This filter is used to identify the managed by imperia groups.
Objects that fulfill this condition are considered as imperia groups.
Which user can assume which group has to be visible to imperia. With directory services, there is no uniform standard. imperia initially supports the PAM scheme.
In this regard, groups contain a
memberuid in the attribute (which is
uid of the user they belong to (Attention! not the
uidnumber). Contrary to this, users do not have an attribute that contains all the groups they can adopt. The main group of users, under which the
memberuid must be set, is not displayed in the user data record under
imperia's superuser group (by default the group with ID
0) can be given to an arbitrary group as user attitude when using LDAP plug-ins.
superuser_group cn=cvs, ou=Roles, o=Imperia, c=de
If a user logs in with this group, he or she will have all the permissions of the superuser group.
This setting affects only the LDAP authentication plug-in.
Administration of a superuser created in imperia cannot be done via a user created in the directory service. Despite that, the superuser has to be mapped to a user in the directory service. This is done in the following way:
superuser cn=tgier, ou=People, o=Imperia, c=de
If a user logs in as superuser, the entered password is compared with the credentials of the specified DN entry and a temporary user with the ID
1 is created.
This setting affects only the LDAP authentication plug-in.
If this variable is set, the LDAP authentication plug-in makes a connection to the directory service at each CGI call from a user.
To clarify: if this variable is omitted or
0, imperia takes the whole information from the directory service through the configured administrator access.
Write access to the directory service via LDAP is prevented by setting the following variable:
imperia as Front-end for an LDAP Directory Service#
This function is currently developed.
If imperia should be used as a front-end for an LDAP-compliant directory service, the following settings are required:
Entering RDN Attribute for a New User#
Object Classes of a New imperia User#
OBJECTCLASSES_USER top person *imperia*User END_OBJECTCLASSES_USER
Entering RDN Attribute for a New group#
Object Classes of a New imperia group#
Object classes a new imperia group belongs to:
OBJECTCLASSES_GROUP top posixGroup END_OBJECTCLASSES_GROUP
LDAP.conf - Example#
Below are examples of
LDAP.conf for PAM and ADIR grouping schemes.
## Servername and IP address for LDAP server. serverldap.imperia.net port389 ## DN and password from ldap adminstrator ## None if we are using the Anonymous Binding. ##bind_dn "cn=Admin, o=intern" ##password superuser ## Container for user entries and attribute for RDN. So the DN of every ## user have the form ## "user_rdn_attribute=value_of_user_rdn_attribute, user_dn" user_dn_1 ou=People, o=Imperia, c=de ##user_dn_2 ou=Sales, o=intern ##user_dn_3 ou=Purchase, o=intern ##user_dn_4 ou=Marketing, o=intern ##user_dn_5 "ou=Distribution, o=intern" user_rdn_attribute cn ## Timelimit for search operations timelimit 0 ## Setting attributes for *imperia* user. USERFIELDS id uidnumber name cn login uid END_USERFIELDS valid_user (gidnumber=100) ## Setting objectclasses an *imperia* user belongs to. ##OBJECTCLASSES_USER ##top ##account ##posixAccount ##shadowAccount ##person ##organizationalPerson ##inetOrgPerson ##END_OBJECTCLASSES_USER ## Setting attribute for *imperia* groups GROUPFIELDS id gidnumber name cn comment cn END_GROUPFIELDS ## group_dn_1 ou=Groups, o=Imperia, c=de valid_group (gidnumber>=0) ## Setting objectclasses an *imperia* group entry belongs to. ##OBJECTCLASSES_GROUP ##top ##posixGroup ##END_OBJECTCLASSES_GROUP grp_schemePAM superuseruid=tomg, ou=People, o=Imperia, c=de
## Servername and IP adress for LDAP server. serverwindb port389 ## DN and password from ldap adminstrator ## None if we are using the Anonymous Binding. bind_dn Administrator@activetest.hyper password xxxxxxx ## Container for user entries and attribute for RDN. user_dn_1 CN=Users,DC=activeTest,DC=hyper user_rdn_attribute cn ## Timelimit for search operations timelimit 0 ## Setting attributes for *imperia* user. USERFIELDS id objectSid name displayName login cn END_USERFIELDS valid_user (objectclass=user) ## Setting objectclasses an *imperia* user belongs to. ##OBJECTCLASSES_USER ##END_OBJECTCLASSES_USER ## Setting attribute for *imperia* groups GROUPFIELDS id objectSid name cn comment description END_GROUPFIELDS ## group_dn_1 CN=Users,DC=activeTest,DC=hyper group_dn_2 CN=Builtin,DC=activeTest,DC=hyper valid_group (objectclass=group) ## Setting objectclasses an *imperia* group entry belongs to. ##OBJECTCLASSES_GROUP ##END_OBJECTCLASSES_GROUP grp_schemeADIR superuser CN=Administrator,CN=Users,DC=activeTest,DC=hyper superuser_group CN=DomainAdmins,CN=Users,DC=activeTest,DC=hyper ##userbind1
Authentication over HTTP#
The Basic plug-in is an alternative authentication method. It differs from other authentication methods in two respects:
Authentication is done without Cookie.
imperia's authentication is overridden.
Instead, the web server accepts users authentication. Successfully registered users get access to the CMS.
When using HTTP authentication, passwords cannot be changed via the Profile menu item.
Authorization of logged in users is still done via the User and group Management of the system. A user must, therefore, exist in imperia in order to use the system.
An authenticated user has no rights in the system without an imperia user profile. He or she only has access to the menu item Profile and the internal mail system.
To use HTTP authentication, the following must be done:
cgi-bindirectory in your web server configuration as a rights-protected area. Take the necessary steps described in your web server's documentation.
Note that imperia performs authorization based on the user data passed from the web server. HTTP authentication data and imperia's user profiles have to match in order for users to be assigned the proper privileges.
imperia's default login page (
htdocs/imperia/index.html) should be bypassed in the HTTP authentication. This page should no longer be accessible. Instead, the
site_main.plscript should be called directly in the
cgi-bindirectory. When linking from another site to the CMS, references should be adjusted accordingly. For example, you can create an HTML document with a reference to the
site_main.plscript in the
cgi-bindirectory. Rename the file accordingly, so that it will be automatically called when someone accesses the production server. Put that document in the document root of your production system.
Enable HTTP authentication in imperia. Find the
AUTH_PLUGINvariable in the
site/configdirectory and change it as follows:
"AUTH_PLUGIN" = "Basic"
It is possible to enable HTTP authentication to the web server for the usual imperia login beforehand. In this case users will have to also log in through imperia's authentication. If the
cgi-bindirectory is not password protected, the login to the system is not possible, as the data of the HTTP header cannot be compared to the web server's.
RESULT: When accessing
site_main.pl a login prompt appears on the web server. imperia's menu appears after successful authentication.