Skip to content

Users & Groups

The administration of users in imperia is based on the group concept. This concept comes from the fact that in a company several employees do similar jobs, which calls for the same access permissions.

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.

Group Management#

To access the group management dialog go to Menu -> System -> Groups.

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.

group management dialog

In this dialog one can:

  • restrict the displayed groups (by the first letter),
  • search groups (in the field Search the group list),
  • create a new group, see next section Create new group,
  • see and edit the permissions of existing groups, see section Edit group,
  • delete groups, see section Delete group.

Create new group#

Please note

The number of groups that can be created depends on the purchased license.

  1. In the group management click the button Create new group.
    The page EDIT GROUP DATA opens:
    page EDIT GROUP DATA
  2. Enter a name for the group.
  3. Also, you may write Comments to the group. For example, describe its functionality.
  4. Select groups that can see this group:
    you can 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.
  5. Select groups that can change this group:
    you can choose which groups have the permissions to edit this group. By default, this checkbox is not activated.
    Enter the names of groups you want to grant this right or leave it empty.
  6. Click Save to save your changes. A confirmation message will appear.

The new group will be then listed in the group management.

Edit group#

  1. To edit an existing group, in the group management, select the group you wish to edit.
    The page EDIT GROUP DATA (with extended options) opens:
    Edit a group dialog
    The first section is identical to the dialog in Create new group.
    Additionally, here you can see which users the selected group and/or super user-group is assgined to.
  2. By clicking you can edit the data.
  3. You can also limit the lists to display only active users.

Edit permissions of a group#

In the following, it will be explained how to set the group's permissions to the modules in imperia. (More information on this topic, read the introduction of this chapter and the chapter Controller Permissions).

In the group management click Permissions' Overview.The page PERMISSIONS OVERVIEW opens. There you have two options to edit the permissions:

  • You can set the permission for each module separately by selecting the desired one, e.g. "Categories":
    Permissions
    You will then be directed to the permissions of the module (here "Categories"), where you can specify the permissions for the selected group:
    Permissions

  • You can set the permissions for all modules simultaneously, click Mass permissions management:
    Permissions
    There, you have following options:

    • Set the access permissions to single modules by de-/activating the checkboxes or
    • Select All checkboxes or
    • Copy Permissions from available groups
      1. First, select the module you want to copy the permissions for.
      2. Then, enter the name of the group you want to copy the permissions from.
      3. Save the settings by clicling Copy.A log about the copied permissions will be shown to you after the successful copy.

Delete group#

Note

  • 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.

Please note

If an existing group is deleted, all users that can adopt that group loose the permissions associated with it.

  1. To delete a group, in the group management, click at the end of the line of the to be deleted.
  2. A confirmation pops up. To delete choose OK.

User management#

To access the user management dialog go to Menu -> System -> Users.

user management dialog

In this dialog you can:

  • restrict the displayed users (by the fields' values 'last name', 'first name', 'login'; alphabetically; by the status 'active', 'inactive', 'all' ),
  • search users (in the field Free search),
  • create a new user, see next section Create new user,
  • see and edit the existing users, see section Edit user,
  • delete users, see section Delete user.

Create new user#

Please note

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.

  1. In the user management, click Create new user. The USER SETTINGS opens: user management dialog
    The dialog is divided into several sections. In the following only the important ones will be described:

    • User information:
      • Login (mandatory): The login-name of the user.
      • Password (mandatory): a valid password comprises of at least five alphanumeric characters. Passwords with fewer characters are rejected by the system. In case there are different password rules on your system, an error with the current rules is displayed if the entered value does not meet them.
      • Re-enter password (mandatory)
      • Language (optional): The language is preselected by “default” (that is to be changed in General Settings), but can be changed here individually.
      • Active (Checkbox): A checkbox to select whether a user is active or not (by default 'active').
      • Password expiration: (default is Never); use the calender icon to select a date for password expiration.
    • Group Membership:
      Select from (existing) groups, which ones the user can take.
    • Permissions:
      Set the groups that will have permissions to edit the new user's data. To give all groups the permissions to edit the new user select the checkbox All groups may edit this user.

  2. The new user's data is stored by clicking Save. A confirmation notification is displayed. To exit without saving use Cancel.

The new user will be displayed in the user management.

Delete user#

Important

  • 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 new user.

  1. To delete a user, in the user management click at the end of the row.
  2. Confirm the deletion

LDAP/Directory Services#

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://www.cpan.org/ or 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.

Note

Under site/modules/core/Dynamic/Authenticator you will find different plug-ins that can be used for the user administration.

Limitations#

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:

  • imperia* account:

    • 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.

  • User account:

    • 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.

imperia Login#

There are several methods to login to imperia via an LDAP connection:

  • Password:

    • 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-encryption keyword must be set accordingly.

  • Kerberos:

    • 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.

  • LDAP

    • 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:

  • In the /site/config/system.conf file;

  • In the /site/config/ldap.conf file.

system.conf#

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"

ldap.conf#

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.

Please note

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 account would be used.

Note

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 admin, user):

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

Note

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 (login and 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.

Please note

  • 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.

Password Encryption#

This setting affects only the default authentication plug-in (password):

password-encryption none

Currently, the methods none and MD5 are implemented.

Password Coding#

To register (bind) to an LDAP server, a password encoding is necessary before transfer, since it cannot be transmitted in plain text.

password-encoding    SASL

The implemented standard processes are none and 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.

valid_user      (&(objectclass=Person))

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

The fields id, name and comment can be set here. The id field is the only required one and it has to be numeric.

Please note

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.

valid_group       (&(objectclass=Group))

Objects that fulfill this condition are considered as imperia groups.

Grouping Scheme#

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.

grp_scheme     PAM

In this regard, groups contain a memberuid in the attribute (which is multivalued) and 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 gidnumber.

Superuser#

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.

Superuser Access#

Please note

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.

User Access#

Please note

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.

userbind      yes

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#

Write access to the directory service via LDAP is prevented by setting the following variable:

readonly      yes

imperia as Front-end for an LDAP Directory Service#

Please note

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#
user_rdn_attribute       cn
Object Classes of a New imperia User#
OBJECTCLASSES_USER
top
person
*imperia*User
END_OBJECTCLASSES_USER
Entering RDN Attribute for a New group#
group_rdn_attribute      cn
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.

PAM#

## 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

ADIR#

## 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.

Important

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.

Configuration#

To use HTTP authentication, the following must be done:

  1. Restrict the cgi-bin directory in your web server configuration as a rights-protected area. Take the necessary steps described in your web server's documentation.

    Please consider

    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.

  2. 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.pl script should be called directly in the cgi-bin directory. 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.pl script in the cgi-bin directory. 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.

  3. Enable HTTP authentication in imperia. Find the AUTH_PLUGIN variable in the site/config directory and change it as follows:

    "AUTH_PLUGIN" = "Basic"

    Important

    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-bin directory 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.