LiveUser Permission Management

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:

liveuser_applications
application_id application_define_name
1 TEST

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.

liveuser_areas
application_id area_id area_define_name
1 1 EVENT
1 2 RECEIPT
1 3 REAL_ESTATE
1 4 ADMIN

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:

liveuser_rights
area_id right_id right_define_name has_implied
1 1 EVE_VIEW 0
1 2 EVE_CREATE 0
1 3 EVE_EDIT 0
1 4 EVE_DELETE 0

Dealing with users

The «liveuser_users» Table

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

liveuser_users
auth_user_id handle ...
25 userF ...

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
liveuser_perm_users
perm_user_id auth_user_id auth_container_name perm_type
12 25 0 1

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

Code
     ...
        '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.

liveuser_perm_users
perm_user_id auth_user_id auth_container_name perm_type
12 25 0 1

Mapping using an associative array

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

Code
   ...
        '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».

liveuser_perm_users
perm_user_id auth_user_id auth_container_name perm_type
12 25 myTestDB 1

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:

We'll cover them in the next pages.

Get in touch!

We'd love to hear from you, what you think about this page or what we can do for you.

Contact Us

View this page with IE8+, Mozilla Firefox, Safari, Chrome and Mobiles

Last modificaton on 21 May 2015 by St├ęphane Van Nerom

© 2006-2014 - GVN - All rights reserved
v2.0.14