Question about restricting user access to site & data.

[nelsonm]

Hi all,

I'm not sure if this is the right place for these questions, but i'll ask anyway.

I'm designing my first customer scheduling and work order tracking system for a franchise. One big issue i'm not sure on how to approach is - user access restrictions once the user is logged into the system. I want to restrict access to the system and data based on the user's access restrictions.


Questions:
0. In general, how is access restriction implemented.
1. Are access restrictions normally defined in an employee or user database table?
2. Should access restriction be a single field or a group of fields?
3. If a single field, is it normally done using a bit field?
4. Should access restriction be done during each mysql query or at each UI?


Currently there are three levels of authorization:
1. Franchisor - full unrestricted access to system, screens and data.
2. Franchisee - access restricted to franchisee's screens and data only.
3. Technician - access restricted to franchisee technician's assigned work orders.

The system is divided into three components:
1. The Call Center site.
2. Franchisee mobile site.
3. The Technician mobile site.

The "Call Center" site is used by all franchisee call centers for entering, editing and scheduling customer work orders on the dispatch board screen. Each franchisees' instance of the "Call Center" site, based on login and access restriction, must be restricted to show only that franchisees' customer, technician and work order data.

The "Franchisee" mobile site will run off of a smart phone. Each instance of the "Franchisee" mobile site, based on login and access restriction, must be restricted to show only that franchisees' statistics and totals.

The "Technician" mobile site will run off of a data enabled tablet. Each instance of the "Technician" mobile site, based on login and access restriction, must be restricted to show only that Technicians' assigned work orders.

Any help would be appreciated.

[abushahin]

Hello Nelsonm, generally when I have implemented restricted access based on user is by defining type of user in a database table (usually login table [username,password,user_type]).
Then with php or any other server side processing it is possible to restrict users from accessing certain pages unless they are a certain type of user. So once they have logged in you can store in a session variable the type of user they are and on each page check for allowed user types.

[nelsonm]

abushahin, thanks for responding...

1. Is it better to use a separate login/access table then adding login/access fields to the user/employee table?

2. What about data restriction? Is it better to restrict during sql query or at the UI?

[abushahin]

Nelsonm no probs, ok so
1. i would use a seperate login table although it may just be a one to one relationship but then i can link it to seperate tables in the future if i add other types of members etc.
2. you can do it both ways i guess but like i said before i would do it with the UI as that way i can restrict access based on user type. Either way you will have to first define user type then on each page check for user type.

Just to give you an idea:

if (usertype!="member")
{
Redirect script or message goes here
exit;
}
else
{
everything else here.

}

Hope that helps

[nelsonm]

thanks,

I guess i'll have to do a little more research and think about it some more.

[rocknbil]

1. Is it better to use a separate login/access table then adding login/access fields to the user/employee table?

I say yes. As the resources grow, there may be different resource assignments, or even specific access. Take, for example, a school. Teachers only access classes for which they are teaching. If they teach three classes, you would want to give them access to those classes (resources) at some predefined level." Let's say the levels are 0=student, 1=teacher, 2=manager, 3=admininstrator . . . you would have values like

userid|class|group|acc_level
1234|12|0|0 (student)
1235|12|3|1 (teacher)
1236|12|2|2 (manager)
1234|12|3|3 (administrator)

In that example, the manager does not have access to class with id 12, because he/she accesses only classes assigned to group 3.

This allows your resources and access levels to be infinite, change at any time, and not require changes to the database or if planned well, even changes to the programming.

The exception of course is the superuser, to which these access levels mean nothing. So you may have a single field in the users table for superadmin, set it as 1 or 0.

[nelsonm]

rocknbil

i appreciate the example but i just don't follow.

the manager does not have access to class with id 12, because he/she accesses only classes assigned to group 3.

can you explain further?

[rocknbil]

Well . . . that was just an example, typed quickly. What it demonstrates is that class 12 may be associated with multiple groups, and the manager may be assigned to group 2, but would only access class 12 **if** it has been added to group 2. Here's a (more correct and complete) example, tables groups, classes, etc.

This may seem beyond the scope of your project, but may get you thinking about expandability and ability to change the parameters on the fly. Technicians may be limited to work orders, but what if the tech manager needs to see all work orders? You now need to bring in the concepts of group assignment. Refining the school example,

class_access
id|userid|class|acc_level
1|1234|12|0
2|1235|12|1
3|1236|12|2
4|1237|12|3
5|1234|13|0
6|1235|13|1
7|1236|13|2
8|1237|13|3

group_access
id|user_id|group_id|acc_level
1|1236|2|2
1|1235|5|1
1|1237|3|3
1|12311|2|1

classes
id|instructor|title
12|1235|Sociology
13|1238|Programming 101

class_groups
id|class_id|group_id
1|12|3
1|12|2
2|13|4

access_levels
id|level|title
1|0|Student
2|1|Instructor
3|2|Group Manager
4|3|Administrator

groups
id|title
2|General Instruction
3|Social Sciences
4|IT/Programming

users
id|fname|lname
1234|Joe|Student
1235|Wise|Instructor
1236|Group|Manager
1237|Power|Adminstrator
1238|Tech|Instructor
12311|General|Tutor

class_access table:

1|1234|12|0 Joe Student has student access only to Sociology as a student.

2|1235|12|1 Group Manager has access to Sociology as an instructor, even though they are not the assigned instructor.

3|1236|12|2 Group Manager has access to any group assigned to "group 2", but would not have access via the social sciences group (3), it's only because Sociology has been added to a second group, General Instruction (2), and he/she has access as a Group Manager via that group.

4|1237|12|3 Power Administrator has administrator access to Sociology via both their group and direct assignment as administrator of Sociology. Why you'd do this? Say you remove Sociology from group 3, or remove Power Administrator from the Social Sciences Group. Power Administrator still has administrative access to Sociology via the direct assignment.

5|1234|13|0 Joe Student has student access only to Programming 101 as a student.

6|1235|13|1 Wise Instructor has instructor access to Programming 101, but note also they'd have instructor access to any class in the (undemonstrated) group 5.

7|1236|13|2 Group Manager has group manager access to Programing 101 via both group and class assignment, as above. This may seem redundant, but the same thing applies: remove access to group or direct class assignment and one or the other will persist. The idea is you have a fliud assignment of various access levels,

8|1237|13|3 Power Administrator has been assigned as admin for this class, but note they have no group entry. Their power admin access only applies to Programming 101, no other classes in group 4 (but DOES apply in social sciences and Sociology as above.)

group_access table:

The above covers all of these except this one:

1|12311|2|1 General Tutor has no direct class assignment, but is a tutor for any class in General Instruction (currently only Sociology)


I may have some typos, and there does exist the potential for redundant data, but hopefully you'll get the gist. You'd want a fluid assignment by group or specific resource, then in your programming, determine which resources are accessible via group or specific resource (class, in this case) and assign levels.

You can also see how easily you can add classes, different access levels, and different groups without restructuring your database. In your case, the three components could be the "classes," the three levels of access are the groups. You could then, say, assign a technician to a group - "IT issues." The possibilities are endless.