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.

---

---

Group Management

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.

---

Create group

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 detail area for the group settings opens below the group list:

   

2. Enter a name for the group.

3. Also, you may write Comments to the group. For example, describe its functionality.
4. 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.

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

   

6. Click Save to save your changes.

The new group will be listed in the group management.

---

Edit group

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

2. Optionally access the user data from here by clicking Edit. Proceed as described in Create user.

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

---

Delete group

Warning

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

Note

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.

  

---

---

User Management

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.

---

Create user

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 detail area on the right now shows the fields for the user data.

2. Enter the general user information:

   

   • Assign a user name. The user logs in with this name.
   • Set the group membership: Select the groups to which the user should belong. The user can change the group afterwards.
   • Set a password: By default, the password must consist of at least five alphanumeric characters. You can make a change to this setting in system.config.
   • Confirm the password.
   • Select an expiry date for the password. Use the calendar function to do this.

3. Add personal information for the user:

   

   • Enter the first name and the last name of the new user.
   • 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.
   • Enter the user's email address.

4. Assign the user permissions:

   

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

5. Set the status of the user profile:

   • With the Active option you can (de)activate the user's profile (only as superuser). Please also read the chapter Delete user.

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

---

Delete user

Warning

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

1. In the User Management, click Delete at the end of the line of the desired user.

   

2. Confirm the security prompt that appears.

---

---

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.

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.

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.

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

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

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

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.

Warning

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.

   Note

   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"
   

   Warning

   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.