Permissions

Permissions

In association with the login, you can manage permissions granted to the user.

Define the permission scheme for your system

One of the first point to start with is to decide how to organize your permissions on a functional point of view.

Applications

Start by the highest functional level: the applications. List all applications that will require permission management.

Areas

Each application may further be divided into different functional areas. For each application, list all areas that will require particular permission management.

Rights

For each area, list all different rights to be taken into account (view, create, edit, delete for instance).

From the functional to the technical...

Now that you have defined your needs, we'll see how to fill in the corresponding LiveUser tables.

The «liveuser_applications» Table

For each application, note the name and associate an id to it.

The table contains few fields:

• application_id: the id of the application
• application_define_name: the name of the application

Example:

The «liveuser_areas» Table

For each area, note the area name, the application id it belong to and an associated area id.

The table contains few fields:

• area_id: the id of the area
• application_id: the id of the application the area is part of
• area_define_name: the name of the area

Example: in our example, the «TEST» application will be divided into 4 areas.

The «liveuser_rights» Table

For each area, note the right name, the area id it should be associated with and a right id.

The table contains few fields:

• right_id: the id of the right
• area_id: the id of the area the right is referring to
• right_define_name: the name of the right
• has_implied: boolean specifying whether when a user is granted this right, another (others) right(s) may automatically be granted as well. The list of implied rights are specified in the «liveuser_right_implied» table.
  Attention: this is only to be used with the complex permission management (see later). Until then, we'll leave its value to «0».

Example: Users will be granted 4 different rights to the «EVENT» area:

Dealing with users

The «liveuser_users» Table

Information regarding user authentication is stored in the «liveuser_users» table.

The «liveuser_perm_users» Table

Information regarding user permission is stored in the «liveuser_perm_users» table:

• perm_user_id: a unique identifier for a user at permission management level
• auth_user_id: the identifier of the user at authentication management level
• auth_container_name: the number or name of the authentication container
• perm_type: we'll keep the value for a simple user (= 1) and come back later on on its use

Mapping between authentication and permission tables

To make the link between both tables, the «auth_user_id» for a specific authentification container is mapped to a unique «perm_user_id». In this example, only one authentication container is used.

It may be usefull to remember here that LiveUser can handle more than one authentication container (for instance, one database containing the list of permanent employees and one XML file containing the list of freelance contractor) but handles only one permission container. So all users from any authentication container will be mapped to a unique «perm_user_id».

Note that the mapping is optional. If a link cannot be made between a record in the «liveuser_users» table and a record in the «liveuser_perm_users» table, the authenticated user will not belong to any group and will not be granted any right.

Mapping using a numeric array

In our sample configuration file, the «authContainters» contains one authentication source, a MDB2 one. No key is associated to it. This source is thus implicitely associated with the value «0».

<?php     ...
        'authContainers' => array(
            array(
                'type'          => 'MDB2',          // auth container name
                'expireTime'    => 3600,            // max lifetime of a session in seconds
                'idleTime'      => 1800,            // max time between 2 requests
                'allowDuplicateHandles' => 0,
                'allowEmptyPasswords'   => 1, 
                'passwordEncryptionMode'=> 'MD5',
   ...
?>

The value to be set as «auth_container_name» is thus equal to zero.

Mapping using an associative array

You can change the configuration file and associate a key to the authentication container.

   ...
        'authContainers' => array(
            'myTestDB' => array(
                'type'          => 'MDB2',          // auth container name
                'expireTime'    => 3600,            // max lifetime of a session in seconds
                'idleTime'      => 1800,            // max time between 2 requests
                'allowDuplicateHandles' => 0,
                'allowEmptyPasswords'   => 1,
                'passwordEncryptionMode'=> 'MD5',
   ...

In this case, the value to be set as «auth_container_name» must be equal to «myTestDB».

Whatever system you choose, keep your solution consistent. Otherwise, it won't work.

Assigning rights to users

There are several ways to do it:

• assigning directly a right to a user
• assigning a right to a group of users
• assigning a right to a sub-group of users and/or inherit an implied right

By enumerating them, we have somehow defined the 3 levels of permissions management LiveUser can deal with:

• simple level
• medium level
• complex level

We'll cover them in the next pages.

	Web www.gvngroup.be